[opensuse-factory] GRUB, instead of gfxmenu

I did updates via zypper dup from download.opensuse.org/factory this AM on one system, and subject was the result. MBR is standard code. Grub is on (hd0,0). Why would any updates have found it necessary to mess with the installed Grub on (hd0,0)? Which update did it? How do I prevent it from happening again? Possible related matter: I use a /boot which is shared between Fedora and openSUSE. As a consequence, I try to avoid letting either mess with Grub at all. To that end, I don't normally mount the /boot partition on /boot. Instead, I automount it on /disks/hda/boot, and when I know something needs (hd0,0) it to actually be on /boot, I remount it there, as when running mkinitrd or installing a new kernel. Also to that end, I've renamed /etc/grub.conf to /etc/grub.conf- to prevent scripts that use that file from tampering with the real boot partition. As a consequence of that, lately the kernel installations have been hampered by e.g what is show here: # Bootsplash: openSUSE (1024x768) # 14840 blocks # 2008-11-20 19:47:51 ERROR: Core::ReadFiles: Failed to open /etc/grub.conf # /boot directory is not mounted. If this is bad detection you can avoid it by 'export PBL_SKIP_BOOT_TEST=1' # error: %post(kernel-pae-base-2.6.27.5-3.2.i586) scriptlet failed, exit status 1 # # 2008-11-20 19:51:55 kernel-pae-base-2.6.27.5-3.2.i586.rpm install failed (Full /var/log/zypp/history at http://fm.no-ip.com/tmp/SUSE/Factory/zypp-history-kt880 ) Note that the "# /boot directory is not mounted..." above is a lie. It may say in /etc/fstab that that should have been the case, but it was not the actual state while the new kernel was being installed. Why does a new kernel installation require anything to access /etc/grub.conf anyway? -- "Love is not easily angered. Love does not demand its own way." 1 Corinthians 13:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2008-11-28 at 16:10 -0500, Felix Miata wrote:
# /boot directory is not mounted. If this is bad detection you can avoid it by 'export PBL_SKIP_BOOT_TEST=1' ... Note that the "# /boot directory is not mounted..." above is a lie. It may say in /etc/fstab that that should have been the case, but it was not the actual state while the new kernel was being installed.
I opened a bugzilla that was solved with that hack (export PBL_SKIP_BOOT_TEST=1). The cause was different that yours, but the solution could be the same. If you are interested I'll post the bug number, but now my dinner is waiting :-)
Why does a new kernel installation require anything to access /etc/grub.conf anyway?
Because it adds a new entry to boot that precise kernel, instead of reusing the "vmlinuz" symlink. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkwYjkACgkQtTMYHG2NR9X9HACeIdqfJT4pmSHXC6soC5UfJV/4 oKEAn3YhycHBtL+shID10SKenlbkZVRb =nWj4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2008/11/28 22:27 (GMT+0100) Carlos E. R. composed:
On Friday, 2008-11-28 at 16:10 -0500, Felix Miata wrote:
# /boot directory is not mounted. If this is bad detection you can avoid it by 'export PBL_SKIP_BOOT_TEST=1'
Note that the "# /boot directory is not mounted..." above is a lie. It may say in /etc/fstab that that should have been the case, but it was not the actual state while the new kernel was being installed.
I opened a bugzilla that was solved with that hack (export PBL_SKIP_BOOT_TEST=1). The cause was different that yours, but the solution could be the same. If you are interested I'll post the bug number, but now my dinner is waiting :-)
Please? :-)
Why does a new kernel installation require anything to access /etc/grub.conf anyway?
Because it adds a new entry to boot that precise kernel, instead of reusing the "vmlinuz" symlink.
The question remains. Boot with openSUSE Grub happens via /boot/grub/menu.lst, not /etc/grub.conf. AFAICT, the latter is a config file for installing Grub's stage* files, which has zip todo with configuring new kernels in Grub's menu. -- "Love is not easily angered. Love does not demand its own way." 1 Corinthians 13:5 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2008-11-28 at 16:51 -0500, Felix Miata wrote:
On 2008/11/28 22:27 (GMT+0100) Carlos E. R. composed:
On Friday, 2008-11-28 at 16:10 -0500, Felix Miata wrote:
# /boot directory is not mounted. If this is bad detection you can avoid it by 'export PBL_SKIP_BOOT_TEST=1'
Note that the "# /boot directory is not mounted..." above is a lie. It may say in /etc/fstab that that should have been the case, but it was not the actual state while the new kernel was being installed.
I opened a bugzilla that was solved with that hack (export PBL_SKIP_BOOT_TEST=1). The cause was different that yours, but the solution could be the same. If you are interested I'll post the bug number, but now my dinner is waiting :-)
Please? :-)
Bug 440337 It may not be related to your problem, but the solution to my problem was to use that variable because boot partition is not detected on a chroot. But you can report your situation, so that they can alter the code and your /boot is detected.
Why does a new kernel installation require anything to access /etc/grub.conf anyway?
Because it adds a new entry to boot that precise kernel, instead of reusing the "vmlinuz" symlink.
The question remains. Boot with openSUSE Grub happens via /boot/grub/menu.lst, not /etc/grub.conf.
Sorry, I read to fast. I confused the file.
AFAICT, the latter is a config file for installing Grub's stage* files, which has zip todo with configuring new kernels in Grub's menu.
Yes, you are right. It should not be altered, I think. Unless grub itself is reinstalled :-? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkwhREACgkQtTMYHG2NR9VDJACfei22F42PYm4iwddB5HErxDBm fLIAoJJs6e6+YBo72WkvzBTyvYhdF73i =m+ul -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Carlos E. R. napsal(a):
On Friday, 2008-11-28 at 16:51 -0500, Felix Miata wrote:
On 2008/11/28 22:27 (GMT+0100) Carlos E. R. composed:
On Friday, 2008-11-28 at 16:10 -0500, Felix Miata wrote:
# /boot directory is not mounted. If this is bad detection you can avoid it by 'export PBL_SKIP_BOOT_TEST=1'
Note that the "# /boot directory is not mounted..." above is a lie. It may say in /etc/fstab that that should have been the case, but it was not the actual state while the new kernel was being installed.
I opened a bugzilla that was solved with that hack (export PBL_SKIP_BOOT_TEST=1). The cause was different that yours, but the solution could be the same. If you are interested I'll post the bug number, but now my dinner is waiting :-)
Please? :-)
Bug 440337
It may not be related to your problem, but the solution to my problem was to use that variable because boot partition is not detected on a chroot.
But you can report your situation, so that they can alter the code and your /boot is detected.
This check is again fstab and /proc/mounts. It is not perfect as /proc/mounts is not perfect. But this is to prevent user which have separated /boot which is not automounted at start to update kernel (without mounted /boot it doesn't work) and because I know that this check is not perfect you can use that variable which prevent check and you are sure that you know what to do.
Why does a new kernel installation require anything to access /etc/grub.conf anyway?
Because it adds a new entry to boot that precise kernel, instead of reusing the "vmlinuz" symlink.
The question remains. Boot with openSUSE Grub happens via /boot/grub/menu.lst, not /etc/grub.conf.
Sorry, I read to fast. I confused the file.
AFAICT, the latter is a config file for installing Grub's stage* files, which has zip todo with configuring new kernels in Grub's menu.
Yes, you are right. It should not be altered, I think. Unless grub itself is reinstalled :-?
This is bad behavior of post-install script, which call update bootloader. Other bootloader like lilo, elilo, powerlilo need it and grub use it's standard routine for it (which also rewrite its position). If you file bug I can try change it. What I am not sure is if after update grub is needed rewrite boot code and if this call doesn't use same script, this is not so easy as it looks :) JR, maintainer of perl Bootloader -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (3)
-
Carlos E. R.
-
Felix Miata
-
josef reidinger