Bug 521471

Summary: Computer won't boot F12 snapshot 1
Product: [Fedora] Fedora Reporter: Andreas Tunek <andreas.tunek>
Component: kdiff3Assignee: Neal Becker <ndbecker2>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: awilliam, cgrim, mike.cloaked, pebolle, rda
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-09 20:18:17 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:

Description Andreas Tunek 2009-09-06 09:26:13 UTC
Description of problem:
Can not boot F12 snapshot 1 using USB stick. It says "No root device found

No root device found

Boot has failed, sleeping forever."

Version-Release number of selected component (if applicable):
Don't know. Sorry.

How reproducible:
Always on my computer

Steps to Reproduce:
1. Run F11 snapshot using USB stick.
2.
3.
  
Actual results:
Computer won't boot.

Expected results:
Computer should boot!

Additional info:

Comment 1 Paul Bolle 2009-09-06 11:24:49 UTC
0) "No root device found" and "Boot has failed, sleeping forever." are lines of the init script of the kernel's "generic" initrd. Component kernel?

1) In my case first seen with kernel-2.6.31-0.203.rc8.git2.fc12.i686 (kernel-2.6.31-0.190.rc8.fc12.i686 still boots normally).

Comment 2 Bob Arendt 2009-09-06 23:41:12 UTC
I saw the same problem and was able to fix it.  This is:
Bug 520207 : Filesystem label does not match kernel command line parameter

You can dynamically edit this during boot (at the grub-like boot countdown).  Hit Tab while booting and manually change the LABEL=F12-Snap1-i686-Live to LABEL=F12-i686 (or F12-x86_64) as appropriate.  LABEL=LIVE does *not* work.

You can permanently update the boot line on the USB stick.  Mount the live USB key on another system (the mount label will be F12-i686 or F12-x86_64).
  cd /media/F12-i686/syslinux
  edit syslinux.cfg, change all occurances of
  from: root=live:LABEL=F12-Snap1-i686-Live
  to:   root=live:LABEL=F12-i686

Save, sync, and unmount the stick. It should now find the disk and continue to boot

Comment 3 Paul Bolle 2009-09-07 13:45:35 UTC
(In reply to comment #2)
> I saw the same problem and was able to fix it.  This is:
> Bug 520207 : Filesystem label does not match kernel command line parameter

0) Well, comment #1 happened on a Rawhide system, and not a live USB disk. Also happens with kernel-2.6.31-0.204.rc9.fc12.i686 (i.e. current Rawhide kernel). Moreover, the correctly booting  kernel and the not-booting kernel use identical command lines. So this could be a different issue than the issue described in comment #2.

1) Could someone please move this from (nonsensical) kdiff3 to something more appropriate: e.g. kernel, dracut?

Comment 4 cgrim 2009-09-07 17:14:20 UTC
0) I have the same problem on Rawhide system with kernels 2.6.31-0.203.rc8.git2.fc12.x86_64 and 2.6.31-0.204.rc9.fc12.x86_64. They use identical command line parameters as 2.6.31-0.180.rc7.git4.fc12.x86_64, which is the last working kernel version for me.

Comment 5 Mike C 2009-09-09 15:21:31 UTC
Thanks to Bob Arendt via Fedora-Devel-List, who suggested "using /sbin/dosfslabel or /sbin/e2label to read the actual label.
Then use that for the label on the boot line."

This actually works and gets the usbkey to boot when the advice in #2 did not work for me.

Comment 6 Adam Williamson 2009-09-09 20:18:17 UTC
this is a dupe of 520207.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** This bug has been marked as a duplicate of bug 520207 ***

Comment 7 Paul Bolle 2009-09-09 21:31:22 UTC
0) The issue described in comment #3 (and comment #4 most likely too) is of course different.

1) It turns out I can boot kernel-2.6.31-0.204.rc9.fc12.i686 if I change
    root=UUID=[...]
to
    root=/dev/mapper/[...]
So apparently the root=UUID=[...] part of the kernel command line is somehow not correctly handled somewhere.

2) Is the UUID issue already reported?

Comment 8 Paul Bolle 2009-09-09 21:34:55 UTC
(In reply to comment #7)
> 2) Is the UUID issue already reported?

Yes, in bug #521416.