Bug 389331

Summary: Cannot boot system after installation on a PlayStation 3
Product: [Fedora] Fedora Reporter: Julio Merino <jmmv+fedora>
Component: mkinitrdAssignee: Peter Jones <pjones>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: 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 03:09:10 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235705    
Attachments:
Description Flags
Fix for nash to recognize the ps3d disk none

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-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.)
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.