[Discuss] ubuntu quirks, UUID and all that!

[John Blomfield]

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