Systemd-boot, after switch from grub cannot install intel-ucode

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.

Thank you so much in advance.

Can we see the output of df -h?

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.

[nemo@psi ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
dev              16G     0   16G   0% /dev
run              16G  2,0M   16G   1% /run
/dev/sda1        98G   21G   73G  22% /
tmpfs            16G  129M   16G   1% /dev/shm
tmpfs            16G   32K   16G   1% /tmp
/dev/sda2       818G  130G  646G  17% /home
tmpfs           3,2G   76K  3,2G   1% /run/user/1000
/dev/nvme0n1p1   96M   88M  8,3M  92% /boot

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?

Your efi partition is less than 100MB! That is too small for systemd-boot.

The kernels and initrams get a little bigger with each kernel release. You were probably right at the edge and didn’t realize it.

Here are the current sizes with my mkinitcpio config. Depending on what you are putting in yours, init might be a little different.

-rwxr-xr-x 1 root root  40K Jun 19 17:20 amd-ucode.img
-rwxr-xr-x 1 root root  32M Jun 19 17:20 initrd
-rwxr-xr-x 1 root root  54M Jun 19 17:20 initrd-fallback
-rwxr-xr-x 1 root root 9.0M Jun 19 17:20 linux

Because that is how kernel-install works. It is great for multi-booters because it prevents collisions.

If you want to see where the code that does that is located in /usr/lib/kernel/install.d and /etc/kernel/install.d

I was under that impression. You suggest to resize from windows or linux (if you have any experience with 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?

1 Like

If you uninstall the package using pacman that should be the only thing.

Are they still being created or are they just left over?

Still being created. I’ve tried to reinstall Linux package (that obviously pull from latest kernel) and it still create the entries there.

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.

the only file that I’ve there is linux.preset (checked also for hidden ones, but none exists) and contains this:

[root@psi mkinitcpio.d]# cat linux.preset 
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/d804c053597b4ab3b550e8f38959c6ee/5.12.12-arch1-1/linux"
PRESETS=(default fallback)
default_image="/boot/d804c053597b4ab3b550e8f38959c6ee/5.12.12-arch1-1/initrd"
fallback_image="/boot/d804c053597b4ab3b550e8f38959c6ee/5.12.12-arch1-1/initrd-fallback"
fallback_options="-S autodetect"

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.

If you delete that preset file and reinstall the linux package it should put the default preset back.

Thank you so much. It worked. Sorry for the late reply, I only had time to try yesterday night.

1 Like

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