/mnt/boot: Do we need to rely on Arch+systemd installation guide?

Topic: /mnt/boot: Do we need to rely on Arch+systemd installation guide? (Read 1815 times) previous topic - next topic

0 Members and 2 Guests are viewing this topic.

/mnt/boot: Do we need to rely on Arch+systemd installation guide?

11 December 2022, 14:56:15

If we don't survive, we don't do anything else.
                -- John Sinclair

sov-x550cc:[sov-thade-tage]:~% ls /boot
amd-ucode.img  efi  grub  initramfs-linux-fallback.img  initramfs-linux.img  intel-ucode.img  memtest86+  vmlinuz-linux
sov-x550cc:[sov-thade-tage]:~%

installing artix from [stable] 'community-qt' image [via Ventoy] i have partitioned my SSD manually and then created filesystems manually too. the calamares installer created following layout:

Code: [Select]

sov-x550cc:[sov-thade-tage]:~% sudo ls /boot/efi
EFI
sov-x550cc:[sov-thade-tage]:~% sudo ls /boot/efi/EFI
Artix  boot
sov-x550cc:[sov-thade-tage]:~%

my system is working as expected now.

BUT digging in some old threads at forums i have found this pull request at github: gpt-generator, bootctl, nspawn: EFI mount point handling updates
AND it seems like Lennart Poettering and systemd had mediated Arch`s deviation from linux`s FHS for new installations:

Quote

from artix installation guide
NOTE: The BIOS boot partition is necessary on UEFI systems with a GPT-partitioned disk. EFI system partition has to be created and mounted at /mnt/boot and the suggested size is around 512 MiB.

Quote

from Archwiki
The simplest scenarios for mounting the EFI system partition are:
mount ESP to /boot. This is the most straightforward method.
This facilitates system maintenance, as /boot is the default path where microcode packages place the CPU microcode initramfs files, and where mkinitcpio places kernels and initramfs images.
This ensures that the above files are accessible to most boot loaders, as not all of them can access files on other volumes.
mount ESP to /efi.
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 (typically /boot).
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.
mount ESP to /efi and additionally mount an "Extended Boot Loader Partition" (XBOOTLDR) to /boot. This can be useful when a previously created ESP is too small to hold multiple boot loaders and/or kernels but the ESP cannot be easily resized (such as when installing Linux after Windows to dual boot). This method is supported by at least systemd-boot.
Tip:
/efi is a replacement^[1] for the historical and now discouraged ESP mountpoint /boot/efi.
[...]

i have no permission to edit Artixwiki so i am starting a POLL:
'Why do we need to rely on Arch+systemd installation guide? Isn`t it would be better to conform to linux`s FHS?'

APPENDIX A:

gpt-generator, bootctl, nspawn: EFI mount point handling updates

Quote

poettering commented on Jul 21, 2016
Quote
fsateler commented on Jul 21, 2016
Quote
poettering commented on Jul 20, 2016
This updates bootctl quite a bit and makes it search for the EFI mount point at /boot, /efi and /boot/efi.
But the gpt-generator does not use /boot/efi. Is this intentional?

Yes. Because /boot/efi is just stupid, as it implies that an ESP partition implies a separate /boot partition, but that's nonsense.

Also, a generator is run with nothing but the root dir plus /run mounted. That means even if we wanted we couldn't check if /boot/efi is a usable mount point as that as likely itself on a mount point that isn't mounted yet. Which is another reason why /boot/efi is stupid.

Quote

martinpitt commented on Jul 21, 2016
Quote
poettering commented on Jul 21, 2016
Because /boot/efi is just stupid, as it implies that an ESP partition implies a separate /boot partition

No, it doesn't, why would it? The EFI partition must be separate of course, but distro installers don't configure a separate /boot partition on EFI (as that would indeed be silly).

Quote

poettering commented on Jul 21, 2016
Quote
martinpitt commented on Jul 21, 2016
No, it doesn't, why would it? The EFI partition must be separate of course, but distro installers don't configure a separate /boot partition on EFI (as that would indeed be silly).

