Text only | Text with Images

Artix Linux Forum

Artix Linux => Installation / Migration / Configuration => Topic started by: Sov Thade Tage em Ereb on 11 December 2022, 14:56:15

Title: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 11 December 2022, 14:56:15
Code: [Select]
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 (https://github.com/systemd/systemd/pull/3757)
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 (https://wiki.artixlinux.org/Main/Installation#Partition_your_disk_.28BIOS.29)
NOTE: The BIOS boot partition is necessary on UEFI systems with a GPT-partitioned disk. EFI system partition (https://wiki.archlinux.org/title/EFI_system_partition#Mount_the_partition) has to be created and mounted at /mnt/boot and the suggested size is around 512 MiB.
Quote
from Archwiki (https://wiki.archlinux.org/title/EFI_system_partition#Typical_mount_points)
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 (https://github.com/systemd/systemd/pull/3757)
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?

1 https://github.com/systemd/systemd/pull/3757#issuecomment-234290236↵
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: capezotte on 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 (https://refspecs.linuxbase.org/FHS_3.0/fhs-3.0.html#bootStaticFilesOfTheBootLoader). 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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 11 December 2022, 21:29:44
Quote from: capezotte – on
[...]
 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
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: lq on 11 December 2022, 21:45:41
Quote from: Sov Thade Tage em Ereb – on
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"
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 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 :D

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.



Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: capezotte on 12 December 2022, 02:03:54
Quote from: Sov Thade Tage em Ereb – on
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
It can be mounted anywhere I would have thought? But /boot/efi is where mine gets mounted and where it's staying :D

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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: capezotte on 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).
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 12 December 2022, 10:34:36
Quote from: capezotte – on
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]
:o
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: 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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 12 December 2022, 11:56:54
Quote from: Lancia – on
>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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: capezotte on 12 December 2022, 12:15:00
Quote from: Sov Thade Tage em Ereb – on
[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 (https://askubuntu.com/questions/862946/unable-to-install-ubuntu-on-acer-aspire-es1-533), 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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 13 December 2022, 02:46:07
Quote from: capezotte – on
A faulty UEFI implemenation. I know computers that crash if you try to install GRUB (https://askubuntu.com/questions/862946/unable-to-install-ubuntu-on-acer-aspire-es1-533), 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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 13 December 2022, 13:43:14
Quote from: Sov Thade Tage em Ereb – on
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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Lancia on 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.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 13 December 2022, 18:07:16
Quote from: Lancia – on
>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.
I'm sure there is but the question was
Quote
WHY SIMPLE mounting at /boot
As you point out more than simply mounting the ESP at boot would need to be done.

To me it's going to lengths to solve a problem which doesn't need to exist. And for anyone wanting several distros installed it's best to keep the kernels on the rootfs not mixed in with the ESP.
While I'm not saying it's impossible to achieve I see little benefit to mounting the ESP at /boot but plenty of disadvantages though.

I'm sure if I put my mind to it I could mount /home at /emoh but I'd expect potential breakage.
Imho /boot/efi is a good solution. /this/is/where/i/put/my/efi would be workable but a bit silly. /boot introduces unnecessary issues. And I still fail to see any benefits ?
Title: [History] /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 14 December 2022, 15:15:45
Quote from: capezotte – on
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).
now i want to thank you folks for timely dealing with the issue and for a guidance too.
still i have a question [honestly, a too bit technical so do not bother if it`s too complicated].
'i was following Archwiki installation guide --maybe it`s systemd`s bug but here are the steps:
FAULTY SETUP
USABLE SETUP
Can Anyone Explain How Could It be Possible To Drop Efivars Getting Up From A Bed?'
Quote from: capezotte – on
[...]
A faulty UEFI implemenation. I know computers that crash if you try to install GRUB (https://askubuntu.com/questions/862946/unable-to-install-ubuntu-on-acer-aspire-es1-533), no matter where the ESP is mounted [...]
thanks to Caperzotte i have rediscovered Rod Smith`s site where i have found where to go for reading more[1] here is one possible explanation given by him

Quote
Quick Recommendations:
Most Linux distributions install the EFI version of GRUB 2 on EFI-based computers. When I first wrote these pages, GRUB 2 barely worked, but it's much more reliable in 2018 than in 2011 [...]
There are problems with GRUB 2, though. Some of these problems relate to the fact that it can be difficult to control your boot mode (EFI vs. BIOS) when you install an OS, and therefore difficult to tell which version of GRUB you've installed. There are also cases where GRUB misbehaves; it may fail to launch, refuse to chainload to Windows or OS X, or do other strange things [...]
Be aware that there are significant system-specific quirks [...]
i don`t think it`s Grub`s failure however, and it`s even more better now than it was back in 2018, and could anyone explain me if it is responsible for efivars at all?

HISTORY A:
while reading Rod`s article i have found WHERE those instructions outlawing /boot/efi mount point HAD COMETH FROM:
Quote
Once Linux is installed, the ESP is typically mounted at /boot/efi, so these directories would be /boot/efi/EFI/ubuntu and /boot/efi/EFI/redhat, respectively, on a working Linux installation. A proposal at freedesktop.org (http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec) would encourage mounting the ESP at /boot rather than at /boot/efi. This proposal has yet to be adopted by any major distribution, although Arch Linux users are fond of mounting the ESP at /boot.


then i have found The Linux Userspace API (UAPI) Group (https://uapi-group.org/) hosting the specification; here is the path

Rod Smith`s hints on how to fix another case of UEFI failure [registering Grub] (https://askubuntu.com/a/863139)

Roderick Smith`s site dedicated to EFI and UEFI (http://www.rodsbooks.com/efi-bootloaders/index.html)

EFI Disk Structures (http://www.rodsbooks.com/efi-bootloaders/principles.html)

This page is obsolete. Current version is at https://systemd.io/BOOT_LOADER_SPECIFICATION.TL;DR (https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/)

This content has moved to the UAPI group website (https://systemd.io/BOOT_LOADER_SPECIFICATION/)

The Boot Loader Specification (https://uapi-group.org/specifications/specs/boot_loader_specification/)

Quote
The $BOOT Partition Placeholder:
    In the text below, the placeholder $BOOT will be used to refer to the partition determined as follows:
  • On disks with an MBR partition table: → the boot partition, as described above
  • On disks with a GPT partition table: → the XBOOTLDR partition if it exists
  • Otherwise, on disks with a GPT partition table: → the ESP

Quote
Mount Points:
It is recommended to mount $BOOT to /boot/, and the ESP to /efi/. If $BOOT and the ESP are the same, then either a bind mount or a symlink should be established making the partition available under both paths.

(Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended. Such a nested setup complicates an implementation via direct autofs mounts — as implemented by systemd for example —,[sic] as establishing the inner autofs will trigger the outer one. Mounting the two partitions via autofs is recommended because the simple VFAT file system has weak data integrity properties and should remain unmounted whenever possible.)
p.s.: those partitions tend to get bigger year after year [300MiB (old Debian page) => 550MiB (Rod`s and Archwiki`s ones) and...]
Quote
Creating These Partitions:
    An installer for an operating system should use this logic when selecting or creating partitions:
    • [...]
    • Otherwise, if on GPT and an ESP is found and it is large enough (let’s say at least 1G[sic]) it should be used as $BOOT and used as primary location to place boot loader menu resources in.
1 [a very useful section titled Additional Resources which i am going to follow little later]↵
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 14 December 2022, 18:34:03
Quote
my Arch system was bootable but overheating and crashing after seven minutes; i have checked efivars among other stuff --they were absent!!!
Are you saying that in your first example there were no efivars at all ? Or that they were null ? Or that some were missing?
But regardless I can't explain it off the top of my head.

Though judging from this post and previous threads there is something wrong with your hardware.
It seems, based on what you say, that your computer overheats and crashes at lot, and this a partly an educated guess, when under load. Personally I'd be making it my priority to sort that out and then be worrying about where the ESP is mounted  ;)

I admit it had passed me by that freedesktop.org recommend mounting the ESP at /boot. Maybe the reason that "This proposal has yet to be adopted by any major distribution" is because it's a bad idea ? Unless at the same time the distros started storing the kernel and initramfs somewhere other than /boot?

You link Rod's site as "Roderick Smith`s site dedicated to EFI and UEFI"
This is not incorrect however I'd go with "Roderick Smith`s site: The home of rEFInd"

rEFInd is far superior to grub2. The only reason to choose to use grub is if your computer is BIOS only.
The reason most linux users use grub is because that's what the installer installs and most of them would be, with justification, scared to switch even if they knew there was a better option.

Being diplomatic grub2 is a pile of turd. Ridiculously over complicated configuration. Shitty look, Easy to end up with just a black screen, "Grub Rescue", Now what ? Whatever happened to KISS - keep it simple stupid.

rEFInd be like: "No config, who cares". "Found these installs, which would you like to boot?"


Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 15 December 2022, 20:40:19
Quote from: gripped – on
Are you saying that in your first example there were no efivars at all ? Or that they were null ? Or that some were missing?
But regardless I can't explain it off the top of my head.
they were TOTALLY ABSENT [empty dir] upon a check: ls /sys/firmware/efi/efivars
[but see below]
Quote from: gripped – on
Though judging from this post and previous threads there is something wrong with your hardware.
It seems, based on what you say, that your computer overheats and crashes at lot, and this a partly an educated guess, when under load. Personally I'd be making it my priority to sort that out and then be worrying about where the ESP is mounted  ;)
no, this my machine normally does not overheat or crashes [i used her for several years --first with Windows 8, then in dual boot with UbuntuStudio, then UbuntuStudio alone, then SocialismStudio+Openbox and in last spring i have switched to Arch where this issue had arised.

a minute ago i have found my old cheatcheet i used for Arch installation --and please folks i am nearly blind and having short-term memory loss oftenly so now i have recollected the sequence of events
firstly installing Arch i have gotten unbootable system
because --just look on it:

Code: [Select]
mount --mkdir /dev/sda1 /mnt/boot
[...]
grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB

i have copied that from Archwiki (https://wiki.archlinux.org/title/GRUB#UEFI_systems) grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB and even if i check all the stuf for consistency and constanly monitor MY OWN activity for correctness --i had made wrong substitution because was confused by too many options in their Mount the EFI system partition (https://wiki.archlinux.org/title/EFI_system_partition#Mount_the_partition)
then for all subsequent attempts [two or three] but final one i was using /boot in both commands, achieving faulty setup i have described in original post.

and finally i have found Debian`s old article telling to use /boot/efi.

Quote from: gripped – on
You link Rod's site as "Roderick Smith`s site dedicated to EFI and UEFI"
This is not incorrect however I'd go with "Roderick Smith`s site: The home of rEFInd"

rEFInd is far superior to grub2. The only reason to choose to use grub is if your computer is BIOS only.
The reason most linux users use grub is because that's what the installer installs and most of them would be, with justification, scared to switch even if they knew there was a better option.

Being diplomatic grub2 is a pile of turd. Ridiculously over complicated configuration. Shitty look, Easy to end up with just a black screen, "Grub Rescue", Now what ? Whatever happened to KISS - keep it simple stupid.

rEFInd be like: "No config, who cares". "Found these installs, which would you like to boot?"
yes Grub may be quiet black-screenish sometimes, but ...as you have said 'that`s what the installer installs' and personally i am not ready to switch to another bootloader from an already installed system;
and in addition, and that`s why i have preferred Grub while planning installions --it DOES support my chosen filesystem: XFS (https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader);
among the other ones only LILO has a support for it but DOES NOT work with UEFI hardware.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 15 December 2022, 21:24:46
Quote from: Sov Thade Tage em Ereb – on
no, this my machine normally does not overheat or crashes
My mistake. You must have been talking about another machine in this (https://forum.artixlinux.org/index.php/topic,4844.0.html) thread.
Quote
i have had a freezing of the system after some fifteen minutes.
Quote
the machine gets overheated before the system freezes
Quote
and i was literally exhausted after several  hours of sitting in front of constantly crashing baby
Sounds like the other machine has cooling issues ?

Quote
yes Grub may be quiet black-screenish sometimes, but ...as you have said 'that`s what the installer installs' and personally i am not ready to switch to another bootloader from an already installed system;
I wasn't so much saying you should switch as expressing my love for rEFInd and my hatred for grub2.
Though truth told I think everybody capable should switch :)
Because it's better ;)

Unless.....
Quote
and in addition, and that`s why i have preferred Grub while planning installions --it DOES support my chosen filesystem: XFS (https://wiki.archlinux.org/title/Arch_boot_process#Boot_loader);
among the other ones only LILO has a support for it but DOES NOT work with UEFI hardware.
Though I do believe it's possible to use XFS with rEFInd as well as other, dare I say, exotic filesystems. But you need to source third party drivers. It's all on Rod's site.

It surprises me you would be adverse to switching bootloaders as you clearly enjoy tinkering. Which is a complement not criticism.

Getting back to your efivars thing.
My guess. Your efivars aren't setup because some part of your 'mount esp on /boot' process has resulted in some sort of issue / mismatch between kernel - initramfs - kernel modules.
That's the only sane reason I can think of as to why it would work (have efivars) mounted anywhere else but not work when mounted on /boot.

However I'd expect a lot more breakage than just efivars so I'm not convinced by my own theory either.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 15 December 2022, 23:30:03
Quote from: gripped – on
[...] expressing my love for rEFInd [...] I think everybody capable should switch :)
Because it's better ;)
[...] I do believe it's possible to use XFS with rEFInd as well as other, dare I say, exotic filesystems. But you need to source third party drivers. It's all on Rod's site.

It surprises me you would be adverse to switching bootloaders as you clearly enjoy tinkering. Which is a complement not criticism.
oh no i`m not reluctant --i am really interested in trying/learning software other than i already do have. that is just like i said --i need XFS[1]
i would check Rod`s site for the stuff you mentioned.

Quote from: gripped – on
My mistake. You must have been talking about another machine in this (https://forum.artixlinux.org/index.php/topic,4844.0.html) thread.Sounds like the other machine has cooling issues ?
yes it was said in that another thread;
that laptop is Asus K50IN born in some 2010th so that is not cooling issue but TECHNOLOGY LEVEL issue.
Pentium T4300 (https://en.wikipedia.org/wiki/List_of_Intel_Pentium_processors#%22Penryn-3M%22,_%22Penryn-L%22_(45_nm)) [Penryn-3M (45 nm)] is rated at TDP 35Wt. and the cooling system is really small and gaspy oftenly[2]
1 i make hour-or-two-long audio recordings of my life performance plus a lot of editing or overdubs --XFS suits my needs the best [but i would not dare recommending XFS to anyone using an 'HDD-only' setup; it is the best performer with an SSD; for an HDD-based system ext4 outperforms XFS]↵
2 especially if rendering stuff in Kdenlive or playing someting (https://en.wikipedia.org/wiki/PlaneShift_(video_game)) based on old 3D-engine like Crystal Space (https://en.wikipedia.org/wiki/Crystal_Space); for making my videos i have switched to using my newer Asus laptop [x550cc; Intel Core i3 model i3-3217U]; probably this newer machine has better designed cooling system too↵
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Lancia on 16 December 2022, 10:14:58
> among the other ones only LILO has a support for it but DOES NOT work with UEFI hardware.

There's elilo, though it stopped being developed long ago.

> It surprises me you would be adverse to switching bootloaders as you clearly enjoy tinkering. Which is a complement not criticism.

The bootloader isn't exactly something you should be "tinkering" with unless you're doing it in some kind of virtual environment, far away from the main OS. Any mistake can lead to an unbootable system.
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: Sov Thade Tage em Ereb on 17 December 2022, 03:10:04
Quote from: Lancia – on
Quote
> among the other ones only LILO has a support for it but DOES NOT work with UEFI hardware.

There's elilo, though it stopped being developed long ago.
mmm ...i heard about it at some point but Archwiki does not list it, probably because it`s unmaintained; so making installations i have not even recollected it does exist.


Quote from: Lancia – on
Quote
> It surprises me you would be adverse to switching bootloaders as you clearly enjoy tinkering. Which is a complement not criticism.
The bootloader isn't exactly something you should be "tinkering" with unless you're doing it in some kind of virtual environment, far away from the main OS. Any mistake cal lead to an unbootable system.

oh yes i tweaked and reinstalled oftenly so i had had in total several hours of scary grub-cmd or blinky-blinky_underscore when was making some mistakes
Title: Re: /mnt/boot: Do we need to rely on Arch+systemd installation guide?
Post by: gripped on 17 December 2022, 03:42:07
Quote from: Lancia – on
The bootloader isn't exactly something you should be "tinkering" with unless you're doing it in some kind of virtual environment, far away from the main OS. Any mistake cal lead to an unbootable system.
I'm sorry i disagree. The bootloader is just another part of a computer.
It's all there for tinkering with.

Text only | Text with Images