Bug 444365 - Bad: partitioner does not check the existence of a mac disc label
Bad: partitioner does not check the existence of a mac disc label
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Patch, StringChange
Depends On:
Blocks: AnacondaStorage
  Show dependency treegraph
 
Reported: 2008-04-27 18:57 EDT by S.A. Hartsuiker
Modified: 2009-06-18 13:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-18 13:46:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A small patch to make valid python (561 bytes, patch)
2008-04-29 05:59 EDT, Jeroen van Meeuwen
no flags Details | Diff

  None (edit)
Description S.A. Hartsuiker 2008-04-27 18:57:09 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

How reproducible:
Always


Steps to Reproduce:
1. Take a disc without mac disc label
2. Start and finish install
3. Reboot

Actual Results:
The questionmark/smileyface icon appears

Expected Results:
The system should boot properly

Additional info:
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?
Comment 1 John Poelstra 2008-04-28 08:35:55 EDT
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.
Comment 2 Jeremy Katz 2008-04-28 23:07:22 EDT
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.
Comment 3 David Woodhouse 2008-04-29 03:55:40 EDT
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
point. 

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
a list.
Comment 4 David Woodhouse 2008-04-29 04:05:31 EDT
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.
Comment 5 David Woodhouse 2008-04-29 05:12:37 EDT
How do the last three commits in
{http,git}://git.infradead.org/users/dwmw2/anaconda look?

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.
Comment 6 David Woodhouse 2008-04-29 05:15:17 EDT
I forgot to mention that the above is all completely untested and implemented
with my rudimentary grasp of python...
Comment 7 Jeroen van Meeuwen 2008-04-29 05:59:32 EDT
Created attachment 304087 [details]
A small patch to make valid python

Reading over the last three commits I saw some invalid python; patch attached.
Comment 8 David Woodhouse 2008-04-29 07:04:41 EDT
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
wrong...

--- a/partitions.py
+++ b/partitions.py
@@ -1230,8 +1230,13 @@ class Partitions:
             for bootreq in bootreqs:
                 if not bootreq:
                     continue
+                if bootreq.drive[0].type.name not in partedUtils.allowedLabels():
+                    errors.append(_("Bootable partitions cannot be on a disk
with a %s "
+                                    "partition
layout.")%(bootreq.drive[0].type.name,))
+
                 if (isinstance(bootreq, partRequests.RaidRequestSpec) and
Comment 9 Jeremy Katz 2008-04-29 08:45:06 EDT
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)
Comment 10 David Woodhouse 2008-04-29 09:38:16 EDT
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
install.
Comment 11 Bug Zapper 2008-05-14 06:16:25 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Chris Lumens 2009-04-08 15:54:18 EDT
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.
Comment 13 Bug Zapper 2009-06-09 20:28:54 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.