Bug 820366 - Cannot boot 17 Beta installer: /dev/root does not exist
Summary: Cannot boot 17 Beta installer: /dev/root does not exist
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker https://fedoraproject...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-09 18:54 UTC by Andrew McNabb
Modified: 2012-06-04 23:08 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-04 23:08:47 UTC
Type: Bug


Attachments (Terms of Use)
init.log (220.67 KB, text/plain)
2012-05-14 19:06 UTC, Andrew McNabb
no flags Details
diff between non-working init.log and working init.log (131.78 KB, text/plain)
2012-05-14 20:10 UTC, Andrew McNabb
no flags Details

Description Andrew McNabb 2012-05-09 18:54:05 UTC
The Fedora 17 Beta installer is failing to start from within a PXE boot. The last messages on the screen are:

dracut Warning: Unable to process initqueue
dracut Warning: /dev/root does not exist
Dropping to debug shell.

This makes it impossible to install by PXE booting. I'm not sure if this is an Anaconda problem or a Dracut problem.

I can't think of anything unusual about this environment or configuration that would take effect so early in the process.

Comment 1 Andrew McNabb 2012-05-09 18:55:41 UTC
By the way, this is similar to bug #810207, except I am doing a PXE boot instead of a preupgrade, and I do not see a "dracut Warning: no suitable images" message.

Comment 2 Andrew McNabb 2012-05-10 20:33:11 UTC
By the way, I made sure to add the following to the kernel command-line:

repo=http://mirrors.cs.byu.edu/fedora/releases/test/17-Beta/Fedora/x86_64/os/

but this does not have any effect on the cryptic error message.

Since this makes it impossible to install, and I'm not currently aware of any mistakes in the pxe configuration, I'm submitting it as a blocker.

Comment 3 Adam Williamson 2012-05-10 22:36:37 UTC
I think this is invalid, as tflink has done successful PXE installs. We need far more detail, at least. We especially need to know the exact cmdline / bootloader config you used.



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

Comment 4 Adam Williamson 2012-05-10 22:37:05 UTC
If you're passing root=, then don't. You should only pass repo=.

Comment 5 Brian Lane 2012-05-10 22:42:45 UTC
Please try again with the Final TC4 image. There have been a number of
important fixes since Beta.

Also make sure your repo has .treeinfo pointing to the squashfs.img or has
LiveOS/squashfs.img

I think this is a dupe of 810136 but will wait for a retest with current media.

Comment 6 Andrew McNabb 2012-05-10 22:59:09 UTC
The exact kernel command-line (from /proc/cmdline) is:

initrd=f17-Beta-x86_64/initrd.img repo=http://mirrors.cs.byu.edu/fedora/releases/test/17-Beta/Fedora/x86_64/os/ ks=nfs:aml.cs.byu.edu:/admin/install/f17.ks ksdevice=BOOTIF biosdevname=0 sshd BOOTIF=01-22-22-22-22-22-22 BOOT_IMAGE=f17-Beta-x86_64/initrd.img

I have not tried the Final TC4 image, and if it fixes the problem, that's great. The .treeinfo file in the repo includes the line "mainimage = LiveOS/squashfs.img". I'd be happy to try the TC4 image. Is there a way to get the vmlinuz and initrd.img without downloading the whole DVD ISO and extracting the files manually? Also, can it boot with a repo url pointing to a 17-Beta repository?

Comment 7 Adam Williamson 2012-05-11 01:33:10 UTC
Well, you could get it from netinst.iso, which is much smaller. Or, I believe, it's available at http://dl.fedoraproject.org/pub/alt/stage/17.TC4/Fedora/x86_64/os/isolinux/ . It would be better not to point to a Beta repository but to an up-to-date 17 mirror, e.g. http://dl.fedoraproject.org/pub/alt/stage/17.TC4/Fedora/x86_64/os/ , but a Beta repo _may_ work.



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

