http://bugzilla.novell.com/show_bug.cgi?id=505546
User Winfrid.Tschiedel@ts.fujitsu.com added comment http://bugzilla.novell.com/show_bug.cgi?id=505546#c500322
Summary: Grub fails to write bootrecord on dmraid disk (GPT labeled) Classification: openSUSE Product: openSUSE 11.2 Version: Milestone 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: Winfrid.Tschiedel@ts.fujitsu.com QAContact: jsrain@novell.com Found By: ---
Created an attachment (id=293215) --> (http://bugzilla.novell.com/attachment.cgi?id=293215) saved installation logs
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tablet PC 1.7; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; MS-RTC LM 8; InfoPath.2)
I tried to install openSUSE 11.2 Milestone 1 on Fujitsu Primergy RX220 ( Promise FastTrak TX 150 S4 ), one disk with RAID0, GPT labeled ( Same problem exists also on Fujitsu Primergy rx200s4 with ESB2 (LSI Firmware) and one disk RAID0. Installation works until the boot record should be written. In case of rx220 the boot record should be written to the root partition. Beside the error 22: No such partition also the MBR was destroyed.
Reproducible: Always
Steps to Reproduce: 1. Installed openSUSE 11.2 on fake raid with GPT
Actual Results: No boot redord was written
Expected Results: Correct operation, install a system which can be booted afterwards
In the latest release of fedora 11 (Preview) almost everything works out of the box, which means only manual interaction for the following items is needed : mklabel gpt (no botton for writing new partition table!) mkinitrd on distribution is in error
for details please read #500322 (bugzilla.redhat.com)
I tried to write a new bootrecord with fedora 11 - which worked - but openSUSE 11.2 cannot handle this bootrecord - so chainloading failed .
Next I tried to load the openSUSE boot menu with configfile /boot/grub/menu.lst So I could start openSUSE 11.2, but boot fails because root partition is not found. This seems to be similar to #500979 - with one difference that at that time (SLED 11) only the problem on ESB2 occurred. There is also a second difference, in the previous edition (openSUSE 11.1,SLED 11) there was a problem with GPT and dmraid, which ended up, that the RAID information was destroyed (please see #436825 )
http://bugzilla.novell.com/show_bug.cgi?id=505546
Jozef Uhliarik juhliarik@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |ASSIGNED
http://bugzilla.novell.com/show_bug.cgi?id=505546
User juhliarik@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=505546#c2
Jozef Uhliarik juhliarik@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juhliarik@novell.com AssignedTo|juhliarik@novell.com |duwe@novell.com
--- Comment #2 from Jozef Uhliarik juhliarik@novell.com 2009-05-28 06:40:21 MDT --- Short summary from log: - installation GRUB on "/" partition in this case /dev/mapper/pdc_cbbgheicjb_part3 - change boot flag - without any changes MBR
Configuration is valid but Winfrid manually deselect checkbox for installing generic boot code to MBR. It is not risk if Winfrid know what he did and if he want manually add chainloader/configfile to other installed system. (Boot from other installed OS)
Result: - installation GRUB to "/" partition -> fault - changing boot flag -> fault
It seems that grub has problem with device mapper and GPT. Reassing to Duwe it is GRUB issue. Maybe there are troubles with GPT table but I didn't modify it and partition for installing GRUB is partition number 3. In this case configuration is valid.
Next error output from installing GRUB:
command: setup --stage2=/boot/grub/stage2 --force-lba (hd0,2) (hd0,2) quit
error output:
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> setup --stage2=/boot/grub/stage2 --force-lba (hd0,2) (hd0,2) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0,2)"... failed (this is not fatal) Running "embed /boot/grub/e2fs_stage1_5 (hd0,2)"... failed (this is not fatal) Running "install --force-lba --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0,2) /boot/grub/stage2 p /boot/grub/menu.lst "... failed
Error 22: No such partition grub> quit
device map: (it is valid) (hd0) /dev/disk/by-id/raid-pdc_cbbgheicjb (fd0) /dev/fd0
http://bugzilla.novell.com/show_bug.cgi?id=505546
User Winfrid.Tschiedel@ts.fujitsu.com added comment http://bugzilla.novell.com/show_bug.cgi?id=505546#c3
--- Comment #3 from Winfrid Tschiedel Winfrid.Tschiedel@ts.fujitsu.com 2009-05-28 07:07:33 MDT --- Please check also #474264
On fedora 11 there is no limitation with GPT ! There seem to be enhancement on grub compared with grub on SLES, openSUSE and fedora 10.
http://bugzilla.novell.com/show_bug.cgi?id=505546
User Winfrid.Tschiedel@ts.fujitsu.com added comment http://bugzilla.novell.com/show_bug.cgi?id=505546#c4
--- Comment #4 from Winfrid Tschiedel Winfrid.Tschiedel@ts.fujitsu.com 2009-05-29 03:37:49 MDT --- Just to give you an update -
in the meantime I succeeded to install openSUSE 11.2 Milestone 2 ( the only thing I changed, was that I was writing the bootrecord to MBR ) Later I could write the bootrecord to the partition and boot the system with chainloading .
The only thing which still does not work is write a bootrecord to a partition with partition number 4 and higher, which is in the meantime supported by fedora 11.
http://bugzilla.novell.com/show_bug.cgi?id=505546
User ByteEnable@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=505546#c5
--- Comment #5 from Robert Thomas ByteEnable@gmail.com 2009-10-10 19:09:41 MDT --- It's still broken as of 11.2 M8. It fails with attempting to install grub when using the "boot from partition" As stated earlier, I had to use the "boot from MBR" option and then subsequently use the rescue system. Rescue system has no problem installing the boot loader with the boot from partition option.
http://bugzilla.novell.com/show_bug.cgi?id=505546
http://bugzilla.novell.com/show_bug.cgi?id=505546#c6
Torsten Duwe duwe@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|duwe@novell.com |yast2-maintainers@suse.de
--- Comment #6 from Torsten Duwe duwe@novell.com 2010-03-11 13:43:07 UTC --- You must not copy all GPT partitions into the compat MBR, but _only_ those required for booting or use by old OSes.
http://bugzilla.novell.com/show_bug.cgi?id=505546
http://bugzilla.novell.com/show_bug.cgi?id=505546#c7
Stefan Schubert schubi@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |schubi@novell.com AssignedTo|yast2-maintainers@suse.de |juhliarik@novell.com
--- Comment #7 from Stefan Schubert schubi@novell.com 2010-03-11 15:07:04 UTC --- Josef, please have a look again.
http://bugzilla.novell.com/show_bug.cgi?id=505546
http://bugzilla.novell.com/show_bug.cgi?id=505546#c8
Jozef Uhliarik juhliarik@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |duwe@novell.com
--- Comment #8 from Jozef Uhliarik juhliarik@novell.com 2010-03-12 09:25:15 UTC --- Torsten could you better explain your comment#6? IMHO configuration of GRUB settings:
setup --stage2=/boot/grub/stage2 --force-lba (hd0,2) (hd0,2) quit
is clear and valid for using GPT.
Please write more details what is wrong on configuration (hd0,2) (hd0,2).
http://bugzilla.novell.com/show_bug.cgi?id=505546
http://bugzilla.novell.com/show_bug.cgi?id=505546#c9
Torsten Duwe duwe@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED CC| |duwe@novell.com Info Provider|duwe@novell.com |
--- Comment #9 from Torsten Duwe duwe@novell.com 2010-03-12 12:28:19 UTC --- The GPT allows for an arbitrary number of coequal partitions. The MBR only has room for 3 (plus one protecting the GPT data area).
First: do not simply copy GPT partition 1,2,3 into MBR 1,2,3; use only those required for booting or for legacy OSes.
Second: check which partition index grub will use: the GPT or the MBR. I must admit I haven't tested / looked this up yet.
Conclusion: there's a 50% chance (hd0,2) is not what you think it is.
http://bugzilla.novell.com/show_bug.cgi?id=505546
http://bugzilla.novell.com/show_bug.cgi?id=505546#c12
Alexander Graf agraf@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED CC| |agraf@novell.com Info Provider|agraf@novell.com |
--- Comment #12 from Alexander Graf agraf@novell.com 2010-03-15 15:01:48 UTC --- GPT syncing isn't as easy as it sounds. If we only sync boot partitions we have a different disk layout with GPT than with MBR. So all assumptions on the enumeration just fail.
My parted patch just tries to sync the first partitions. If there's no EFI driver partition, it adds a fake entry as entry 4 because otherwise Linux wouldn't load the partition table as GPT.
So you definitely end up with at least partitions 0, 1 and 2 being sync'ed. If you're on a Mac (or have an EFI partition), you also get partition 3 synced. That's all we can sync to the MBR because it only allows for 4 entries.
Hence I'm having a hard time understanding what exactly the issue here is. Maybe kpartx screws up the GPT detection?
http://bugzilla.novell.com/show_bug.cgi?id=505546
http://bugzilla.novell.com/show_bug.cgi?id=505546#c13
Petr Uzel puzel@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|puzel@novell.com |duwe@novell.com
--- Comment #13 from Petr Uzel puzel@novell.com 2010-03-29 11:29:17 UTC --- (In reply to comment #12)
GPT syncing isn't as easy as it sounds. If we only sync boot partitions we have a different disk layout with GPT than with MBR. So all assumptions on the enumeration just fail.
I agree. And I don't get how the way syncing is done might cause the grub failure.
As for the booting from GPT partition with no>3, IMHO the proper solution is to make grub understand GPT labels, as well as prefer GPT table if there is hybrid GPT/MBR header. There is a 'grub-read-gpt' - maybe something is wrong with this patch?
Maybe kpartx screws up the GPT detection?
I don't think so: I've created GPT-partitioned dmraid array with hybrid GPT/MBR header (with parted). AFAICT kpartx -a -p _part $dev correctly detected GPT and created the correct dm maps.
http://bugzilla.novell.com/show_bug.cgi?id=505546
http://bugzilla.novell.com/show_bug.cgi?id=505546#c14
Torsten Duwe duwe@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|duwe@novell.com |agraf@novell.com
--- Comment #14 from Torsten Duwe duwe@novell.com 2010-03-29 12:06:22 UTC --- Sorry, grub is 32-bit all the way through. Teaching it 64-bit block numbers is beyond my current resources.
Alex, your code needs to be smarter about which GPs to copy! The first MBR partition entry protects the GPT, the other 3 are free to be used.
Different views on partition numbers is nothing new, and deliberately accepted by the uefi consortium :-( We'll need to deal with that, later...
http://bugzilla.novell.com/show_bug.cgi?id=505546 http://bugzilla.novell.com/show_bug.cgi?id=505546#c16
Alexander Graf agraf@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |WONTFIX
--- Comment #16 from Alexander Graf agraf@suse.com --- Closing as per request.