Unsolved
This post is more than 5 years old
42 Posts
0
41226
XPS13 9333 - UEFI: efi_no_storage_paranoia
Hi,
I set up my XPS13 9333 to dual boot Windows and Linux (EFI, no legay MBR). Everything had been working fine till recently, when turning on the laptop simply started Windows (FYI I don't have the dev edition) without letting me choose the OS.
After some research, I found that the problem is that more than half of the NVRAM is used. Because of some buggy firmwares, "efibootmgr" won't add anything to the NVRAM unless a specific option is passed to the kernel (efi_no_storage_paranoia).
If I don't pass that parameterl, there's no way for me to add new entries to the NVRAM (and hence use Linux). Removing some of the existing entries is not an option either because upon reboot the BIOS restores them, reverting all my changes.
I really don't want to switch to the legacy boot, also because it requires a complete wipe of all my data and I also don't want to use Windows only.
Can someone from Dell say whether UEFI is working correctly on this laptop and passing efi_no_storage_paranoia to the kernel is safe or not? I don't want to discover this by briking my laptop.
Thanks.
DELL-Jared D
350 Posts
1
July 24th, 2014 19:00
First, that sounds peculiar if you previously were dual-booting just fine since the EFI boot entries shouldn't be changing, at least on the Linux side: the firmware only knows enough to load grub, and that shouldn't change at all when you upgrade your kernel. I'd like to know what the output of "efibootmgr -v" is. It sounds like the root cause of the issue is that Windows did something to the boot entry list or made some other change. A couple of things that can cause problems are Windows' Fast Boot functionality and Secure Boot. Also, what version of Windows are you running? You might also want to look at this (and similar information on these issues): http://askubuntu.com/questions/371559/grub-not-showing-on-startup-for-windows-8-1-ubuntu-13-10-dual-boot
Second, to answer your question about buggy firmware, that "efi_no_storage_paranoia" option is because of another vendor's firmware. As far as I know, Dell hardware has never been affect by similar bugs. If you're curious, here's some entertaining reading:
http://mjg59.dreamwidth.org/22855.html
http://mjg59.dreamwidth.org/25091.html
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=68d929862e29a8b52a7f2f2f86a0600423b093cd
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=8c58bf3eec3b8fc8162fe557e9361891c20758f2
kfnmpah
42 Posts
0
July 25th, 2014 07:00
I too find strange that only now the bug appeared.
I first installed Linux, Debian to be more specific, months ago. Few days ago I had to reinstall everything and that's when the problems started. I had to pass efi_no_storage_paranoia to install GRUB, because grub-install couldn't add a new entry in NVRAM as before. Then an update of GRUB made it disappear. This happened once more.
I don't know why I have this problem only now, maybe the first time I installed Debian I was using an old kernel or maybe the BIOS update that I did after I installed Debian changed something.
Anyway, using bcedit as suggested in the first link you posted, I modified the entry originally intended to boot Windows to start GRUB instead. "grub-install" normally keeps the original entry for Windows, adds one for GRUB and makes it the default one, but this other solution works just fine.
Thank you very much for the hint
kfnmpah
42 Posts
0
August 26th, 2014 17:00
I needed a kernel oops to find the real source of the problem.
I'm using the EFI pstore backend, which means pstore is using the non-volatile EFI storage for my logs. I had enough logs to not be able to fill the NVRAM more without efi_no_storage_paranoia.