Bug 521471 - Computer won't boot F12 snapshot 1
Summary: Computer won't boot F12 snapshot 1
Keywords:
Status: CLOSED DUPLICATE of bug 520207
Alias: None
Product: Fedora
Classification: Fedora
Component: kdiff3
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Neal Becker
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-06 09:26 UTC by Andreas Tunek
Modified: 2009-09-09 21:34 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-09-09 20:18:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.