[Bug 726836] New: installing the grub /package/ installs the bootloader. Please don't do that!
https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c0 Summary: installing the grub /package/ installs the bootloader. Please don't do that! Classification: openSUSE Product: openSUSE 12.1 Version: RC 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader AssignedTo: jsrain@suse.com ReportedBy: jnelson-suse@jamponi.net QAContact: jsrain@suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 I have been using grub2. it works well. I had removed grub, but last night zypper re-installed it. This morning, I had a non-booting machine trying to use grub1 but without any configuration. Please don't install the /bootloader/ when the /package/ is installed. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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#c1 Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jsrain@suse.com |duwe@suse.com --- Comment #1 from Jiri Srain <jsrain@suse.com> 2011-10-31 06:38:20 UTC --- I guess that GRUB behaves depending on existence/contents of /etc/grub.conf. Meaning, if you remove this file, it does not know where to install itself. Torsten? -- 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#c2 --- Comment #2 from Torsten Duwe <duwe@suse.com> 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#c3 Torsten Duwe <duwe@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |duwe@suse.com AssignedTo|duwe@suse.com |mchang@suse.com Summary|installing the grub |grub package installation |/package/ installs the |destroys working grub2 |bootloader. Please don't do |setup |that! | --- Comment #3 from Torsten Duwe <duwe@suse.com> 2011-10-31 09:05:06 UTC --- Yast should take care of the step mentioned above. I might as well add a "conflicts: grub2" to the spec, just to be sure. -- 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 <jnelson-suse@jamponi.net> 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#c5 Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsrain@suse.com --- Comment #5 from Jiri Srain <jsrain@suse.com> 2011-10-31 13:57:41 UTC --- Jon, the alternate view is following: When you have GRUB installed and want to update it, you typically want 'rpm -U grub.rpm' to do everything for you. This is true for other packages as well, you don't need anthing else than update the package itself, if it is packaged correctly. With GRUB it is the same. If you just update the package, without installation, it was useless. That's why GRUB behaves the way it does. If you want to avoid installing it, just tell it not to install. It must read where to install to anyway, or do you think it always install to MBR regardless the configuration? -- 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 <jnelson-suse@jamponi.net> 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#c7 --- Comment #7 from Michael Chang <mchang@suse.com> 2011-10-31 15:13:32 UTC --- Jiri, I agreed with you, without installation(or setup) we can't have the updated fix effective, say if the fix was in stage1 or stage1.5 :) However I think Jon's problem was that grub installed regardless of the current loader setting (in his case would be grub2). I know .. grub2 is not supported in perl-Bootloader, not to mention the yast2 bootloader, we might have to blame on it. Even grub2 is not a valid "loader type" entry in sysconfig IMO. But my concern is that even we do support grub2 in not only packaging level but also in system level(say system settings would be effectively manipulated by system wide managing tools like yast2 or update-bootloader), the issue would still persist because in the postinstall scriptlet I see if [ -e /etc/grub.conf ] ; then /usr/sbin/grub --batch < /etc/grub.conf >/dev/null 2>&1 fi It would install the grub by checking existence of /etc/grub.conf which seems not correct to me. When we remove the grub package it was not removed because it was created by system tools/users and thus not belongs to any package. This means it is very likely to overwrite current loader regardless of the settings. I would think it should use update-bootloader in postinstall which would honor sysconfig setting ? or yast takes care it (but this depends on if user install by yast2 bootloader) .. or any other idea? -- 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 <jsrain@suse.com> 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#c9 Jon Nelson <jnelson-suse@jamponi.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jnelson-suse@jamponi.net --- Comment #9 from Jon Nelson <jnelson-suse@jamponi.net> 2011-10-31 15:33:40 UTC --- Don't forget that /etc/sysconfig/bootloader *also* contains preferences for /where/ to install the bootloader (if at all). -- 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 <mchang@suse.com> 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#c11 --- Comment #11 from Michael Chang <mchang@suse.com> 2011-10-31 15:53:54 UTC --- (In reply to comment #8)
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).
Yes.. but the problem is that it did contain some information (seems to be a leftover by last installation) :(
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.
YES. It's hard to tell now since GRUB2 lacks support. JFYI I am working on grub2 perl-Bootloader now (as my hackweek project but not finished).. let's see. :) Thanks. -- 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 <jnelson-suse@jamponi.net> 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#c13 --- Comment #13 from Michael Chang <mchang@suse.com> 2011-11-03 15:46:14 UTC --- (In reply to comment #12)
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.
True, but I don't think we can fix it. :( The principle is that these tools came from upstream, they should work as is, what we usually do is to package them and people use them is **identical** with upstrean. Another principle is that these changes can't get upstreamed, unless they are willing to accept disto specific patches .. It would become maintenance burden if we have to porting these specific patches each time when update newer version(and also test burden to these patches). I would view these tools as building block of systems but not directly touched by normal user .. You could use them, of course, but you are in *expert mode* and you are on your own ... Thanks. -- 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 <mchang@suse.com> 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#c15 --- Comment #15 from Jon Nelson <jnelson-suse@jamponi.net> 2011-11-03 23:51:48 UTC --- (In reply to comment #13)
(In reply to comment #12)
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.
True, but I don't think we can fix it. :(
I think it can be fixed. the rpm postinstall scripts can very easily check /etc/sysconfig/bootloader and stop there if bootloader is not empty or 'grub'.
The principle is that these tools came from upstream, they should work as is, what we usually do is to package them and people use them is **identical** with
Sure, but the /rpm post install scripts/ aren't upstream. -- 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 <mchang@suse.com> 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#c17 --- Comment #17 from Michael Chang <mchang@suse.com> 2011-11-22 08:17:27 UTC --- Hi Jon, I just submitted a patch that tried to fix this issue in a way that you addressed in comment#12, SRID is 92987. Thanks a lot for report & contribute to this issue. -- 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 <bwiedemann@suse.com> 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.
https://bugzilla.novell.com/show_bug.cgi?id=726836 https://bugzilla.novell.com/show_bug.cgi?id=726836#c19 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #19 from Michael Chang <mchang@suse.com> 2011-12-06 02:04:20 UTC --- Resolved fixed as the cause was known and patch was accepted. -- 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.
participants (1)
-
bugzilla_noreply＠novell.com