You are not logged in.

#1 2020-06-21 02:41:06

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

[SOLVED] Ideas regarding the filesystem package.

While the filesystem package is complete, I feel it's missing two mountpoints, they maybe are not a Linux standard, but may be defined on Arch (also maybe pass the idea upstream).

Those two are /efi and /etc/secureboot.

Reason of why to include them:

/efi should be the default mountpoint for an ESP if it's under UEFI with GPT.

/etc/secureboot can be the first step for Secure Boot support on Arch (not that it's not possible already), this at least defines to everyone where to search for db files, and where to mount an encrypted filesystem, partition or external storage device, to make the same Secure Boot keys usable by different distributions.

This may look bad for someones and good for others, do say your opinion with technical details and reasons and also ask questions if desired.

Last edited by GaKu999 (2020-06-21 19:07:29)


My reposSome snippets

Heisenberg might have been here.

Offline

#2 2020-06-21 02:53:17

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,657
Website

Re: [SOLVED] Ideas regarding the filesystem package.

GaKu999 wrote:

/efi should be the default mountpoint for an ESP if it's under UEFI with GPT.

Where are you getting this?  That is a viable option, but there are many others.  Unless there is reason to do otherwise, mounting the ESP on /boot is advised.

But more importantly, why would this be in the filesystem package?  The filesystem package is not unique to EFI systems.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2020-06-21 03:09:29

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

Trilby wrote:

Where are you getting this?  That is a viable option, but there are many others.  Unless there is reason to do otherwise, mounting the ESP on /boot is advised.

Yes, i'm aware, it's just an idea based on ESP and XBOOTLDR concept, and an /efi directory would be useless with my concept on a BIOS with MBR system, also depending of the situation it's only purpose (I think) would be to keep intel-ucode.img outside of the ESP...also people that don't use systemd-boot and instead use other bootloaders may see like a weird thing to keep them separate.

Trilby wrote:

But more importantly, why would this be in the filesystem package?  The filesystem package is not unique to EFI systems.

Well, since it's the one that defines the / hierarchy on Arch, it should be the one...unless making yet another core package to define just /efi and /etc/secureboot is a good idea...? neutral
Maybe not a core package but still...seems like a weird thing to do...at least to me...

On my case systemd-boot, with some EFISTUBs, binaries and a live Arch squash are in the ESP, because of intel-ucode.img living on /boot, and dracut needs to load it from there...

Here's an view of my ESP if interested made with lsd -A --tree:

efi
├── .rsync-filter
├── admin.img
├── EFI
│  ├── BOOT
│  │  └── BOOTX64.EFI
│  ├── Linux
│  │  ├── Arch-linux-fallback.efi
│  │  ├── Arch-linux-live.efi
│  │  └── Arch-linux.efi
│  ├── systemd
│  │  └── systemd-bootx64.efi
│  └── tools
│     ├── keytoolx64.efi
│     ├── poweroffx64.efi
│     └── rebootx64.efi
├── live
│  └── archlivex64.sfs
├── loader
│  ├── .rsync-filter
│  ├── auths
│  │  ├── db.auth
│  │  ├── kek.auth
│  │  ├── pk.auth
│  │  └── rm_pk.auth
│  ├── entries
│  │  ├── keytool.conf
│  │  ├── poweroff.conf
│  │  └── reboot.conf
│  ├── loader.conf
│  └── random-seed
└── shellx64.efi

Of course if intel-ucode.img didn't live in /boot I would also ditch /efi anyways, not even initrds are made in there for me! big_smile

EDIT: didn't cover the last question...
EDIT: I fixed a smilie...

Last edited by GaKu999 (2020-06-21 03:17:29)


My reposSome snippets

Heisenberg might have been here.

Offline

#4 2020-06-21 10:16:17

nl6720
Wiki Admin
Registered: 2016-07-02
Posts: 247

Re: [SOLVED] Ideas regarding the filesystem package.

An /efi directory shouldn't be created by default as it affects the decisions made by systemd-gpt-auto-generator(8):

systemd-gpt-auto-generator(8) wrote:

The ESP is mounted to /boot/ (except if an Extended Boot Loader partition exists, see below), unless a mount point directory /efi/ exists, in which case it is mounted there.

It could lead to an undesirable result for people who want the ESP to be mounted on /boot and rely on automounting performed by systemd-gpt-auto-generator.

Offline

#5 2020-06-21 10:37:04

lahwaacz
Wiki Admin
From: Czech Republic
Registered: 2012-05-29
Posts: 689

Re: [SOLVED] Ideas regarding the filesystem package.

GaKu999 wrote:

Those two are /efi and /etc/secureboot.

Reason of why to include them:

/efi should be the default mountpoint for an ESP if it's under UEFI with GPT.

/etc/secureboot can be the first step for Secure Boot support on Arch [...]

These two should not exist (as in don't make any sense) for BIOS systems. The filesystem package is not UEFI-specific.

Offline

#6 2020-06-21 12:22:29

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,657
Website

Re: [SOLVED] Ideas regarding the filesystem package.

GaKu999 wrote:

Well, since it's the one that defines the / hierarchy on Arch

Is it?  *lots* of packages own top level directories.

Filesystem creates paths that should exist regardless of other packages providing them.  But /efi certainly doesn't meet this criteria.

Perhaps one could argue that that directory be created by certain boot loaders - but even then it is forcing a decision that should belong to the user.

And what purpose would this serve?  I initially thought it would only prevent the user from having to run one 'mkdir' command once while installing their system - but it wouldn't even do that.  The directory would have to be made before pacstrap and before the filesystem package was installed.  So it would serve no purpose at all.

Last edited by Trilby (2020-06-21 12:27:21)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#7 2020-06-21 13:32:46

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

nl6720 wrote:

An /efi directory shouldn't be created by default as it affects the decisions made by systemd-gpt-auto-generator(8):

systemd-gpt-auto-generator(8) wrote:

The ESP is mounted to /boot/ (except if an Extended Boot Loader partition exists, see below), unless a mount point directory /efi/ exists, in which case it is mounted there.

It could lead to an undesirable result for people who want the ESP to be mounted on /boot and rely on automounting performed by systemd-gpt-auto-generator.

Well, that also is another reason, it seems that /efi is defined as an user made directory, makes sense, not everyone uses UEFI and there's a lot of BIOS systems still alive...


My reposSome snippets

Heisenberg might have been here.

Offline

#8 2020-06-21 13:36:49

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

lahwaacz wrote:

These two should not exist (as in don't make any sense) for BIOS systems. The filesystem package is not UEFI-specific.

Yes, I'm aware, a BIOS system would not care about /efi nor attempting to use Secure Boot...
This would only make sense if BIOS would be an obsolete, hard to find system on working computers, which isn't the truth today because there's a LOT of BIOS systems still alive and kicking.


My reposSome snippets

Heisenberg might have been here.

Offline

#9 2020-06-21 13:45:57

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

Trilby wrote:

And what purpose would this serve?  I initially thought it would only prevent the user from having to run one 'mkdir' command once while installing their system - but it wouldn't even do that.  The directory would have to be made before pacstrap and before the filesystem package was installed.  So it would serve no purpose at all.

Yes, doesn't make much sense, systemd-boot, grub or any other bootloader that may think of using ESP alongside XBOOTLDR for the system may just as well define each one /efi on their hierarchy...

I mentioned it twice so I will explain, just to clarify my opinion, ESP for binaries an "tiny" stuff, XBOOTLDR, "large" stuff like many live images, then again this can perfectly be an user made decision and makes no sense on BIOS, also not everyone cares about complying with the EFI standard and use FAT16 on an external ESP, or maybe doesn't care about if there's blobs alongside the EFI binaries or if /boot/intel-ucode.img is outside of their encrypted root filesystem...

User made decisions are also one of the reasons I didn't think of mentioning /media at all...


My reposSome snippets

Heisenberg might have been here.

Offline

#10 2020-06-21 13:50:04

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,657
Website

Re: [SOLVED] Ideas regarding the filesystem package.

I'm confused.  You seem to be vaguely mentioning various counterpoints, but you keep coming back to BIOS systems as the only exception paired with the expectation that they will soon be obsolete.  I run a uefi system.  I don't use secure boot and I don't mount my ESP on /efi.  Both of those seem completely silly to me.  I wouldn't want to prevent others from doing so, but you seem to be working under the assumption that all uefi systems would use the /efi mountpoint - that's nonsense.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#11 2020-06-21 14:07:33

Scimmia
Bug Wrangler
Registered: 2012-09-01
Posts: 8,065

Re: [SOLVED] Ideas regarding the filesystem package.

GaKu999, you're all over the map. What do either of those mount points have to do with encryption? You mention people defying specs with FAT16 on an external ESP, but that's part of the spec. You mention that certain things should be in certain places without providing any reasoning or references. Nothing you've said in this thread makes any sense at all.

Offline

#12 2020-06-21 14:18:26

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,773

Re: [SOLVED] Ideas regarding the filesystem package.

My EFI system partition is not mounted. It contains grubx64.efi, which was generated and installed when I installed Arch, and this loads kernels from /boot, which is a btrfs partition. I see no reason to ever mount the EFI system partition, since I never edit its contents -- its only purpose is to store the bootloader, so if I make a conscious choice to reinstall grub, I will manually mount the ESP and manually run grub-install.

Why should I have additional mountpoints on my system which serve no role except the dangerous one of allowing my frozen, unchanging ESP to run the risk of accidentally getting damaged? Mounted partitions are easier to accidentally remove files from (including by rogue programs) than partitions which are not mounted.

GaKu999 wrote:

I mentioned it twice so I will explain, just to clarify my opinion, ESP for binaries an "tiny" stuff, XBOOTLDR, "large" stuff like many live images, then again this can perfectly be an user made decision and makes no sense on BIOS, also not everyone cares about complying with the EFI standard and use FAT16 on an external ESP, or maybe doesn't care about if there's blobs alongside the EFI binaries or if /boot/intel-ucode.img is outside of their encrypted root filesystem...

systemd-boot is a stupid boot manager, by design (its principle is that boot managers should not really do anything, deferring basically everything to the manufacturer's crippled UEFI firmware), and thus XBOOTLDR makes sense for it. It took systemd-boot *way* too long to acknowledge the reality that such a thing is needed, and refind or grub still provide much more pleasant experiences as both come with EFI filesystem drivers for mounting *any* filesystem type (or at least most, and all the commonly desired ones). But hey, systemd-boot eventually got there.

Please note, however, that the EFI standard REQUIRES support for fat12 and fat16. I've happily used fat12 for a long time, on several different laptops.

Keep in mind the caveat that the EFI standard as it is worded only requires fat12 and fat16 to be supported for secondary (removable) media. This is nonsensical, since the drivers must exist either way, but it basically permits a conforming firmware implementation to include code that makes a judgment call about whether the device is the primary EFI filesystem or a secondary/removable one, and then in the former case basically error out with "haha, even though we have the drivers for it, we have a management policy you're not allowed to use fat12 for the primary EFI partition, so we're arbitrarily denying you. We will now proceed to fatally exist. lulz"

I have no proof that any existing implementation actually does this. I doubt there is one, but I could be wrong.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#13 2020-06-21 14:25:12

Scimmia
Bug Wrangler
Registered: 2012-09-01
Posts: 8,065

Re: [SOLVED] Ideas regarding the filesystem package.

eschwartz wrote:

Keep in mind the caveat that the EFI standard as it is worded only requires fat12 and fat16 to be supported for secondary (removable) media.

I'm not certain that's true. The summary mentions FAT16 and FAT12 for removable media, but the actual technical info only ever says that it's based on the size of the media, so the summary is probably just assuming that fixed media is big enough to have FAT32, not restricting FAT16 and FAT12 to removable only.

Offline

#14 2020-06-21 14:27:49

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

Trilby wrote:

I'm confused.  You seem to be vaguely mentioning various counterpoints, but you keep coming back to BIOS systems as the only exception paired with the expectation that they will soon be obsolete.  I run a uefi system.  I don't use secure boot and I don't mount my ESP on /efi.  Both of those seem completely silly to me.  I wouldn't want to prevent others from doing so, but you seem to be working under the assumption that all uefi systems would use the /efi mountpoint - that's nonsense.

Sorry my bad, seems that I wasn't clear enought, /efi should not be an EFI system thing, this is only a vague concept (for me) regarding as I said ESP along XBOOTLDR.
Well Secure Boot is not that sturdy, since firmware backdoors are a thing, I personally can't say it's a nice security measure, not something that important nor impressive (and I use it), maybe with a backdoor free system it would be more impressive and less silly...

/efi is quite silly with all being said, and if you don't care having intel-ucode lingering around the ESP, may as well use /boot anyways. not that XBOOTLDR is to widely used, at least it seems to be a quite new concept.
The only reason to have them separate would be a weird firmware that complains about to large ESP (I have seen a couple) or people that dual-boot windows and would like to have live rescue arch on their ESP (I have seen people mention that windows doesn't like big ESPs, but may be wrong about that) so that 'big' stuff that would fit <512MB would be sitting on XBOOTLDR...
But adding those ideas make this entire thread non arch specific...and more like user made modifications to a complex system, then again I only use arch as mi daily driver so, not even I care about that (except for live usbs because of the firmware mention, that explains by itself why archiso looks like that)

Offtopic note, can intel-ucode.img contain malicious code? Can't seem to find not much information about it...


My reposSome snippets

Heisenberg might have been here.

Offline

#15 2020-06-21 14:29:53

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

Scimmia wrote:

GaKu999, you're all over the map. What do either of those mount points have to do with encryption? You mention people defying specs with FAT16 on an external ESP, but that's part of the spec. You mention that certain things should be in certain places without providing any reasoning or references. Nothing you've said in this thread makes any sense at all.

I maybe said something wrong, I'm not a tech savy after all, but quote me, this is thread is getting quite big by now, at least for me...


My reposSome snippets

Heisenberg might have been here.

Offline

#16 2020-06-21 14:35:38

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

eschwartz wrote:

I have no proof that any existing implementation actually does this. I doubt there is one, but I could be wrong.

I have seen a couple of those that are utterly broken for some reason, not wanting to load >512MB ESP or without FAT16 on external media, taking into account that they no longer have traces of the old windows that came with them...


My reposSome snippets

Heisenberg might have been here.

Offline

#17 2020-06-21 14:44:19

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

eschwartz wrote:

My EFI system partition is not mounted. It contains grubx64.efi, which was generated and installed when I installed Arch, and this loads kernels from /boot, which is a btrfs partition. I see no reason to ever mount the EFI system partition, since I never edit its contents -- its only purpose is to store the bootloader, so if I make a conscious choice to reinstall grub, I will manually mount the ESP and manually run grub-install

With that being said, it looks like quite a good idea, and each distro installed on the system may register their entry to grub so a shared /boot would be nonsensical, maybe even prepare one partition for live rescue images that get loaded to ram, allowing full editing to the entire storage if wanted big_smile

While not thread specific, I appreciate that information regarding bootloaders, that alone makes systemd-boot look bad big_smile


My reposSome snippets

Heisenberg might have been here.

Offline

#18 2020-06-21 14:52:27

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,773

Re: [SOLVED] Ideas regarding the filesystem package.

Scimmia wrote:
eschwartz wrote:

Keep in mind the caveat that the EFI standard as it is worded only requires fat12 and fat16 to be supported for secondary (removable) media.

I'm not certain that's true. The summary mentions FAT16 and FAT12 for removable media, but the actual technical info only ever says that it's based on the size of the media, so the summary is probably just assuming that fixed media is big enough to have FAT32, not restricting FAT16 and FAT12 to removable only.

That's an interesting nuance I overlooked (and it's been a while since I read the spec). It makes this even stupider though, because this is a specification, not a tutorial.

Why should the spec care how big the disk is, or whether it's loaded over the USB protocol vs. SCSI/SAS/SATA.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#19 2020-06-21 15:00:42

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,773

Re: [SOLVED] Ideas regarding the filesystem package.

GaKu999 wrote:
eschwartz wrote:

I have no proof that any existing implementation actually does this. I doubt there is one, but I could be wrong.

I have seen a couple of those that are utterly broken for some reason, not wanting to load >512MB ESP or without FAT16 on external media, taking into account that they no longer have traces of the old windows that came with them...

"Not wanting to load without fat16 on external media" -- I'm not sure what this means.

Regarding sizes and >512MB, my understanding was, per https://www.rodsbooks.com/efi-bootloade … iples.html, there are some buggy firmwares which have problems with <512MB, not greater than. He also points out that this is only a fat32 problem, and fat16 will usually make UEFI firmwares happy but in return prevent the Windows installer from successfully installing with such an ESP.

Last edited by eschwartz (2020-06-21 15:29:21)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#20 2020-06-21 15:08:59

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

eschwartz wrote:
GaKu999 wrote:
eschwartz wrote:

I have no proof that any existing implementation actually does this. I doubt there is one, but I could be wrong.

I have seen a couple of those that are utterly broken for some reason, not wanting to load >512MB ESP or without FAT16 on external media, taking into account that they no longer have traces of the old windows that came with them...

"Not wanting to load without fat16 on external media" -- I'm not sure what this means.

Regarding sizes and >512MB, my understanding was, per https://www.rodsbooks.com/efi-bootloade … iples.html, there are some buggy firmwares which have problems with >512MB, not greater than. He also points out that this is only a fat32 problem, and fat16 will usually make UEFI firmwares happy but in return prevent the Windows installer from successfully installing with such an ESP.

It means that they only care for bootable usbs to use fat16, ignoring the size...really broken and ugly...
Anyways I hope there aren't many of those, there are also some firmwares that break if whatever binary they load exceeds >32MB or even require cold boots or 10 seconds of no power shutdown to work properly...
Maybe I only had bad luck...but still, they made me waste time on changing how my live usbs where partitioned...


My reposSome snippets

Heisenberg might have been here.

Offline

#21 2020-06-21 17:13:17

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

This is healthy posting experience, can be closed now if wanted, I don't think more could ever be said about it.
For being my actual first post it didn't end up in dustbin so I'm happy tongue

My mistakes where, choose to be around the filesystem package, now that I think about it there was no reason to focus on that one, and used the wrong words and statements for that.

This could have been a post about bootloaders and another one of how useful Secure Boot actually is, still it fulfilled that purpose, albeit that wasn't the intention...


My reposSome snippets

Heisenberg might have been here.

Offline

#22 2020-06-21 18:44:35

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 24,657
Website

Re: [SOLVED] Ideas regarding the filesystem package.

GaKu999 wrote:

This is healthy posting experience, can be closed now if wanted.

It's not likely to be closed, but if your curiosity or question has been addressed, you can mark it as [SOLVED] by editting your first post to add that to the title.

While I was very critical of your suggestion, I do applaud how receptive you were to feedback.  Keep that up and you'll do well with arch.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#23 2020-06-21 19:06:54

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 530

Re: [SOLVED] Ideas regarding the filesystem package.

Trilby wrote:
GaKu999 wrote:

This is healthy posting experience, can be closed now if wanted.

It's not likely to be closed, but if your curiosity or question has been addressed, you can mark it as [SOLVED] by editting your first post to add that to the title.

While I was very critical of your suggestion, I do applaud how receptive you were to feedback.  Keep that up and you'll do well with arch.

Oh, and there I assumed that would be an issue post thing...my bad, it would seem that the forums closing policy is for old or problematic\garbage posts, will do. big_smile


My reposSome snippets

Heisenberg might have been here.

Offline

Board footer

Powered by FluxBB