With 12.04 Precise Pangolin the development release was really stable so I quite happily used it actively throughout the cycle... but unfortunately it wasn't quite as good with 12.10 Quantal Quetzal and I found that I relied more on my non-wubi 12.04 Edubuntu install (although that wasn't entirely without problems either).
The down side of switching to the development release is that I lose touch with the latest production release , which is more useful in keeping track of current issues, and since I'm not upgrading my Edubuntu machine I want to keep both 12.10 and 13.04 on the same machine (with Wubi).
I already have a Wubi-resize script that will duplicate a Wubi install (and keep it in synch). I've added a custom menu entry to boot the sychronized disk to make sure it's functional. Now I need to be able to switch and run independent Wubi installs (without the tedium of booting to Windows to manually switch the root.disks).
So that led me to my latest testing approach:
1. Duplicate the up-to-date 12.10 install using the Wubi resize script and rename the new.disk to raring.disk
2. Add a custom boot entry for this raring.disk
3. Manually update /usr/share/lupin-support/grub-mkimage on the Raring install to stop it splatting /wubildr whenever there's an update to Grub (which would make the raring intall the default)
4. Turn off Ubuntu One synchronization and other automatic backups on the Raring install
5. Go nuts without worrying about breakage
Here's the custom boot entry (modify the one on root.disk only and change the highlighted bits):
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry 'Ubuntu - Raring Ringtail' --class ubuntu --class gnu-linux --class gnu --class os {
gfxmode $linux_gfx_mode
insmod gzio
insmod ntfs
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 18B4B7BBB4B799A8
loopback loop1 /ubuntu/disks/raring.disk
set root=(loop1)
linux /vmlinuz root=UUID=18B4B7BBB4B799A8 loop=/ubuntu/disks/raring.disk ro quiet splash $vt_handoff
initrd /initrd.img
}
Here's the diff on grub-mkimage (modify the one on raring.disk only):
--- /mnt/usr/share/lupin-support/grub-mkimage 2011-09-20 03:44:44.000000000 -0700
+++ /usr/share/lupin-support/grub-mkimage 2012-10-29 22:02:55.784517389 -0700
@@ -112,7 +112,7 @@
exit 1
fi
fi
-
+exit 0 # for raring test install, bypass creation of wubildr
wubildr_partitions="$(find_wubildr)"
if [ ! -f "$target" ] && [ -z "$wubildr_partitions" ]; then
Now all I have to do is wait for something exciting to happen with Ringtail:
I have three wubi installations on lots of my machines.
ReplyDeleteI flip between the grub.cfg in each partition by 40_custom entries like
menuentry "ubuntu-10.10-netbook configfile" {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set 4caa8dbdaa8da454
loopback loop0e /ubuntu-10.10-netbook/disks/root.disk
set root=(loop0e)
configfile (loop0e)/boot/grub/grub.cfg
}
You will run into problems when the grub version in a target
/boot/grub is sufficiently different from the one you actually
booted with (especially for interactive fixing upping).
I note that you use the symlinks /vmlinuz and /initrd.img.
I'm not sure why that's not mentioned more often as a way to save
typing and ensure you get a fairly recent version of kernel.
As you note, in our scheme kernel or grub updates will "claim" the
wubildr and hence default version. I've recently begun thinking
about making wubildr backups so I can put them back to what I want.
But I'll note your solution to check on tomorrow.
WRT grub version, having both 10.04 and 12.04 caused a problem recently
when a 10.04 entry "claimed" wubildr and therefore 12.04 configfile
was invalid for the grub which was actually running.
I ended up (by mounting other root on a running system) creating a
/boot/grubold directory in the 12.04 loop and put a grub.cfg in there
which was sufficiently old version with a boot of /vmlinuz and /initrd.img
and having in the 10.04 grub.cfg a "configfile" entry similar to the
above referencing /boot/grubold/grub.cfg. Seems you don't actually need
the rest of the grub contents in the grubold directory. Modules and
commands come from the original source.
Doing things it seems it was only vaguely intended we should be able to do.
Yes I avoid the use of configfile because of incompatibility between different grub versions. As long as you use the symlinks to the latest kernel and initrd, you don't really need the whole grub menu for each install (it's easy enough to setup both if you want it now and then). Using different /wubildr files doesn't work for me, because that also requires a reboot into another OS to switch.
DeleteLet me know how it goes with the grub-mkimage edits.