well, but /boot would effectively be empty then, only having a subdir? Why have it then?

¹https://github.com/systemd/systemd/pull/3757#issuecomment-234290236 ↵

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #1 – 11 December 2022, 15:55:49

Just ask @SGOrava for a wiki account via DMs. You can then edit the install guide.

(protip: use archived links instead of adding massive quote blocks and a pointless appendix that just makes your topic 10ft tall with little benefit)

The words "EFI" or "/efi" don't even show up on the actual FHS document. This is something entirely up to whoever is installing the bootloader, so by mounting the ESP to /boot, we're not disagreeing with the FHS. In fact, we already agree with Lennart while disagreeing with the FHS by making /sbin a link to /bin which in turn is a symlink to /usr/bin.

Besides, I actually agree with these ideas. They make packaging much simpler and spare me from typing /boot/efi/EFI.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #2 – 11 December 2022, 21:29:44

Quote from: capezotte – on 11 December 2022, 15:55:49

[...]
This is something entirely up to whoever is installing the bootloader, so by mounting the ESP to /boot, we're not disagreeing with the FHS.[...]
Besides, I actually agree with these ideas. They make packaging much simpler and spare me from typing /boot/efi/EFI.

Point A:
i have read that 'some UEFI implementations do not allow for anything else being placed at /esp' and doing otherwise may cause a system to crash.

Point B:

Quote

3.5.2. Specific Options
The operating system kernel must be located in either / or /boot.

Certain architectures may have other requirements for /boot related to limitations or expectations specific to that architecture. These requirements are not enumerated here; distributions are allowed to add requirements as needed to enable system startup on these architectures.

and here is what i have in my system:

Code: [Select]

Mathematicians often resort to something called Hilbert space, which is
described as being n-dimensional.  Like modern sex, any number can play.
                -- Dr. Thor Wald, "Beep/The Quincunx of Time", by James Blish

sov-x550cc:[sov-thade-tage]:~% sudo su
[sudo] password for sov-thade-tage: 

No matter how subtle the wizard, a knife in the shoulder blades will seriously
cramp his style.

sov-x550cc:[root]:/home/sov-thade-tage# cd /boot
sov-x550cc:[root]:/boot# df .
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda2      430584404 107175924 323408480  25% /
sov-x550cc:[root]:/boot# cd /boot/efi
sov-x550cc:[root]:/boot/efi# df .
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/sda1         306572   312    306260   1% /boot/efi
sov-x550cc:[root]:/boot/efi# fdisk -l
Disk /dev/sda: 447.13 GiB, 480103981056 bytes, 937703088 sectors
Disk model: KIOXIA-EXCERIA S
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 19B60879-08B6-6B41-AEEE-8ABBB4AC5D71

Device         Start       End   Sectors   Size Type
/dev/sda1       2048    616447    614400   300M EFI System
/dev/sda2     616448 862205951 861589504 410.8G Linux root (x86-64)
/dev/sda3  862205952 912537599  50331648    24G Linux swap
sov-x550cc:[root]:/boot/efi# parted -l
Model: ATA KIOXIA-EXCERIA S (scsi)
Disk /dev/sda: 480GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name  Flags
 1      1049kB  316MB  315MB   fat32                 boot, esp
 2      316MB   441GB  441GB   xfs
 3      441GB   467GB  25.8GB  linux-swap(v1)        swap


sov-x550cc:[root]:/boot/efi#

so for UEFI system 'specific limitations or expectations' are FAT32.
are you OK with keeping your KERNELS at a FAT32-formatted partition?
answer please

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #3 – 11 December 2022, 21:45:41

Quote from: Sov Thade Tage em Ereb – on 11 December 2022, 21:29:44

so for UEFI system 'specific limitations or expectations' are FAT32.
are you OK with keeping your KERNELS at a FAT32-formatted partition?
answer please

"Ceterum censeo M$ esse delendam"

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #4 – 12 December 2022, 01:17:27

Well you're right that section of wiki page could do with a rewrite.

Quote

