Bug 1329293 - NVMe installation fails: Cannot find /dev/root
Summary: NVMe installation fails: Cannot find /dev/root
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 24
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-21 14:33 UTC by Johannes Pfrang
Modified: 2016-04-22 12:38 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-22 12:38:30 UTC
Type: Bug


Attachments (Terms of Use)
Fedora 24 nvme install log (3.58 MB, text/plain)
2016-04-21 14:33 UTC, Johannes Pfrang
no flags Details
Fedora 24 nvme install log (root=/dev/nvme0n1) (341.82 KB, text/plain)
2016-04-21 14:34 UTC, Johannes Pfrang
no flags Details

Description Johannes Pfrang 2016-04-21 14:33:52 UTC
Created attachment 1149476 [details]
Fedora 24 nvme install log

I've built a new system with a Samsung 950 Pro NVMe SSD as the only storage device attached to a D3417-B11 with an Intel Xeon E3-1225 v5.
Trying to install the latest Fedora 24 alpha builds or nightly composes fails, because no `/dev/root` device can be found.

dracut-initqueue[694]: /lib/dracut-lib.sh@433(check_finished): for f in '$hookdir/initqueue/finished/*.sh'
dracut-initqueue[694]: /lib/dracut-lib.sh@434(check_finished): '[' '/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh' = '/lib/dracut/hooks/initqueue/finished/*.sh' ']'
dracut-initqueue[694]: /lib/dracut-lib.sh@435(check_finished): '[' -e '/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh' ']'
dracut-initqueue[694]: /lib/dracut-lib.sh@435(check_finished): . '/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh'
dracut-initqueue[694]: //lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh@1(source): '[' -e /dev/root ']'
dracut-initqueue[694]: /lib/dracut-lib.sh@435(check_finished): return 1

Finally, the script times out and drops to the emergency shell. Complete `rd.debug` log attached.
I also tried booting with `root=/dev/nvme0n1`, but that didn't help either.
Log in the next commit.

Comment 1 Johannes Pfrang 2016-04-21 14:34:40 UTC
Created attachment 1149478 [details]
Fedora 24 nvme install log (root=/dev/nvme0n1)

Comment 2 Harald Hoyer 2016-04-22 09:11:28 UTC
inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 rd.live.check rd.debug root=/dev/nvme0n1

inst.stage2? and rd.live.check?

Comment 3 Harald Hoyer 2016-04-22 09:14:23 UTC
anyway, the anaconda part in dracut is searching for a partition/device with LABEL Fedora-S-dvd-x86_64-24 

Are you sure, this is available in your system?

Reassigning to component anaconda, as this is the installer image

Comment 4 Johannes Pfrang 2016-04-22 09:29:51 UTC
inst.stage2 and rd.live.check were there by default. The latter I assume because I chose the default "Test this media and install Fedora 24" in the grub/syslinux menu.

More complete STR on how I came to the above logs:

1. Download a working Fedora 24 Installer image. I used `Fedora-Server-netinst-x86_64-24-20160421.n.0.iso` last time because the openQA results look good.
2. Write the iso to a USB stick. (I was using unetbootin 619-1 from an Arch Linux installation)
3. Boot as UEFI
4. Select "Test this media and install Fedora 24" (optionally add `rd.debug` and remove `quiet`)
5. Boot screen goes until "Starting plymouth" or so and hangs there for ~180 seconds until the dracut timeout scripts run and drops to emergency shell.

Checked lsmod and made sure the nvme module is loaded and /dev/nvme0 and /dev/nvme0n1 exist.

Comment 5 Johannes Pfrang 2016-04-22 09:37:16 UTC
adamw strikes again....

https://www.happyassassin.net/2014/02/04/more-on-booting-a-practical-fedora-uefi-guide-and-dont-use-universal-usb-stick-writers/

I'll try this out next time I get to the machine.

Comment 6 David Shea 2016-04-22 12:38:30 UTC
(In reply to Johannes Pfrang from comment #4)
> 2. Write the iso to a USB stick. (I was using unetbootin 619-1 from an Arch
> Linux installation)

There's your problem. I don't know exactly what unetbootin does, but it apparently involves modifying filesystem UUIDs (this ISO should show up as 2016-04-21-08-38-11-00 in /dev/by-uuid, it appears to be usb-Generic_Flash_Disk_DFAB1258-0:0 in the log) and labels, and we need those. Writing the iso directly to a USB stick is a better bet.


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