HELLO WORLD!
A purchased the developer ediion XPS 13 ( 2015 ) bios A03,
booted it up... and, as many people have mentioned, the trackpad is really poor, cutting out, jumping etc.
Without googleing, i decided to try to see if an update would fix the issue.
So i did the sudp apt-get update and upgrade thing
after downloading a bunch of packages, the console complained about a package conflct ( wish i wrote it down! i didnt, sorry! )
Also, touchscreen and touchpad stopped working entirely...
after a re-boot... everything was much worse... it displayed the desltop background, and a cursor. but nothing else... it was dead. trackpad, keyboard, and touchscreen did nothing.
Also, networkis dead.
I wasnt too bothered at this point, as ia hate Ubuntu anyway, and always planned on installing Arch.
Ive installed arch a billion times on UEFI systems... i know what im doing.
However, im now stuck, as i cannot add grub to the UEFI boot order.
I add it with efibootmgr, but on reboot, the change is undone.
The only way i can get arch to boot, is by booting the Arch install USB running efiboot -n (my grub number) and then re-booting.
Ive even tried adding the grubx64.efi via the F12 boot options... but again, after a re-boot the settings are re-set.
Any ideas?
It seems that this is a bios bug!?
THANKS!
Chris.
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? :-))
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?
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.
Thanks...
[code]
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
[/code]
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.
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!
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.
Use UEFI boot and use GPT but actually read about it before you start trying to use it.
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...
efibootmgr -n 000a; reboot
efibootmgr -o 000a,W,X,Y,Z; efibootmrg -v ( shows boot order as 000a,W,X,Y,Z ) reboot
efibootmgr -o 000a,W,X,Y,Z;
efibootmrg -v ( shows boot order as 000a,W,X,Y,Z )
reboot
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.
Can you try to remove the extra entries that are pointing to the same file?
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.
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:
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.
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)