[SO] How to switch the current installation from /boot ESP to /efi ESP

webcapcha · 2024-10-28 17:40:19

Looks like having /efi as ESP is better than /boot according to admins from Arch official telegram group. Because in case of having /boot I will end up having two copies of kernels. Not sure I got the point correctly.

For now I have

/                                           /dev/mapper/HynixVolGroup-root
│                                                                     ext4        
├─/proc                                     proc                      proc        
│ └─/proc/sys/fs/binfmt_misc                systemd-1                 autofs      
├─/sys                                      sys                       sysfs       
│ ├─/sys/firmware/efi/efivars               efivarfs                  efivarfs    
│ ├─/sys/kernel/security                    securityfs                securityfs  
│ ├─/sys/fs/cgroup                          cgroup2                   cgroup2     
│ ├─/sys/fs/pstore                          pstore                    pstore      
│ ├─/sys/fs/bpf                             bpf                       bpf         
│ ├─/sys/kernel/tracing                     tracefs                   tracefs     
│ ├─/sys/fs/fuse/connections                fusectl                   fusectl     
│ └─/sys/kernel/config                      configfs                  configfs    
├─/dev                                      dev                       devtmpfs    
│ ├─/dev/shm                                tmpfs                     tmpfs       
│ ├─/dev/pts                                devpts                    devpts      
│ ├─/dev/hugepages                          hugetlbfs                 hugetlbfs   
│ └─/dev/mqueue                             mqueue                    mqueue      
├─/run                                      run                       tmpfs       
│ ├─/run/credentials/systemd-journald.service
│ │                                         tmpfs                     tmpfs       
│ ├─/run/credentials/systemd-network-generator.service
│ │                                         tmpfs                     tmpfs       
│ ├─/run/credentials/systemd-udev-load-credentials.service
│ │                                         tmpfs                     tmpfs       
│ ├─/run/credentials/systemd-tmpfiles-setup-dev-early.service
│ │                                         tmpfs                     tmpfs       
│ ├─/run/credentials/systemd-sysctl.service tmpfs                     tmpfs       
│ ├─/run/credentials/systemd-tmpfiles-setup-dev.service
│ │                                         tmpfs                     tmpfs       
│ ├─/run/credentials/systemd-vconsole-setup.service
│ │                                         tmpfs                     tmpfs       
│ ├─/run/credentials/systemd-tmpfiles-setup.service
│ │                                         tmpfs                     tmpfs       
│ ├─/run/user/1000                          tmpfs                     tmpfs       
│ │ └─/run/user/1000/doc                    portal                    fuse.portal 
│                                           tmpfs                     tmpfs       
├─/tmp                                      tmpfs                     tmpfs       
├─/boot                                     /dev/nvme0n1p1            vfat        
└─/home                                     /dev/mapper/HynixVolGroup-home
                                                                      ext4

so /boot is separate partition

/etc/fstab

# /dev/mapper/HynixVolGroup-root
UUID=b5eb9c7f	/         	ext4      	rw,relatime	0 1

# /dev/mapper/HynixVolGroup-home
UUID=39c333f5	/home     	ext4      	rw,nodev,nosuid,relatime	0 2

# /dev/nvme0n1p1
UUID=038C      	/boot     	vfat      	rw,nosuid,noexec,nodev,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/mapper/HynixVolGroup-swap
UUID=dac42db8	none      	swap      	defaults  	0 0

First step is create /efi
Second step. Should I copy kernels from /boot to /efi manually? and than change /etc/fstab?

Last edited by webcapcha (2024-10-29 19:58:17)

V1del · 2024-10-28 17:48:38

It doesn't sound like you got the point correctly. There's nothing inherently wrong with having /boot be the ESP. A drawback of it is that FAT is not the most resilient filesystem and is comparatively easily broken or corrupted, which is why I'd also reccommend you don't use the ESP as /boot to house the kernel, but this has nothing to do with "getting two copies of the kernel"

If you want to go through with that, you'd copy kernels from /efi to /boot and reconfigure your fstab as well as your bootloader to load the kernel images from /boot which is a linux filesystem.

webcapcha · 2024-10-28 17:55:25

V1del wrote:

If you want to go through with that, you'd copy kernels from /efi to /boot and reconfigure your fstab as well as your bootloader to load the kernel images from /boot which is a linux filesystem.

Did you mean from /boot to /efi?

