Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Cannot boot system after installation on a PlayStation 3|
|Product:||[Fedora] Fedora||Reporter:||Julio Merino <jmmv+fedora>|
|Component:||mkinitrd||Assignee:||Peter Jones <pjones>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||asayama, dcantrell, dwmw2|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-17 03:09:10 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Julio Merino 2007-11-18 07:51:12 EST
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-126.96.36.199-42.fc8 label=linux read-only initrd=/boot/initrd-188.8.131.52-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.)
Comment 1 Julio Merino 2007-11-18 16:04:56 EST
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.
Comment 2 Kazunori Asayama 2008-02-13 21:37:01 EST
*** Bug 381621 has been marked as a duplicate of this bug. ***
Comment 3 David Woodhouse 2008-04-08 04:43:38 EDT
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)
Comment 4 Jesse Keating 2008-04-08 07:41:12 EDT
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.
Comment 5 David Woodhouse 2008-04-08 14:34:44 EDT
You used LVM. This prevents booting when you install directly to partitions on /dev/ps3da.
Comment 6 Jesse Keating 2008-04-08 14:59:40 EDT
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?
Comment 7 Julio Merino 2008-04-08 16:56:21 EDT
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.
Comment 8 Jesse Keating 2008-04-08 17:20:04 EDT
(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.
Comment 9 Kazunori Asayama 2008-04-08 22:18:58 EDT
*** Bug 439137 has been marked as a duplicate of this bug. ***
Comment 10 David Woodhouse 2008-04-09 03:46:08 EDT
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.
Comment 11 Jesse Keating 2008-04-09 07:25:48 EDT
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.
Comment 12 Kazunori Asayama 2008-04-09 07:38:53 EDT
(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.
Comment 13 John Poelstra 2008-04-10 12:40:22 EDT
moving to F9 tracker; removing from F9 blocker
Comment 14 David Woodhouse 2008-04-13 09:33:32 EDT
This seems not to be fixed in mkinitrd-6.0.45. Would be really nice to fix by F9.
Comment 15 David Woodhouse 2008-04-14 15:03:32 EDT
mkinitrd-6.0.46 boots fine, although it complains that it can't find the resume device /dev//dev/ps3da2
Comment 16 Jeremy Katz 2008-04-17 03:09:10 EDT
The resume thing is fixed in 47
Comment 17 Arturo Alejandro Hoffstadt Urrutia 2008-05-01 19:19:42 EDT
(In reply to comment #16) > The resume thing is fixed in 47 What do you mean by 47?
Comment 18 David Woodhouse 2008-05-02 04:41:54 EDT
He means version 6.0.47 of mkinitrd.