NOTE: The BIOS boot partition is necessary on UEFI systems with a GPT-partitioned disk.

I've heard it called an efi partition, and an esp (EFI system partition) but 'BIOS boot partition' is confusing terminology.

Quote

EFI system partition has to be created and mounted at /mnt/boot and the suggested size is around 512 MiB

It can be mounted anywhere I would have thought? But /boot/efi is where mine gets mounted and where it's staying

Quote

If you are doing a UEFI installation, the boot partition is not optional and needs to be formatted as fat32.

EFI partition or esp.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #5 – 12 December 2022, 02:03:54

Quote from: Sov Thade Tage em Ereb – on 11 December 2022, 21:29:44

Point A:
i have read that 'some UEFI implementations do not allow for anything else being placed at /esp' and doing otherwise may cause a system to crash.

Fair. Should've expected this given there are manufacturers lazy (or evil) enough to hardcode esp/EFI/boot/bootx64.efi as the only boot entry.

Quote

so for UEFI system 'specific limitations or expectations' are FAT32.
are you OK with keeping your KERNELS at a FAT32-formatted partition?
answer please

Yes, in fact the one I'm currently using was loaded from one (and has been for multiple years at this point). It's not like my kernel is over 4GB in size or bootloaders need (or even care about) fine-grained permissions and attributes.

Quote from: gripped – on 12 December 2022, 01:17:27

It can be mounted anywhere I would have thought? But /boot/efi is where mine gets mounted and where it's staying

Indeed it can, most bootloaders actually ask/guess where yours is during install.

I also used to mount mine there when I first installed Arch, and stored the kernels on the / partition.

Just to be clear, I'm not against mentioning /boot/efi or /efi on the wiki as a mountpoint option. However, saying it's the only correct option is just as misleading as claiming /boot = ESP is the only correct option.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #6 – 12 December 2022, 02:43:50

Back in the days of lilo and then grub legacy a separate 'boot partition' was quite common. Normally mounted at /boot.
That's maybe why I don't much like the EFI partition / ESP being referred to as the boot partition. As the two uses are very different.
And definitely not 'BIOS boot partition' when it's UEFI not BIOS. There's enough industry confusion between the two terms already without adding to it.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #7 – 12 December 2022, 02:57:07

I went ahead and adjusted the wiki page to suggest /boot/efi as the mountpoint. It clears the BOOT/ESP confusion and doesn't break anything for people with compliant UEFI firmware if they're going to install GRUB (or any other bootloader with drivers for Linux filesystems).

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #8 – 12 December 2022, 10:34:36

Quote from: capezotte – on 12 December 2022, 02:03:54

Just to be clear, I'm not against mentioning /boot/efi or /efi on the wiki as a mountpoint option. However, saying it's the only correct option is just as misleading as claiming /boot = ESP is the only correct option.

i agree it`s not honest to suppress facts about alternative options ...but could you please look at this scenario:
'i have EFI system partition in a size of 300MiB [satisfying to most of recommendation] and i have only one kernel --it makes kernel + initrams + initramfs-fallback taking some 84MiB;
then i decide i need linux-lts plus linux-rt plus linux-libre [i do not know their sizes, sorry] 84MiB*4 makes 336MiB:
so now i have problems or must to indulge in self-limitation because there is no place for EFI system, bootloader, memtest86+!!!

obvious answer --to shrink my root partition and to grow EFI system partition --but IT`S WRONG because i have XFS!
IT CANNOT BE SHRUNK...'