In case of UKI may I just recreate kernel in /efi?

So in this scenario the bootloader (systemd-boot) will stay on /boot and on /efi will be only kernel UKI image, is it correct?

webcapcha · 2024-10-28 18:23:00

Or should I completely copy everything from /boot to /efi?
My setup is systemd-boot with lvm on luks

V1del · 2024-10-28 18:37:00

No if you want to use UKI's you'd create a secondary partition, which houses the UKI's and then load the kernels from that partition (which should be an XBOOTLDR marked GPT partition) via systemd-boot which resides on the ESP.

What you need to understand is that the actual mount point of the ESP does not matter at all so "copying from /boot to /efi" is absolutely meaningless if /boot was your ESP and will be the same exact partition just now on /efi (... other than you need configuration to move the kernel files (which land in /boot by default regardless of whether it is a mount point or not) there)

From what we see of your setup, you need to either do a bunch more reading to have any "benefit" from moving stuff around or just keep your setup as is. if you "just mount ESP to /efi and adjust fstab" you win absolutely nothing at all and thing will break on the next kernel update at the earliest. So if this is your entire motivation, don't change anything

Last edited by V1del (2024-10-28 18:41:29)

webcapcha · 2024-10-28 18:46:56

V1del wrote:

No if you want to use UKI's you'd create a secondary partition, which houses the UKI's and then load the kernels from that partition

one more partition to my setup? I thought I'd have /boot where it will load the initramfs/encryption modules needed to load the rest of the system

and /efi for kernel

Those readings don't help, I'm already read wiki hours and hours and not only today. Chatgpt gives completely different steps

Would appreciate more step by step guide. And regarding profits. It's not about profits it's personal laptop. No profits at all. Just follow best practice.

Last edited by webcapcha (2024-10-28 18:48:42)

webcapcha · 2024-10-28 18:52:41

according to wiki a lot of benefits

mount the ESP to /efi:
It ensures a separation of concerns between OS- and EFI-related files, which may include other OSes' files better left alone.
It avoids increasing the size requirement of the ESP by not placing the files installed to /boot in it: only the EFI binaries (the boot loader (and optionally drivers) and/or the unified kernel image) will be stored on the ESP, which saves storage space.
It allows to preserve Linux-specific filesystem permissions for files residing in /boot, avoiding FAT limitations.
It allows to mount separately the ESP according to the need, e.g. only when upgrading the bootloader.
If using system encryption with the appropriate setup, it allows to leave only a few required files unencrypted while /boot remains protected: this can be useful for unified kernel images or boot loaders that have file system drivers capable of accessing the kernel(s) and files that are stored elsewhere.

webcapcha · 2024-10-28 18:54:36

So if I understood correctly the UKI or regular kernel should be on /efi (it's not separate partition)
and "some important files" for booting system will remain on /boot (which is currently partition)

No profits, benefits, just follow wiki

loqs · 2024-10-28 20:17:56

webcapcha wrote:

and "some important files" for booting system will remain on /boot (which is currently partition)

Yes you need something that supports lvm on luks to be loaded from the ESP which I believe systemd-boot does not directly support which is why V1del explained about XBOOTLDR.
Edit:
Please also do not bump your posts. If you post is the last in a thread please edit it rather than creating a new post.

Last edited by loqs (2024-10-28 20:18:57)

webcapcha · 2024-10-29 05:32:28

loqs wrote:

webcapcha wrote:
and "some important files" for booting system will remain on /boot (which is currently partition)
Yes you need something that supports lvm on luks to be loaded from the ESP which I believe systemd-boot does not directly support which is why V1del explained about XBOOTLDR.
Edit:
Please also do not bump your posts. If you post is the last in a thread please edit it rather than creating a new post.

According to the wiki I don't need XBOOTLDR I want to realize this scenario
https://wiki.archlinux.org/title/EFI_sy … 0the%20ESP

I already mentioned it here

Last edited by webcapcha (2024-10-29 05:33:11)

kermit63 · 2024-10-29 07:16:46

The last bullet you linked to in the wiki:

If using system encryption with the appropriate setup...

Right now, you don't have the appropriate setup. You are using systemd-boot, which can only access files in FAT format (like the efi partition), or an XBOOTLDR partition (which you don't have).

If your plan is to move the non-EFI files from the EFI partiton, you need to put it somewhere systemd-boot can read, i.e. an XBOOTLDR partition.

