You are not logged in.
As stated: I try to create new entries with efibootmgr, but nothing happens.
At the moment, I have 3 entries:
root@kdesktop /home/keikoz # efibootmgr
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0000,0003
Boot0000* rEFInd
Boot0002* Archlinux
Boot0003 Hard Drive
I try to create a new one:
root@kdesktop /home/keikoz # efibootmgr -c -g -d /dev/sda -p 1 -w -L "rEFInd-SSD" -l '\EFI\refind\refindx64.efi'
But I still have 3 entries:
root@kdesktop /home/keikoz # efibootmgr
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0000,0003
Boot0000* rEFInd
Boot0002* Archlinux
Boot0003 Hard Drive
Note 1: some month ago, when I first installed the UEFI-GPT system, i could create entries without problems.
Note 2: My MOBO is an Asus P8Z77-V LE and I've read on another topic that it could be a matter of UEFI firmware. I just updated the bios to the latest version, but the problem is still there.
Any ideas ?
Last edited by kero (2013-04-28 21:24:43)
Offline
That looks like a bug to me, but I don't have a solution. I do have two comments, though:
The -g and -w options are almost certainly unnecessary; -g causes the program to treat a disk with an invalid protective MBR as valid, and -w writes a unique signature to the MBR if needed, according to the man page. In all honesty, I'm not really 100% sure what the practical effects of either of these options is, but I've never used them, and I don't believe either is necessary on a healthy system. Using them, though, might trigger a bug that could have unintended consequences. Therefore, my advice is to not use them. Either switch is probably better handled by writing a fresh and valid protective MBR with a tool like gdisk or parted, although I'd really want to discuss the matter with efibootmgr's author to understand why those options exist in the first place before making an absolute statement on their value.
You've specified "-d /dev/sda" and "-p 1", which together tell the program that your ESP is on /dev/sda1. This is the default, so those options also have no effect and could be eliminated. They're more commonly used, though, and so are less likely to be a source of trouble, with one caveat: If your ESP is not /dev/sda1, you should adjust those parameters appropriately. I just tested and found that specifying the wrong partition did create an entry; however, that behavior might be system-dependent or might vary between efibootmgr versions, and I might not be using the same version that you're using.
Offline
Thanks for your answer.
The -g and -w options are almost certainly unnecessary; -g causes the program to treat a disk with an invalid protective MBR as valid, and -w writes a unique signature to the MBR if needed, according to the man page. In all honesty, I'm not really 100% sure what the practical effects of either of these options is, but I've never used them, and I don't believe either is necessary on a healthy system. Using them, though, might trigger a bug that could have unintended consequences. Therefore, my advice is to not use them. Either switch is probably better handled by writing a fresh and valid protective MBR with a tool like gdisk or parted, although I'd really want to discuss the matter with efibootmgr's author to understand why those options exist in the first place before making an absolute statement on their value.
You are probably right. Actually, I just followed the indication of the wiki. Anyway, leaving these options out doesn't solve the problem. Other things can also not be done, as changing the boot order.
That looks like a bug to me.
Indeed: I searched on the bugtracker, and the same problem is reported here: https://bugs.archlinux.org/task/34641
Last edited by kero (2013-04-28 23:14:22)
Offline
srs5694 schrieb:
The -g and -w options are almost certainly unnecessary; -g causes the program to treat a disk with an invalid protective MBR as valid, and -w writes a unique signature to the MBR if needed, according to the man page. In all honesty, I'm not really 100% sure what the practical effects of either of these options is, but I've never used them, and I don't believe either is necessary on a healthy system. Using them, though, might trigger a bug that could have unintended consequences. Therefore, my advice is to not use them. Either switch is probably better handled by writing a fresh and valid protective MBR with a tool like gdisk or parted, although I'd really want to discuss the matter with efibootmgr's author to understand why those options exist in the first place before making an absolute statement on their value.
You seem quite knowlegdable in that topic, would you mind changing this section:
https://wiki.archlinux.org/index.php/Be … de#EFISTUB
Offline
srs5694 wrote:srs5694 schrieb:
The -g and -w options are almost certainly unnecessary; -g causes the program to treat a disk with an invalid protective MBR as valid, and -w writes a unique signature to the MBR if needed, according to the man page. In all honesty, I'm not really 100% sure what the practical effects of either of these options is, but I've never used them, and I don't believe either is necessary on a healthy system. Using them, though, might trigger a bug that could have unintended consequences. Therefore, my advice is to not use them. Either switch is probably better handled by writing a fresh and valid protective MBR with a tool like gdisk or parted, although I'd really want to discuss the matter with efibootmgr's author to understand why those options exist in the first place before making an absolute statement on their value.You seem quite knowlegdable in that topic, would you mind changing this section:
https://wiki.archlinux.org/index.php/Be … de#EFISTUB
This is because srs5694 is the author and maintainer of rEFInd and gptfdisk. I would hope he is knowledgable since all us UEFI and/or GPT using folks are trusting our machine configurations to his software. That is why srs5694 is such a bad ass.
Edit: I made the change to the Beginner's Guide.
Last edited by WonderWoofy (2013-04-28 18:43:30)
Offline
Little update: considering the bug that I reported over, I solved the problem by downgrading temporarily the kernel, to a 3.7.x version. That gives me the possibility to make the necessary changes with efibootmgr.
I mark the issue as "solved".
Last edited by kero (2013-04-28 21:26:18)
Offline