dracut VS ramroot

Upstream has been telling people not to use a central configuration file for 8 years so nobody should really be putting anything in there to begin with. One can make a reasonable argument that ZFSBootMenu ought to override the configuration file just like it overrides the configuration drop-in directory, but another can make a reasonable argument that people who really know what they want may wish to load common configuration options for both their system and ZBM images in /etc/dracut.conf.

I absolutely have no idea... Seems like somehow something is not supported. You should create an issue in the dracut repo: https://github.com/dracutdevs/dracut/issues. That's something you should probably everywhere like I did in my issue: https://www.reddit.com/r/voidlinux/comments/11ofqt2/booting_with_dinit. The void community can sometimes be really unhelpful so I hope you will get help there.

bug 1529311 is closed as duplicate of bug 1476039 which was fixed by https://access.redhat.com/errata/RHBA-2018:0964 included in dracut-033-535.el7. These patches were mentioned in 1476039: https://github.com/dracutdevs/dracut/commit/19453dc8744e6a59725c43b61b2e3db01cb4c57c and https://github.com/dracutdevs/dracut/pull/261. Also it was mentioned that it was fixed in

It's a shell script that sets up some basics and runs an event loop to run hooks that eventually lead to the availability of your root device.

dracut can build initrd with bluetooth support

The documentation is super minimal, but the livenet module supports torrent files using the live:torrent: URL syntax.

Nope, all these environments are missing initial device configuration required for keyboard to be able to connect. (There was an attempt to add bluetooth support into dracut, that didn't go well)

I get exactly this error. So it turns out, the decryption depends on a systemd unitsystemd-cryptsetup-generator, which will not read any embedded cmdline parameters, only ones passed in the commandline so when the commandline parameter is asking to decrypt things, it is not generated.

Now I can use ramroot and run the whole OS on RAM.

Anyway, I wrote and maintain a guide to make this setup: https://mags.zone/help/arch-usb.html. I also made a package to optionally load everything to RAM during boot: https://github.com/arcmags/ramroot.

I wrote a tool to load root entirely into RAM on Arch. It checks available RAM and prompts on boot.

You could also use the Arch Linux guide above and install Arch Linux on the USB drive, making sure the boot and root partition sizes are less than the amount of ram in the machine you are booting on. Then install ramroot which will load up your system into ram on boot. This will mean the system runs off ram and not USB. If you need to make changes, install applications or update, you could boot it normally so it runs off USB as any changes won't be saved if it is booted into ram. If your home folder is on another partition on the USB, I don't think that is loaded into ram on boot so you can still save files to it and any personalisations should also be kept between boots.