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.
Created attachment 1473853 [details] rdsosreport.txt rdsosreport.txt
Created attachment 1473854 [details] journalctl
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
> Ryzen Possibly the same issue as bug 1608242.
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.
@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.
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.
(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.
What kernel version is used in Ubuntu 18.04?
(In reply to Steven Haigh from comment #9) > What kernel version is used in Ubuntu 18.04? 4.15.0-29
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...
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.
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.
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.
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.