Point #2 is only useful if you are just starting to partition your drive in preparation for an installation. Since you have everything already set up, it's not practical to embark on a massive resizing of your partitions just to recover a few mbs of space from the EFI partition.

V1del · 2024-10-29 09:45:48

You need to stop picking bits and pieces of the wiki that do not apply to your situation...

kermit63 explained the necessities assuming you want most of the current setup intact otherwise, there are a few alternate pathways but they assume you'd switch bootloaders but even then you're unlikely to get past the "needs an additional /boot partition" requirement.

Your original motivation "Because in case of having /boot I will end up having two copies of kernels." is complete nonsense. So you should explain to us and mostly to yourself what your motivation is for wanting to do this - all evidence points to there being a misunderstanding of how things work in which case you're strongly advised to keep the setup as is. Are you running out of space on the ESP or why do you want to do this?

The only thing I can see is that you can avoid an instance of vmlinuz-linux on the ESP if you properly generate the UKI onto /efi, which will save you ~13MB, but the UKIs still need to be there which will be the vast majority of the required space

Last edited by V1del (2024-10-29 10:11:33)

webcapcha · 2024-10-29 11:06:45

I don't know how to make a link to telegram English group.

Originally I was willing to switch from regular kernel setup to UKI setup, later

Admin @grazzolini told me

I mean, that kernels are installed to /boot, no matter what's there. So, you would have the kernels on /boot + your UKI on /boot/EFI/Linux

and better to use /efi as ESP

And according to wiki making ESP as /efi has advantages.

I just want to figure out what the structure it will be and not about philosophy rants.

Should it be two separate partitions boot and efi. Or efi could be from my understanding a directory. Now I have /boot partition 2GB

V1del · 2024-10-29 13:15:12

What's your setup now? If you don't have UKIs now what benefit do you envision from switching to UKIs? Do you want to start using secure boot?

And do you run into space constraints with the 2GB? Yes you can technically "save some space" because you can omit carrying vmlinuz-linux on the ESP, but that's mostly on the smaller side, the big fat binary to load will be the UKI and you will not be able to get that off of the ESP in your current setup.

Every mount point starts as a directory, they start getting special once you mount a partition there. If you move the ESP to /efi then you still need to get the kernel images there in your current setup. -- All of this is configurable and doable, it just doesn't make a whole lot of difference in the end because the ESP is still your single point of failure to a successful boot

This isn't a philosophy rant but a technical consideration. If you want a technical benefit, you'd need to get a seperate partition with a better filesystem that you can offload the UKI to, which is not encrypted that you mount to /boot instead of the ESP. If that's not something you consider doing then there's little to no benefit to your plan.

If you're dead set on switching this anyway... create /efi, switch fstab, umount /boot, mount it to /efi, copy the vmlinuz-linux linux-initramfs and amd/intel-ucode.img to your /boot, and fix your mkinitcpio: https://wiki.archlinux.org/title/Unifie … reset_file

Last edited by V1del (2024-10-29 13:26:12)

webcapcha · 2024-10-29 17:47:23

V1del wrote:

What's your setup now? If you don't have UKIs now what benefit do you envision from switching to UKIs? Do you want to start using secure boot?

Well, here it says "when the cat doesn't have to do, he licks balls". Some years ago I was subscribed to feed from https://0pointer.net/blog/ (author of systemd?), and a lot of things happened since, I bump into up that feed in my reader and looks like the author promoted UKI. I already switched to UKI yesterday, it was pretty easy.
Security boot was active even before UKI (yeah orcs can steal my laptop if you what I mean)

Current setup.

bootctl list
         type: Boot Loader Specification Type #2 (.efi)
        title: Arch Linux (6.11.5.arch1-1) (selected)
           id: arch-linux.efi
       source: /boot//EFI/Linux/arch-linux.efi
     sort-key: arch
      version: 6.11.5.arch1-1
        linux: /boot//EFI/Linux/arch-linux.efi
      options: nowatchdog cryptdevice=UUID=4c22b167:cryptlvm:allow-discards root=/dev/HynixVolGroup/root rw,relatime

I've already modified linux.preset

#default_config="/etc/mkinitcpio.conf"
#default_image="/boot/initramfs-linux.img"
default_uki="/boot/EFI/Linux/arch-linux.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