Comment 8 Adam Williamson 2012-05-11 03:03:26 UTC
Voting ahead of the meeting tomorrow: hard to know on this one. I hereby appoint tflink to proxy my vote, hoping more info will be available by then.



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

Comment 9 Andrew McNabb 2012-05-11 16:19:01 UTC
I grabbed the vmlinuz and initrd.img from http://dl.fedoraproject.org/pub/alt/stage/17.TC4/Fedora/x86_64/os/isolinux/ and pointed repo at http://dl.fedoraproject.org/pub/alt/stage/17.TC4/Fedora/x86_64/os/ but I'm still seeing the same error. Just to double-check, I did `cat /proc/cmdline`, it shows the new repo.

Is there any other information I can provide?

Comment 10 Andrew McNabb 2012-05-11 20:36:47 UTC
I just switched ks to use http instead of nfs, but I'm getting the same error. Are there any logs that show what it's trying to do? The "/dev/root does not exist" message is pretty vague.

To try to find more information, I just ran wireshark to trace all of the traffic. All I see is TFTP traffic from downloading the initrd.img followed by a DHCP offer and ack. There is nothing else after that: no DNS lookup, HTTP connections, etc. There aren't any problems with the network, though, as I was able to run curl manually and connect to an HTTP server.

Anyway, I hope this information is helpful.

Comment 11 Brian Lane 2012-05-11 21:00:55 UTC
This is possibly related to bug 811242

Try it with your kickstart available over http instead of nfs.

Comment 12 Andrew McNabb 2012-05-11 21:29:37 UTC
Yes, as in Comment #10, I have tried with both http and nfs and get the same error.

Comment 13 Brian Lane 2012-05-11 23:42:14 UTC
heh, sorry. It sounds like a local networking problem of some kind -- it works fine for me. If you can get the init.log that would really help.

Comment 14 Adam Williamson 2012-05-12 00:45:55 UTC
Discussed at 2012-05-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-11/f17-final-blocker-review-meeting-5.2012-05-11-17.04.html . It was agreed that it's difficult to determine the blocker status of this bug at present as the reproduction scenario is unclear - bcl tried to reproduce the issue as described and could not. It was agreed to postpone the decision until more information is available.



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

Comment 15 Andrew McNabb 2012-05-14 17:28:01 UTC
\(In reply to comment #13)
> heh, sorry. It sounds like a local networking problem of some kind -- it works
> fine for me. If you can get the init.log that would really help.

What sort of local networking problem could it be? Wireshark is showing that the system isn't even trying to use the network for anything.

Where can I find init.log? If I do `find / -name init.log` it doesn't show any results.

Is there any way to manually confirm at what stage in the boot process it got stuck?

Comment 16 Brian Lane 2012-05-14 18:15:27 UTC
I'm just guessing, since http works fine for me (I haven't tried nfs).

pass rd.debug on the kernel cmdline and then pull /run/initramfs/init.log

Comment 17 Tim Flink 2012-05-14 18:42:45 UTC
Discussed during the 2012-05-14 mini blocker review meeting.

Rejected as a blocker for Fedora 17 because other testers have been unable to reproduce the issue as described and therefore doesn't appear to be severe enough to justify blocker status.

If more information turns up that makes the issue more reproducible or more severe, please re-propose as a blocker

Comment 18 Andrew McNabb 2012-05-14 19:06:42 UTC
Created attachment 584450 [details]
init.log

As requested, I am attaching init.log from a boot with `rd.debug` enabled.

With `rd.debug`, I also noticed an error on the console that does not appear in the log file. I'm not sure if this is related to the cause of the problem or if it is just a side-effect. I could post a screenshot, but it might be easier just to type in a few lines (with the details of the setsid usage statement omitted):

"""
/lib/dracut-lib.sh@801(emergency_shell): strstr '
Usage:
 setsid [options] <program> [arguments ...]
...
/lib/dracut-lib.sh@802(emergency_shell): setsid /bin/sh -i -l
"""

