Improve GetESP() about sbctl HOT 23 CLOSED

You don't have bootctl?! terrible :)

I think we can implement the same logic and also look for SYSTEMD_ESP_PATH and ESP_PATH as fallbacks. Better to use the possible options we have available. Preferably not mess with mounting anything.

from sbctl.

Hmm, lets go blkid and the ENV variables then we can figure out dbus later. It probably improves the status quo regardless :) Thanks!

from sbctl.

I'd prefer not to depend on bootctl, since I don't have that here :P

@Foxboron do you have any preference between a command line parameter or env vars? Looping through those directories seems reasonable to me, though. We could even implement logic to try and mount the ESP (if given in the command line or via env var) by calling mount $ESP_PATH, but I don't think that's entirely necessary.

from sbctl.

This is one of the more "this seems easy". But the missing part is that systemd checks with blkid and/or udev depending on privileged or unprivileged operation. I have no clue if the partition types is stored in procfs or sysfs or if there needs to be some simple partition introspection for this.

I might be over complicating this as well and we could just assume BOOT/BOOTX64.EFI should exist on one of those paths. Which should cover most of the usecases.

from sbctl.

From the systemd source code why it has both udev and blkid selection mechanism.

/* If we are unprivileged we ask udev for the metadata about the partition. If we are privileged we
* use blkid instead. Why? Because this code is called from 'bootctl' which is pretty much an
* emergency recovery tool that should also work when udev isn't up (i.e. from the emergency shell),
* however blkid can't work if we have no privileges to access block devices directly, which is why
* we use udev in that case. */

from sbctl.

Should we assume that udev is always available? And default to some silly checking for BOOTx64.EFI if that is not the case?

from sbctl.

I think udev is only available on systems with systemd or eudev. BTW, not sure why they are saying the blkid does not work in unpriviledged mode as it seems to work for me.

BTW there is a wipefs command that support JSON output.

from sbctl.

BTW, not sure why they are saying the blkid does not work in unpriviledged mode as it seems to work for me.

blkid doesn't work for unprivileged users (just check it). maybe you're part of the disk group.

from sbctl.

I'm inclined to assume udev is available and leave the current approach by iterating over /efi, /boot and /boot/efi as a fallback. Does that sound good? We can set a default ESP partition in the config when that is implemented.

from sbctl.

BTW, not sure why they are saying the blkid does not work in unpriviledged mode as it seems to work for me.

blkid doesn't work for unprivileged users (just check it). maybe you're part of the disk group.

I figured it out. When blkid is run it will create a cache file under /run/blkid/blkid.tab. After that unprivileged users can read the cache instead of the devices directly. There is some program that calls blkid on my system that creates that cache by running blkid.

from sbctl.

I'm inclined to assume udev is available and leave the current approach by iterating over /efi, /boot and /boot/efi as a fallback. Does that sound good? We can set a default ESP partition in the config when that is implemented.

Even if udev is available if there are multiple vfat partitions with ESP partition GUID (for example a user has inserted Arch boot ISO) how would you select.

from sbctl.

So the systemd code is looping over /efi, /boot and /boot/efi and queries each of these with either blkid or udev. It checks if it's a mount, if it's the correct UUID and so on. It doesn't query all disks, just the expected mount locations of the partition. It also force mounts it by trying to lookup path/trigger first. I think we can follow the same logic?

• check if SYSTEMD_ESP_PATH or ESP_PATH is defined
• Loop over /efi, /boot and /boot/efi and check for a valid ESP.

from sbctl.

I think we can follow the same logic?

Sounds good.

from sbctl.

@igo95862 Want to try implement it :)?

from sbctl.

@igo95862 Want to try implement it :)?

Closer to weekend probably.

BTW how would you want to add udev? Use some existing udev go binds? Link to libsystemd with cgo?

from sbctl.

Preferably some existing udev go library would be the best option I think.

from sbctl.

How about this one: https://github.com/pilebones/go-udev

from sbctl.

Hmm, there really wasn't that many udev libraries. That library is probably nice :)

from sbctl.

Hmm, there really wasn't that many udev libraries. That library is probably nice :)

Well, its actually GPL3. (just realized) Unless you want to re-license entire project...

from sbctl.

I think implementing the blkid is easier because it won't require any extra libraries just some command line parsing.

from sbctl.

Actually what was the problem with lsblk? It can be used to retrieve the same information as blkid or udev plus output in JSON making parsing easy.

from sbctl.

Ohhh! Neat! I'm not sure if this is new or I was completely blind to it when I implemented it the first time :)

from sbctl.

At least from March 2018 balena-io-modules/drivelist#255

from sbctl.