11:33 a.m.
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
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
11:02 a.m.
On Wed, Aug 26, 2015 at 10:33 AM, Paul Cartwright
<pbcartwright(a)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.
--
Chris Murphy
11:57 a.m.
New subject: grub2-install fails-SOLVED, I think..
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.
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
12:06 p.m.
New subject: grub2-install fails- now SHIM
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..
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
1:17 a.m.
New subject: grub2-install fails- now SHIM
On Fri, Aug 28, 2015 at 11:06 AM, Paul Cartwright
<pbcartwright(a)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.
--
Chris Murphy
6:15 a.m.
New subject: grub2-install fails- now SHIM
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...
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
2 p.m.
New subject: grub2-install fails- now SHIM
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.
https://fedoraproject.org/wiki/GRUB_2
10:12 p.m.
New subject: grub2-install fails- now SHIM
On Sat, Aug 29, 2015 at 1:48 PM, Paul Cartwright <pbcartwright(a)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"
--
Chris Murphy
5:19 a.m.
New subject: grub2-install fails- now SHIM
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?
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
12:35 p.m.
New subject: grub2-install fails- now SHIM
On Sun, Aug 30, 2015 at 4:19 AM, Paul Cartwright <pbcartwright(a)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
--
Chris Murphy
12:43 p.m.
New subject: grub2-install fails- now SHIM
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..
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
5:20 a.m.
On Fri, Aug 28, 2015 at 12:02 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Wed, Aug 26, 2015 at 10:33 AM, Paul Cartwright
<pbcartwright(a)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.
6:18 a.m.
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..
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
1:59 p.m.
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/."
https://fedoraproject.org/wiki/GRUB_2
2:51 p.m.
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/."
https://fedoraproject.org/wiki/GRUB_2
so grub2-efi installs it, but how do you
modify/maintain it??
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
3:31 p.m.
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/."
> >
> >https://fedoraproject.org/wiki/GRUB_2
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.
5:36 p.m.
On 08/29/2015 04:31 PM, Gordon Messmer wrote:
>> >
>> >https://fedoraproject.org/wiki/GRUB_2
> 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...
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
3:03 p.m.
On Sat, Aug 29, 2015 at 2:59 PM, Gordon Messmer
<gordon.messmer(a)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/."
https://fedoraproject.org/wiki/GRUB_2
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"...
3:41 p.m.
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.
7:27 a.m.
On Sat, Aug 29, 2015 at 4:41 PM, Gordon Messmer
<gordon.messmer(a)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.
12:58 p.m.
On Sun, Aug 30, 2015 at 6:27 AM, Tom H <tomh0665(a)gmail.com> wrote:
On Sat, Aug 29, 2015 at 4:41 PM, Gordon Messmer
<gordon.messmer(a)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?
--
Chris Murphy
5:15 p.m.
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.
8:15 p.m.
On Sun, Aug 30, 2015 at 4:15 PM, Gordon Messmer
<gordon.messmer(a)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
3160
days inactive
3165
days old
23 comments
4 participants
participants (4)
-
Chris Murphy -
Gordon Messmer -
Paul Cartwright -
Tom H