I just realized the Dracut installation named the partition "OpenSUSE". I didn't realize until just now, while checking something else.
The Dracut image is installed on P7:
No wonder rEFInd defaults to an OpenSUSE logo for this installation--I thought that was odd! 
I figured I would mention it, since typically a Garuda installation does not label the partition at all unless I ask it to in Calamares. It's not problematic, but obviously not particularly desirable either.
Did you reuse an existing partition for that install?
Yes, but it was Spiral Linux. I'm pretty sure I had named the partition "Spiral_Linux" or similar as well.
I've never installed OpenSUSE on this particular machine.
Are other people not getting this on their Dracut installations?
I just wiped the partition label, then re-installed the same ISO and the installer did not create a partition label. I was mistaken that this was caused by the installer somehow. It seems ridiculous in hindsight--what does OpenSUSE have to do with anything?
I must have installed OpenSUSE on that partition at some point when I first set up the disk and have just completely forgotten about it, and never noticed the partition label until I went to make a change in GParted.
Is too late to join? I see a couple of old chips on the carpet that you guys tossed so I could eat those.
I am testing it since July when I saw the dracut hook probably mistakenly pushed cuz it was removed 1-2 days afterwards. But I stopped for many months waiting for something more complete in development and somehow missed this thread!
Restarted testing since I saw it included in the Latte-free ISO from another thread.
I am on a good old BIOS LEGACY machine if that matters somehow (probably not).
It's never too late to join the dracut party!
I re-started dracutting this time not with my custom installation but with garuda-dracut-support straight on my main machine. Much better!!
plymouth doesn't seem to display but I have no errors in journalctl so maybe that step is just too fast. I don't care much about plymouth anyway so if it's normal I won't test that one more./etc/dracut.conf.d/myflags.conf
Of course I need to test more with kernel updates and stuff but so far I reinstalled my kernel and it works.
I do have a question on the script you are using to run dracut.
I believe you launch /usr/share/libalpm/scripts/dracut-install?
Any way to skip the fallback image generation without editing that file which I presume would get overriden by an upstream update?
With initcpio it was easy I just needed to comment the fallback lines in *.preset file associated to the kernel, this never gets overriden, at least not automatically. Whoogling around I couldn't find how to do that with dracut and I cannot find the list of ALL possible options you can use in myflags.conf. Maybe it's possible to skip fallback in there but I can't find how. 
https://wiki.archlinux.org/title/Dracut
https://man7.org/linux/man-pages/man8/dracut.8.html
It's easy to do manually from CLI but when it is run by a hook I couldn't find how to skip the fallback.
You can override hooks by placing one with the same name in /etc/pacman.d/hooks
Ha not bad! Instead of going through dracutās config you attack it through pacman, clever! Gives me a couple of ideas to set that one hook! Thanks a lot! 
Thatās my XMas gift, right?
Ok thatās Section 4.3 here
Makes sense, now!
@FDG if you want to make your changes persistent, you could do some rudimentary config file support and add it to https://gitlab.com/garuda-linux/packages/stable-pkgbuilds/garuda-dracut-support/ 
Not exactly upstream if itās our own package
Honestly I thought dracut-install script was pushed by extra/dracut package and not garuda/garuda-dracut-support. With your gitlab link above itās obvious now. I have not looked at the package content until just now. 
Oh cool! You think my changes are good enough for that?
Honestly (yet again! lol) I was strongly under the impression my changes are very specific to my own installation and taste and that they would not benefit to be by default cuz they would reach potentially only a small number of users. I might have misexplained my changes. loll
If they are good though, yeah of course Iāll start a couple of gitlab tutos to learn how to do that and would add my stuff. Seriously part of my bucket list to have at least one in my life!
On my first change, I wanted to remove the useless (to me) not found modules when generating initramfs. But thatās me, what if some Garuda user needs one or more of those modules, they would not get added to their image with my changes but they would with the actual Garuda dracut config. Am I not too specific (would fit less users) with that change?
On my second change I wanted to completely skip the generation of initramfs fallback image. I would think those fallbacks are good for newbies who could mess something up, they would have a fallback image to boot off of.
That being said if 1 or more of those changes are good for a Garuda package then Iād be delighted to start learning how to push that in gitlab. After some more testing firstā¦ lol
Arenāt fallback images there to support hardware changes? Do they help newbies in some way as well?
Can you be more specific about what change you are making to suppress those messages?
Yeah youāre right, itās in case someone changes HW on his machine and the std image would not boot. Or if someone completely swaps his drive into another machine with different HW. That could anyway yield into other types of issues (from AMD to Intel, GPU brand swaps, depends which kernel the guy is running too, etc.).
Would it be a problem for Garuda if no fallback image were to be generated?
Yes I created /etc/dracut.conf.d/myflags.conf with this content:
omit_dracutmodules+=" acpi_cpufreq bootchart bluetooth crypt crypt-gpg crypt-loop dbus-broker ecryptfs nvmf uefi-lib dmraid lvm mdraid dash busybox ghash_clmulni_intel mksh network-legacy network dmsquash-live-ntfs dmsquash-live multipath stratis cifs fcoe fcoe-uefi iscsi nbd nfs pcspkr ssh-client nbd ssh-client biosdevname qemu qemu-net rngd network-wicked tpm2-tss memstrack squash lvmmerge resume "
This contains way more modules than those not found during image build, I put the other ones in there for other reasons, my plan is to slim down that line to only those not found during image build.
Why not make it optional based on a config file? It seems like a good idea to have it by default and then people could remove it if they opted to do so.
The modules that are found and not found depend on what is installed. If we hard exclude all the modules not found on your specific install then people with different configurations may have issues.
For example, what are the implications of removing BT support? Does that mean that someone with a BT keyboard wonāt be able to put their password in to enter emergency mode?
Likewise, removing support for crypt and various filesystems seems like a bad idea broadly.
One of the big advantages of dracut is that it is pretty good at automatically figuring out what to put in the initrd. If we hard filter that list to a broad degree, it means that everyone needs to go back to manual configuration.
Iāll perform more thorough tests with the specific hooks and if it seems good Iāll get back on the details of what I did and that config file for optional opting out.
Amazing package!
There you go Iāve said it all. After a lot of tests and booted so many times even Einstein himself wouldnāt be able to calculate the number, I ended up with one of the best config in my Garuda installations.
I managed to build an image that boots the kernel virtually as fast as initcpio (something I could not achieve since July with my own dracut, not garuda-dracut-support).
ā°āĪ» systemd-analyze
Startup finished in 368ms (kernel) + 4.513s (initrd) + 9.990s (userspace) = 14.872s
graphical.target reached after 9.989s in userspace.ā°āĪ» systemd-analyze blame | head
8.260s NetworkManager-wait-online.service
4.432s dev-ttyS0.device
4.432s sys-devices-platform-serial8250-tty-ttyS0.device
4.431s dev-ttyS1.device
4.431s sys-devices-platform-serial8250-tty-ttyS1.device
4.431s dev-ttyS3.device
4.431s sys-devices-platform-serial8250-tty-ttyS3.device
4.431s dev-ttyS2.device
4.431s sys-devices-platform-serial8250-tty-ttyS2.device
4.427s sys-module-configfs.device
For comparison, this is what I get with MKINITCPIO (donāt mind network wait, look at kernel times:
ā°āĪ» systemd-analyze
Startup finished in 4.428s (kernel) + 13.502s (userspace) = 17.931s
graphical.target reached after 13.502s in userspace.ā°āĪ» systemd-analyze blame | head
11.836s NetworkManager-wait-online.service
4.018s disables-usb-wakeup.service
432ms plymouth-start.service
333ms upower.service
243ms systemd-tmpfiles-setup.service
151ms xfs.mount
112ms dev-nvme0n1p1.device
94ms plymouth-deactivate.service
94ms plymouth-quit-wait.service
93ms plymouth-quit.service
It doesnāt stop there.
With manual config in /etc/dracut.conf.d/myflags.conf it builds a clean image by excluding all modules it cannot find on my machine, including UEFI stuff (I am an old LEGACY fan).
Even better, I managed to cut in HALF the image size. I found out the module that makes the biggest difference in size is plymouth.
With plymouth bulit in I get 38megs and omitting plymouth I get 17megs!
Since I donāt see plymouth splash screen every time cuz it flies too fast and when I do see it itās 1sec or so, there is no point for me to have plymouth built in the image. A slower machine + a guy who loves to see a progress bar with a splash screen would better benefit from it.
I have tested a couple of DKMS unload/load modules (like uninstalling virtualbox and reinstalling and tested 5 kernel installs.
.rw------- 20M root 27 Dec 13:50 ļ initramfs-6.2.0-rc1-tkg-bore.img
.rw------- 18M root 27 Dec 13:23 ļ initramfs-linux-lts.img
.rw------- 17M root 27 Dec 13:13 ļ initramfs-linux-tkg-bore-amd.img
.rw------- 17M root 27 Dec 13:25 ļ initramfs-linux-xanmod.img
.rw------- 19M root 27 Dec 13:21 ļ initramfs-linux-zen.img
I was able to boot into all of them, except 6.2RC1 cuz I made a mistake while compiling but that doesnāt matter here.
As you can see, all those images are pretty small.
I love Garuda dracut, I do not want to see mkinitcpio on my machines ever again!
On a next post I will expose my solution to skip fallback image generation. Easy with my fingers up my nose and so far after countless image generations and boots, no issue at all. I think the solution is rather clean, but Iāll learn from the experts on that.
Thanks a lot Garuda team (mostly TNE and Dalto I think?) for bringing this package!
explain what
are
It could by TNE and Nico, or Nico and TNE
Nichts genaues weiĆ man nicht 
It's my package with some code from the AUR! Thanks for the nice words :3
This package will be used in the next Garuda release, maybe I should invite you to the new release thread as a very diligent tester of this and also the dr460nized rework? Would you be interested in that? @FGD
Would I? Yes of course, count me in!
Last important test (to me) I wanted to perform: see how my no-fallback image solution works out in the event of a downgrade and upgrade of dracut packages.
Since downgrade does not find any other version than 0.2 of garuda-dracut-support I couldn't test this one. But I did test downgrading and re-upgrading dracut.
Flawless. lolll
For DALTO and others who might be interested, this is my solution to automatically not generate a fallback image which so far does not require any manual intervention through all the test cases I ran:
Created:
/etc/pacman.d/hooks/
.rw-r--r-- 255 root 27 Dec 12:51 ļ
60-dracut-remove.hook
.rw-r--r-- 453 root 27 Dec 14:05 ļ
90-dracut-install.hook
To overwrite those of the same name in /usr/share/libalpm/hooks.
File contents:
[Trigger]
Type = Path
Operation = Remove
Target = usr/lib/modules/*/pkgbase
[Action]
Description = Removing initramfs...
When = PreTransaction
Exec = /usr/share/libalpm/scripts/dracut-remove-no-fallback
NeedsTargets
[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules//vmlinuz
Target = usr/lib/dracut/
Target = usr/lib/systemd/systemd
[Trigger]
Operation = Install
Operation = Remove
Operation = Upgrade
Type = Package
Target = -dkms
[Action]
Description = Updating initramfs...
When = PostTransaction
Exec = /usr/share/libalpm/scripts/dracut-install-no-fallback
NeedsTargets
From there I created 2 scripts located in the same folder as the original scripts (those from garuda-dracut-support):
/usr/share/libalpm/scripts/
.rwxr-xr-x 725 root 26 Dec 16:29 ļ /usr/share/libalpm/scripts/dracut-install-no-fallback
.rwxr-xr-x 224 root 26 Dec 16:28 ļ /usr/share/libalpm/scripts/dracut-remove-no-fallback
File contents:
#!/bin/bash -e
all=0
lines=()
while read -r line; do
if [[ "${line}" != */vmlinuz ]]; then
all=1
continue
fi
lines+=("/${line%/vmlinuz}")
pkgbase="$(<"${lines[-1]}/pkgbase")"
install -Dm644 "/${line}" "/boot/vmlinuz-${pkgbase}"
done
if (( all )); then
lines=(/usr/lib/modules/*)
fi
for line in "${lines[@]}"; do
if ! pacman -Qqo "${line}/pkgbase" &> /dev/null; then
continue
fi
pkgbase="$(<"${line}/pkgbase")"
kver="${line##*/}"
echo ":: Building initramfs for ${pkgbase} (${kver})"
dracut --force "/boot/initramfs-${pkgbase}.img" "${kver}"
done
#!/bin/bash -e
while read -r line; do
if [[ "${line}" == */pkgbase ]]; then
read -r pkgbase < "/${line}"
rm -f "/boot/vmlinuz-${pkgbase}" "/boot/initramfs-${pkgbase}.img"
fi
done
If I missed a use case where this could break, plz let me know so I can test it.