I cloned this bug to change the title and emphasis, as my meaning, overall isn't clear.

Lilo supports boot-by-label -- despite the comments below that "grub cannot because of limitations in the PC architecture".  If lilo can support boot by label, then so can grub.  If grub cannot.  Then grub is BROKEN and this bug should NOT be closed out.  Either grub should be fixed or removed as the default bootloader.  

Second problem is that grub doesn't work well with journaling file systems -- most notably 'xfs', which was 'deprecated' because _grub_ was broken.  Xfs works fine with 'lilo'.  So again, say either grub should be fixed, or the choice of default bootloader should revert to lilo (and maybe Elilo on EFI Boot machines -- maybe lilo and elilo will be merged?  Hopefully?).


Grub *could* keep a mapping that's updated at each boot and any time a disk label is changed (maybe 'fam' send a notification or an event could be generated on the 'dbus' to notify scripts to update any boot managers of a label change?)  These items are not impossible to do.  It's a matter of integration.  

Meanwhile, lilo just seems to work -- assuming you re-run lilo if you change your boot labels -- grub has no option to make it work with boot label and is thus a 'problem'.

Please don't say it can't be done when it can.


The below happened because I had to change 'boot' partitions.
The new initrd was on the new boot partition, but because grub doesn't
have the ability to understand boot labels (unlike lilo),
it couldn't be updated an still tried to boot from boot images on the
old partition.

-------(original old bug text follows) -- but apparently not the comments associated with the original bug (see there for comments on supposed "impossibility of a fix due to architectural constraints"...to which I say
'pah'! :^)

+++ This bug was initially created as a clone of Bug #512695 +++

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

Much emphasis has been placed on not using fixed device addresses, but to use symbolic labels.  Grub seems to only support using 'fixed' addresses like
'hd(0,1)'.

Needless to say, this entirely defeats the purpose of moving toward addressing
disks by label -- as when disk ordering changes, the identity of hd(0) also changes.



Reproducible: Always

Steps to Reproduce:
1. Create a new system and look at grub's boot menu options, or
2. look at a current system and note that OS's are booted by physical disk hd(x) and partition, hd(x,part). Physically change the order of your disks so what was.
3. In steps 1 and 2, you need to install with, or use a system that is mounting the disks symbolically in fstab.  I use mount by label, (so my fstab specifies
LABEL=Root     /     xfs     noatime,logbufs=8 1 1
LABEL=Var      /var  xfs     noatime,logbufs=8 1 2
Label=Swap     swap  swap    defaults          0 0
Label=Boot     /boot xfs     noatime,logbufs=8 1 2
...etc.

Actual Results:  
My kernel and grub menus were on /boot, which was originally sda2. However, Sda2 wasn't big enough for the number and size of the new kernels I was putting on it.  So I repurposed another partition sda8.  After copying the data from sda2->sda8, then labeling the new partition 'Boot', and relabeling the old partition 'Oboot', 
grub continued to boot from the old partition (which, fortunately, I had not scrubbed yet).

Only by manually changing grub's boot options and forcing it to rewrite the MBR to boot from sda8, or, in 'grubby', hd(0,7), could I get it to boot from the new partition.

Expected Results:  
I expected grub to boot using the partition labeled 'Boot'

Flagging this as critical, since if someone doesn't realize that grub is still booting from the old partition and reformats the old partition before manually updating both grub's config files AND manually enters grub and learns grub sufficiently to have it install a new boot record that points to the new partition, they will have an unbootable system.