Bug 512695

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