The issue has been reported to Red Hat.

https://bugzilla.redhat.com/show_bug.cgi?id=1608242

Many thanks for this!

Thanks for information. I'm trying to get AMD attention on Twitter with this topic.

I hope it's not against any rules or anything to talk about other vendors here, because I don't have an ASRock board but I'm having the same problem and this is the only hit I've gotten for the symptoms when searching online.  I updated the bios of my MSI board (x370 SLI PLUS) today to one that mentions "Update AGESA Code 1.0.0.4C" in its patch notes, and immediately started seeing a long hang during bootup with the same sort of messages as the OP.  It eventually boots on its own (or ctrl-C to move on early), but udev is a broken mess when doing so, spawning 30+ processes and frequently causing spam in dmesg about systemd-udevd hanging for over 120 seconds.

Unfortunately I'm not able to downgrade the bios back to a usable version because the BIOS-based flash won't allow downgrading, but I did discover a workaround that might also be relevant to figuring out what's happening.  I have a habit of not removing old kernels after updating, so I was able to experiment with a few and found that 4.14.13 has no issues, but 4.16.12 and 4.17.8 both exhibit the broken behaviour.  I don't know if it's an AGESA problem or a kernel bug, but somewhere between 4.14.13 and 4.16.12 something changed in the kernel that is making something break horribly.

Also, I don't know if the OP ever tried getting help on the L1techs forum, but I searched there myself and saw that a few of them noticed something I also did:  the hardware device at the beginning of those errors is listed as AMD's "Encryption Controller", managed by driver "ccp".  It's used for hardware encryption but apparently is also related to AMD's Platform Security Processor (PSP).  Kernel 4.14 is when they first started adding support for the PSP part, so maybe incomplete support for it is why that one works okay for me.  Anyway, one person claims the problem went away when using a kernel compiled with CONFIG_CRYPTO_DEV_SP_PSP=n.  They didn't mention virtualisation or any negative effects, so YMMV there.  

For now, I'm just going to keep using the old 4.14 kernel I have and watch for a fix.  I got lucky by still having that kernel around, because it's in a sweet spot of being barely new enough to have the nested page table (NPT) bug fix (which is a big deal for GPU passthrough to a VM, which I use heavily), but is old enough to not be affected by whatever is breaking things.  

Neither option (disabling the feature in a kernel compile and hoping it doesn't affect anything important, or using a 4.14 kernel) is a good solution, but I'm mentioning everything I've found on the problem so far in case it helps anyone else with finding a workaround or reporting the problem.  This situation sucks, but hopefully it gets noticed and fixed soon.

ASRock X470 Taichi - had to downgrade BIOS to (beta) 1.35 and Fedora 28 boots normally.

@ASRock - please Investigate it with AMD - this is really annoying!

I have the same issue on my AB350 Pro4 with Ryzen 5 2600 after updating BIOS from 4.70 to 5.00 version. It doesn't reproduce on Arch Linux, only on Fedora.

EDIT: BIOS 4.90 is working fine, so the issue is in the latest 5.00 version. Interesting, that this BIOS and 1.50 for X470 both have AGESA PinnaclePI-AM4_1.0.0.4. Maybe this is the reason.

Im having exacly the same issue - Fedora 28 Live can't boot with udevd errors.

I can't find anything in BIOS that can prevent this from happening. My system is stable, no manually overclocked. I'm able to boot Ubuntu 18.01, but I need to run Fedora and I'm very disappointed.

ASRock X470 Taichi. R7 2700X, 32GB RAM (2933MHz), Radeon RX 570.

BIOS 1.50

It happens every time.

Old BIOS 7B79v13 works fine. Latest BIOS 7B79v14 fails exactly the same way.

The system takes very long time to shut down and hardware acceleration for virtualization (KVM) is not working for me after the bios update. It is definitely turned on on the bios (SVM, SR-IOV, IOMMU), running virtual machines is unfortunately the main reason I purchased this computer in the first place.

I've tried many UEFI settings (also clear cmos) without any success, I'm very certain that this bug was introduced with the new UEFI 1.5 version. 

I'm not sure if this is relevant but I did not overclock anything.

@asrock can you confirm this behavior? This is one of the most expensive AM4 motherboards on the market, I would hope to see this resolved in the near future. btw where can I find the changelog of a bios version? 

Thx for your reply. I will head over to the forums you mentioned and see if someone can help me...

Greetings from Lower Bavaria

Tobi

the bad news = i know very very little about linux

the good news = level1techs (on you tube and a forum i think) seem to know a very very lot about linux and wendell the you tube presenter seems to favour asrock boards

it may well help you faster if you ask over there while waiting for answer here

i know he uses a x370 taichi ,i dont know if he has a x470 yet though