Red Hat Bugzilla – Bug 438683
cmdline kickstarts halt when GPT label exists
Last modified: 2008-05-21 11:33:41 EDT
Pulling out install failure when anaconda complains about GPT labelled disks.
+++ This bug was initially created as a clone of Bug #433681 +++
Description of problem:
The disk in question is /dev/sdc which is a 10TB LUN with a GPT label.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Label disk with GPT
2. reinstall node
anaconda should be able to understand GPT labels on ppc.
The partitioning section of my kickstart file is:
clearpart --initlabel --drives=sda
Why is anaconda looking at anything besides sda?
-- Additional comment from email@example.com on 2008-02-20 15:45 EST --
(In reply to comment #0)
> Why is anaconda looking at anything besides sda?
Because we look for any other filesystem labels on the system so we can avoid
those when we label our filesystems.
-- Additional comment from firstname.lastname@example.org on 2008-02-21 12:38 EST --
(In reply to comment #2)
> Because we look for any other filesystem labels on the system so we can avoid
> those when we label our filesystems.
Does anaconda have to stop the installation process when it finds a GPT label
for this? I haven't had any problems reading GPT labels on any platform.
-- Additional comment from email@example.com on 2008-02-21 14:52 EST --
No, you just hit an error for your particular set up. Not sure what's causing
it. We support GPT labels (we have to, that's the only way to go on
Itanium...and on x86 Mac systems).
Can you give me any more information on how to reproduce your problem? How was
the 10TB GPT disk provisioned? Some external source?
-- Additional comment from firstname.lastname@example.org on 2008-02-21 15:01 EST --
It is a 10TB LUN from a FC RAID attached via a LightPulse FC HBA. The GPT label
was applied with parted, pyparted to be more specific. I think there was just
one large partition on the LUN at the time of that install.
-- Additional comment from email@example.com on 2008-03-11 15:22 EST --
Arg, I ran into a similar problem on a new x86_64 cluster with SAN storage
attached which I haven't touched yet.
Parted exceptions can't be handled in command line mode!
/dev/sde contains GPT signatures, indicating that it has a GPT table. However,
it does not have a valid fake msdos partition table, as it should. Perhaps it
was corrupted -- possibly by a program that doesn't understand GPT partition
tables. Or perhaps you deleted the GPT table, and are now using an msdos
partition table. Is this a GPT partition table?
My kickstart file only references /dev/sda. I appreciate your attempt not to
duplicate file system labels, but aborting the install for a partition you can't
read seems silly to me. If anaconda can't read the partition, surely the system
won't when it boots without anaconda.
Here is the latest incarnation of this problem from RHEL5.2-Server-20080320.0:
Can't have a question in command line mode!
/dev/sdc currently has a gpt partition layout. To use this disk for the
installation of Red Hat Enterprise Linux Server, it must be re-initialized,
causing the loss of ALL DATA on this drive.
Would you like to format this drive?
custom ['_Ignore drive', '_Format drive']
If GPT labels are supported, why is anaconda asking me to ignore/format the disk?
Looks like this is limited by archLabels in partedUtils.py. Can we add gpt for
ppc? We need to use GPT on those SAN disks because they are larger than 2TB.
How common is this configuration of >2TB partitions? Is this a ppc only issue?
In terms of trying to identify blockers we need to know if this is a common or
niche scenario, and whether a "don't do that" relnote is an option.
(In reply to comment #3)
> How common is this configuration of >2TB partitions?
It's very common for us because that is the hardware configuration we use in our
test environment. I don't have data on customers' storage configurations, but I
would guess that large lun sizes are going to be more common. The only way to
partition these disks in a cross-architecture manner is with GPT.
> Is this a ppc only issue?
I think so. As stated in comment #2, gpt is not listed as a supported label for
ppc. Nor is it listed for s390.
> In terms of trying to identify blockers we need to know if this is a common or
> niche scenario, and whether a "don't do that" relnote is an option.
It's common in our test environment and will cost us extra time verifying GFS on
I do testing on ppc with SAN devices, and we don't use partitions this large (>
2TB). I do agree with the bug originator, and think that this should be
addressed, and gpt support for ppc should be added, if not for 5.2, for the next
release with a note on release notes.
My understanding is that systems that would require GPT labels are still not
common, but of course the later this is addressed, the better.
PM: This is a simple fix and we should get this in to anaconda for 5.2. The fix is to allow gpt labels on
ppc or ppc64 platforms within anaconda rather than report them as "invalid, you must format!" problems.
adding qa-ack and setting rhel-5.2.0 flag.
David, thanks for taking up this fix.
Installed Snapshot 4 without having any issues with my GPT labels! Thank you!
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.