Comment 19 Andrew McNabb 2012-05-14 19:32:07 UTC
Ok. After reading through the log, I realized that the scripts are in a "manual" networking mode, even though they're using DHCP. I then removed "ksdevice=BOOTIF" from the kernel command-line, and it now proceeds further than it used.

So if you're trying to reproduce this, make sure to use "ksdevice=BOOTIF" on the kernel command-line and set "ipappend 2" in the pxelinuk configuration. I hope this is helpful.

(In reply to comment #17)
> If more information turns up that makes the issue more reproducible or more
> severe, please re-propose as a blocker

Done.

Comment 20 Tim Flink 2012-05-14 19:42:06 UTC
(In reply to comment #19)

> So if you're trying to reproduce this, make sure to use "ksdevice=BOOTIF" on
> the kernel command-line and set "ipappend 2" in the pxelinuk configuration. I
> hope this is helpful.

This is pretty much exactly what I have in my PXE configuration that was working with TC4 - haven't tried TC5 yet but I don't expect significantly different results.

LABEL F17-tc4-x64
        kernel /images/F17-tc4-x64/vmlinuz
        MENU LABEL F17-tc4-x64
        append initrd=/images/F17-tc4-x64/initrd.img ksdevice=bootif lang=  rd.debug repo=http://192.168.0.5/cblr/ks_mirror/F17-tc4-x86_64/ kssendmac  ks=http://192.168.0.5/cblr/svc/op/ks/profile/F17-tc4-x64
        ipappend 2

Can you try again with a public mirror? It would help to rule out any oddities that could be present in the non-public mirror that you're using

Comment 21 Andrew McNabb 2012-05-14 20:10:03 UTC
Since Friday, I've been pointing at a public mirror as described in Comment #11. Just to clarify, my non-working configuration is:

label f17-x86_64
    menu label Fedora 17 Beta x86_64
    kernel f17-Beta-x86_64/vmlinuz
    append initrd=f17-Beta-x86_64/initrd.img repo=http://dl.fedoraproject.org/pub/alt/stage/17.TC4/Fedora/x86_64/os/ ks=http://aml.cs.byu.edu/install/f17.ks ksdevice=BOOTIF biosdevname=0 sshd rd.debug
    ipappend 2

And my working configuration is:

label f17-x86_64
    menu label Fedora 17 Beta x86_64
    kernel f17-Beta-x86_64/vmlinuz
    append initrd=f17-Beta-x86_64/initrd.img repo=http://dl.fedoraproject.org/pub/alt/stage/17.TC4/Fedora/x86_64/os/ ks=http://aml.cs.byu.edu/install/f17.ks biosdevname=0 sshd
    ipappend 2

The only difference is the "ksdevice=BOOTIF". I've booted both multiple times, so I'm sure that this change is enough to make it start and stop working.

It's odd that you're not seeing the same difference. Is it possible that the network configuration mode depends certain dhcp options? If so, the init.log contains detailed dhcp information. Momentarily, I will post a diff of the logs between the two configurations. There seem to be significant differences in the network configuration.

Comment 22 Andrew McNabb 2012-05-14 20:10:41 UTC
Created attachment 584461 [details]
diff between non-working init.log and working init.log

Comment 23 Brian Lane 2012-05-14 20:55:54 UTC
ksdevice=BOOTIF is not a valid value. It should be bootif.

https://fedoraproject.org/wiki/Anaconda/Options#ksdevice

Comment 24 Andrew McNabb 2012-05-14 21:13:15 UTC
Wow. Good catch. And that is the most horrible error message I have ever seen. :)

In Fedora 16 and previous, the option was not case-sensitive. In the end, the option should either be case-insensitive or have a reasonable error message to go with it.

For Fedora 17, I think it's probably fine for this to go in the errata instead of be a blocker.

Comment 25 Adam Williamson 2012-05-14 23:22:28 UTC
andrew: lots of problems ultimately wind up hitting the '/dev/root does not exist' error, unfortunately.

yes, this should definitely be commonbugsed if we can't do anything to 'fix' it.



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


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