Filesystem                      Size  Used Avail Use% Mounted on
dev                              14G     0   14G   0% /dev
run                              14G  1.8M   14G   1% /run
efivarfs                        326K  163K  159K  51% /sys/firmware/efi/efivars
/dev/mapper/HynixVolGroup-root   79G   16G   59G  21% /
tmpfs                            14G  189M   14G   2% /dev/shm
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-network-generator.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-udev-load-credentials.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev-early.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-sysctl.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-sysusers.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-vconsole-setup.service
tmpfs                            14G   76M   14G   1% /tmp
/dev/nvme0n1p1                  2.0G  706M  1.4G  35% /boot
/dev/mapper/HynixVolGroup-home  849G   20G  786G   3% /home
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-tmpfiles-setup.service
tmpfs                           1.0M     0  1.0M   0% /run/credentials/systemd-networkd.service
tmpfs                           2.8G   80K  2.8G   1% /run/user/1000

And do you run into space constraints with the 2GB? Yes you can technically "save some space" because you can omit carrying vmlinuz-linux on the ESP, but that's mostly on the smaller side, the big fat binary to load will be the UKI and you will not be able to get that off of the ESP in your current setup.

No I didn't

This isn't a philosophy rant but a technical consideration. If you want a technical benefit, you'd need to get a seperate partition with a better filesystem that you can offload the UKI to, which is not encrypted that you mount to /boot instead of the ESP. If that's not something you consider doing then there's little to no benefit to your plan.
If you're dead set on switching this anyway... create /efi, switch fstab, umount /boot, mount it to /efi, copy the vmlinuz-linux linux-initramfs and amd/intel-ucode.img to your /boot, and fix your mkinitcpio: https://wiki.archlinux.org/title/Unifie … reset_file

As I said I don't fully understand all this ESP, efi, etc. No I don't need that wiki page one more time. I just got a message from telegram group "it's better to use /efi as ESP". And wiki among three options suggests /efi.

Since I don't fully understand, ideally I just want an example from whom already uses this crappy ESP as /efi, like here is a config. And then I will decide do I want it or not

From my understanding, the kernel with be placed in /boot (just directory) and the /efi (partition) will be for what currently located in /boot/EFI.

I expected this topic will be smaller, but I have spare time

Last edited by webcapcha (2024-10-29 17:49:26)

V1del · 2024-10-29 18:35:11

I'm already running the ESP on /efi, but in my case the ESP has no contents other than GRUB to load the kernels from the root filesystem. It's 10MB in size and that's already too much just for GRUB

The only thing you win with your current setup is that vmlinuz-linux will be placed in /boot before being used to create the UKI into /efi/EFI/Linux/arch-linux.efi. so you saving yourself 14MB worth of diskspace ~+/- depending on whether you have multiple kernels, but you're still generating the entire UKI image into the ESP which is the thing that needs to be kept intact in order to have a successful boot.

The thing I'm trying to explain to you is that you don't get many benefits from a technical perspective, but assuming you're doing the necessary switch at all places correctly you're also not having any drawbacks in comparison. You will basically have the same setup you already have.

Last edited by V1del (2024-10-29 18:38:32)

webcapcha · 2024-10-29 18:54:39

V1del wrote:

I'm already running the ESP on /efi, but in my case the ESP has no contents other than GRUB to load the kernels from the root filesystem. It's 10MB in size and that's already too much just for GRUB
The only thing you win with your current setup is that vmlinuz-linux will be placed in /boot before being used to create the UKI into /efi/EFI/Linux/arch-linux.efi. so you saving yourself 14MB worth of diskspace ~+/- depending on whether you have multiple kernels, but you're still generating the entire UKI image into the ESP which is the thing that needs to be kept intact in order to have a successful boot.
The thing I'm trying to explain to you is that you don't get many benefits from a technical perspective, but assuming you're doing the necessary switch at all places correctly you're also not having any drawbacks in comparison. You will basically have the same setup you already have.

Okay, if current setup is good enough and no reasonable things to improve, will leave as it is.

Last but not the least question about amd-ucode.

The regular kernel setup looks like

 type: Boot Loader Specification Type #1 (.conf)
        title: Arch Linux (default)
           id: arch.conf
       source: /boot//loader/entries/arch.conf
     sort-key: arch
        linux: /boot//vmlinuz-linux
       initrd: /boot//amd-ucode.img
               /boot//initramfs-linux.img
      options: cryptdevice=UUID=4c22b167-21b1-417d-bdf5-dbc8012c9128:cryptlvm:allow-discards root=/dev/HynixVolGroup/root

