Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install.
Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is there a way to reinstall it without reinstalling the world? Would it make sense to split the whole bootloader thing out of Anaconda such that it would be possible to re-run it? I can access my install just fine using chroot.
FWIW, the same question applies to upgrading the bootloader. Somehow I'm on Fedora 20 using grub 0.97.
--Andy
Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install.
besides that it is the wrong list: grub2-install
Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is there a way to reinstall it without reinstalling the world? Would it make sense to split the whole bootloader thing out of Anaconda such that it would be possible to re-run it? I can access my install just fine using chroot.
FWIW, the same question applies to upgrading the bootloader. Somehow I'm on Fedora 20 using grub 0.97
how comes? grub2 took over with F16 or F17
On Apr 3, 2014 7:18 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install.
besides that it is the wrong list:
What's the right list?
grub2-install
$ grub2-install /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
This is with efi. WTF is a GRUB drive? Will this set up the boot menu in anything resembling a sensible manner? (I doubt it, since I don't consider having kernel entries listed in the ESP to be sensible, but that's a separate issue.) Will it set up EFI boot manager entries? Is the efibootmgr program usable by mortals?
For non-EFI, I have to do some i386-pc crap. At least I think I have some idea how that's supposed to work.
FWIW, the last time I got grub2-mkconfig to work, it generated a config that, strictly speaking, functioned, but it spewed warnings every time I booted. That was a while ago.
Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is there a way to reinstall it without reinstalling the world? Would it make sense to split the whole bootloader thing out of Anaconda such that it would be possible to re-run it? I can access my install just fine using chroot.
FWIW, the same question applies to upgrading the bootloader. Somehow I'm on Fedora 20 using grub 0.97
how comes? grub2 took over with F16 or F17
Upgrades.
--Andy
Am 04.04.2014 04:44, schrieb Andrew Lutomirski:
On Apr 3, 2014 7:18 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
besides that it is the wrong list:
What's the right list?
the users list, not the developers list
grub2-install
$ grub2-install /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
/dev/sda1????????????
grub2-install /dev/sda don't install GRUB2 these days into a partition
grub2 was a challenge on installations running for many years because in that case you need to shrink the frist partition and move it so that there is enough space before
On Fri, Apr 4, 2014 at 10:52 AM, Reindl Harald h.reindl@thelounge.netwrote:
Am 04.04.2014 04:44, schrieb Andrew Lutomirski:
On Apr 3, 2014 7:18 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
besides that it is the wrong list:
What's the right list?
the users list, not the developers list
grub2-install
$ grub2-install /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
/dev/sda1????????????
grub2-install /dev/sda don't install GRUB2 these days into a partition
grub2 was a challenge on installations running for many years because in that case you need to shrink the frist partition and move it so that there is enough space before
I tried this recently. It installs GRUB to read the configuration file out
of /boot/grub2/grub.cfg, not out of /boot/efi/EFI/fedora/grub.cfg. The GRUB2 Wiki page doesn't say anything about how to get it set correctly for UEFI. Until I do, I need to copy /boot/efi/EFI/fedora/grub.cfg to /boot/grub2/ every time I install a new kernel.
Fred
On Thu, 2014-04-03 at 19:44 -0700, Andrew Lutomirski wrote:
On Apr 3, 2014 7:18 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install.
besides that it is the wrong list:
What's the right list?
grub2-install
$ grub2-install /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
This is with efi. WTF is a GRUB drive? Will this set up the boot
You don't want to be doing any kind of grub(2)-install if you actually have a native UEFI install. That's not how UEFI booting works. But it's difficult to divine from your emails how your system is actually set up at all.
Can you please answer the following?
1. What is the output of 'efibootmgr -v'? 2. Do you have a /boot/efi/EFI/fedora/grub.cfg ? 3. Do you have a /boot/grub/grub.conf ? 4. Do you have a /boot/grub2/grub.cfg ?
For a 'yes' answer to 2, 3 or 4 it would be nice to have the contents visible somewhere.
its now grub2-install /dev/sdX
Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine
On Mon, Apr 7, 2014 at 8:16 PM, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2014-04-03 at 19:44 -0700, Andrew Lutomirski wrote:
On Apr 3, 2014 7:18 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
Once upon a time (Fedora 15? -- I've lost track), it was possible to
reinstall the bootloader using grub-install.
besides that it is the wrong list:
What's the right list?
grub2-install
$ grub2-install /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
This is with efi. WTF is a GRUB drive? Will this set up the boot
You don't want to be doing any kind of grub(2)-install if you actually have a native UEFI install. That's not how UEFI booting works. But it's difficult to divine from your emails how your system is actually set up at all.
Can you please answer the following?
- What is the output of 'efibootmgr -v'?
- Do you have a /boot/efi/EFI/fedora/grub.cfg ?
- Do you have a /boot/grub/grub.conf ?
- Do you have a /boot/grub2/grub.cfg ?
For a 'yes' answer to 2, 3 or 4 it would be nice to have the contents visible somewhere. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, 2014-04-07 at 20:20 -0400, Corey Sheldon wrote:
its now grub2-install /dev/sdX
It's not for UEFI.
grub2 is the default now with or without uefi
Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine
On Mon, Apr 7, 2014 at 9:49 PM, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2014-04-07 at 20:20 -0400, Corey Sheldon wrote:
its now grub2-install /dev/sdX
It's not for UEFI.
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, 2014-04-07 at 23:54 -0400, Corey Sheldon wrote:
grub2 is the default now with or without uefi
But you don't run grub2-install on a UEFI native installation of Fedora. UEFI boot loading does not involve a bootloader installed in that manner.
On Tue, Apr 8, 2014 at 4:49 AM, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2014-04-07 at 20:20 -0400, Corey Sheldon wrote:
its now grub2-install /dev/sdX
It's not for UEFI.
It would be good if someone who knows something could rewrite the GRUB_2 wiki page to say that. And to stop referring to a release of Fedora that is no longer supported. The Unified Extensible Firmware Interface wiki page is rather outdated and unhelpful as well. Surprisingly, the best information I could find about efibootmgr is in a page that is actually about Fedup.
Here's what I've discovered:
If you have UEFI and you have run grub2-install, you need to un-do that by re-installing grub2-efi:
yum reinstall grub2-efi
And since Windows on my system places itself first in the EFI boot list every time it is booted, you need to run
efibootmgr -v # (to learn Fedora's boot number) efibootmgr -o <boot#1>,<boot#2>,... # (to choose which system you want to boot by default)
If you want to see how Anaconda originally ran efibootmgr, you can look at /var/log/anaconda/anaconda.program.log
Fred
So just to refresh my understanding of your setup:
you have a non-bootable system with a standard uefi dual-boot?
and you can't seem to get the bootloader (grub) to re-install....
Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine
On Tue, Apr 8, 2014 at 12:16 AM, Fred New fred.new2911@gmail.com wrote:
On Tue, Apr 8, 2014 at 4:49 AM, Adam Williamson awilliam@redhat.comwrote:
On Mon, 2014-04-07 at 20:20 -0400, Corey Sheldon wrote:
its now grub2-install /dev/sdX
It's not for UEFI.
It would be good if someone who knows something could rewrite the GRUB_2 wiki page to say that. And to stop referring to a release of Fedora that is no longer supported. The Unified Extensible Firmware Interface wiki page is rather outdated and unhelpful as well. Surprisingly, the best information I could find about efibootmgr is in a page that is actually about Fedup.
Here's what I've discovered:
If you have UEFI and you have run grub2-install, you need to un-do that by re-installing grub2-efi:
yum reinstall grub2-efi
And since Windows on my system places itself first in the EFI boot list every time it is booted, you need to run
efibootmgr -v # (to learn Fedora's boot number) efibootmgr -o <boot#1>,<boot#2>,... # (to choose which system you want to boot by default)
If you want to see how Anaconda originally ran efibootmgr, you can look at /var/log/anaconda/anaconda.program.log
Fred
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Tue, 2014-04-08 at 00:27 -0400, Corey Sheldon wrote:
So just to refresh my understanding of your setup:
Neither I nor Fred are the original poster who had the problem. He hasn't posted to this thread since Thursday.
is that a fair understanding as you know the issue?
Corey W Sheldon Owner, 1st Class Mobile Shine 310.909.7672 www.facebook.com/1stclassmobileshine
On Tue, Apr 8, 2014 at 12:31 AM, Adam Williamson awilliam@redhat.comwrote:
On Tue, 2014-04-08 at 00:27 -0400, Corey Sheldon wrote:
So just to refresh my understanding of your setup:
Neither I nor Fred are the original poster who had the problem. He hasn't posted to this thread since Thursday. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Tue, 2014-04-08 at 07:16 +0300, Fred New wrote:
The Unified Extensible Firmware Interface wiki page is rather outdated and unhelpful as well.
In what way? I wrote it, just a month or two ago. I'm not aware of anything in it which is outdated.
If you have UEFI and you have run grub2-install, you need to un-do that by re-installing grub2-efi:
yum reinstall grub2-efi
That won't 'undo' anything. The grub2-efi package doesn't actually have any scripts, so reinstalling it doesn't really do anything much.
And since Windows on my system places itself first in the EFI boot list every time it is booted,
That's likely an issue in your system's firmware or Windows install (somehow). It shouldn't be doing that.
On Tue, Apr 8, 2014 at 7:30 AM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2014-04-08 at 07:16 +0300, Fred New wrote:
The Unified Extensible Firmware Interface wiki page is rather outdated and unhelpful as well.
In what way? I wrote it, just a month or two ago. I'm not aware of anything in it which is outdated.
Sorry, my mistake. I thought this one also referred to Fedora 18. The main problem I had was the UEFI boot order problem mentioned below. This page doesn't tell me how to use efibootmgr to fix that.
If you have UEFI and you have run grub2-install, you need to un-do that
by
re-installing grub2-efi:
yum reinstall grub2-efi
That won't 'undo' anything. The grub2-efi package doesn't actually have any scripts, so reinstalling it doesn't really do anything much.
Well in my case, reinstalling grub2-efi caused GRUB2 to stop reading the configuration file from /boot/grub2/grub.cfg and to start reading from /boot/efi/EFI/fedora/grub.cfg again. I didn't have to re-run grub2-mkconfig because the configuration file was already built during the last kernel update. I haven't tried booting Windows from my GRUB menu since this fix, but I suspect it will work again, too. With the grub2-install GRUB, it couldn't find Windows because it wasn't looking in the EFI partition.
And since Windows on my system places itself first in the EFI boot list every time it is booted,
That's likely an issue in your system's firmware or Windows install (somehow). It shouldn't be doing that.
Yes, it seems that any time I touch my firmware configuration ("BIOS settings") or interrupt the boot sequence to boot Windows (after I've managed to put Fedora first), the boot order resets to Windows first. It may not be Windows doing it. I cannot move Fedora to the top of the list using the "BIOS settings", I need to use efibootmgr for that. (HP Envy 17-j007eo)
Fred
On Apr 8, 2014, at 9:19 AM, Fred New fred.new2911@gmail.com wrote:
On Tue, Apr 8, 2014 at 7:30 AM, Adam Williamson awilliam@redhat.com wrote:
In what way? I wrote it, just a month or two ago. I'm not aware of anything in it which is outdated.
Sorry, my mistake. I thought this one also referred to Fedora 18.
It does. And for UEFI it's the same since Fedora 18.
a. Anything after grub2-install is ignored because the target must be mounted, typically that's at /boot/efi.
b. If you actually use grub2-install and overwrite the existing grubx64.efi on the EFI System partition, it breaks UEFI Secure Boot computers ability to boot Fedora because the resulting bootloader will not be signed.
c. Even if you don't use Secure Boot, the custom created grubx64.efi (core.img) is sufficiently different in behavior from the prebaked grubx64.efi that you may want to pull your hair out anyway.
So everyone just needs to stop recommending reinstalling grub this way. Chances are the only reason grub would need to be reinstalled is if the EFI System partition file system is actually fakaked. There isn't a reason for it to become deleted. So the repair scenario is quite a bit more difficult than before: unmount the ESP, reformat the ESP, remount it, reinstall shim and grub2-efi packages, run grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg.
And then grep -i efibootmgr /var/log/anaconda/anaconda.program.log.
Use the resulting commands, and the last one with path to shim.efi should use double \. That ought to delete the old Fedora entry and put in a new one.
The main problem I had was the UEFI boot order problem mentioned below. This page doesn't tell me how to use efibootmgr to fix that.
If you have UEFI and you have run grub2-install, you need to un-do that by re-installing grub2-efi:
yum reinstall grub2-efi
That won't 'undo' anything. The grub2-efi package doesn't actually have any scripts, so reinstalling it doesn't really do anything much.
Ahh well, if someone has run grub2-install, reinstalling grub2-efi ought to cause the signed grubx64.efi to be reinstalled which is at least going to get them more consistency with Fedora proper as clean installed.
Well in my case, reinstalling grub2-efi caused GRUB2 to stop reading the configuration file from /boot/grub2/grub.cfg and to start reading from /boot/efi/EFI/fedora/grub.cfg again.
grub2-install core.img/grubx64.efi looks to /boot/grub2/ for grub.cfg, the prebaked one in grub2-efi looks for it on the ESP in /EFI/fedora/
I didn't have to re-run grub2-mkconfig because the configuration file was already built during the last kernel update. I haven't tried booting Windows from my GRUB menu since this fix, but I suspect it will work again, too. With the grub2-install GRUB, it couldn't find Windows because it wasn't looking in the EFI partition.
And since Windows on my system places itself first in the EFI boot list every time it is booted,
That's likely an issue in your system's firmware or Windows install (somehow). It shouldn't be doing that.
Yes, it seems that any time I touch my firmware configuration ("BIOS settings") or interrupt the boot sequence to boot Windows (after I've managed to put Fedora first), the boot order resets to Windows first. It may not be Windows doing it. I cannot move Fedora to the top of the list using the "BIOS settings", I need to use efibootmgr for that.
Ick. Well, every firmware's boot manager is different. The idea is that we should have a UI to choose which bootloader to use and therefore which OS to boot. But if your firmware doesn't offer a boot manager UI to choose an OS loader, well you're kinda stuck having to hack on grub to get it to find and chainload (I think it's multiboot on UEFI actually) the Windows bootloader.
Chris Murphy
On Tue, 2014-04-08 at 10:54 +0200, Chris Murphy wrote:
On Apr 8, 2014, at 9:19 AM, Fred New fred.new2911@gmail.com wrote:
On Tue, Apr 8, 2014 at 7:30 AM, Adam Williamson awilliam@redhat.com wrote:
In what way? I wrote it, just a month or two ago. I'm not aware of anything in it which is outdated.
Sorry, my mistake. I thought this one also referred to Fedora 18.
It does. And for UEFI it's the same since Fedora 18.
a. Anything after grub2-install is ignored because the target must be mounted, typically that's at /boot/efi.
b. If you actually use grub2-install and overwrite the existing grubx64.efi on the EFI System partition, it breaks UEFI Secure Boot computers ability to boot Fedora because the resulting bootloader will not be signed.
c. Even if you don't use Secure Boot, the custom created grubx64.efi (core.img) is sufficiently different in behavior from the prebaked grubx64.efi that you may want to pull your hair out anyway.
So everyone just needs to stop recommending reinstalling grub this way.
I don't think anyone has actually explicitly recommended doing so for UEFI; I just think the people who've mentioned it haven't understood UEFI at all and are just parroting the 'standard' advice for 'reinstalling grub'.
Thanks for the mail, though, because I didn't actually know what grub2-install *does* on UEFI, only that it's not necessary. :P
On Apr 8, 2014, at 9:14 AM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2014-04-08 at 10:54 +0200, Chris Murphy wrote:
So everyone just needs to stop recommending reinstalling grub this way.
I don't think anyone has actually explicitly recommended doing so for UEFI; I just think the people who've mentioned it haven't understood UEFI at all and are just parroting the 'standard' advice for 'reinstalling grub'.
I agree. What I meant when I said everyone was "no one in particular but it seems like some aren't realizing GRUB stuff is different on UEFI."
Chris Murphy
On Apr 8, 2014 3:19 AM, "Fred New" fred.new2911@gmail.com wrote:
snip
And since Windows on my system places itself first in the EFI boot list every time it is booted,
That's likely an issue in your system's firmware or Windows install (somehow). It shouldn't be doing that.
Yes, it seems that any time I touch my firmware configuration ("BIOS settings") or interrupt the boot sequence to boot Windows (after I've managed to put Fedora first), the boot order resets to Windows first. It may not be Windows doing it. I cannot move Fedora to the top of the list using the "BIOS settings", I need to use efibootmgr for that. (HP Envy 17-j007eo)
It may indeed be your firmware in your case, but Windows 8 does force similar annoying behaviour if you have its "fastboot" option enabled. Turn it off and you get to control your boot order again.
http://winaero.com/blog/how-to-disable-or-enable-fast-startup-in-windows-8-1... roughly what I recall doing.
On Mon, Apr 7, 2014 at 5:16 PM, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2014-04-03 at 19:44 -0700, Andrew Lutomirski wrote:
On Apr 3, 2014 7:18 PM, "Reindl Harald" h.reindl@thelounge.net wrote:
Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install.
besides that it is the wrong list:
What's the right list?
grub2-install
$ grub2-install /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map.
This is with efi. WTF is a GRUB drive? Will this set up the boot
You don't want to be doing any kind of grub(2)-install if you actually have a native UEFI install. That's not how UEFI booting works. But it's difficult to divine from your emails how your system is actually set up at all.
Sorry for the delay -- I was out of town.
Can you please answer the following?
- What is the output of 'efibootmgr -v'?
$ sudo efibootmgr -v BootCurrent: 0008 Timeout: 1 seconds BootOrder: 0003,0008,0000,0001 Boot0000* SATA2:PLDS DVD+/-RW DH-16A6S BIOS(10,0,00) Boot0001* SATA1:INTEL SSDSC2BB600G4 BIOS(11,0,00) Boot0003* grub HD(1,800,40000,75f192ff-2a82-4e4e-b83c-c41f3bb39847)File(\EFI\grub\grubx64.efi) Boot0008* UEFI: Built-in EFI Shell Vendor(5023b95c-db26-429b-a648-bd47664c8012,)AMBO Boot000A* Hard Drive BIOS(2,0,00)AMGOAMNO........o.I.N.T.E.L. .S.S.D.S.C.2.B.B.6.0.0.G.4............ ........A...................... .....>..Gd-.;.A..MQ..L.T.B.L.W.3.3.4.3.A.0.F.W.0.6.T.0.N.G. . ... ...AMBO
This is definitely screwed up. I can't fix it because any attempt to change my efi variables results in an OOPS. I can't report the OOPS with abrt because of a correct but inconsequential kernel taint due to #906568, which is probably fixed in 3.14. So I was going to wait for the 3.14 rebase or perhaps boot a custom kernel to see what helps. I haven't had time for that yet.
- Do you have a /boot/efi/EFI/fedora/grub.cfg ?
No. But I have a /boot/efi/EFI/redhat/grub.conf, attached. /etc/grub.conf is a symlink to it.
That file, in turn, contains this:
device (hd1,2) HD(1,800,40000,49d25af2-6f79-4970-8b9e-dc3ccf762c2c)
which I had to fix, once I figured out what UUID went there.
This file has been abused over the years by grubby. I like Debian/Ubuntu's way of handling this *much* better.
- Do you have a /boot/grub/grub.conf ?
No.
- Do you have a /boot/grub2/grub.cfg ?
No.
The immediate cause of my need to reconfigure the bootloader was that I changed hard disks. Imaging the partition table and fs superblocks directly causes all manner of problems because the UUIDs will be the same if I have both disks in the machine at the same time. So I copied files, and at first all I got was a grub prompt.
It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed.
My point, though, is that it would be great if either the wiki had good instructions or, even better, if anaconda's bootloader installation process were factored out into a command I could run.
--Andy
On Apr 8, 2014, at 4:29 PM, Andrew Lutomirski luto@mit.edu wrote:
$ sudo efibootmgr -v
[snip]
Boot0003* grub HD(1,800,40000,75f192ff-2a82-4e4e-b83c-c41f3bb39847)File(\EFI\grub\grubx64.efi)
Option A: This entry is correct if you aren't using UEFI Secure Boot, and you're using a grub2-install produced grubx64.efi/core.img, and you realize it points to /boot/grub2/grub.cfg.
Option B: You need to remove the entry if you're going to revert or change to the Fedora 18-20 way of doing this with the prebaked grubx64.efi in grub2-efi package.
Delete this entry with this efibootmgr -b 0003 -B
You need to install or reinstall grub2-efi and shim packages.
You need to write a new NVRAM entry pointing to shim.efi, and realize this grubx64.efi points to /boot/efi/EFI/fedora/grub.cfg.
I can't fix it because any attempt to change my efi variables results in an OOPS. I can't report the OOPS with abrt because of a correct but inconsequential kernel taint due to #906568, which is probably fixed in 3.14. So I was going to wait for the 3.14 rebase or perhaps boot a custom kernel to see what helps. I haven't had time for that yet.
Make sure the firmware is up to date. And if with 3.14 and current firmware you still get an oops when modifying NVRAM entries you'll want to file a bug against the kernel. If it were me I'd file both on kernel.org and redhat.com bugzillas with the proper cross-referencing.
It may still end up being a firmware problem that the kernel folks can't do anything about, but to have a chance of it being fixed kernel side requires a bug
- Do you have a /boot/efi/EFI/fedora/grub.cfg ?
No. But I have a /boot/efi/EFI/redhat/grub.conf, attached. /etc/grub.conf is a symlink to it.
That's what grub legacy EFI used. I forget if fedup upgrades grub on UEFI systems.
The immediate cause of my need to reconfigure the bootloader was that I changed hard disks. Imaging the partition table and fs superblocks directly causes all manner of problems because the UUIDs will be the same if I have both disks in the machine at the same time. So I copied files, and at first all I got was a grub prompt.
It's not finding the grub.cfg possibly because it's a grub2-install grubx64.efi which looks to /boot/grub2/fedora but you don't have a grub.cfg there.
It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed.
Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg.
or, even better, if anaconda's bootloader installation process were factored out into a command I could run.
I don't understand what this means.
Chris Murphy
On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy lists@colorremedies.com wrote:
You need to install or reinstall grub2-efi and shim packages.
Aha, a correct answer! Thanks! Based on this hint, I think I figured it out. I updated the wiki accordingly.
Can you take a quick look at: https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_...
I can't fix it because any attempt to change my efi variables results in an OOPS. I can't report the OOPS with abrt because of a correct but inconsequential kernel taint due to #906568, which is probably fixed in 3.14. So I was going to wait for the 3.14 rebase or perhaps boot a custom kernel to see what helps. I haven't had time for that yet.
Make sure the firmware is up to date. And if with 3.14 and current firmware you still get an oops when modifying NVRAM entries you'll want to file a bug against the kernel. If it were me I'd file both on kernel.org and redhat.com bugzillas with the proper cross-referencing.
It may still end up being a firmware problem that the kernel folks can't do anything about, but to have a chance of it being fixed kernel side requires a bug
- Do you have a /boot/efi/EFI/fedora/grub.cfg ?
No. But I have a /boot/efi/EFI/redhat/grub.conf, attached. /etc/grub.conf is a symlink to it.
That's what grub legacy EFI used. I forget if fedup upgrades grub on UEFI systems.
It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed.
Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg.
https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957
or, even better, if anaconda's bootloader installation process were factored out into a command I could run.
I don't understand what this means.
Being able to do:
$ sudo fedora-configure-bootloader
would be awesome. It would probably have to take some command line arguments.
--Andy
On Apr 9, 2014, at 12:59 PM, Andrew Lutomirski luto@mit.edu wrote:
On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy lists@colorremedies.com wrote:
You need to install or reinstall grub2-efi and shim packages.
Aha, a correct answer! Thanks! Based on this hint, I think I figured it out. I updated the wiki accordingly.
Can you take a quick look at: https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_...
Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise.
It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed.
Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg.
https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957
I'm not familiar with this usage: efibootmgr -B -b 0
If 0 is the same as 0000 then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel.
A valid command would be efibootmgr -b 0003 -B
or, even better, if anaconda's bootloader installation process were factored out into a command I could run.
I don't understand what this means.
Being able to do:
$ sudo fedora-configure-bootloader
would be awesome. It would probably have to take some command line arguments.
Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it.
Chris Murphy
On Mon, Apr 14, 2014 at 2:55 PM, Chris Murphy lists@colorremedies.com wrote:
On Apr 9, 2014, at 12:59 PM, Andrew Lutomirski luto@mit.edu wrote:
On Tue, Apr 8, 2014 at 7:41 PM, Chris Murphy lists@colorremedies.com wrote:
You need to install or reinstall grub2-efi and shim packages.
Aha, a correct answer! Thanks! Based on this hint, I think I figured it out. I updated the wiki accordingly.
Can you take a quick look at: https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_...
Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise.
Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh.
I tried to clarify it a bit, though.
It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed.
Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg.
https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957
I'm not familiar with this usage: efibootmgr -B -b 0
If 0 is the same as 0000 then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel.
A valid command would be efibootmgr -b 0003 -B
-B -b 0 seems to be the same as -B -b 0000, and my 0000 isn't the same as your 0000 :) The kernel crash is something else, in any case.
or, even better, if anaconda's bootloader installation process were factored out into a command I could run.
I don't understand what this means.
Being able to do:
$ sudo fedora-configure-bootloader
would be awesome. It would probably have to take some command line arguments.
Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it.
Anaconda does this somehow, I think. Even just exposing that would be nice.
--Andy
On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski luto@mit.edu wrote:
Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise.
Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh.
Huh, you're sure? You have to either remove all removable NVRAM boot entries, or you have to remove the file/device the entry points to trigger the use of //BOOT/BOOT<arch>.efi. If this isn't working, what does happen instead? It just hangs?
I tried to clarify it a bit, though.
It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed.
Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg.
https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957
I'm not familiar with this usage: efibootmgr -B -b 0
If 0 is the same as 0000 then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel.
A valid command would be efibootmgr -b 0003 -B
-B -b 0 seems to be the same as -B -b 0000, and my 0000 isn't the same as your 0000 :)
I'm basing it off the 0000 entry in your bug 73761. It points to a DVD drive.
Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it.
Anaconda does this somehow, I think. Even just exposing that would be nice.
No all it does is look for a Fedora boot entry in NVRAM and then uses efibootmgr -b xxxx -B against it. It doesn't have a mechanism, nor should it, to obliterate everything in NVRAM which can contain a lot more than just boot entries.
ls -l /sys/firmware/efi/efivars
Two dozen variables. On my Mac there's 50+ items including speaker and brightness level.
Chris Murphy
On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy lists@colorremedies.com wrote:
On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski luto@mit.edu wrote:
Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise.
Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh.
Huh, you're sure? You have to either remove all removable NVRAM boot entries, or you have to remove the file/device the entry points to trigger the use of //BOOT/BOOT<arch>.efi. If this isn't working, what does happen instead? It just hangs?
Hmm. I assumed that just asking the system to boot off that disk would do the trick. Apparently not.
Removing other entries is hard, given the aforementioned OOPS. :(
I tried to clarify it a bit, though.
It's currently mostly working, modulo the efibootbgr issue. But I don't actually know what to type into efibootmgr to fix it, the OOPS notwithstanding. I can probably figure it out once the OOPS is fixed.
Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg.
https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957
I'm not familiar with this usage: efibootmgr -B -b 0
If 0 is the same as 0000 then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel.
A valid command would be efibootmgr -b 0003 -B
-B -b 0 seems to be the same as -B -b 0000, and my 0000 isn't the same as your 0000 :)
I'm basing it off the 0000 entry in your bug 73761. It points to a DVD drive.
Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it.
Anaconda does this somehow, I think. Even just exposing that would be nice.
No all it does is look for a Fedora boot entry in NVRAM and then uses efibootmgr -b xxxx -B against it. It doesn't have a mechanism, nor should it, to obliterate everything in NVRAM which can contain a lot more than just boot entries.
ls -l /sys/firmware/efi/efivars
Two dozen variables. On my Mac there's 50+ items including speaker and brightness level.
I meant that I assumed that anaconda set up a new boot manager entry. If it doesn't, and just relies on fallback, then I guess there's nothing to ask for.
Of course, that'll change once anaconda becomes sensible enough to set up each ESP once and keep it unmounted from then on, since that'll involve changing the RPMs so they don't install to /boot/efi.
Unless, of course, /boot/efi just becomes the efi boot template, in which case some script will need to propagate the contents.
--Andy
On Apr 14, 2014, at 4:27 PM, Andrew Lutomirski luto@mit.edu wrote:
On Mon, Apr 14, 2014 at 3:14 PM, Chris Murphy lists@colorremedies.com wrote:
On Apr 14, 2014, at 4:04 PM, Andrew Lutomirski luto@mit.edu wrote:
Create a boot menu entry can be skipped if it's not a dual boot system. /boot/efi/EFI/BOOT contains shim.efi as bootx64.efi which is run by default on a system without an NVRAM entry already pointing to shim or grub, and a fallback entry is created automagically. With Windows, yeah you probably have to do something manually because it probably always boots Windows otherwise.
Not on my crappy motherboard :( It apparently can't boot from EFI/BOOT on a hard disk. Sigh.
Huh, you're sure? You have to either remove all removable NVRAM boot entries, or you have to remove the file/device the entry points to trigger the use of //BOOT/BOOT<arch>.efi. If this isn't working, what does happen instead? It just hangs?
Hmm. I assumed that just asking the system to boot off that disk would do the trick. Apparently not.
No. Boot entries in NVRAM come first. See UEFI spec 2.4.0, section 3.4.1.2, and 12.3.1.3 "This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost."
Removing other entries is hard, given the aforementioned OOPS. :(
Sure. OOPS isn't good. But chances are it's naughty firmware.
I tried to clarify it a bit, though.
> It's currently mostly working, modulo the efibootbgr issue. But I > don't actually know what to type into efibootmgr to fix it, the OOPS > notwithstanding. I can probably figure it out once the OOPS is fixed.
Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg.
https://bugzilla.kernel.org/show_bug.cgi?id=73761 https://bugzilla.redhat.com/show_bug.cgi?id=1085957
I'm not familiar with this usage: efibootmgr -B -b 0
If 0 is the same as 0000 then that seems to ask for the removal of a fixed entry: the DVD in CSM-BIOS mode (?) which I wouldn't expect to work, ever. But then it also shouldn't crash the kernel.
A valid command would be efibootmgr -b 0003 -B
-B -b 0 seems to be the same as -B -b 0000, and my 0000 isn't the same as your 0000 :)
I'm basing it off the 0000 entry in your bug 73761. It points to a DVD drive.
Something that properly deals with restoring shim, grub, grub.cfg, and NVRAM would be nice. But the NVRAM part might be a rat hole, seeing as some of the manufacturer NVRAM behaviors are pretty icky. And on top of that don't seem to have a good way for users to reset/wipe it. It's something I think the UEFI Forum ought to put in the standard and require it.
Anaconda does this somehow, I think. Even just exposing that would be nice.
No all it does is look for a Fedora boot entry in NVRAM and then uses efibootmgr -b xxxx -B against it. It doesn't have a mechanism, nor should it, to obliterate everything in NVRAM which can contain a lot more than just boot entries.
ls -l /sys/firmware/efi/efivars
Two dozen variables. On my Mac there's 50+ items including speaker and brightness level.
I meant that I assumed that anaconda set up a new boot manager entry. If it doesn't, and just relies on fallback, then I guess there's nothing to ask for.
It does create a new boot manager entry using efibootmgr.
Of course, that'll change once anaconda becomes sensible enough to set up each ESP once and keep it unmounted from then on, since that'll involve changing the RPMs so they don't install to /boot/efi.
Has there been buy off on this?
Chris Murphy
On Mon, Apr 14, 2014 at 4:22 PM, Chris Murphy lists@colorremedies.com wrote:
No. Boot entries in NVRAM come first. See UEFI spec 2.4.0, section 3.4.1.2, and 12.3.1.3 "This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost."
That's a little unfortunate if you have a used motherboard. Oh, well.
Anyway, as far as I can tell, the newly updated wiki page should be helpful now.
Removing other entries is hard, given the aforementioned OOPS. :(
Sure. OOPS isn't good. But chances are it's naughty firmware.
I'm sure it is. :)
Of course, that'll change once anaconda becomes sensible enough to set up each ESP once and keep it unmounted from then on, since that'll involve changing the RPMs so they don't install to /boot/efi.
Has there been buy off on this?
No clue.
I suspect it would be easy to implement by anyone who understands GRUB 2 syntax. That's not me, alas.
--Andy
On Mon, 2014-04-14 at 17:22 -0600, Chris Murphy wrote:
Huh, you're sure? You have to either remove all removable NVRAM
boot entries, or you have to remove the file/device the entry points to trigger the use of //BOOT/BOOT<arch>.efi. If this isn't working, what does happen instead? It just hangs?
Hmm. I assumed that just asking the system to boot off that disk would do the trick. Apparently not.
No. Boot entries in NVRAM come first. See UEFI spec 2.4.0, section 3.4.1.2, and 12.3.1.3 "This directory contains EFI images that aide in recovery if the boot selections for the software installed on the EFI system partition are ever lost."
THREAD NECRO ALERT!
Well, there's scope for all kinds of undefined behaviour there, really. The spec basically describes a certain minimal set of behaviours that must be implemented, but there's all sorts of scope for firmwares to implement other paths on top.
If a firmware UI implements some kind of option that could be described as "just one time, boot from this hard disk", what that might do isn't really defined by the spec at all. It could mean "do a fallback path UEFI boot from this disk". Or it could mean "do a CSM (BIOS compatibility mode) boot from this disk". Or some firmware engineer who'd hit the crack pipe *really hard* could come up with some other meaning, I guess.
On Thu, 2014-04-03 at 18:08 -0700, Andrew Lutomirski wrote:
Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install.
Just wondering if you've read this page yet:
https://fedoraproject.org/wiki/GRUB_2?rd=Grub2
On Thu, Apr 3, 2014 at 8:09 PM, Ankur Sinha sanjay.ankur@gmail.com wrote:
On Thu, 2014-04-03 at 18:08 -0700, Andrew Lutomirski wrote:
Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install.
Just wondering if you've read this page yet:
I did, but this:
This is an untested write-up from memory and guessing - be careful
didn't inspire much confidence.
--Andy
-- Thanks, Warm regards, Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Andrew Lutomirski -
Ankur Sinha -
Chris Murphy -
Corey Sheldon -
Dan Scott -
Fred New -
Reindl Harald