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?
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 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.
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 {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.
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 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
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 install.
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
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping