-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support an option to infer --disk {disk}
based on an efi system mount point
#159
Comments
Right now I have to do something like this: part=''$(mount | grep "${efiMount}" | cut -d ' ' -f 1)
part=''${part#/dev/}
disk=''$(readlink /sys/class/block/$part)
disk=''${disk%/*}
disk=/dev/''${disk##*/}
shim_loader_name="nixos-grub-shim-''${part}";
sudo efibootmgr --create --label "$shim_loader_name" --loader "${shim_path}" --disk "$disk" |
As in the other issue, I'm not sure what your question is here. If it helps, on Fedora-likes we don't run grub-install at all for UEFI. Package installation dumps files in /boot/efi/EFI directly. |
Making the user manually resolve the ESP mount point to determine the disk to pass to efibootmgr seems, at the least, inconvenient. And it does seem lots of folks don't use grub-install, which has its own consequences I've been noticing, I think we are unfortunately in the same boat. But in fact that exacerbates my point, I'd bet code similar to what I shared exists in Fedora... and many others. It seems like a reasonable thing to ask efibootmgr to know how to resolve the ESP mount point to determine the |
Sure, I'd be willing to review patches for that. |
Ack. I can't really claim to be able to get to this anytime soon, but this is what I'm doing now, maybe it can be helpful or a starting place to someone else. I also wrote this a while ago and haven't re-reviewed it, so please don't trust it blindly:
|
I just wound up on a system where our
grub-install
was working fine, butefibootmgr
was failing unless the--disk /dev/nvme0n1
was specified.It seems that
grub-install
takes an--efi-directory
that I suspect it uses to resolve to the boot drive, to then appropriately call efibootmgr.But why? Why make every caller do that? It seems like there ought to be a way to say
sudo efibootmgr --create --efi-dir /boot
or something wherebyefibootmgr
does the disk resolution. Maybe there's an easy way to do the reverse boot resolution, but my first approach is a bunch of string hacks and again, I know this functionality already exists in disparate places.The text was updated successfully, but these errors were encountered: