Bug 389331
| Summary: | Cannot boot system after installation on a PlayStation 3 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Julio Merino <julio> | ||||
| Component: | mkinitrd | Assignee: | Peter Jones <pjones> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | CC: | asayama, dcantrell, dwmw2 | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | ppc64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-04-17 07:09:10 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 235705 | ||||||
| Attachments: |
|
||||||
Created attachment 263131 [details]
Fix for nash to recognize the ps3d disk
After further inspection, I believe I have a bug fix for this.
The attached patch, which is to be applied to nash (included in the mkinitrd
package), adds the new 'ps3d' device name to the table to guess which devices
are disks. It makes the 'showlabels' command work in nash and allows a custom
kernel to boot for me (which failed before because it couldn't mount the root
file system, even when specifying it as a device name). I am fairly confident
that it will fix the problem I reported earlier.
*** Bug 381621 has been marked as a duplicate of this bug. *** Your patch has "ps3d" and DEV_NAME_BEGINS, while the entry for SCSI disks has "sd" and DEV_NAME_EQUALS. Is that intentional? I would have thought they'd be using the same flags, as the naming is similar (ps3da, ps3da1 ... sda, sda1) Is this still needed? I did an install of F9 Beta to the PS3 and it was working just fine. I question whether this is a blocker. You used LVM. This prevents booting when you install directly to partitions on /dev/ps3da. Ah yes, silly me for using the defaults :) Given that you have to go out of your way to make this happen, should we really classify it as a blocker, for our 10s of PS3 users? David: I don't know. I just copy/pasted an entry from the file and adapted it for ps3d. Maybe DEV_NAME_EQUALS will work, but it is difficult for me to try now. (But if it is really needed, I think I'd find some free time to do it...) Jesse: The correct question is: should this remain unfixed when the fix is TRIVIAL? If the fix is delayed, it is easy to see that the situation will repeat again. The bug report will remain open until Fedora 10 release cycle, at which point it will be looked at because it is marked as blocker. It has already been around for five months since this was sent. (In reply to comment #7) > David: I don't know. I just copy/pasted an entry from the file and adapted it for ps3d. Maybe > DEV_NAME_EQUALS will work, but it is difficult for me to try now. (But if it is really needed, I think I'd find > some free time to do it...) > > Jesse: The correct question is: should this remain unfixed when the fix is TRIVIAL? > > If the fix is delayed, it is easy to see that the situation will repeat again. The bug report will remain open > until Fedora 10 release cycle, at which point it will be looked at because it is marked as blocker. It has > already been around for five months since this was sent. that's not it at all. It's a question of "Will we hold up the Fedora 9 release for it". Peter is working on some other rather important for F9 things that we would actually hold up the release for, so I don't want to get into resource contention on this issue. *** Bug 439137 has been marked as a duplicate of this bug. *** You're probably right that we shouldn't hold up the release for it. But we shouldn't really need to either. It's a very simple patch with almost zero possibility of regression. LVM might be a default, but it doesn't make a lot of sense in a lot of cases, including on PS3. And at one point (before the official Fedora releases, by which point of course we fixed it) people _had_ to avoid LVM because the dm tools couldn't cope with /dev/psd3* either. So it isn't entirely unlikely that people will avoid LVM. While I agree we shouldn't "need" to, again it's a resource issue with the upstream mkinitrd maintainer, who is rather busy with some rather important things to the F9 release. I'll see if we can get a timeslice to integrate this patch. (In reply to comment #7) I tried it. DEV_NAME_BEGINS worked, but DEV_NAME_EQUALS didn't. I don't understand why DEV_NAME_EQUALS works in sd's case, however, as far as I saw the dev_name_cmp function in the nash/procdev.c, it seemed correct to use 'DEV_NAME_BEGINS' in ps3d's case. moving to F9 tracker; removing from F9 blocker This seems not to be fixed in mkinitrd-6.0.45. Would be really nice to fix by F9. mkinitrd-6.0.46 boots fine, although it complains that it can't find the resume device /dev//dev/ps3da2 The resume thing is fixed in 47 (In reply to comment #16) > The resume thing is fixed in 47 What do you mean by 47? He means version 6.0.47 of mkinitrd. |
After installing Fedora 8 Final ppc on a PlayStation 3, the system does not boot. When I get to the kboot prompt after installation, I just hit return to use the default settings generated by the installer and the machine hangs later on saying that it could not find the root device. Here is part of the output generated from initrd. I have omitted all the messages spitted out by the kernel in between these because I am copying the messages by hand (from a screen with lots of flicker). I have summarized, though, where it detects the hard disk partitions. ---- cut here ---- Red Hat nash version 6.019 starting Mounting proc filesystem Mounting sysfs filesystem Creating /dev Creating initial device nodes Setting up hotplug. Creating block device nodes Loading ehci-hod.ko module Loading ohci-hod.ko module Loading uhci-hod.ko module Loading mbcache.ko module Loading jbd.ko module Loading ext3.ko module Loading scsi-mod.ko module Loading sd_mod.ko module Loading ps3stor_lib.ko module Loading ps3rom.ko module Loading ps3disk.ko module [ kernel finds ps3da1 and ps3da2 ] Trying to resume from LABEL=SWAP-ps3da2 Unable to access resume device (LABEL=SWAP-ps3da2) Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs. setuproot: moving /dev failed: No such file or directory no fstab,sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Booting has failed. ---- cut here ---- At that point the only thing I can do is ctrl+alt+del to reboot the machine and get back to kboot. The yaboot.conf file after installation has the following entry: ---- cut here ---- image=/boot/vmlinuz-2.6.23.1-42.fc8 label=linux read-only initrd=/boot/initrd-2.6.23.1-42.fc8.img append="root=LABEL=/1" ---- cut here ---- The problem seems to be due to LABELs. If instead of the LABEL=/1 parameter specified as the root device I change that to the real device name (/dev/ps3da1), the machine works fine. (As there is a workaround, I'm filling this as medium severity.) Note that the labels are correctly set on the device, though: # e2label /dev/ps3da1 /1 # I have also tried changing the label to something else (such as ROOT) and it still fails. No idea about what is going on, because the initrd correctly loads the ps3disk module and the kernel finds the partitions after that. (Which to me means that the initrd init command should properly see the labels before doing the switchroot.)