Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1613153 - Dracut fails with udev / dev-mapper timeout
Summary: Dracut fails with udev / dev-mapper timeout
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: LiveCD
Version: 28
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-07 06:45 UTC by Max
Modified: 2019-05-28 22:05 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 22:05:41 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
dmesg (57.10 KB, text/plain)
2018-08-07 06:45 UTC, Max 		no flags Details
rdsosreport.txt (90.39 KB, text/plain)
2018-08-07 06:47 UTC, Max 		no flags Details
journalctl (90.81 KB, text/x-vhdl)
2018-08-07 06:48 UTC, Max 		no flags Details
View All

Description Max 2018-08-07 06:45:58 UTC 
Created attachment 1473851 [details]
dmesg

Description of problem:
The fedora f28 livecd fails to boot (on dracut I believe). I have tried the kde spin (what I normally use), the updated kde spin, and the default fedora f28 gnome workstation image downloaded from the website (my log files come from a boot of that one)


Version-Release number of selected component (if applicable): Fedora 28 Workstation (Gnome)


How reproducible: Boot


Steps to Reproduce:
1. Boot livecd

Actual results:
Failure to get past dracut


Expected results:
Image boots normally


Additional info:

I have just built a new PC (specs here https://pastebin.com/NLTfVRbv ), there is nothing presently on the PC. I am trying to install fedora 28 through livecd image via usb.

I have updated the BIOS to the latest, and otherwise there seem to be no hardware issues. Just for testing I tried booting the ubuntu livecd (latest official version, 18.04) and that worked fine - and booted very quickly. By comparison there is a section where the boot process of f28 stalls for a few minutes (but this is not precisely where it fails).

I have some photos and also log files from dracut emergency shell.

This is where it takes a few minutes:
https://imgur.com/Hx6h3Mn

And it results in the following red error message (this boot without debugging mode / verbose errors)
https://imgur.com/VwNmpAU
You can also see where it finishes boot.

The f28 workstation image boot with the errors:
https://i.imgur.com/ZqKpE4b.jpg

Dracut dmesg:
https://i.imgur.com/RrSK2Rr.jpg

You can see the errors here with verbose output
https://i.imgur.com/1JPu0by.jpg
https://i.imgur.com/PMq0Hhq.jpg


I will also attach full dmesg, rdsosreport and journalctl output.


Things I've tried;
- Writing the usb livecd image using dd instead of fedora media writer
- Disabling many things in the bios
- Clearing bios (resetting settings to defaults)
- Tried to blacklist nouveau
- Tried with acpi=off kernel flag
- Using different USB ports and usb 2 ports
- Waiting a really long time
- Booting on both uefi and bios (ie. trying both)
- Taking out all but 1 stick of ram and switching ram sticks
- Taking out nvme drive 

Overall nothing has produced any different result.
Comment 1 Max 2018-08-07 06:47:44 UTC 
Created attachment 1473853 [details]
rdsosreport.txt

rdsosreport.txt
Comment 2 Max 2018-08-07 06:48:03 UTC 
Created attachment 1473854 [details]
journalctl
Comment 3 Max 2018-08-07 06:56:05 UTC 
Also some key messages (I think)

systemd-udevd[544]: seq 1845 '/devices/pci0000:00/0000:00:07.1/0000:24:00.2' is taking a long time
...
systemd[1]: Failed to start udev Wait for Complete Device Initialization.
....
systemd-udevd[544]: seq 1845 '/devices/pci0000:00/0000:00:07.1/0000:24:00.2' killed
....
dev-mapper-live\x2drw.device: job dev-mapper-live\x2drw.device/start timed out
Timed out waiting for device dev-mapper-live\x2drw.device
Comment 4 Vedran Miletić 2018-08-09 18:25:38 UTC 
> Ryzen
Possibly the same issue as bug 1608242.
Comment 5 Steven Haigh 2018-08-10 02:26:08 UTC 
Try downgrading your BIOS to one that contains an AGESA version *below* 1.0.0.4.

I lodged the report as linked in the above comment, and I believe this is an AGESA issue.
Comment 6 Max 2018-08-10 07:22:07 UTC 
@Vedran & @Steven - This is not really an option for me, because I need almost the latest bios version to run a "Pinnacle Ridge" or zen+ CPU on the motherboard (ie. a 2xxx as opposed to the earlier 1xxxx Ryzen CPU). And there is nothing about AGESA in the very last bios version that I'm using, only one earlier (which I definitely need).

Given the same hardware works fine for at least 2 other popular distros, I don't think it's reasonable to say that bios downgrade is the solution for this. Or if you are saying just to test, unfortunately if I do downgrade mine, it won't work at all with my CPU.

One thing that both ubuntu and manjaro have in common is that they don't use dracut, so maybe this can be pinned down to a bug in dracut? Not sure.

I can try just about anything else, but downgrading BIOS not an option for me, I already had to borrow a series 1xxx CPU to upgrade it in the first place to use the CPU I bought for this build.
Comment 7 Steven Haigh 2018-08-10 07:32:19 UTC 
Looking at the BIOS page:
https://www.asrock.com/mb/AMD/AB350M%20Pro4/index.asp#BIOS

It seems that 4.70 *should* work with your CPU.

I can tell you with 100% certainty that AGESA 1.0.0.2a works with the 2700x CPU.

BIOS version 4.70 for your board has AM4_1.0.0.1a - which should also work.

Note that the descriptions for v4.30 and v4.50 have:
- Update AGESA for future coming processors.
- Update AGESA for upcoming processors.

If you are willing to try a Beta BIOS, then "[Beta] 4.82" has AGESA 1.0.0.2a - which I am currently using.
Comment 8 Vedran Miletić 2018-08-10 07:51:23 UTC 
(In reply to Max from comment #6)
> @Vedran & @Steven - This is not really an option for me, because I need
> almost the latest bios version to run a "Pinnacle Ridge" or zen+ CPU on the
> motherboard (ie. a 2xxx as opposed to the earlier 1xxxx Ryzen CPU). And
> there is nothing about AGESA in the very last bios version that I'm using,
> only one earlier (which I definitely need).
> 
> Given the same hardware works fine for at least 2 other popular distros, I
> don't think it's reasonable to say that bios downgrade is the solution for
> this. Or if you are saying just to test, unfortunately if I do downgrade
> mine, it won't work at all with my CPU.
> 

I can confirm that Ubuntu 18.04 doesn't have the same issue for me.
Comment 9 Steven Haigh 2018-08-10 07:52:56 UTC 
What kernel version is used in Ubuntu 18.04?
Comment 10 Vedran Miletić 2018-08-10 07:56:23 UTC 
(In reply to Steven Haigh from comment #9)
> What kernel version is used in Ubuntu 18.04?

4.15.0-29
Comment 11 Steven Haigh 2018-08-10 07:59:31 UTC 
Dang, that's old. In fact, its even end of life.

I wonder if Ubuntu with a newer kernel would do the same... Seeing as it has affected both Arch and Fedora (both of which are more bleeding edge than Ubuntu), I tend to think it would...
Comment 12 Max 2018-08-10 08:07:36 UTC 
Ubuntu 18.04 kernel is 4.15. I tried the updated fedora livecd which definitely has a kernel at least that recent (and probably more recent).

I tried to flash my bios to 4.70 as you said Steven and it actually worked - Fedora LivdCD (workstation - default) booted to GUI without any issues (ie. no boot delay).

I will try to burn KDE spin now, but I suspect it will work the same.

Really weird though, someone should really fix the underlying issue.
Comment 13 Steven Haigh 2018-08-10 08:13:45 UTC 
The final fix will need to come in a new AGESA version from AMD - or someone doing the kernel work.

I've pinged a few AMD employees that do kernel code and passed the info on to them.

Will have to just wait it out until something happens.
Comment 14 Ben Cotton 2019-05-02 21:10:39 UTC 
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 15 Ben Cotton 2019-05-28 22:05:41 UTC 
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Note You need to log in before you can comment on or make changes to this bug.