I disabled UEFI on my machine, but my previous test installation of dual-booting Win8/Kubuntu with UEFI worked. I did, however, install grub into the MBR, and as far as I understand selecting Win8 from the grub menu then chain-loads the actual EFI boot loader, which in turn starts Win8. This way, I didn't have to change the "BIOS" settings at all. Maybe that's an option for you. too?
If you are booting grub via the MBR, then UEFI is using legacy boot.
At which point i think grub chain loads the windows VBR... but i may be wrong.
Im not sure if i can use legacy boot, as my disk is partitioned GPT, not MBR.
the EFI vfat partition starts at sector 2048.
I know legacy grub uses the first 64 sectors... Im not sure where GPT stores its partition data... installing to MBR on GPT clobber some important stuff?
If the change is getting undone, the most likely candidate is that the file is somewhere that the BIOS can't read. It does parse the list of BootOrder and make sure that the entries are actually valid entries.
So here's some pointers to check out:
1) Check and make sure you haven't turn on Secure Boot. You probably would know if you did.
2) Is the EFI System Partition a FAT32 (vfat) partition at the start of the disk?
As a last ditch effort if you can't seem to get it to take and have a correctly formatted ESP, put the file in \efi\boot\bootx64.efi. That should work.
I know that there is some investigation going on for key debounce, not just on DE but on Windows. Are you a really fast typist? Until a better firmware solution is found, you should be able to adjust the software debounce in Gnome/KDE/Unity to adjust your typing style. Not everyone seems to encounter this, but those that are encountering the problem have had good luck with that.
With your BootOrder problem, can you check if those extra entries show up in BIOS Setup? If not, the BIOS is not liking them for some reason. I'm assuming you tried to add 0000 from F2 and 000A and 0005 from efitbootmgr? See if 0000 might stay in the list.
Also, on Arch,make sure you're running a very new kernel, like 4.0 + the HDA patches and you should be in good shape!
Boot0010* UEFI: Generic Flash Disk 8.07ACPI(a0341d0,0)PCI(1d,0)USB(0,0)USB(1,0)HD(1,800,eff800,0120017c)..BO
I know UEFI is capable of booting grub, because grub boots fine when i select it for next boot with ...
efibootmgr -n 000a
As you can see, my current boot order 3,6,7,8
If i add 000a anywhere in that boot orrrrrder, on the next boot, it is back to 3,6,7,8.
Secure boot is definatly disabled.
I will try copying grub to /efi/boot/bootx64.efi, but as that location is nowhere in the boot order, i dont see why the laptop should attempt to boot ittttttttttttt.
the EFI partition is correctly formatted.
Im so close to having the perfect laptop, just need to get it booting without USB recue disks, and sort the sticking keys.
However I would not recommend doing this unless you know what you are doing.
I know legacy grub uses the first 64 sectors... Im not sure where GPT stores its partition data... installing to MBR on GPT clobber some important stuff?
The partition table is stored twice (at the beginning and at the end of the disk). Again this is covered on the Arch Linux wiki. There is a "protective MBR" so writing to MBR in principle shouldn't clobber things
If you're using UEFI boot then the MBR is not used. The UEFI firmware directly boots one of the .efi files on your EFI partition. In my case it loads /EFI/grub/grubx64.efi
Why are you trying to use GPT without understanding how it works first?
I would recommend you either
* Use legacy boot and just use the older style MBR partition style. The easiest option
* Use UEFI boot and use GPT but actually read about it before you start trying to use it.
I had exactly the same problem. There is a different work-around, somewhat simpler: After having installed Ubuntu boot again from the live USB (UEFI or legacy), install a tool called boot-repair (help.ubuntu.com/.../Boot-Repair) and run it. Now you can reboot and the UEFI boot order should be correct.
Funny enough I found this because I got stuck with another problem when following the suggestions of CDS84. Given that I could not legacy boot my Ubuntu live USB I would need to boot it using UEFI and, hence, the boot order was again screwed in the sense that I could not set it, neither in the bios nor using efibootmgr.
Here it was suggested to use the boot-repair tool to get the boot sequence working.
I assume that boot-repair fixes grub, it certainly does nothing to the Bios nor uses it efibootmgr. However, I am not expert enough to dig into it to understand exactly where the but lies.
I had this exact problem and found a simpler solution.
It appears that while "Enable Legacy Option ROMs" is enabled in the BIOS it is not possible to add UEFI boot entries. Once I disabled the legacy options I was able to save the changes.
I'm not sure of this, but take a look at /sys/fs/pstore/ and see if you have anything in there. If you do, delete all the files, those are just old kernel logs that take precious space.
You need the kernel module "efi-pstore". I know that Debian has that module and it's automatically loaded, so it's probably the same for Ubuntu. Maybe you had a bunch of kernel oops when you used Ubuntu and the efi variable storage got filled with logs.
ralph.b
8 Posts
0
May 13th, 2015 09:00
I disabled UEFI on my machine, but my previous test installation of dual-booting Win8/Kubuntu with UEFI worked. I did, however, install grub into the MBR, and as far as I understand selecting Win8 from the grub menu then chain-loads the actual EFI boot loader, which in turn starts Win8. This way, I didn't have to change the "BIOS" settings at all. Maybe that's an option for you. too?
(Why UEFI, anyway? :-))
cds84
5 Posts
0
May 13th, 2015 14:00
Thanks for the reply... but..
If you are booting grub via the MBR, then UEFI is using legacy boot.
At which point i think grub chain loads the windows VBR... but i may be wrong.
Im not sure if i can use legacy boot, as my disk is partitioned GPT, not MBR.
the EFI vfat partition starts at sector 2048.
I know legacy grub uses the first 64 sectors... Im not sure where GPT stores its partition data... installing to MBR on GPT clobber some important stuff?
DELL-Mario L
26 Posts
0
May 13th, 2015 14:00
If the change is getting undone, the most likely candidate is that the file is somewhere that the BIOS can't read. It does parse the list of BootOrder and make sure that the entries are actually valid entries.
So here's some pointers to check out:
1) Check and make sure you haven't turn on Secure Boot. You probably would know if you did.
2) Is the EFI System Partition a FAT32 (vfat) partition at the start of the disk?
As a last ditch effort if you can't seem to get it to take and have a correctly formatted ESP, put the file in \efi\boot\bootx64.efi. That should work.
DELL-Mario L
26 Posts
0
May 13th, 2015 15:00
I know that there is some investigation going on for key debounce, not just on DE but on Windows. Are you a really fast typist? Until a better firmware solution is found, you should be able to adjust the software debounce in Gnome/KDE/Unity to adjust your typing style. Not everyone seems to encounter this, but those that are encountering the problem have had good luck with that.
With your BootOrder problem, can you check if those extra entries show up in BIOS Setup? If not, the BIOS is not liking them for some reason. I'm assuming you tried to add 0000 from F2 and 000A and 0005 from efitbootmgr? See if 0000 might stay in the list.
Also, on Arch,make sure you're running a very new kernel, like 4.0 + the HDA patches and you should be in good shape!
cds84
5 Posts
0
May 13th, 2015 15:00
Thanks...
BootNext: 000A
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0003,0006,0007,0008
Boot0000* "grubx64.efi" ACPI(a0341d0,0)PCI(1f,2)SATA(3,ffff,0)HD(1,800,fa000,184521bf-04b8-4e33-a55f-cbce902dc296)File(\EFI\grub\grubx64.efi)
Boot0002* MiniCard SSD BIOS(2,0,50333a2053414d53554e472053534420504d383531204d2e32203232383000)..BO
Boot0003* USB Storage Device BIOS(5,0,5553422053746f726167652044657669636500)..BO
Boot0005* grub HD(1,800,fa000,184521bf-04b8-4e33-a55f-cbce902dc296)File(\EFI\grub\grubx64.efi)
Boot0006* Diskette Drive BIOS(1,0,4469736b6574746520447269766500)..BO
Boot0007* MiniCard SSD BIOS(2,0,50333a2053414d53554e472053534420504d383531204d2e32203232383000)..BO
Boot0008* CD/DVD/CD-RW Drive BIOS(3,0,43442f4456442f43442d525720447269766500)..BO
Boot000A* Linux HD(1,800,fa000,184521bf-04b8-4e33-a55f-cbce902dc296)File(\EFI\grub\grubx64.efi)
Boot0010* UEFI: Generic Flash Disk 8.07 ACPI(a0341d0,0)PCI(1d,0)USB(0,0)USB(1,0)HD(1,800,eff800,0120017c)..BO
I know UEFI is capable of booting grub, because grub boots fine when i select it for next boot with ...
efibootmgr -n 000a
As you can see, my current boot order 3,6,7,8
If i add 000a anywhere in that boot orrrrrder, on the next boot, it is back to 3,6,7,8.
Secure boot is definatly disabled.
I will try copying grub to /efi/boot/bootx64.efi, but as that location is nowhere in the boot order, i dont see why the laptop should attempt to boot ittttttttttttt.
the EFI partition is correctly formatted.
Im so close to having the perfect laptop, just need to get it booting without USB recue disks, and sort the sticking keys.
THANKS.
delcypher
21 Posts
0
May 14th, 2015 01:00
Just to clarify GPT can be used independently of UEFI. I know because I've done it. The Arch Linux wiki covers using GRUB with BIOS (legacy) boot
wiki.archlinux.org/.../GRUB
However I would not recommend doing this unless you know what you are doing.
The partition table is stored twice (at the beginning and at the end of the disk). Again this is covered on the Arch Linux wiki. There is a "protective MBR" so writing to MBR in principle shouldn't clobber things
wiki.archlinux.org/.../GUID_Partition_Table
If you're using UEFI boot then the MBR is not used. The UEFI firmware directly boots one of the .efi files on your EFI partition. In my case it loads /EFI/grub/grubx64.efi
Why are you trying to use GPT without understanding how it works first?
I would recommend you either
* Use legacy boot and just use the older style MBR partition style. The easiest option
* Use UEFI boot and use GPT but actually read about it before you start trying to use it.
cds84
5 Posts
0
May 14th, 2015 03:00
Thanks.
I know how to use UEFI and GPT. I appologise for not knowing that there was a duplicate table at the end of the disk. Forgive me.
To get back on topic...
will correctly boot entry 000a ( but report current boot as 0000 )
will result in a failure to boot.
rescue disk efibootmgr -v shows that boot order is W,X,Y,Z. ( 000a was un-done )
In other words.. i can boot 000a when 000a is selected as the NEXT boot.
but i cannot boot 000a when 000a is added to the head of the boot order.
Without discussing the pros and cons of GTP vs MBR... Firmware bug... Yay or Nay?
Again, i using the latest A03 firmware.
Thanks everyone.
DELL-Mario L
26 Posts
0
May 14th, 2015 10:00
Can you try to remove the extra entries that are pointing to the same file?
cds84
5 Posts
0
May 14th, 2015 13:00
Thanks for all the surgestions.
I've stumbled upon a work-around.
1) backup EFI partition.
2) Delete all EFI files.
3) In bios, load defaults
There is a message abou boot order being reset according to EFI partition contents ( in this case NOTHING )
4) reboot - restore EFI files by legacy booting rescue USB.
5) Reboot, re-enable UEFI,Use bios menu to manuall add the grub efi.
Now, grub is installed as boot option 0000. And the default boot order is 0000.
Im not sure if the origonal problem of not being able to change boot oders still remains,
and i dont want to temp fait by experimenting.
wosen7
1 Message
0
July 18th, 2015 23:00
I had exactly the same problem.
There is a different work-around, somewhat simpler:
After having installed Ubuntu boot again from the live USB (UEFI or legacy), install a tool called boot-repair (help.ubuntu.com/.../Boot-Repair) and run it.
Now you can reboot and the UEFI boot order should be correct.
Funny enough I found this because I got stuck with another problem when following the suggestions of CDS84. Given that I could not legacy boot my Ubuntu live USB I would need to boot it using UEFI and, hence, the boot order was again screwed in the sense that I could not set it, neither in the bios nor using efibootmgr.
Digging to solve that problem led me to this forum post:
http://en.community.dell.com/techcenter/os-applications/f/4613/t/19631116
Here it was suggested to use the boot-repair tool to get the boot sequence working.
I assume that boot-repair fixes grub, it certainly does nothing to the Bios nor uses it efibootmgr. However, I am not expert enough to dig into it to understand exactly where the but lies.
idfoster
1 Message
0
July 19th, 2015 21:00
I had this exact problem and found a simpler solution.
It appears that while "Enable Legacy Option ROMs" is enabled in the BIOS it is not possible to add UEFI boot entries. Once I disabled the legacy options I was able to save the changes.
kfnmpah
1 Rookie
•
42 Posts
0
July 20th, 2015 14:00
I'm not sure of this, but take a look at /sys/fs/pstore/ and see if you have anything in there. If you do, delete all the files, those are just old kernel logs that take precious space.
More info here: https://www.kernel.org/doc/Documentation/ABI/testing/pstore
You need the kernel module "efi-pstore". I know that Debian has that module and it's automatically loaded, so it's probably the same for Ubuntu. Maybe you had a bunch of kernel oops when you used Ubuntu and the efi variable storage got filled with logs.
(I had the same problem quite some time ago: http://en.community.dell.com/techcenter/os-applications/f/4613/t/19592911)