So I did a test install on a NUC with the Cassini ISO. I saw the boot loader choice and chose grub since I use btrfs snapshots and will need to boot one.
However, mkinitcpio was not installed and dracut was. So how does that affect any package I install that tells me to modify a initcpio config file and run mkinitcpio??
It depends.
dracut can automatically handle a lot of things and sometimes doesn’t need modifications. We would need an exact example to give more information.
If you are using grub, you use sudo dracut-rebuild instead of sudo mkinitcpio -P.
The example I was thinking about was the overlayfs for grub-btrfs. If I add that I have to edit /etc/mkinitcpio.conf and then run mkinitcpio -P
So that is something I usually do when I install grub-btrfs
I don’t think dracut doesn’t need any modification for that. It supports it out of the box.
However, grub-btrfs needs to be modified. Support was recently committed to a branch where the author is working on that support.
In the meantime, you have a few choices:
mkinitcpio
/etc/grub.d/41_snapshots-btrfs by adding rd.live.overlay.overlayfs=1 to kernel_parameters
rd.live.overlay.overlayfs=1
Thanks for the help. It has never been clear when I need the overlayfs or not. When I use EOS-Plasma I can boot a snapper snaphot without any errors that I know of.
Yes, sddm/plasma will let you boot off a read-only snapshot and do a restore.
My experience with 3 computers to move from mkinitcpio to dracut: 2 laptop and 1 desktop PC were total failure. I’m using LUKS-encrypted partitions on all computers, that encryption is offered during EndeavourOS installation via Calamares (LUKS1 is used as GRUB2 still does not support properly LUKS2, although cryptsetup is using LUKS2 by default). On those machines were root partition (EXT4, encrypted) together with boot folder but EFI (512 MiB FAT32, ~10 MiB used, unencrypted) and home (EXT4, encrypted) are separate partitions.
First result when using guidance at here, was one unbootable desktop PC remotely, which still is waiting to be fixed.
What is wrong with that tutorial? First place: how to properly move back from dracut to mkinitcpio is currently missing.
Initially after dracut was installed, reconfigure-kernels command started, still I ended up after reboot in unbootable system. I somehow needed also reinstall GRUB via chroot:
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=EndeavourOS-grub --modules="part_gpt part_msdos"
sudo grub-mkconfig -o /boot/grub/grub.cfg
These additional modules were needed due to LUKS-encrypted partitions. Without these modules there were some error messages during boot but still booted. With these modules these error messages are gone.
When you are using LUKS-encrypted partitions, entering to chroot is a bit more challenging:
lsblk -f # this will show proper UUID value of encrypted partition, also after decrypting it is useful to check again with that command
sudo cryptsetup open --type luks --allow-discards /dev/nvme0n1p2 mycryptdevice && sudo mkdir -p /run/media/liveuser/<UUID> && sudo mount /dev/mapper/mycryptdevice /run/media/liveuser/<UUID> && sudo arch-chroot /run/media/liveuser/<UUID> && sudo mount /dev/nvme0n1p1 /boot/efi
There is needed to fine tune the dracut conf - this does not work out of the box in case LUKS-encrypted partitions. I got error messages: “EFI mount failed, Failed to start CLI Netfilter Manager”
Then tried to figure out, what is needed to add to dracut conf. First checked logs:
journalctl -xb -p err
Failed to start CLI Netfilter Manager.
A start job for unit ufw.service has failed
Failed to mount /boot/efi.
A start job for unit boot-efi.mount has failed
Then investigated:
journalctl --boot=-1 --unit=ufw.service
ufw.service: Main process exited, code=exited, status=1/FAILURE
ufw.service: Failed with result 'exit-code'.
ufw-init[381]: modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.1.3-arch1-1
find /lib/modules/ -type f -iname "*ip_tables*"
./6.1.4-arch1-1/build/include/uapi/linux/netfilter_ipv4/ip_tables.h
./6.1.4-arch1-1/build/include/linux/netfilter_ipv4/ip_tables.h
./6.1.4-arch1-1/kernel/net/ipv4/netfilter/ip_tables.ko.zst
journalctl --boot=-1 --unit=boot-efi.mount
mount: /boot/efi: unknown filesystem type 'vfat'.
boot-efi.mount: Mount process exited, code=exited, status=32/n/a
boot-efi.mount: Failed with result 'exit-code'.
Somehow it searched module from wrong folder - this shows, that initramfs was not properly updated. There were kernel update from 6.1.3 to 6.1.4 happened beforehand.
Then tried to load vfat module via dracut.
Firstly checked, which modules exist:
find /lib/modules/6.1.4-arch1-1/kernel -type f -iname "*fat*"
./fs/fat/fat.ko.zst
./fs/fat/vfat.ko.zst
./fs/exfat/exfat.ko.zst
Then read dracut official guidance and created a file /etc/dracut.conf.d/filesystems.conf with content:
filesystems+=" vfat "
Then regenerated initramfs:
sudo reinstall-kernels 1>reinstall.log 2>reinstall-error.log
This was intentional to get full logs.
Crucial parts from log:
dracut-install: Failed to find module 'vfat '
dracut: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.5FI5Dy/initramfs --kerneldir /lib/modules/6.1.4-arch1-1/ -m vfat
We remember, that previously we checked, that vfat module existed at /lib/modules/6.1.4-arch1-1/kernel/fs/fat/vfat.ko.zst and also /lib/modules/6.1.4-arch1-1/kernel/fs/fat/fat.ko.zst were there.
Here are full logs:
reinstall-kernels-logs.pdf (79.0 KB)
Just to mention, that packages kernel-install-for-dracut binutils elfutils pigz were installed while moved from mkinitcpio to dracut.
Then I decided to move back to mkinitcpio from dracut:
sudo pacman -Syu mkinitcpio # agree with kernel-install-for-dracut removal
sudo pacman -Rns dracut cpio elfutils pigz
… as these packages were installed and now not needed. Also /var/log/pacman.log confirmed, what were installed, although I documented initially, when installed dracut, which packages were installed and which removed:
[2023-01-05T20:46:55+0200] [PACMAN] Running 'pacman -Syu --needed kernel-install-for-dracut'
[2023-01-05T20:46:55+0200] [PACMAN] synchronizing package lists
[2023-01-05T20:46:56+0200] [PACMAN] starting full system upgrade
[2023-01-05T20:49:27+0200] [PACMAN] Running 'pacman -Rns mkinitcpio-openswap'
[2023-01-05T20:49:32+0200] [ALPM] transaction started
[2023-01-05T20:49:32+0200] [ALPM] removed mkinitcpio-openswap (0.1.0-3)
[2023-01-05T20:49:32+0200] [ALPM] transaction completed
[2023-01-05T20:49:32+0200] [ALPM] running '30-systemd-update.hook'...
[2023-01-05T20:49:36+0200] [PACMAN] Running 'pacman -Syu --needed kernel-install-for-dracut'
[2023-01-05T20:49:36+0200] [PACMAN] synchronizing package lists
[2023-01-05T20:49:36+0200] [PACMAN] starting full system upgrade
[2023-01-05T20:49:46+0200] [ALPM] running '60-mkinitcpio-remove.hook'...
[2023-01-05T20:49:46+0200] [ALPM] transaction started
[2023-01-05T20:49:46+0200] [ALPM] warning: /etc/mkinitcpio.conf saved as /etc/mkinitcpio.conf.pacsave
[2023-01-05T20:49:46+0200] [ALPM] removed mkinitcpio (34-2)
[2023-01-05T20:49:46+0200] [ALPM] installed cpio (2.13-3)
[2023-01-05T20:49:46+0200] [ALPM] installed dracut (056-1)
[2023-01-05T20:49:46+0200] [ALPM] installed kernel-install-for-dracut (1.6-1)
Yes, we needed to remove mkinitcpio-openswap initially in order to install kernel-install-for-dracut and its dependencies as guided also here.
Then rebuilt kernel in chroot environment again.
sudo pacman -Syu mkinitcpio-openswap
This may vary as sometimes you might need to reinstall even kernel itself (sudo pacman -Syu linux).
Result was emergency shell:
Then finally discovered, what was wrong. Thanks to hints from EndeavourOS IRC there was found, that /etc/mkinitcpio.conf file was changed, missing parts were:
FILES="/crypto_keyfile.bin"
HOOKS="base udev autodetect modconf block keyboard keymap encrypt filesystems fsck"
COMPRESSION="zstd"
Then restored it:
sudo cp /etc/mkinitcpio.conf.pacsave /etc/mkinitcpio.conf
Then updated initramfs via reinstalling:
yay -S mkinitcpio-openswap
If you are in chroot environment, then often is live USB kernel version different than in chrooted OS. Therefore you cannot even use mkinitcpio -P. Actually inside /etc/mkinitcpio.d/ folder were no profiles, so that command did not work anyway.
Then finally after exiting chroot and rebooting from local storage, I got back the system.
Conclusion: I guess dracut is good system but for LUKS1, LUKS2-encrypted partitions there is needed to improve it. Also guidance and official announcement - I was impressed by decision, that dracut was officially adopted in EndeavourOS 2022.12 Cassini and therefore decided also to move to it but it was too early.
have you checked how RHEL-based distributions like Fedora or CentOS use dracut with LUKS? They use dracut for a very long time already (since 2009) and I can’t believe that LUKS does not work with it.
I found during searches also some hints from Red Hat but haven’t time to dig into it. My real work is a bit different than such one. But that is one good idea to dig into… Also reminding, that these computers are production ones and not meant for experiments. I really hoped, that as dracut is now official in EndeavourOS, it is really thoroughly tested but it seems I was wrong. I just wrote that journey for case anyone else might benefit it and also facing similar situation and wants rescue from it.
I can explain what needs to be done in a few minutes. Currently in a meeting.
I hope the official EndeavourOS guidance (and dracut, if needed) will be improved and at some point it will be ready to move to dracut from mkinitcpio also for LUKS (1,2) users. I hope there will be then such announcement and I hope I will notice it also.
I will update the documentation as soon as I have time to test it but what you need to do if you are using grub is create a file /etc/dracut.conf.d/encryption.conf and include the following content:
install_items+=" /etc/crypttab /crypto_keyfile.bin "
You should do that before running sudo dracut-rebuild
I will try to test that later today and update the documentation as long as everything works.
Also, I just took a read through your notes in more detail and it looks like there may be some confusion somewhere.
It looks like you followed the instructions for systemd-boot instead of the instructions for grub.
There should be no need to do this. The only case I can think of where this would happen is if you rebuilt your initrams without your ESP mounted.
Sounds like I somehow understood wrongly that guidance and installed kernel-install-for-dracut, although I have GRUB and should install eos-dracut - I admit my mistakes. This might be one reason, why my journey failed with dracut. I guess the order would be better if to start with installation step and not the command, which does not exist unless proper packages are installed. Then there will be no such mistakes like I did - installed wrong packages. Table of contents would be appreciated - this will give also brief overview of article and allows to jump directly to right part.
I also considered to switch to systemd-boot as it is less prone to break but it seemed even deeper digging and didn’t switch yet. Although we remember one serious issue in August 2022 with GRUB, which ended up with unbootable system and therefore systemd-boot could be reasonable step. That guidance seemed not complete and didn’t have time to dig deeper. But it sounds promising and hopefully at some point I will switch to it. There in guidance are a bit different information, that I see in system. E.g. EFI is not in /efi but usually is in /boot/efi , also there were no such entries like described in guidance but this might be as I haven’t installed yet systemd-boot. Actually there in article is described usage but not installation - this was main obstacle, I could not follow that guidance.
Probably when using systemd-boot, that /etc/dracut.conf.d/encryption.conf with install_items+=" /etc/crypttab /crypto_keyfile.bin " isn’t necessary. But such descriptions are necessary, especially typical situations, where certain modules are needed to load, e.g. having nVidia GPU and noticed also from log:
journalctl -xb -p err
systemd-modules-load[321]: Failed to find module 'crypto_user'
systemd-modules-load[321]: Failed to find module 'v4l2loopback'
systemd-modules-load[321]: Failed to find module 'nvidia-uvm'
systemd-modules-load[321]: Failed to find module 'pkcs8_key_parser'
… although in /lib/modules-load.d/ were files bluez.conf, nvidia-utils.conf, pkcs8.conf and also OBS Studio virtual camera module conf exist.
I think there may be more that needs to be done. My initial quick test failed when the install was encrypted.
I will get a good test and then post the instructions.
The wiki article has been updated with the instructions for converting to dracut when using luks encryption.
Thank you! Is there any difference with systemd-boot in case of using (LUKS) encrypted partitions? That guidance of systemd-boot seems only having usage section but how to install? Sounds like the Arch wiki article covers it. Still there are questions - how to move from GRUB to systemd-boot and also back if needed.
Yes. With systemd-boot, you don’t put the keyfile into the initramfs since it is unencrypted. As a result, if you have multiple encrypted partitions, you will be asked for your password more than once.
Changing your bootloader is a bigger effort than switching to dracut. I would not advise doing so unless you have a reason to.
The instructions for that are here:
if you have multiple encrypted partitions, you will be asked for your password more than once.
That is not a good solution for now. With GRUB only once the password is asked even in case of multiple encrypted partitions.
Thank you for guides! At some point will test in virtual machine. Somehow we need to keep up with the times and make those switches with new components also in production machines.
That hasn’t been the case for me. I’ve switched to systemd-boot now, but when I was on GRUB, I had to enter the password for my system drive (a SSD) and then the different password for my data drive (a HDD). Do you mean partitions on the same drive and/or that share the same password?