Bugzilla – Bug 512695
grub does not support booting boot-by-label
Last modified: 2009-09-23 00:34:19 UTC
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.
First, booting from a logical volume (sda5+) is not supported (even though it usually somehow works). I understand what you mean, but your suggestion is technically not feasible. Grub's first stage needs to fit in c.a. 440 bytes (1 sector shared with partition table) and be able load further code (2nd stage, filesystem driver, menu, etc.), which is in a partition, which you intend to move. Do you think it is possible to put code which searches all partitions to find the right one into that limited amount of memory? The EFI architecture, which is present in some (still rare) x86_64 computers, allows to select device to boot from at the boot time, the i386 architecture doesn't allow anything similar.
I'm sorry for not getting back to this sooner. I have limited time at my computer at times, and have too many interrupts come in that require attentions. If I may, I'd like to comment on this in terms of a dialogue, -- it may not be easily fixable, but that doesn't mean it isn't a design flaw. Design flaws shouldn't be brushed away or ignored because they are hard to fix. The idea of moving to not using partition names like hd1a, sd1a, was to create portability. I had a situation, where I moved a labeled partition from one space to another. I changed the labels and set my system to boot via labels (which only works if you first load a ramdisk containing udev code that can create /dev with mappings for the GUID's and labels to the real device names, which, on legacy boot systems is still "hdax or sdax" (mine are all sdax, btb). So at a high level, moved my "Boot" partition (labeled "Boot"), to a larger partition (there's no reason, BTW, why it shouldn't boot from any partition, primary or extended -- linux != Windows...Windows may have that restriction, but we shouldn't limit ourselves to the windows world's constraints). Regardless, my point was that my new partition wasn't used for booting. The old partition ws now named "OBoot" -- and was no the valid named partition to boot from. This is a horrible situation to put users in -- we are 'fostering' the idea of using labels or ID's, but then those labels are ignored when booting. NOTE: this IS NOT the case with lilo. Since you have to run lilo after you install your kernel images -- and from your current system, it knows to boot from the correct partition. This is a BIG BUG specific to grub. If it confused lilo as well, I'd be less adamant about it being a design flaw with grub that needs to be addressed. Just because it is 'hard' doesn't make it not a bug. There is a work around -- go with lilo -- because it works. Yeah, Grub is the all new 'shiny bootloader' with sparkles that users are being pushed to migrate to. BUT -- I point out -- that grub also has problems with Journalled Filesystems -- especially XFS. So what was the response of some OpenSuse developers: to say XFS was no longer officially supported -- because of GRUB bugs. Again -- lilo continues to work with XFS. Do you see a pattern here? There are multiple problems with Grub that are not being addressed. Yet because someone's insistence on using grub, they get rid of or allow horrible bugs to exist because they are too hard to fix in 'grub'...that should tell you something when 'lilo', a more reliable and older (but no where near as flashy, I admit!) loader still works. If grub doesn't work or is broken or hard to fix, then it's a grub bug and it should be deprecated. Lilo, and eventually Elilo (maybe they'll be merged, hopefully?). Should remain as standards. They are reliable and don't have these bugs. Note -- my system(s) may have (appear to have) the extended boot support -- but the claim is I'd have to reformat my disks and restart from scratch. Ick! Not a nice upgrade path. Please note -- this is *directly* tied to bug 513004 (https://bugzilla.novell.com/show_bug.cgi?id=513004). It was the same "incident" that caused this bug and it. In that bug, I reported that the 'yast' tools saw my system and modified the boot-menu in my NEW partition (the one labeled "Boot')...and claimed to do modifications to install tools and boot options there -- even installed a new boot sector in "Boot" for me. Unfortunately, 'grub' was still booting from "oboot". They wanted a bunch of logs I didn't think I had anymore :-(, so I never responded...*sigh* ...
This looks a lot like a dupe of P2 bug 483136 on Factory.
As I wrote, this is result of the way systems are booted, which was designed dozens of years ago. With this architecture, it is not hard to fix, it is impossible from the reasons I wrote (anyway, if you can create a code which looks through the partitions and finds the right one according to label in addition to current functionality and which fits into 440 bytes, we can discuss ways to improve the behavior). The solution for your problem may be EFI, which is present in newer machines (but not all); there firmware allows you to boot from _any_ partition (there is restriction on the filesystem though), therefore you can move your (in this case) /boot/efi wherever you want to and can boot, but the legacy boot architecture does not allow to achieve what you require. Anyway, even EFI menu entries, which fit to bootloader configuration, refer to a particular partition (and, again, it is the way firmware was designed) There is a design difference between LILO and GRUB - LILO translates the UNIX path to blocks on the configuration time (therefore you don't even need to keep the label), GRUB has the partition in the configuration file which is being read at the boot time. Both have their advantages and disadvantages, if you want to challenge the GRUB approach, I suggest you should discuss this with upstream GRUB developers.
If this isn't supported, then why is it referred to as working, *** This bug has been marked as a duplicate of bug 483136 ***