http://bugzilla.novell.com/show_bug.cgi?id=512695 User suse@tlinx.org added comment http://bugzilla.novell.com/show_bug.cgi?id=512695#c2 L. A. Walsh changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from L. A. Walsh 2009-09-19 17:43:20 MDT --- 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* .. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=512695 User jsrain@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=512695#c4 Jiri Srain changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #4 from Jiri Srain 2009-09-22 00:42:21 MDT --- 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. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=512695 L. A. Walsh changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |541257 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.