https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c2 --- Comment #2 from Torsten Duwe 2011-10-31 09:00:58 UTC --- Correct. While I agree that Jon's experience is rather unpleasant, the behaviour is IMHO correct. The vast majority of users have no idea about the difference between a binary package and the glue that sticks beneath the bottom of the file system to make it boot; they'll just "update the boot loader". OTOH, a working grub2 in the system should somehow signal its ancestor that it is not actively needed any more. Maybe the config file should be renamed to /etc/grub2.conf. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c4 --- Comment #4 from Jon Nelson 2011-10-31 13:31:33 UTC --- Might I respectfully offer an alternative? It seems to me that, under normal circumstances, the (package) installation of a bootloader and the /setup/ (install binary bits in the MBR or whatever) are very different steps, especially considering none of the other bootloaders install themselves (syslinux, lilo, grub2). Furthermore, under normal circumstances doesn't the "installation system" take care of bootloader installation? How do the values in /etc/sysconfig/bootloader control how and when the bootloader is installed or updated? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c6 --- Comment #6 from Jon Nelson 2011-10-31 14:28:04 UTC --- I don't believe that it's true for other packages. Does installing a new syslinux rpm or a new grub2 rpm actually update the bootloader itself (akin to 'grub2 install /dev/sda' or some such)? The reason that grub was reinstalled in the first place was to meet some dependency due to 'zypper dup' -- since I already had grub2 installed and working it really surprised me that grub simply installed over it, the result being a non-working system. I would be equally surprised if simply /installing/ syslinux or lilo would overwrite an existing bootloader. I see that /etc/sysconfig/bootloader has all of the config options I'd expect (including LOADER_LOCATION=none to prevent any post-install). Is grub honoring /etc/sysconfig/bootloader? If I set the LOADER_TYPE to grub2 will re-installing grub overwrite the boot sector/bootloader ? I might suggest that asking grub/grub2/lilo/syslinux/whatever to conform to the *user* preferences in /etc/sysconfig/bootloader is ideal. Furthermore, and this is a bit of a pipe dream, it'd be nifty if 'grub2-install' and 'grub-install' (and others) would grump if they are being used and /etc/sysconfig/bootloader is *not* the same value (by that I mean if I use grub2-install with /etc/sysconfig/bootloader set to use lilo then I'd think if nifty to see a warning message: WARNING: /etc/sysconfig/bootloader configured to use lilo, not grub2. Continue?" ) I hope I am expressing myself clearly here. Thank you for listening. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c8 --- Comment #8 from Jiri Srain 2011-10-31 15:24:20 UTC --- Actuall, /etc/grub.conf was file I was refering to. If it did not contain information that GRUB1 should install to MBR, it would not (either because the file does not exist, or because it does not tell to install to MBR). Removal and re-installation of the package may be the problem; not sure if we can handle it on package level, if we want to support users switching to GRUB2 manually (there is currently no support in perl-Bootloader), I guess there is no other way. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c10 --- Comment #10 from Michael Chang 2011-10-31 15:45:50 UTC --- (In reply to comment #6)

I don't believe that it's true for other packages. Does installing a new syslinux rpm or a new grub2 rpm actually update the bootloader itself (akin to 'grub2 install /dev/sda' or some such)?

The reason that grub was reinstalled in the first place was to meet some dependency due to 'zypper dup' -- since I already had grub2 installed and working it really surprised me that grub simply installed over it, the result being a non-working system. I would be equally surprised if simply /installing/ syslinux or lilo would overwrite an existing bootloader.

Thanks for the explanation .. can you tell what package depends on grub? Anyway it makes sense to me that the bug was caused by update and dependency,

I see that /etc/sysconfig/bootloader has all of the config options I'd expect (including LOADER_LOCATION=none to prevent any post-install). Is grub honoring /etc/sysconfig/bootloader? If I set the LOADER_TYPE to grub2 will re-installing grub overwrite the boot sector/bootloader ?

Depends on the tools you deal with the bootloader -- generally if you use system wide tools like "update-bootloader" or "yast2 bootloader" they would honor the sysconfig settings. Use package level tools like grub-install would not .. set LOADER_TYPE to grub2 is useless for now .. as it's not ready. Only package level tools provided to work.

I might suggest that asking grub/grub2/lilo/syslinux/whatever to conform to the *user* preferences in /etc/sysconfig/bootloader is ideal.

I agree.

