Red Hat Bugzilla – Bug 444365
Bad: partitioner does not check the existence of a mac disc label
Last modified: 2009-06-18 13:46:04 EDT
From Bugzilla Helper:
User-Agent: Opera/9.26 (Windows NT 5.1; U; en)
Description of problem:
The partioner during install does not check if the disc on which we are installing has
a valid mac disc label. If this happens not to be the case, then the system will not
be able to boot after the installer finishes.
Bad: system not bootable after install, due to missing mac disc label.
Good: Manually creating the disclabel in stage2 using parted fixes this.
Version-Release number of selected component (if applicable):
anaconda from the F9-Preview DVD
Steps to Reproduce:
1. Take a disc without mac disc label
2. Start and finish install
The questionmark/smileyface icon appears
The system should boot properly
Some sort of warning about hte missing mac disc label would be nice, alternatively,
since anaconda should be able to check that it is running on a ppc arch, maybe create
the mac disc label if absent?
my experience with this on an earlier release of Fedora (FC6) was that anaconda
never wrote the mac disk level even though I specified it during install.
If this is still the case we should change the summary of this bug title.
I can't remember why, but for some reason I did not report a bug on it.
We allow MS-DOS on ppc because it's valid for a lot of cases. We probably
should check the disklabel of the request in the sanity check, but the thing
that's difficult is what to do if it's not mac -- we don't expose
re-initializing outside of the "this isn't sane". And I don't know that it's
something we generally want to expose.
So there are some difficult UI questions to be answered here and any real
progress is likely going to require the involvement of someone from the PPC SIG.
Nothing PPC-specific here; install on a PC to a disk with non-MSDOS partitions,
and you'll get exactly the same behaviour. The installer does know which
partition type is best for each platform, but will only actually _act_ on that
if it's creating a new partition table. If there's any recognised partition
scheme on the disk already, the installer won't change it.
I was going to say that perhaps we should show a warning before the partitioning
screen (or even a checkbox on it), saying something like "Your disk is
partitioned with a $FOO disklabel, so will not be bootable. Would you like to
change it?". But we don't know which disk the boot partition will be on at that
Jeremy is right; we should check the disklabel of the disk containing the boot
partition, in the sanity check. And yes, that means we should probably show the
disklabel type and have a UI for changing it.
Note that some platforms support more than one partition type, so the sanity
check wouldn't be a simple comparison against the 'preferred' type -- we'd need
Hm, I think I lie -- we do have a list of acceptable partition types for each
architecture (archLabels). Either I misremember, or this has been worked on
since I last looked.
The simple answer would be to have such a list for each platform, so that Macs
_only_ have 'mac' in their list, while pSeries has 'msdos','gpt'.
The behaviour still isn't quite right though -- because you're only given the
option of reinitialising or ignoring the offending drive if the disklabel isn't
the right type. But you _could_ use it for anything other than the boot
partition; Linux doesn't care what disklabel type you have.
How do the last three commits in
It turns the archLabels() array into a function allowedLabels() which can return
different results for different platforms, then allows you to _use_ a partition
with the 'wrong' type of disklabel, and finally switches getDefaultDiskType() to
use allowedLabels() too rather than duplicating the knowledge.
I think we still need to add something to the sanity check to make sure that the
boot partition is on a disk with the appropriate disklabel.
I forgot to mention that the above is all completely untested and implemented
with my rudimentary grasp of python...
Created attachment 304087 [details]
A small patch to make valid python
Reading over the last three commits I saw some invalid python; patch attached.
Oops, thanks. I've updated the git tree to include that.
I see in partitions.py where we iterate over all the boot partition requests and
check for things like them being RAID or LVM -- that's where we want to check
for them being on a disk with a supported disklabel. But I don't see how to find
the disklabel type of the partition from the request. This is almost certainly
@@ -1230,8 +1230,13 @@ class Partitions:
for bootreq in bootreqs:
if not bootreq:
+ if bootreq.drive.type.name not in partedUtils.allowedLabels():
+ errors.append(_("Bootable partitions cannot be on a disk
with a %s "
if (isinstance(bootreq, partRequests.RaidRequestSpec) and
As I sort of implied, but probably not enough in the initial comment, this
behavior is what it's always been. Any fixes will involve string changes which
it's too late for. So we'll look at for F10. But the quick turnaround on
getting something together will help get something in right after F9 branches
(which should be soon)
Yeah, I definitely wouldn't want to do this before F9, and not just because of
the string changes -- it's rawhide material (even if someone with python-clue
looks over it and fixes up the pseudo-patch in comment #8) and wants testing on
a whole bunch of platforms with various pre-existing partition schemes.
My workaround has always been to switch to tty2 and 'dd if=/dev/zero
of=/dev/sda' for a few seconds before the installer gets that far through the
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
We have made extensive changes to the partitioning code for F11 beta, such that it is very difficult to tell whether your bug is still relevant or not. Please test with either the latest rawhide you have access to or F11 and let us know whether you are still seeing this problem. Thanks for the bug report.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: