Sorry, but I just wanna ask something, it looks like stupid question but I need to get an answer. Here, I have to point the sda2 with EFI, right? Not sd7, which will be empty for the new Arch LInux? I just wanna not make mistakes:) *Device Start End Sectors Size Type* /dev/sda1 2048 616447 614400 300M Windows recovery environment /dev/sda2 616448 821247 204800 100M EFI System /dev/sda3 821248 1083391 262144 128M Microsoft reserved /dev/sda4 1083392 362373119 361289728 172,3G Microsoft basic data /dev/sda5 362373120 812933119 450560000 214,8G Microsoft basic data /dev/sda6 812933120 836370431 23437312 11,2G Linux swap /dev/sda7 836370432 976771071 140400640 66,9G Linux filesystem
You don't need separate EFI partition if that's the question. Since it's small - I think you can use it not for /boot, but only for bootloader. I usually mount EFI partition as /boot/efi. Linux kernel will stay in sda7 in this case for you, that's fine. GRUB2 should be able to pick it up from there
On 7/18/23 06:41, Sergey Filatov wrote:
.... mount EFI partition as /boot/efi.
While that is/was pretty common, I believe the current recommendation is to mount: esp onto /efi gpt type : EF00 boot onto /boot gpt type : EA00 (type XBOOTLDR) rather than having the efi mounted underneath another mount. For some additional info see [1] [2]. gene .. [1] https://uapi-group.org/specifications/specs/boot_loader_specification/ .. [2] https://0pointer.net/blog/
On 7/18/23 09:23, Genes Lists wrote:
While that is/was pretty common, I believe the current recommendation is to mount:
To be more precise, the recommendation is to mount the efi as /boot, and as Sergey suggested, if your EFI partition is too small, then use separate efi and boot partitions as above. gene
On Tue, 2023-07-18 at 09:26 -0400, Genes Lists wrote:
On 7/18/23 09:23, Genes Lists wrote:
While that is/was pretty common, I believe the current recommendation is to mount:
To be more precise, the recommendation is to mount the efi as /boot, and as Sergey suggested, if your EFI partition is too small, then use separate efi and boot partitions as above.
I don't install my kernels on a fat partition without UNIX privileges. IOW if it should be required that the efi partition is a fat partition, I wonder why this is recommended.
On 7/18/23 09:45, Ralf Mardorf wrote:
I don't install my kernels on a fat partition without UNIX privileges. IOW if it should be required that the efi partition is a fat partition, I wonder why this is recommended.
OI assume a part of your comment is the security aspect. This of course can be addressed by UKI and secure boot for example. I'll let you peruse the references for more info. But one thing that comes to mind is - its simpler. Simpler in the sense that the UEFI boot process needs to be able to read the XBOOTLDR partition to load the kernel - this in turn only works if there are available EFI file system drivers which in turn must be installed (see package efifs). Not a big deal but these drivers need to keep pace appropriately with the actual "kernel" drivers; at least to some degree. These efi drivers are separate from the in-tree kernel drivers of course. Indeed efi filesys drivers are available for common filesystems including ext4 and btrfs. By contrast, there are no EFI drivers available for md raid, so that cannot be used for /boot mounted as XBOOTLDR partion. gene
On Tue, 2023-07-18 at 14:14 -0400, Genes Lists wrote:
I assume a part of your comment is the security aspect. This of course can be addressed by UKI and secure boot for example.
Hi, if the cat paws at the keyboard, it doesn't need root privileges, it can execute "rm /path/unified_kernel_image" with the cat's user privileges? Apart from that, I would also like to avoid fat as much as possible for anything BSD or Linux related, out of principle. Regards, Ralf
On 7/18/23 14:52, Ralf Mardorf wrote: ...
if the cat paws at the keyboard, it doesn't need root privileges, it can execute "rm /path/unified_kernel_image" with the cat's user privileges?
I think that non-root can only do that if mounted uid=<user>. So, as far as cat-safe filesystem, isn't it no different for fat32, ext4 or btrfs? E.g. On my system here I get cat denied :) as root: # findmnt -t vfat /efi0 TARGET SOURCE FSTYPE OPTIONS /efi0 /dev/sda1 vfat ... # ls -l /efi0/foo 0 -rwxr-xr-x 1 root root 0 Jul 18 15:06 /efi0/foo* As user kitty: $ rm -iv /efi0/foo rm: remove write-protected regular empty file '/efi0/foo'? y rm: cannot remove '/efi0/foo': Permission denied $ ls -l /efi0/foo 0 -rwxr-xr-x 1 root root 0 Jul 18 15:06 /efi0/foo*
...I would also like to avoid fat as much as possible ... out of principle.
understood.
Genes Lists
On 7/18/23 09:45, Ralf Mardorf wrote:
I don't install my kernels on a fat partition without UNIX privileges. IOW if it should be required that the efi partition is a fat partition, I wonder why this is recommended.
OI assume a part of your comment is the security aspect. This of course can be addressed by UKI and secure boot for example.
I'll let you peruse the references for more info. But one thing that comes to mind is - its simpler.
Simpler in the sense that the UEFI boot process needs to be able to read the XBOOTLDR partition to load the kernel - this in turn only works if there are available EFI file system drivers which in turn must be installed (see package efifs).
Not a big deal
Last time I tried, which was long ago, pacman -S efifs worked. What failed for me was getting the efi bios, or efi shells, to load it. Which could be due to my incompetence. Or using an old, no longer supported, PC. Though that particular experiment was not with a very old PC. Or whatever. -- u34
but these drivers need to keep pace appropriately with the actual "kernel" drivers; at least to some degree. These efi drivers are separate from the in-tree kernel drivers of course.
Indeed efi filesys drivers are available for common filesystems including ext4 and btrfs.
By contrast, there are no EFI drivers available for md raid, so that cannot be used for /boot mounted as XBOOTLDR partion.
gene
participants (5)
-
Genes Lists
-
Ralf Mardorf
-
Sergey Filatov
-
Source Code
-
u34＠net9.cf