Furthermore, and this is a bit of a pipe dream, it'd be nifty if 'grub2-install' and 'grub-install' (and others) would grump if they are being used and /etc/sysconfig/bootloader is *not* the same value (by that I mean if I use grub2-install with /etc/sysconfig/bootloader set to use lilo then I'd think if nifty to see a warning message: WARNING: /etc/sysconfig/bootloader configured to use lilo, not grub2. Continue?" )

As far as I know these package level tools are not visible to sysconfig settings (They are identical to upstream thus no concepts about "system"), Use it and break the settings is expected.

I hope I am expressing myself clearly here.

YES. Thanks. :)

Thank you for listening.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c12 --- Comment #12 from Jon Nelson 2011-10-31 15:55:26 UTC --- (In reply to comment #10)

(In reply to comment #6)

...

I don't believe that it's true for other packages. Does installing a new syslinux rpm or a new grub2 rpm actually update the bootloader itself (akin to 'grub2 install /dev/sda' or some such)?

The reason that grub was reinstalled in the first place was to meet some dependency due to 'zypper dup' -- since I already had grub2 installed and working it really surprised me that grub simply installed over it, the result being a non-working system. I would be equally surprised if simply /installing/ syslinux or lilo would overwrite an existing bootloader.

Thanks for the explanation .. can you tell what package depends on grub?

jnelson@worklaptop:~> rpm -q --whatrequires grub patterns-openSUSE-base-11.4-6.9.1.x86_64 bootcycle-0.3-234.1.x86_64 jnelson@worklaptop:~>

...

Furthermore, and this is a bit of a pipe dream, it'd be nifty if 'grub2-install' and 'grub-install' (and others) would grump if they are being used and /etc/sysconfig/bootloader is *not* the same value (by that I mean if I use grub2-install with /etc/sysconfig/bootloader set to use lilo then I'd think if nifty to see a warning message: WARNING: /etc/sysconfig/bootloader configured to use lilo, not grub2. Continue?" )

As far as I know these package level tools are not visible to sysconfig settings (They are identical to upstream thus no concepts about "system"), Use it and break the settings is expected.

And that is exactly my point -- the *package* should not be overriding the decisions made at the *system* level. For example, let's say I had set /etc/sysconfig/bootloader to "lilo" -- installing grub, however, would have overwritten the lilo installed bootloader. In the scripts for grub (and others), they ought to 'source /etc/sysconfig/bootloader', and something like this ought to work: source /etc/sysconfig/bootloader LOADER_TYPE=${LOADER_TYPE:-grub} # default is grub LOADER_LOCATION=${LOADER_LOCATION:-mbr} if [ "$LOADER_TYPE" != "whatever-I-am" ]; then exit 0 fi if [ "$LOADER_LOCATION" == "mbr" ]; then ... install to mbr elif [ .... ] and so on. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c14 --- Comment #14 from Michael Chang 2011-11-03 15:57:00 UTC --- (In reply to comment #12)

...

can you tell what package depends on grub?

jnelson@worklaptop:~> rpm -q --whatrequires grub patterns-openSUSE-base-11.4-6.9.1.x86_64 bootcycle-0.3-234.1.x86_64

Thanks. I'll take look on above two packages. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c16 --- Comment #16 from Michael Chang 2011-11-08 08:50:14 UTC --- (In reply to comment #15)

I think it can be fixed.

Sorry. I think it's my misunderstanding that your attempt is to patch tools like grub-install to sync with sysconfig settings.

the rpm postinstall scripts can very easily check /etc/sysconfig/bootloader and stop there if bootloader is not empty or 'grub'.

Yes, it's a way to go. But for your case, it might not work since grub2 is not supported by perl-bootloader. This fix only guarantee that loaders installed by system level tools would not overwritten. To me the question is that why system update would require install grub2 even when you had removed it, in an usual case I think it shouldn't, this seems a bug to me. I checked the two packages which requires it 1. patterns-openSUSE-base In factory the grub is moved from Require to Recommends, so I'd assume that it would not be a problem now (I tried my 12.1 beta1 it didn't require grub) 2. bootcycle Do you explicitly install this package ? or it get default installed? If the later case I thought it's much likely a bug, it should be an optional package if I understand it's usage correctly .. In my 12.1 beta1 this package seems to be default installed but I can't make sure. Anyway we should also consider to solve in a direction that the package update shouldn't require mandatory grub2 update if no valid reason it is required .. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c18 --- Comment #18 from Bernhard Wiedemann 2011-11-24 12:00:10 CET --- This is an autogenerated message for OBS integration: This bug (726836) was mentioned in https://build.opensuse.org/request/show/93422 Factory / grub -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.