[Bug 850130] New: bootloader update does not handle MBR in GTP properly
https://bugzilla.novell.com/show_bug.cgi?id=850130 https://bugzilla.novell.com/show_bug.cgi?id=850130#c0 Summary: bootloader update does not handle MBR in GTP properly Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: Linux Status: NEW Severity: Major Priority: P5 - None Component: Bootloader AssignedTo: jsrain@suse.com ReportedBy: ohering@suse.com QAContact: jsrain@suse.com Found By: Outsourced Testing Blocker: --- 13.1 on falla.arch.suse.de The single disk in falla has a GPT label, but just a BIOS. After a zypper dup from 12.3 to 13.1rcN the boot failed, the code in MBR (most likely) loaded incorrect blocks, and the box crashed after jumping into the garbage. After that was fixed up, a few days later another zypper dup updated some packages which triggered the same boot failure. At that time I tried to analyze what happens in the various %post install scripts. The commands I found did not lead to the error for some reason, but maybe I just did not find all of them (or I ran them in wrong order). The very first failure after dup from 12.3 was fixed up by "grub2-install --force /dev/sda". This basically also helped with the second dup. Today I got the packages listed below from the 13.1 repos, and now the box once again fails to boot. I think something is not handling the MBR in GPT case correctly, thats why I opend this bug to track it down and fix it. The following packages are going to be upgraded: apparmor-docs 2.8.2-4.5.1 -> 2.8.2-4.8.1 apparmor-parser 2.8.2-4.5.1 -> 2.8.2-4.8.1 apparmor-profiles 2.8.2-4.5.1 -> 2.8.2-4.8.1 apparmor-utils 2.8.2-4.5.1 -> 2.8.2-4.8.1 branding-openSUSE 13.1-10.4.12 -> 13.1-10.4.13 gfxboot-branding-openSUSE 13.1-10.4.12 -> 13.1-10.4.13 grub2-branding-openSUSE 13.1-10.4.12 -> 13.1-10.4.13 libapparmor1 2.8.2-4.5.1 -> 2.8.2-4.8.1 libcolord2 1.1.2-2.1 -> 1.1.2-5.2 libstorage-ruby 2.24.7-1.1 -> 2.24.8-1.1 libstorage4 2.24.7-1.1 -> 2.24.8-1.1 libwicked0 0.5.2-128.1 -> 0.5.2-144.1 libwicked0-debuginfo 0.5.2-128.1 -> 0.5.2-144.1 perl-apparmor 2.8.2-4.5.1 -> 2.8.2-4.8.1 plymouth-branding-openSUSE 13.1-10.4.12 -> 13.1-10.4.13 sysconfig 0.81.5-2.1 -> 0.81.5-3.1 sysconfig-netconfig 0.81.5-2.1 -> 0.81.5-3.1 sysconfig-network 0.81.5-2.1 -> 0.81.5-3.1 udevmountd 0.81.5-2.1 -> 0.81.5-3.1 wallpaper-branding-openSUSE 13.1-10.4.12 -> 13.1-10.4.13 wicked 0.5.2-128.1 -> 0.5.2-144.1 wicked-debuginfo 0.5.2-128.1 -> 0.5.2-144.1 wicked-debugsource 0.5.2-128.1 -> 0.5.2-144.1 xorg-x11-server 7.6_1.14.3-2.2.1 -> 7.6_1.14.3.901-1.1 yast2-packager 3.0.6-5.1 -> 3.0.8-1.1 yast2-pkg-bindings 3.0.3-7.1 -> 3.0.3-8.1 yast2-qt-branding-openSUSE 13.1-10.4.12 -> 13.1-10.4.13 yast2-storage 3.0.7-1.1 -> 3.0.8-1.1 28 packages to upgrade. -- 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=850130 https://bugzilla.novell.com/show_bug.cgi?id=850130#c1 Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsrain@suse.com AssignedTo|jsrain@suse.com |mchang@suse.com --- Comment #1 from Jiri Srain <jsrain@suse.com> 2013-11-13 07:18:04 UTC --- Michael, is there a chance that update of GRUB2 branding causes this misbehavior? Looking at the list from Olaf, I cannot see any other candidate... -- 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=850130 https://bugzilla.novell.com/show_bug.cgi?id=850130#c2 --- Comment #2 from Michael Chang <mchang@suse.com> 2013-11-13 12:15:57 UTC --- The grub2-branding-openSUSE looks quite innocent to me. It only touches grub.cfg changes and thus no changes to core.img location in file system. I'm no file system expert, could it be possible that the file blocks been moved silently? Using static blocks for booting is really fragile, we need to track all it's changes and update bootloader's block list, otherwise system wont boot. We'd better create bios boot partition thus offer us space to embed core.img. We can therefore eliminate such errors due to file blocks been relocated. Core.img understands file system thus can handle relocation after all .. Or any one could have idea why the blocks would go wrong .. sadly I have no clue now. :( -- 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=850130 https://bugzilla.novell.com/show_bug.cgi?id=850130#c3 --- Comment #3 from Olaf Hering <ohering@suse.com> 2013-11-13 14:46:31 CET --- Its not so much about how the lowlevel stuff is supposed to work, as the following command seems to do the right thing: /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe /dev/sda2 I think "(hd,2)" and sda2 work fine either way. Its more about the things that happen during package update. -- 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=850130 https://bugzilla.novell.com/show_bug.cgi?id=850130#c Arvin Schnell <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|bootloader update does not |bootloader update does not |handle MBR in GTP properly |handle MBR in GPT properly -- 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