Created attachment 315161 [details] dmesg from openbsd, in case it is useful Description of problem: Anaconda on the ppc netinstall CD is too inflexible: Can't make an AppleBoot partition small enough, can't proceed with the install without the AppleBoot partition. This seems to be an interplay between missing features in gparted and Anaconda, and a lack of options on the netinstall CD. Version-Release number of selected component (if applicable): Fedora 9 netinstall CD image How reproducible: Happens every time. Steps to Reproduce: 1. Start install process. 2. At the partitioning stage, attempt to make an AppleBoot partition of 1M. 3. The partition editor refuses to make a partition smaller than 16M. Make a partion of 16M. 4. Anaconda refuses to proceed with an AppleBoot partition larger than 1M. 5. Partition with Mac OS X tools. (This means wiping the entire disk.) 6. Start install process again. 7. Anaconda will not use a 1M partition created with the Mac OS X tools. Actual results: Catch 22, can't install with the netinstall CD. No explanation of the 1MB limit. No way to escape the failing pattern. I tried partitioning with the Mac OS X utilities and (IIRC) the Mac OS 9 partitions, but Anaconda would not use the 1M partition I created with those, even when I chose the similarly named partition type using the Mac OS 9 utility. I tried forcing the size of the partition to 1M in gparted, but the actual partition size was 16M, even though the allocation size (or whatever that was called) was 1M. If I recall correctly, Anaconda did install that time, but then the openfirmware or something on the Mac side of things decided that the partition map was unrecognizable and refused to boot. Because I had time, I also tried wiping the disks and installing only Fedora (no multiboot), but, again, either Anaconda would refuse to pass the partition stage or openfirmware or whatever it was would refuse to recognize the partition map. Expected results: Need more explanation. Maybe I just missed it, but I didn't see any README that explained the process. Without the explanation, it's hard to imagine what Anaconda should do. The netinstall CD also does not provide any way to perform different kinds of installs, which is something of a surprise since I have used the x86 rescueCD to perform netinstalls on several occasions in the past. But I didn't really want to install an AppleBoot partition anyway. I'm multibooting with Mac OS X and 9 and openBSD and want the partitions for other purposes. (openBSD's default boot procedure for the MacPPC install process is to provide an ofwboot file to save on the first non-driver partition. It requires the partition to be HFS+, but that really is not a problem.) My first non-driver partition (actual partition 9) is an HFS+ partition for Mac OS 9. When I boot openbsd, I use the 4-finger salute to boot to openfirmware, and invoke openBSD's "ofwboot" by typing: boot hd:9,ofwboot /bsd It would be nice to be able to do something similar, say, invoke Fedora's "ofboot": boot hd:9,ofboot /boot/vmlinuz or maybe even go to yaboot instead of Fedora's ofboot: boot hd:,yaboot The Mac OS X 10.2 and Mac OS 9.2 tools for selecting the boot volume allow selecting a system directory (folder) within the chosen drive. I assume there is some interest in being able to cooperate with the Mac OS tools for multibooting in the future, and I would also guess that the restriction of the AppleBoot partition is not the way to go to get there. Anyway, I want some way to set up a different boot path for the install, without the installer getting stuck on the size of the AppleBoot partition. Additional info: iBook version: 83.0 sales model: M7718J/A boot rom version: 4.1.7f4 Hard disk: Hitachi HTS541616J9AT00 (160 decimal GB, Mac OS X sees it as only 130 G) RAM: 64M+512M (512M is PC133CL2) Since I could never get a successful boot, I don't have a dmesg from Fedora, but I'm attaching a dmesg from openBSD if it helps.
I should have booted the installer instead of writing from memory. s/AppleBoot/Apple Bootstrap/{mostly-global} I did try both, FWIW. The one place where I need to elucidate, when I tried to set the partitions up with the Mac OS 9 tools, I tried a 1M AppleBoot partition, and Anaconda did not try to make use of that.
At the boot: prompt, I just tried "linux rescue" and it goes along until ------- Greetings. anaconda installer init version 11.4.0.82 starting mounting /proc filesystem... done [...] running /sbin/loader detecting hardware... waiting for hardware to initialize... ------- and sits there showing me the flashing cursor for a really long time, more than thirty seconds, then finally asks me for the language and keyboard type. (In comparison, if I type some nonsense option, like "linux memtestppc", it only sits there for a few seconds.) Anyway, it looks like there is a rescue mode after all, if I can only remember that it's an option, not a kernel. Maybe I'll be able to hand-install the thing after all.
Okay, parted killed my ability to boot the Mac OS 9. Mac OS X's disk utility scans the partition and says it's okay, and it mounts okay in Mac OS X. But the Mac OS 9.1 installer doesn't see it. If I use Apple's boot menu (hold option/alt down at the chime), I can select the drive, but from there I get the blinking-question-mark-in-the-floppy message. Guess I have to go find some tool to restore the OS-9 drivers. It also appears that parted can't keep its fingers out of the Mac OS 9 drivers, which is going to make it impossible to multi-boot with Fedora, even if I could get past this bootstrap partition install bug. I wonder if I should write this parted "feature" up as a separate bug ...
Parted has been known not to comply completely to the GPT specification, this might be what is happening with the Mac Os installer. It would be very usefull to have the original partition table and the resulting one, so I could make a diff and debug.
Sorry I missed your question. Yeah, a before and after would have been good. It didn't occur to me at the time that I could dd the raw partitions to keep a record and maybe even restore, so I didn't take a dd in Mac OS X. (Was that what you had in mind?) I've been meaning to post some additional information. I moved the 160G drive to a white 12" iBook G4 at the end of August, for work. The G4's drive is a 30 decimal GB drive, and I put that on the tangerine iBook G3 so my kids could play Bugdom in Mac OS 9. When I cut the partitions, I gave about 2 G to Mac OS 9, 9G to Mac OS X, set aside 1.5G for Mac OS swap, and left about 13G for Fedora. Last Saturday, I finally got a chance to install Fedora. If I'd seen your comment before that, I could have taken the images first. So, the results: On the 30G drive, the installer was able to cut the 1MB AppleBoot partition. The install completed and I was able to log onto a virtual console. I was not able to log into an X11 session. I had attempted to select xfce instead of gnome, which probably has something to do with that. When I tried to reboot to Mac OS 9, the boot-up ROM gave me the bad-drive circle-with-a-bar symbol. I was able to boot to Mac OS X. I was also able to boot the Mac OS 9 install CD and (re-)install the drivers, and now I can boot Mac OS 9 again. Most of the time. At that point, I took a dd of the first eight partitions in Mac OS X. So, next time I get some time, I could try wiping Fedora and re-installing it and send you the dds. The before pictures will not be fresh, however. I'm thinking of starting over from scratch, again, however. Or maybe installing Fedora 10 or Rawhide. Whichever way, I'll grab the images. dd or some other tool?
(In reply to comment #3) > Okay, parted killed my ability to boot the Mac OS 9. Mac OS X's disk utility. What was the command(s) that was used to query/modify the partition? The test case here is to : 1. dd the parititon 2. create the partitions with the Mac Os 9.1 App ( or have a partition that is accepted by Mac Os 9.1 App), 3. Then run parted on it, 4. Then see the Mac Os 9.1 parititon app reject the partition. 5. dd the parititon once more. With this set of steps you will end up with tow files (hopeuflly the firsta 1024 bytes of the device). The fact that the fedora installer does not let you create a partition of less than 7 Mb (for f10) is something that would need to be given an additional bugzilla.
Sorry, I don't remember the commands I used. I am pretty sure I didn't spill any partitions beyond the intended boundaries. Mac OS X boots and Mac OS 9 boots under emulation in Mac OS X. I can consistently boot Mac OS 9 now. I just tried the Fedora 10 preview netinstall image and it gives me an exception (on both my G3 and G4). I suppose I should file a bug report on that. So I won't be able to get before and after pictures for Fedora 10. I doubt I'll be able to re-create the failure creating the 1MB partition, since the 160G drive is now in service in my white iBook G4. I had no problem creating the small partitions on that drive on the G4, by the way.
Just added bug #471733 for the failure to cut the Appleboot partition problem. I should note that Mac OS 9 and Mac OS X 10.2 only recognized 120G of the 160G drive. If I attempted to format more than 120G under either Mac OS 9 or Mac OS X, Mac OS 9 refused to boot. Also, if I formatted more than 16 partitions on the drive, Mac OS 9 refused to boot. Mac OS X did boot with the whole drive formatted (as several partitions), or with more than 16 partitions, but it did not recognize the entire drive, and may not have been stable. When I can budget about a half a day for it, I'll try to get the before and after pictures from Fedora 9, or maybe try the Fedora 10 release if I can't do it in the next week.
still looking for hardware to test this :(
Created attachment 331226 [details] pdisk map of the hard disk when it booted Mac OS 9.1. I'm pretty sure this was a dd, not sure why it's only 1360 bytes. This was October 26, 2008, after the first fix, after I had installed Fedora 9, failed to boot Mac OS 9, and then booted the install CD and fixed it with the HD setup Mac OS utility by re-installing the drivers.
Comment on attachment 331226 [details] pdisk map of the hard disk when it booted Mac OS 9.1. I guess it was pdisk output. dd gives the binary form, and goes on forever, of course.
Created attachment 331228 [details] dd of /dev/rdisk0s1 when it booted Mac OS 9
Created attachment 331229 [details] dd if=/dev/rdisk0 count=8 when it still booted Mac OS 9.1 before failed fedora 10 install
Created attachment 331230 [details] dd if=/dev/rdisk0 count=8 after failed fedora 10 install, Mac OS 9 partition no longer boots Sorry about the mess on the last attachment. I'm not thinking very clearly, I guess.
Created attachment 331231 [details] dd if=/dev/rdisk0s1 after failed fedora 10 install, Mac OS 9 partition no longer boots All the other partition map partitions (/dev/rdisk0s2 to /dev/rdisk0s8) were untouched. Classy (/dev/rdisk0s9) is the Mac OS 9.1 partition.
Sorry about the mess above, and sorry this is taking so long. Anyway, last weekend, I attempted a Fedora 10 install. That failed, but it failed primarily because the ethernet cable come out about eight hours in. I wish there were an easy way to choose a stripped-down X11 install, with a package manager like the one in the installer. If I'd noticed that the comments from the attachment screen were being added here, I'd have tried to give a more intelligible description of everything in those. My inductions: /dev/rdisk0 is the entire drive, and /dev/rdisk0s1 through /dev/rdisk0s8 would be the map, drivers, and partition labels for the mounted volumes, which would be /dev/rdisk0s9 through /dev/rdisk0s16, I think. Only the partial dump of rdisk0 and rdisk0s1 changed during the install process. I tagged the filenames of the dumps with the dates I took them. I can upload the dumps of /dev/rdisk0s2 through rdisk0s8 if they would be useful. Next, I'll upload the dumps I took after using the Mac OS 9.1 install CD to restore the drivers.
Created attachment 331232 [details] dd if=/dev/rdisk0 count=8 after restoring the drivers, Mac OS 9.1 partition boots again. I must be careful to refrain from updating to Mac OS 9.2 before the dust settles, because I don't have have an install disk for Mac OS 9.2 with a Mac OS 9 drive set up application to use to update the drivers with.
Created attachment 331234 [details] dd if=/dev/rdisk0s1 after restoring the drivers, Mac OS 9.1 partition boots again.
Created attachment 342562 [details] dmesg of booted fedora 11 release candidate Installing the release candidate took 14 or 15 hours on a 1.5M ADSL line. Letting it install the boot partition ended up with the disk drivers over-written again. Mac OS 9 then would fail to boot until I re-updated the drivers (again) using the Mac OS 9.1 install CD. (On the workaround -- I have to refrain from updating Mac OS 9 to 9.2, so the install CD will let me update the drivers. I may try making a bootable Mac OS 9.2 CD sometime, but that's not at all a Fedora issue, and not something one can do after the fact.) I'm thinking this might be a separate bug, or maybe I need to dig up the boot manager project and report the bug directly to them. They would be the ones who would know why they overwrite the drivers, and whether the bug could be fixed by simply refraining from overwriting the drivers.
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
I finally have HW and I am interested in further investigating this issue. To be clear I am considering the description in comment 3 to be the actual issue. Where parted changes the gpt partition in such a way that it is no longer recognizable to the mac. I will be testing with f11. Joel: Thx for all you input. This will hopefully help with the debugging. The partitioning code for anaconda (installer) has changed substantially. I encourage you to give it another try with f11 and see what the results are.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Joel Rees, Unfortunately Joel has left Red Hat. I'm the new parted maintainer, some questions: 1) Does your machine use a gpt partition table 2) Does Mac OS 9 recognize gpt partition tables, or does it rely on the msdos compatibility label on the start of the disk ? I'm asking this, because if Mac OS 9 needs the msdos label, you should run gptsync after installation, as parted will write an msdos label which simply reserves the entire disk for gpt use. If you want to have an msdos partition table with approximately the same table as the gpt table, you can create one with gptsync, which will do so. Note this so called hybrid setup (msdos + gpt) is not a supported installation option (hence the need to run gptsync manually).
(In reply to comment #23) > Joel Rees, > > Unfortunately Joel has left Red Hat. I'm the new parted maintainer, some > questions: > 1) Does your machine use a gpt partition table > 2) Does Mac OS 9 recognize gpt partition tables, or does it rely > on the msdos compatibility label on the start of the disk ? GPT no. msdos no. MacOS 9 requires the mac disk label. GPT is only used on the mactels, and MacOS 9 is not available for those systems.
(In reply to comment #24) > (In reply to comment #23) > > Joel Rees, > > > > Unfortunately Joel has left Red Hat. I'm the new parted maintainer, some > > questions: > > 1) Does your machine use a gpt partition table > > 2) Does Mac OS 9 recognize gpt partition tables, or does it rely > > on the msdos compatibility label on the start of the disk ? > > GPT no. msdos no. MacOS 9 requires the mac disk label. GPT is only used on > the mactels, and MacOS 9 is not available for those systems. Ah, I got thrown of by Joel's comment about GPT handling. Joel Ress, can you confirm that your machine is using a MAC disklabel / partition table ?
Yes, the host disklabel was Macintosh, as built by either the Mac OS 9 or Mac OS X 10.2 disk partitioning utilities. Definitely prior to the "switch", and the "GPT" is definitely not an MSDOS host disklabel. (Sorry I haven't been very responsive. The daytime job, so to speak.)
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
As far as the 1M limit to the partition editor in Anaconda goes, it seems that had been fixed (I tested F14 in a KVM). I'm really not sure about the rest of this and given there has been no activity I'm going to close this as fixed.
Again, sorry for the time lapse. Did you try F14 on a G3 iBook with a hard drive larger than 120G? (These were specific conditions to the bug(s).) If so, I would like to know how you did that. Last I knew, PPC Fedora was in a state of suspended animation. As far as closing the bug, I can't see much else to do when there is no more PPC Fedora. On the other hand, if the secondary arch sig gets active again, this bug should be checked against actual hardware, since the problems with the Macintosh formatting are likely to be separate from the 1M limit Brian Lane mentions.