After install the boot hangs at the ramdisk initialization

The live usb works fine, but after install the boot hangs at the ramdisk initialization.

I see in /etc/default/grub there are apostrophes where quotes should be at, duplicated bootline parameters. And from the chroot into the system I noticed the hostname is garuda-xfce and not what I entered on install. I'm able to boot into recovery mode, but the networking dns does not resolve.

I'm skeptical about this system feedback using broad planning terms like "modules tree" and "sanity check" in reference to header files and checksums. Doesn't seem Unix like at all, but improperly sourced and obfuscating. Soft Language is exactly what I would expect from a widely written Academic distribution such as Fedora, its certainly no BSD man pages fresh from the Labs. That attention to detail is confirmed to be what built the Arch community.

Minds well add some Finnish subtitles instead of this craptastic redubbing sans empiricism. Seems no one has forked Dracut yet. Why has no one forked it yet? If its not fork-able its not installable. I don't want untested virgin code in my system with a glowing clean slate of history. I would use proprietary software before touching that steaming pile because at least then it passes the standards of a blind fool.

Very Suspicious Misdirection:

In another thread it was mentioned adding vmd module to dracut and it having something to do with nvme drives.

Perhaps this has something to do with dns not resolving in recovery mode:

(Is anyone booting this distribution on metal or is it a proof of concept for virtual machines?)

Please post the terminal/konsole input and output as text (no pictures) from the following command:

garuda-inxi

as text between 3 ~ in first and last line.

1 Like

This is definitely something to investigate. Personally, I never experienced the last 2 ones.

I don’t really get the message of this, what does it refer to?

Of course, it is proof of concept only /s :woozy_face:

As pointed out already, there are system information missing. Without those, troubleshooting any of this is rather pointless.

4 Likes

If your using sway and have a Nvidia graphics card, you may need to modify the logind config and the wayland sessions config to be sway --unsupported-graphics

1 Like

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. :thinking:

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.

5 Likes

I installed mkinitcpio packages entered Y to removing Dracut:
https://archlinux.org/packages/core/any/mkinitcpio/
https://archlinux.org/packages/core/x86_64/mkinitcpio-busybox/

I was missing presets so I reinstalled the kernel package:
https://archlinux.org/packages/core/x86_64/linux-lts/

The fonts were giving issues so I added (setfont) to the BINARIES section of /etc/mkinitcpio.conf and regenerated mkinitcpio using both -g and -P because it does a FAKE attempt if you do not specify -g (WTF???)

I then edited grub kernel boot line to remove quiet quiet splash

update-grub

And my system startup is now hanging at:

[ OK ] Started Accounts Service.

ctrl + alt + F2 I have a working console with network access. Updates are running... Mission accomplished!!! :rofl:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.