Red Hat Bugzilla – Bug 473157
BUG during installation, forces installer to crash.
Last modified: 2009-06-12 08:11:37 EDT
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to Install Fedora 10
Anaconda not to crash
So, basically. I am installing on a NFORCE5 board with NVRAID. I boot the install image with the "nodmraid" option.
After choosing my language I get a series of popups with the heading BUG.
The bodies of these messages are:
Assertion (last_within_agpt <= disk->dev->length - 2) at gpt.c:685 in function _parse_header() failed.
Assertion (last_within_agpt <= disk->dev->length - 2) at gpt.c:699 in function _parse_header() failed.
Assertion (last_usable <= disk->dev->length - 2) at gpt.c:700 in function _parse_header() failed.
Assertion (last_usable_if_grown <= disk->dev->length - 2) at gpt.c:703 in function _parse_header() failed.
After clicking ignore on each of them, anaconda crashes and the installation halts.
Maybe I missed something - the error looks like you got a RAID disk with a GUID Partition Table. How did you create the GPT ?
I am currently also fighting in the same area and writing bugzilla reports to Novell. In my case I created a GPT under openSUSE 11.1 GMC but it looks like that this GPT is incorrect - pointer to the backup gpt points to a location beyound disk boundary. If I tests this disk under fedora I get the same error.
After this I created a new GPT on my dmraid using fedora 10, now I get at least under fedora no errors, but openSUSE still complains. But there is one other point which bothers me - I allocated with mkpartfs primary ext2 <start> <end> a new partition, which got FS ID 0x105 (msftres) ?!
Fujitsu Siemens Computers
My RAID disk was created by using the onboard nvidia bios extensions.
I did an experiment this weekend and physically disconnected all my SATA drives. After doing so I was able to install successfully.
Fedora 10 is having some issues with raid. Don't know if that is at all related to this parted bug.
Sometimes with gpt it complains because some OSs see the disk being a certain size and place the gpt backup label in a certain offset, but when fedora goes and looks at it, it thinks that the backup should be somewhere else and it blows up. ATM there is a patch being discussed on upstream, but there are still some issues to iron out.
With what application did you create your gpt partition table?, and in what OS?
I will try to answer your questions :
I have 2 systems where I can with SATA RAID :
FSC Primergy rx220 with Promise FastTrak S150 TX4 (which I normally use)
FSC Primergy rx200 s4 ESB2 (LSI Firmware).
openSUSE 11.x and SLES 11 have can already create a GPT in the partitioner
( advanced options ).
But in this case I just started an openSUSE 11.1 installation and switched
to an alternate console and created with parted a GPT and afterwards a /boot and a "/" partition. Afterwards I checked the RAID device with parted
using openSUSE and KNOPPIX ( both case I got the warning that somethings is
wrong with my disk, but with entering Ignore I finally see my partitions on
the RAID device ). With fedora 10 parted abends.
So I removed under KNOPPIX the gpt and did under fedora 10 the same steps as
before under openSUSE. A check under fedora does not report any errors for the partition table, but the FS ID for the partition are strange (0x105). A check under openSUSE or KNOPPIX still tell me that my backup partition table is outside the disk.
Hope it was not too confusing,
ok, I'll give this a look-see and compare the partition tables from knopix, suse and fedora to see If I can reproduce.
To give you an update on the problem GPT + dmraid.
If you have access to SLES11/SLED11 RC2 or openSUSE 11.1 you should
do an installation with one of these distributions :
Do an expert partitioning and write a new partition table (gpt).
As far as I have seen, there was no problem with this installed system.
Now the remarks for fedora 10:
Until now I just managed to install fedora 10 on a system with a
promise fasttrak S150 TX4 -
so fedora has no feature to write a new partition table during installation,
I formatted an empty raid disk from an running fedora 10 with parted.
After this I started on this newly formatted disk a fedora 10 installation,
which now worked also with no problem.
But if you try now to install a fedora as a second distribution you will
run into the problems seen under #1.
(In reply to comment #1)
> Hello Joel,
> point which bothers me - I allocated with mkpartfs primary ext2 <start> <end> a
> new partition, which got FS ID 0x105 (msftres) ?!
Pls stop using code from parted to create File systems. It sucks at doing the right thing :). The suggested way is for you to create the partitions with parted and then create the FS with your FS managing app of choice (which I hope will not be parted).
This will be resolved in the next version of parted-1.9.0. Pls see : http://koji.fedoraproject.org/koji/taskinfo?taskID=1405593. This package is not yet in rawhide, but will be in shortly.