[Discuss] ubuntu quirks, UUID and all that!

[John Blomfield]

Sorry to bore everyone with all my problems (below) but a simple 
solution is now at hand.  Dear old SuSe pointed the way!  Most distros 
generate their menu.lst file items for other distros on the system like:

title        Ubuntu 7.10, kernel 2.6.22-14-generic
root        (hd0,2)
kernel        /boot/vmlinuz-2.6.22-14-generic 
root=UUID=19a47c32-55d2-4905-9ebf-ed3ea21f306e ro quiet splash
initrd        /boot/initrd.img-2.6.22-14-generic
quiet

but SuSe does like this:

title        Ubuntu 7.10, kernel 2.6.22-14-generic
root        (hd0,2)
configfile /boot/grub/menu.lst

which enters the menu options set on each distro!!!!!!!!! (I've not come 
across the grub command configfile before but its right there in the man 
page)  All that remains to be done (just once) is to eliminate all the 
items on these sub-menus other than the default and perhaps fail safe 
items, set the time out to 1 second and it flips straight into the 
distro you want.  Kernel upgrades and UUID changes then can occur in 
each distro independently with out screwing up the main menu. :) :) :)

Another thing that was confusing me is that Ubuntu tends to mount every 
ext3 partition on your system by default in you fstab file using UUID's 
and for some reason it could not "resolve" the UUID for the SuSe 
partition but commenting it out as Patrick did solved that problem as 
there was nothing wrong with that partition's file system according to SuSe.

John


John Blomfield wrote:
> Thanks, Mike and Patrick, your's was the sort of thoughtful insight I 
> was looking for.  Your points have lead me to the following:
>
> There are many ways to obtain a partition's UUID (Universal Unique 
> Identifier) e.g.
>
> vol_id -u /dev/sdxx
> blkid
> udevinfo -g env -n /dev/sdxx
> ls -l /dev/disk/by-uuid
>
> and you can search for a UUID and LABEL with findfs (option), where 
> option is LABEL=xxxxx or UUID=xxxxxxxx
>
> to manually set a UUID or LABEL you can use tune2fs (options)
>
> I am getting to the bottom of my problem with multi-boot systems. If 
> you have Ubuntu by itself or just with Windows and you dual boot from 
> the Ubuntu partition /boot/grub/menu.1st there is no problem.  You 
> don't even know the UUID is there in the menu.1st and fstab files or 
> need to know how it got there.  However, if you add another distro to 
> a different partition you have two choices, one is to not allow the 
> new distro to replace the MBR, then manually add a item in the 
> Menu.1st file in the Ubuntu partition.  The other option is to let the 
> new distro replace the MBR.  This also causes the new disto to scan 
> all the partitions for OS's and build a menu.1st file for its 
> /boot/grub directory.  This second method falls down with some distros 
> because they don't "do" UUID's and therefore the menu item for Ubuntu 
> will be minus its UUID.  Probably because Ubuntu is a derivative of 
> Debian it does it correctly even though Debian does not use UUID's 
> itself?  So the first method of modifying the Ubuntu menu.1st would 
> appear to be best but tedious.  With the second method you can of 
> course manual edit the new distro's menu.1st file and add the UUID for 
> Ubuntu if its not there.
>
> The menu.1st file is not generated by grub, its just used by grub to 
> boot the system.  The menu.1st file is generated by the distro system 
> and I believe some of my experiences have been because Ubuntu changes 
> the UUID ( on the partition, the fstab and menu.1st of course to be 
> consistent within itself).  In my efforts to recover from a boot 
> failure which was not understood at the time I lost all the evidence 
> and ended up re-installing Ubuntu.  Reading the forums and blogs on 
> the subject it may be Ubuntu changes UUID when it updates the kernel 
> version or possibly based upon time or number of boots.  This all 
> sounds pretty mystical and improbable so now I have a clean Ubuntu 
> installation I can monitor the UUID for changes and know what I'm 
> looking for.  None of this of course matters a jot as long as you just 
> boot from Ubuntu's menu.1st file.
>
> However, this opens up another wider problem with multi-boot systems 
> that I had not foreseen!  All distro's when they update the kernel 
> tend to change the vmlinuz file name and the initrd image file name.  
> Some distro's replace these files and some just add the new kernel 
> files.  They also change the menu.1st file to add or replace the new 
> boot items.  Hence, if you have a computer with more than one Linux 
> distro or even more than one version of the same distro, and you 
> update the kernel of the distro whose boot menu.1st is NOT the one 
> that actually boots the system then you will get boot failure until 
> you also update manually the appropriate menu.1st file.
>
> My conclusion then is that I need to write a program or script that 
> after each successful boot, perhaps just before shutdown or after an 
> update, will scan the the /boot directory and check for changes in the 
> vmlinuz and initrd files.  If they change then mount the partition 
> with the controlling menu.1st file and update the boot items in it.  
> This would also catch changes in the UUID.  Stay tuned!
>
> John
>
>
>
>
>
>
> Patrick wrote:
>> On Sun, 23 Mar 2008 20:58:38 -0700
>> John Blomfield wrote:
>>
>>  
>>> Ok, all you Ubuntu experts,
>>>     
>>
>> Not me, but here goes...
>>
>>  
>>> what's all the root=UUID=someverylongnumbersequence in the grub 
>>> menu.1st file and the fstab mount file.  I realize its some number 
>>> to do with identifying the partition but it really screws up 
>>> mult-boot systems.  What's it for and why is that Ubuntu is the only 
>>> distro that seems to use it, including Debian.  The UUID seems to 
>>> change with changing kernel and prevents booting, can you just 
>>> change to root=/dev/hdxx in both the fstab and menu.1st files or 
>>> does it crop up elsewhere??  I've googled for hours and can't find a 
>>> straight answer just lots of bug complaints!!
>>>     
>>
>> That's what I did, but that doesn't necessarily mean it's a good
>> idea.  ;-P
>>
>> Their reasons for favouring UUID have something to do with
>> the /dev/hdxx and /dev/sdxx naming conventions changing sometime
>> down the road, to accommodate SATA or something like that.  It's
>> supposed to make some future upgrade go smoother.
>>
>> In the meantime it's a nuisance, and it kept my swap partition
>> from working properly, and with only 160 MB of physical RAM, I
>> really need swap.
>>
>> Anyway, on Xubuntu 6.10 the /dev/hdxx references were present, but
>> commented out.  So I just copied the comments, and commented the
>> UUID=someverylongnumbersequences, and everything seems to work.
>> Kind of.  I think.
>>
>> # /etc/fstab: static file system information.
>> #
>> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
>> proc            /proc           proc    defaults        0       0
>>
>> # UUID=6bbb5d3f-c1e8-4e5b-aca1-acfc24ef6258
>> /dev/hda1       /               ext2    defaults,errors=remount-ro 0 1
>>
>> # UUID=10e21e49-8947-4d54-9965-1edb418db04c
>> /dev/hda2       /boot           ext2    defaults        0       2
>>
>> # UUID=da90d90f-51a2-4cfa-a214-01b0f85f7f9e
>> /dev/hda5       /home           ext2    defaults        0       2
>>
>> # UUID=1c21930b-f8f7-4e1f-bcf3-4f45ac1095ce
>> /dev/hda6       /media/mp6      ext2    defaults        0       2
>>
>> [and so on...]
>>
>>  
>>> John Blomfield
>>>     
>>
>> Patrick.
>>
>>   
>
> _______________________________________________
> Discuss mailing list
> Discuss at vlug.org
> http://ladybug.vlug.org/cgi-bin/mailman/listinfo/discuss
>