Most commonly this is caused by graphics drivers not loading correctly. This is the relevant resource for troubleshooting: Computer doesn’t boot, boots to a black screen, or stops at a message
Do you mean quiet? I took one out once and it broke the Plymouth splash; I believe if you wish to preserve the splash both are needed.
Are you sure you chrooted correctly? That is the hostname in the live environment.
It is unclear what this comment is in reference to, but these terms are very common in Linux, so “doesn’t seem Unix-like at all” seems like an odd conclusion. Paste your findings in the thread where others can have a look.
First, I suppose a compelling reason to fork it would need to be identified. 
Dracut is very extensible; most realistic use cases can be achieved from within the existing framework. It’s hard to imagine a change that would be significant enough to warrant someone maintaining a fork.
Additionally, it is a project with a lot of complex low-level mechanisms and is probably not easy to work with. Someone would have to be very talented, motivated, and have a lot of free time to want to take that on.
There isn’t anything suspicious about it at all, they just wanted to consolidate the resources into a single location. It was handled in the most open-sourced way possible: they opened an issue for it on GitHub and contributors to the project helped do the work.
See here: Offboard dracut from kernel dot org infrastructure. · Issue #1837 · dracutdevs/dracut · GitHub
johannbg commented on Jun 5, 2022 •
edited
Consolidate all dracut’s resources to a single landing space here on github.
- Move wiki from the kernel.org hosted wiki to github’s wiki ( Done me and apparently Harald as well )
- Add a redirect on kernels wiki page to githubs ( Done Harald )
- Send announcement on linux-initramfs mailings about these changes ( Done Harald )
- Rewrite the repo’s README to reflect those changes.
Not for nothing, but no one is forcing you to use dracut. It’s just a default package, it’s not baked in. Just remove it if it is creating such a conflict for you. Mkinitcpio is still available in the same repo it has always been in, ready for you to install whenever you wish.
This does not seem likely to be related to your issue. If the only way you can boot the installation is the fallback image, that doesn’t mean the fallback image is the source of any given issue you find. Recovery mode may be a red herring in this case; I would start by troubleshooting it as a normal network issue. What’s in /etc/resolv.conf?
On the metal is the only supported installation method; there are known issues if installed in a VM.