Monday, October 29, 2012

Getting ready for Ringtail

With the news that the Ubuntu 13.04 Raring Ringtail repositories are in place, I decided to try a different approach this time to using the development release. Usually, at some point in the cycle, I'll try out an upgrade - and if it seems usable - I'll keep it (I always have a full backup just in case).

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:


2 comments:

  1. I have three wubi installations on lots of my machines.

    I 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.

    ReplyDelete
    Replies
    1. 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.

      Let me know how it goes with the grub-mkimage edits.

      Delete