I installed my new drive, and everything was fine. I added another OS, and now I can't do the grub2-install anymore. What am I missing??
# grub2-install /dev/sda grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
boot is mounted:
/dev/sda8 95M 9.5M 86M 11% /boot/efi
ls -l /boot/efi/EFI/fedora total 5864 -rwx------ 1 root root 102 Feb 17 2015 BOOT.CSV drwx------ 2 root root 2048 May 21 14:59 fonts -rwx------ 1 root root 1064296 Apr 28 16:10 gcdx64.efi -rwx------ 1 root root 7653 Aug 21 04:57 grub.cfg -rwx------ 1 root root 1024 Aug 21 04:57 grubenv -rwx------ 1 root root 1064296 Apr 28 16:10 grubx64.efi -rwx------ 1 root root 1276224 Feb 17 2015 MokManager.efi -rwx------ 1 root root 1293304 Feb 17 2015 shim.efi -rwx------ 1 root root 1287032 Feb 17 2015 shim-fedora.efi
On Wed, Aug 26, 2015 at 10:33 AM, Paul Cartwright pbcartwright@gmail.com wrote:
I installed my new drive, and everything was fine. I added another OS, and now I can't do the grub2-install anymore. What am I missing??
# grub2-install /dev/sda grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
grub2-install does not apply on UEFI systems at all, it should not be used. Instead you reinstall shim and grub2-efi packages.
On 08/28/2015 12:02 PM, Chris Murphy wrote:
grub2-install does not apply on UEFI systems at all, it should not be used. Instead you reinstall shim and grub2-efi packages.
thanks, I got some other replies that mentioned efibootmgr, and that did the trick. my default grub was ubuntu, but I wanted it to be fedora. efibootmgr -v showed default 0004, which is ubuntu. once I changed that via: # efibootmgr -o 0002,0004 0002 is fedora. When I rebooted, it used the grub.cfg from fedora and all is well.
On 08/28/2015 12:02 PM, Chris Murphy wrote:
grub2-install does not apply on UEFI systems at all, it should not be used. Instead you reinstall shim and grub2-efi packages.
ok, I wasn't aware of this shim package, but I see how that works now...
https://fedoraproject.org/wiki/GRUB_2
yum install grub2-efi grub2-efi-modules shim
If you do, then try:
yum reinstall grub2-efi grub2-efi-modules shim
instead.
Make sure that /boot/efi is mounted when you do this.
This installs the signed shim and the GRUB 2 binary.
I don't think I need to do that now, since I already changed the bootloader default via efibootmgr -o..
On Fri, Aug 28, 2015 at 11:06 AM, Paul Cartwright pbcartwright@gmail.com wrote:
On 08/28/2015 12:02 PM, Chris Murphy wrote:
grub2-install does not apply on UEFI systems at all, it should not be used. Instead you reinstall shim and grub2-efi packages.
ok, I wasn't aware of this shim package, but I see how that works now...
https://fedoraproject.org/wiki/GRUB_2
yum install grub2-efi grub2-efi-modules shim
grub2-efi-modules is not necessary unless you plan on going off the rails with GRUB modules that aren't baked into the signed Fedora GRUB EFI OS Loader. I've already done that derailment more times than I have fingers and I can attest that it's not worth the trouble.
On 08/29/2015 02:17 AM, Chris Murphy wrote:
https://fedoraproject.org/wiki/GRUB_2
yum install grub2-efi grub2-efi-modules shim
grub2-efi-modules is not necessary unless you plan on going off the rails with GRUB modules that aren't baked into the signed Fedora GRUB EFI OS Loader. I've already done that derailment more times than I have fingers and I can attest that it's not worth the trouble.
it would really be nice if there was some HOW-TO or documentation on all this new UEFI/shim packages...
On 08/29/2015 04:15 AM, Paul Cartwright wrote:
it would really be nice if there was some HOW-TO or documentation on all this new UEFI/shim packages...
There is.
On Sat, Aug 29, 2015 at 1:48 PM, Paul Cartwright pbcartwright@gmail.com wrote:
grub2-mkconfig will add entries for other operating systems it can find. That will be done based on the output of the os-prober tool.
This is why one of my first modifications post-install is to /etc/default/grub to add
GRUB_DISABLE_OS_PROBER="true"
On 08/29/2015 11:12 PM, Chris Murphy wrote:
grub2-mkconfig will add entries for other operating systems it can find. That will be done based on the output of the os-prober tool.
This is why one of my first modifications post-install is to /etc/default/grub to add
GRUB_DISABLE_OS_PROBER="true"
why would you not want it to update other OSes?
On Sun, Aug 30, 2015 at 4:19 AM, Paul Cartwright pbcartwright@gmail.com wrote:
On 08/29/2015 11:12 PM, Chris Murphy wrote:
grub2-mkconfig will add entries for other operating systems it can find. That will be done based on the output of the os-prober tool.
This is why one of my first modifications post-install is to /etc/default/grub to add
GRUB_DISABLE_OS_PROBER="true"
why would you not want it to update other OSes?
I've already hinted at this, because those entries are either wrong or suboptimal. Each distro has its own /etc/default/grub which contains its own unique GRUB_CMDLINE_LINUX= which really only applies to that distro. The Ubuntu GRUB menu entries for Fedora contain Ubuntu boot parameters, not Fedora's. And vice versa.
Further, because Fedora uses grubby to update its grub.cfg rather than rebuilding it from scratch, the Fedora grub.cfg never will get updated to reflect the actual state of Ubuntu's installed kernels as they change.
It's just a shitty workflow. The proper way to do this, as I've mentioned before, is grub-mkconfig should not create menu entries for "other" OS's, it should use the configfile command, and load that other OS's grub.cfg.
So I just disable this crap because it's f'n broken.
:-D
On 08/30/2015 01:35 PM, Chris Murphy wrote:
I've already hinted at this, because those entries are either wrong or suboptimal. Each distro has its own /etc/default/grub which contains its own unique GRUB_CMDLINE_LINUX= which really only applies to that distro. The Ubuntu GRUB menu entries for Fedora contain Ubuntu boot parameters, not Fedora's. And vice versa.
oh ouch...
Further, because Fedora uses grubby to update its grub.cfg rather than rebuilding it from scratch, the Fedora grub.cfg never will get updated to reflect the actual state of Ubuntu's installed kernels as they change.
It's just a shitty workflow. The proper way to do this, as I've mentioned before, is grub-mkconfig should not create menu entries for "other" OS's, it should use the configfile command, and load that other OS's grub.cfg.
So I just disable this crap because it's f'n broken.
mmm I think I see your point.. I'll work on that booting part... F12.. and clean up the entries..
On Fri, Aug 28, 2015 at 12:02 PM, Chris Murphy lists@colorremedies.com wrote:
On Wed, Aug 26, 2015 at 10:33 AM, Paul Cartwright pbcartwright@gmail.com wrote:
I installed my new drive, and everything was fine. I added another OS, and now I can't do the grub2-install anymore. What am I missing??
# grub2-install /dev/sda grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
grub2-install does not apply on UEFI systems at all, it should not be used. Instead you reinstall shim and grub2-efi packages.
grub2-install works on non-SB systems.
And there's no reason that it shouldn't work on SB systems. Aren't the grub and shim executables simply copied from "/usr/something"? So they should be signed.
On 08/29/2015 06:20 AM, Tom H wrote:
grub2-install does not apply on UEFI systems at all, it should not be used. Instead you reinstall shim and grub2-efi packages.
grub2-install works on non-SB systems.
SB-systems?
And there's no reason that it shouldn't work on SB systems. Aren't the grub and shim executables simply copied from "/usr/something"? So they should be signed. --
a little vague here, documentation?? I found I have shim installed, but I wasn't aware of it before I started having issues updating grub with my new kernels..
On 08/29/2015 03:20 AM, Tom H wrote:
grub2-install works on non-SB systems. And there's no reason that it shouldn't work on SB systems. Aren't the grub and shim executables simply copied from "/usr/something"? So they should be signed.
Not according to the documentation, which indicates that: "grub2-install shouldn't be used on EFI systems. The grub2-efi package installs a prebaked grubx64.efi on the EFI System partition, which looks for grub.cfg on the ESP in /EFI/fedora/ whereas the grub2-install command creates a custom grubx64.efi, deletes the original installed one, and looks for grub.cfg in /boot/grub2/."
On 08/29/2015 02:59 PM, Gordon Messmer wrote:
grub2-install works on non-SB systems. And there's no reason that it shouldn't work on SB systems. Aren't the grub and shim executables simply copied from "/usr/something"? So they should be signed.
that was not my writing, someone else sent that to me..
Not according to the documentation, which indicates that: "grub2-install shouldn't be used on EFI systems. The grub2-efi package installs a prebaked grubx64.efi on the EFI System partition, which looks for grub.cfg on the ESP in /EFI/fedora/ whereas the grub2-install command creates a custom grubx64.efi, deletes the original installed one, and looks for grub.cfg in /boot/grub2/."
so grub2-efi installs it, but how do you modify/maintain it??
On 08/29/2015 12:51 PM, Paul Cartwright wrote:
Not according to the documentation, which indicates that:
"grub2-install shouldn't be used on EFI systems. The grub2-efi package installs a prebaked grubx64.efi on the EFI System partition, which looks for grub.cfg on the ESP in/EFI/fedora/ whereas the grub2-install command creates a custom grubx64.efi, deletes the original installed one, and looks for grub.cfg in /boot/grub2/."
so grub2-efi installs it, but how do you modify/maintain it??
You don't. If you modify the grub2 binary, the signature is invalid and the system won't boot (under Secure Boot). There is almost certainly no reason you need to modify/maintain the grubx64.efi binary.
On 08/29/2015 04:31 PM, Gordon Messmer wrote:
so grub2-efi installs it, but how do you modify/maintain it??
You don't. If you modify the grub2 binary, the signature is invalid and the system won't boot (under Secure Boot). There is almost certainly no reason you need to modify/maintain the grubx64.efi binary.
excellent. hopefully from now on I won't have to do anything but install the new kernels, and the system will update grub.cfg .. just like the old days...
On Sat, Aug 29, 2015 at 2:59 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/29/2015 03:20 AM, Tom H wrote:
grub2-install works on non-SB systems. And there's no reason that it shouldn't work on SB systems. Aren't the grub and shim executables simply copied from "/usr/something"? So they should be signed.
Not according to the documentation, which indicates that: "grub2-install shouldn't be used on EFI systems. The grub2-efi package installs a prebaked grubx64.efi on the EFI System partition, which looks for grub.cfg on the ESP in /EFI/fedora/ whereas the grub2-install command creates a custom grubx64.efi, deletes the original installed one, and looks for grub.cfg in /boot/grub2/."
I hadn't read that page. I stand corrected.
How nice that Fedora diverges from upstream. But since this is the case, grub2-install should be patched to say so rather than tell the user "Please specify --target or --directory"...
On 08/29/2015 01:03 PM, Tom H wrote:
the grub2-install command
creates a custom grubx64.efi, deletes the original installed one, and looks for grub.cfg in /boot/grub2/." https://fedoraproject.org/wiki/GRUB_2
I hadn't read that page. I stand corrected.
How nice that Fedora diverges from upstream.
It does, considerably: http://pkgs.fedoraproject.org/cgit/grub2.git/tree/?h=f22
As far as I know, so does everyone else. However, as far as I can tell, this behavior is not one of the divergences. Building a custom efi binary is the normal behavior.
On Sat, Aug 29, 2015 at 4:41 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/29/2015 01:03 PM, Tom H wrote:
https://fedoraproject.org/wiki/GRUB_2
I hadn't read that page. I stand corrected.
How nice that Fedora diverges from upstream.
It does, considerably: http://pkgs.fedoraproject.org/cgit/grub2.git/tree/?h=f22
As far as I know, so does everyone else. However, as far as I can tell, this behavior is not one of the divergences. Building a custom efi binary is the normal behavior.
Crippling an upstream tool is beyond anything other distros patch.
On Sun, Aug 30, 2015 at 6:27 AM, Tom H tomh0665@gmail.com wrote:
On Sat, Aug 29, 2015 at 4:41 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/29/2015 01:03 PM, Tom H wrote:
https://fedoraproject.org/wiki/GRUB_2
I hadn't read that page. I stand corrected.
How nice that Fedora diverges from upstream.
It does, considerably: http://pkgs.fedoraproject.org/cgit/grub2.git/tree/?h=f22
As far as I know, so does everyone else. However, as far as I can tell, this behavior is not one of the divergences. Building a custom efi binary is the normal behavior.
Crippling an upstream tool is beyond anything other distros patch.
What's an example of crippling?
On 08/30/2015 05:27 AM, Tom H wrote:
Crippling an upstream tool is beyond anything other distros patch.
It's not crippled. The efi modules are packaged separately. If you know that you want to run grub2-install, then you need to install the "grub2-efi-modules" package. When you run grub2-install, it will rebuild /boot/efi/EFI/fedora/grubx64.efi. The bootloader will no longer be signed, and the system will no longer boot in Secure Boot mode. All of this is standard, upstream behavior.
On Sun, Aug 30, 2015 at 4:15 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/30/2015 05:27 AM, Tom H wrote:
Crippling an upstream tool is beyond anything other distros patch.
It's not crippled. The efi modules are packaged separately. If you know that you want to run grub2-install, then you need to install the "grub2-efi-modules" package. When you run grub2-install, it will rebuild /boot/efi/EFI/fedora/grubx64.efi. The bootloader will no longer be signed, and the system will no longer boot in Secure Boot mode. All of this is standard, upstream behavior.
Yeah it becomes standard upstream behavior if you install grub2-efi-modules and then grub2-install. Otherwise it's distinctly non-standard, but the GNU folks and by extension the GRUB folks, are stuck with no actual built-in Secure Boot support. All of that gets added on at the distro level. Upstream hasn't incorporated any of this, and last time I check (year or so) they explicitly had no intention of doing so and instead depend on gnupg signatures for code verification.
-
Chris Murphy -
Gordon Messmer -
Paul Cartwright -
Tom H