I mean, it loads amd-ucode.img with regular kernel.

But according to the wiki in case of using UKI

Take care to remove entries pointing to microcode and initramfs.

from /etc/cmdline
Should I turn setup some way to have microcode properly loaded? Currently, it's unloaded at all?

in journalctl -

Oct 29 08:00:18 lenovo-laptop kernel: microcode: Current revision: 0x0a704101

loqs · 2024-10-29 19:01:45

As covered in Microcode#Verifying_that_microcode_got_updated_on_boot the lack of an update entry means it is not being updated by linux. Are you certain that there is an update for your system rather than the microcode provided by firmware is already up to date?

webcapcha · 2024-10-29 19:08:37

loqs wrote:

As covered in Microcode#Verifying_that_microcode_got_updated_on_boot the lack of an update entry means it is not being updated by linux. Are you certain that there is an update for your system rather than the microcode provided by firmware is already up to date?

you helped me to report bug from this topic https://bbs.archlinux.org/viewtopic.php?id=295199

I'm certain that Lenovo doesn't update UEFI to the latest AGESA or so. Checked that time.

So is it enough just to have amd-ucode sitting in /boot? No need to explicitly mention it with this UKI setup?

loqs · 2024-10-29 19:16:52

Assuming your system is still using family: 0x19 (25) model-id: 0x74 (116) stepping: 1 then according to https://git.kernel.org/pub/scm/linux/ke … ode/README there is no microcode update. If there is no firmware update that includes a microcode update you would need to locate a microcode update yourself.

webcapcha · 2024-10-29 19:25:40

loqs wrote:

Assuming your system is still using family: 0x19 (25) model-id: 0x74 (116) stepping: 1 then according to https://git.kernel.org/pub/scm/linux/ke … ode/README there is no microcode update. If there is no firmware update that includes a microcode update you would need to locate a microcode update yourself.

Oct 29 08:00:18 lenovo-laptop kernel: smpboot: CPU0: AMD Ryzen 7 7840HS with Radeon 780M Graphics (family: 0x19, model: 0x74, stepping: 0x1)

how to use that readme? If I find there exactly my record (model: 0x74) then there is a microcode update?

If there is no firmware update that includes a microcode update you would need to locate a microcode update yourself

in case I found record on that link but no firmware update?

loqs · 2024-10-29 19:42:32

If the README contained an entry such as:

  Family=0x19 Model=0x074 Stepping=0x1: Patch=0x0a800000 Length=5555 bytes

Then I would expect either the current or next release of amd-ucode would contain a microcode update for your system that would update the microcode to revision 0x0a800000.

AMD generally only provides microcode updates for data center CPUs via linux-firmware and all other CPU types are expected to obtain microcode updates through firmware updates provided by the system/mainboard vendor.

webcapcha · 2024-10-29 19:57:37

okay thank you
I think https://bbs.archlinux.org/viewtopic.php … 5#p2205425 and https://bbs.archlinux.org/viewtopic.php … 5#p2205415 solve this topic

title doesn't have enough room to type solved

Last edited by webcapcha (2024-10-29 19:58:49)

Arch Linux

#1 2024-10-28 17:40:19

[SO] How to switch the current installation from /boot ESP to /efi ESP

#2 2024-10-28 17:48:38

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#3 2024-10-28 17:55:25

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#4 2024-10-28 18:23:00

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#5 2024-10-28 18:37:00

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#6 2024-10-28 18:46:56

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#7 2024-10-28 18:52:41

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#8 2024-10-28 18:54:36

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#9 2024-10-28 20:17:56

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#10 2024-10-29 05:32:28

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#11 2024-10-29 07:16:46

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#12 2024-10-29 09:45:48

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#13 2024-10-29 11:06:45

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#14 2024-10-29 13:15:12

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#15 2024-10-29 17:47:23

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#16 2024-10-29 18:35:11

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#17 2024-10-29 18:54:39

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#18 2024-10-29 19:01:45

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#19 2024-10-29 19:08:37

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#20 2024-10-29 19:16:52

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#21 2024-10-29 19:25:40

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#22 2024-10-29 19:42:32

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

#23 2024-10-29 19:57:37

Re: [SO] How to switch the current installation from /boot ESP to /efi ESP

Board footer