Hi all,
I generally used to use systemd-boot on Arch (dualbooting Windows 10), but when switched to EndeavourOS, due to laziness I’ve stayed on Grub. Now I’ve decided to come back to systemd-boot and followed this tutorial https://forum.endeavouros.com/t/tutorial-convert-to-systemd-boot/13290
Everything worked but I’ve some issue that I cannot find a way to resolve:
#Issue 1, and the most important of the two: when I try to install intel-ucode I get this error:
[nemo@psi ~]$ sudo pacman -S intel-ucode
[sudo] password for nemo:
resolving dependencies...
looking for conflicting packages...
Package (1) New Version Net Change
extra/intel-ucode 20210608-1 4,55 MiB
Total Installed Size: 4,55 MiB
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [------------------------------------------] 100%
(1/1) checking package integrity [------------------------------------------] 100%
(1/1) loading package files [------------------------------------------] 100%
(1/1) checking for file conflicts [------------------------------------------] 100%
(1/1) checking available disk space [------------------------------------------] 100%
error: Partition /boot too full: 9574 blocks needed, 8450 blocks free
error: not enough free disk space
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.
The problem I think is related to the fact that the EFI partition is the windows one, so probably is too small (?) but before, when I tried to install systemd-boot using the arch wiki the intel-ucode.img was there and there wasn’t any problem regarding space. I’ve uninstalled it, because I couldn’t find the intel-ucode.img anywhere after the switch and now I cannot install it anymore.
#Issue 2: this is not a real issue, but an annoyance mostly. The eos-systemd-boot package (I think is his “fault”) create the entry for systemd-boot using the UUID for the partition as a name, and also place the linux, init etc inside a folder with the same name. That work, but is not very human-readable so I would rather switch to the standard systemd-boot installation; basically the one where the files are in /boot/EFI/ and the entry I can call it whatever I want without something recreating it every time a new kernel is installed.
Also, if you were converting from an Arch-wiki implementation, did you clean up the old kernels/initramfs? If not, you might have doubled the number of initrds which would consume much more space.
That tutorial has two methods. It sounds like you want the manual method instead of the kernel-install method. That uses the standard Arch kernel locations and you can create the loader entries however you like. That method is essentially the same as the arch wiki method. It is just described a bit differently.
In an Arch-based distro, the initramfs and the kernels will just be in /boot/. However they will have a constant name/path as you are wanting.
I’ve tried to clean but the folder wasn’t there and I cannot find any duplicated entries for initramfs.
That tutorial has two methods. It sounds like you want the manual method instead of the kernel-install method. That uses the standard Arch kernel locations and you can create the loader entries however you like. That method is essentially the same as the arch wiki method. It is just described a bit differently.
regarding this it’s ok for me to switch to manual, I’ve always use that method, but the part that I don’t understand is why the initramfs etc aren’t copied in the /boot partition but in the UUID-named folder. It’s also that because of the kernel-install script and I’ve stupidly didn’t noticed it?
I do all my partition operations in Linux. That being said, how risky it is depends on what is adjacent to it and if that can be resized. I would definitely recommend a backup first if you don’t already have one.
Ok, I’ve solved the partition size issue and tested both Eos and Win and both boot up correctly. Now the only thing I’ve to fix is that even if I’ve removed eos-systemd-boot the initramfs and vmlinuz-linux img are automatically created in the UUID-named folder. There is a way to undo the kernel-install script?
Oh, wait, the mkinitcpio templates need to be reset to default.
The easiest way to do that is to delete those scripts and then re-install your kernel(s).
The files to delete are in /etc/mkinitcpio.d
If you reinstalled already it is possible there are pacnew files in that directory. If there are, you can just overwrite the other files with the pacnew files.
changing the path with only /boot generate an error when trying to reinstall linux package
(3/5) Install DKMS modules
==> dkms install --no-depmod -m nvidia -v 465.31 -k 5.12.12-arch1-1
==> depmod 5.12.12-arch1-1
(4/5) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
-> -k /boot/vmlinuz-linux.img -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-linux.img'
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
-> -k /boot/vmlinuz-linux.img -c /etc/mkinitcpio.conf -g /boot/initramfs-fallback.img -S autodetect
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-linux.img'
error: command failed to execute correctly
(5/5) Check if user should be informed about rebooting after certain system package upgrades.