also i do not find any explanation WHY my system does not load efivars if EFI system partition is mounted at /boot instead of /boot/efi [it works in XFCE for seven minutes without efivars and then overloads CPUs badly and freezes completely].
tested with Arch linux in last summer [i do not know maybe it was related to some systemd`s stuff or caused by my machine being one of those 'faulty UEFI implementations'].

if those other two mounting options you have mentioned [/boot or /efi] were UNIVERSALLY valid and Archwiki was SO IMPECCABLE as it seems to unexperienced Ubuntu users THEN why does my machine crash if i follow their Guide?

[please note: i was using UbuntuStudio for some five years until last spring --so no ridiculing is implied]

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #9 – 12 December 2022, 10:59:47

>NOTE: The BIOS boot partition is necessary on UEFI systems with a GPT-partitioned disk.

It's not, I have never encountered a situation where I needed a BIOS boot partition on a UEFI with GPT partitions system.

I have no idea where this notion comes from, you only need an EFI parition to boot on UEFI systems.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #10 – 12 December 2022, 11:56:54

Quote from: Lancia – on 12 December 2022, 10:59:47

>NOTE: The BIOS boot partition is necessary on UEFI systems with a GPT-partitioned disk.

It's not, I have never encountered a situation where I needed a BIOS boot partition on a UEFI with GPT partitions system.

I have no idea where this notion comes from, you only need an EFI parition to boot on UEFI systems.

The way I read it, and it took me a while to get there, the EFI partition is being referred to as "The BIOS boot partition". Which to me was both wrong and confusing. Fixed now thanks to @capezotte
Later on the wiki suggested a label of BOOT for the EFI. Also now fixed.

Further suggestions:
The section heading should just be "Partition your disk".

Quote

NOTE: On UEFI systems with a GPT-partitioned disk, the first partition must be the EFI system partition (ESP). The suggested size is around 512 MiB.

It doesn't need to be the first partition. It just needs to exist.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #11 – 12 December 2022, 12:15:00

Quote from: Sov Thade Tage em Ereb – on 12 December 2022, 10:34:36

[Describes their setup]

Having ESP = BOOT doesn't work for you, I get it. Just as mounting the ESP to somewhere other than /boot complicates things for people that use EFISTUB like me.

Quote

if those other two mounting options you have mentioned [/boot or /efi] were UNIVERSALLY valid and Archwiki was SO IMPECCABLE as it seems to unexperienced Ubuntu users THEN why does my machine crash if i follow their Guide?

A faulty UEFI implemenation. I know computers that crash if you try to install GRUB, no matter where the ESP is mounted. Is literally every Linux installer out there invalid because of them?

In fact, using /efi (/fhqwgads, or any folder not already used by packages) as the mountpoint is going to work on your machine if "polluting" the ESP is the root of the issue.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #12 – 13 December 2022, 02:46:07

Quote from: capezotte – on 12 December 2022, 12:15:00

A faulty UEFI implemenation. I know computers that crash if you try to install GRUB, no matter where the ESP is mounted. Is literally every Linux installer out there invalid because of them?

In fact, using /efi (/fhqwgads, or any folder not already used by packages) as the mountpoint is going to work on your machine if "polluting" the ESP is the root of the issue.

oh thanks i suspect the same --some guys at Asus were lazy enough soldering UEFI onto the board --and i by no means imply that GRUB, linux, God or The Dark Sea of Awareness all might be invalid.
i understand that any folder would work --i cannot understand WHY SIMPLE mounting at /boot DOES NOT [aside from overwhelming the partition or having some access/permission/? conflicts]. i am learning C and want to learn linux deeper so i try to fix the things until it is becoming ridiculously pointless.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #13 – 13 December 2022, 13:43:14

Quote from: Sov Thade Tage em Ereb – on 13 December 2022, 02:46:07

i cannot understand WHY SIMPLE mounting at /boot DOES NOT

I'm too lazy to read everything written so I'll just hazard a guess:
The kernel and initramfs are installed to /boot. If they are written when your ESP is mounted to /boot they will not be available when grub tries to access /boot prior to the ESP being mounted there. Or if there is already a kernel and initramfs in /boot they are going to be older versions as the kernel gets updated..

Just a guess but personally I consider mounting the ESP at /boot a bad idea. /boot/efi is fine.

Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?

Reply #14 – 13 December 2022, 17:03:03

>Or if there is already a kernel and initramfs in /boot they are going to be older versions as the kernel gets updated..

Since in your example /boot is actually the ESP partition, I'm guessing there is a way to tell GRUB to look for the kernel and initramfs in the root of the ESP partition instead of the actual /boot.