SURVEY: What's your experience of LL installed in UEFI mode - good, bad or ugly?

[tomt]

What I posted is not the same as your video. Why would a beginner coming from windows want to go through all that work when a much smaller Distro #45 just released an updated version with UEFI/Secure Boot support baked in? Peppermint 07.

  It comes in both 32-bit and 64-bit editions with the latter having full UEFI/GPT/Secure Boot support baked in, a new version of Ice (our in-house Site Specific Browser framework) is also included with full Firefox web browser support, as well as Chromium. Along with the shift to the 16.04 code

[trinidad]

Sorry Mike if you misunderstand my reply, or I misunderstood Coastie's questions. I have not installed LL 3 on any boxes yet, but have installed 2.8 32 and/or 64 on a least a dozen, with mixed results. Some with difficulty. Some without. Only windows 8 has ever been a problem.  The only reason to use the <force> command is because windows was unable to boot through a normal EFI boot loader because of buggy firmware and was originally installed to the removable media path to avoid the failed boot loader firmware and always boot. The <allow> command is not a universal solution, but an MS fix to allow the change to be made on some OEM's but again it is itself unreliable and varies with OEM's, sometimes due to key requirements, other times due to broken OEM firmware. Sometimes when removable media is written with grub efi by <force> and even ,<allow>, so that Debian install can boot from a DVD, the underlying buggy firmware will not boot windows afterwards. To boot both windows and Debian you must change the removable media path back again, so that windows can once again boot, but of course this is no guarantee that Debian will be able to access DVD through the removable media path after that. EFI has long been supported in Debian, much longer than MS consumer software products, but the issues remain with OEM firmware. The solutions to the sloppy MS practices involving OEM firmware will take some time to appear for Debain users. I use different work arounds when I encounter buggy firmware, and operate from Debian, and not a D-based distro when I can, to make changes, which is problematic but more reliable. In any case the problem is rarely with the Debian based distro, and almost always traceable to buggy, or inoperable OEM firmware, over written in the ESP to force MS windows to load from r-media path no matter of its condition. As far as secure boot in Debian, it may be some time before a stable version appears. Most people don't like to hear that their machine, even some new ones, have broken firmware, unfortunately this is frequently the case. This of course is the whole point of U EFI, to resolve such issues, and force lazy OEM's toward a conscience. As with all things Debian, solutions will evolve from the high end (server systems) down eventually encompassing and assimilating as much of the OEM consumer market as possible. In any case EFI installation problems are not with the design of this distro, but always with buggy or broken OEM firmware, and MS sloppy practices. I have not watched the video you refer to, but if it has worked for some people, it is helpful. That's the nature of this thing. 

https://wiki.debian.org/UEFI#Force_grub-...media_path
https://wiki.debian.org/SecureBoot
https://bugs.debian.org/cgi-bin/bugrepor...bug=820036

Trinidad

 

[m654321]

Sorry Mike if you misunderstand my reply, or I misunderstood Coastie's questions. I have not installed LL 3 on any boxes yet, but have installed 2.8 32 and/or 64 on a least a dozen, with mixed results. Some with difficulty. Some without. Only windows 8 has ever been a problem...

Hi Trinidad,
Many  thanks for taking the time to give such a long reply - some of what you said went  a bit over my head but I get the general gist.
I was particularly interested that you mentioned Win8.1 only being a problem?  What was the nature of the problem & did Win7 avoid it? 

The only issue I seem to have had (though it's nonetheless a tiresome one!) with  the Win8.1/LL2.8 UEFI dual-boot,  wasn't with Win8.1 itself, but  appears  to have been with booting-up on the LL side, where LL would sometimes 'hang indefinitely'  at the start-up screen.  It happens regularly, say after around 20 boot-ups into LL.  To resolve this periodic booting issue, I carry out either one of the following two silly work-arounds:

Solution ( 1): Exit the 'hanging LL'  and return to the grubscreen  (by pressing Ctrl-Alt-Del  keys together), boot into Win8.1 and then logout, and reboot into LL

Solution (2): Exit the 'hanging LL' and return to the boot-device list , go to Setup, disable Secure boot, enable CSM, save new settings, and reboot into LL.  When this is working, Secure boot is re-enabled and CSM disabled.  Everything then proceeds wonderfully until around 20 boot-ups later when the problem re-emerges and I have to go through Solution (1) or (2), yet again...

I  should  mention that 'Fast boot' always  remains  disabled for the above UEFI dual-boot setup.

Did you experience the 'hanging LL' issue?  What was the issue with Win8.1?

Looking forward to your reply

Cheers 
Mike

[trinidad]

I actually had the opposite problem on a friends big custom built 64bit Asus with a 1T SSD, after installing LL2.8 64. Windows 8.1 which was the original system loaded to its boot screen, hung, and then black screened. I had to restore the r-m path for it to load. AMI had no other solution at the time, though since Windows10 the problem does not exist. The board supported BIOS booting, but would not fully boot windows 8.1 after installing LL2.8, even though grub installed properly and recognized the windows system. I have heard several reasons for the problem, none of which proved to be correct. It now works perfectly with Windows10, LL 2.8, and LXDE Posh all installed. I've never had this issue with Windows7 or 10. So many of these problems are OEM and MS related especially with low end laptops. Your problem may be being caused by a logging function in the Windows8 EFI version. EFI Logs do not clean from the BIOS boot, so you must boot from windows EFI occasionally to empty them. Again this does not exist with Windows10. I think the Windows 8 solution to log overrun was a patch. Newer systems have dispensed with the logs altogether. Just a guess. BIOS are going to be disappearing on new laptops, and secure boot for Windows is here to stay, though it's only real purpose is to protect windows systems. These issues are going to continue for Debian based distros until Debian catches up to them. It's like breaking a dozen same colored glasses into a box, and then trying to reassemble each one correctly.

Trinidad         

[trinidad]

You may find this resource more helpful.

http://www.rodsbooks.com/refind/secureboot.html

Trinidad

[N4RPS]

Hello!

I have two UEFI laptops here, and when it comes to installing 3.0 and 'shimming in' UEFI, I'm batting .500.

My Dell 3135 netbook upgrade/install went smoothly by following your tutorial. However, on my Toshiba L55D laptop, I couldn't mount the bios_grub partition I created in the 3.0 installer. It couldn't recognize the partition type.

Apparently, there have been changes in the way all this works in 16.04, as opposed to the way it works in 14.04. This seems to have affected being able to install n3.0 in a multiboot USB environment, and the way the 16.04 installer works.

For ME, even the 'buntu 16.04 installer wouldn't let me install updates along with the base OS. Even though I had a working wireless connection set up, the 'install updates' option was grayed out, no matter what I tried.

16.04.1 is supposed to be released sometime this month. Let's see what the 'buntu boys fix for us all in THAT version, and see what filters down into 3.2.

Perhaps some of the issues people are now facing with 3.0 will disappear on their own, as the Bluetooth issues finally did. In all fairness, Bluetooth was and still is 'broken' in ALL the Debian-based distros  including the 'buntus - despite progress having been made in getting a working version of blueman into the repositories. Had they bothered to include all the .conf files in the /etc/bluetooth folder, they'd have nailed it...

73 DE N4RPS
Rob

[m654321]

My Dell 3135 netbook upgrade/install went smoothly

Thanks for your reply Rob 
So, from what you said above, LL3.0 (with UEFI) installed without a hitch on the Dell 3135?
Does this mean for you that the terminal accepted the use of --force for the following lines where you're 'shimming'...

Code:

apt-get purge -y --force-yes grub* shim-signed linux signed*

and

Code:

apt-get install -y --force-yes grub-efi-amd-signed shim-signed linux-signed-generic

As I mentioned previously, when the install of LL3.0 (with UEFI) was attempted on my Asus G750, the terminal said  --force was deprecated in 16.04. It suggested using --allow, but I couldn't get it to work. Maybe I'm doing something wrong.

Mike

[trinidad]

"However, on my Toshiba L55D laptop, I couldn't mount the bios_grub partition I created in the 3.0 installer. It couldn't recognize the partition type."

Four things I can think of that could cause this, usually by installers detecting disk partitioning inconsistencies, and/or NVRAM change permissions, and OEM specific code requirements

1)GUID and MBR on the same disk.
2)Old style Award BIOS 16bit requirements (If you are attempting dual boot legacy options)
3)HD path missing in NVRAM for the new boot loader. (the most likely cause, and common for the base Debian installer)
4)case sensitivity OEM bug

Being a Toshiba there may be an OEM pre-boot overlay called HWsetup which may have to be configured to match the windows boot and EFI systems changes. Just more MS junk redundancy. Also worth noting that Windows computers that have the UEFI but no standard BIOS have separate programs that run the POST tests and setup automatically at system startup so setting up Linux Lite to run by itself, could require obtaining a mobo specific BIOS from the OEM because in some cases the files will disappear without Windows remaining on the drive, or a new flash of the BIOS, via jumper or battery removal may be necessary. I'm not an Ubuntu guy, but check to see if the HD path is there or not before you do anything else. If it isn't you may need to use rEFInd to solve it.

Trinidad

[N4RPS]

My Dell 3135 netbook upgrade/install went smoothly

Thanks for your reply Rob 
So, from what you said above, LL3.0 (with UEFI) installed without a hitch on the Dell 3135?
Does this mean for you that the terminal accepted the use of --force for the following lines where you're 'shimming'...

Code:

apt-get purge -y --force-yes grub* shim-signed linux signed*

and

Code:

apt-get install -y --force-yes grub-efi-amd-signed shim-signed linux-signed-generic

As I mentioned previously, when the install of LL3.0 (with UEFI) was attempted on my Asus G750, the terminal said  --force was deprecated in 16.04. It suggested using --allow, but I couldn't get it to work. Maybe I'm doing something wrong.

I also got the error about that being deprecated, but just ignored it and went on, and everything seems to have successfully completed  I'm on that same machine now, with a UEFI version of LL 3.0. Hit or miss, I suppose.

I'm glad it DID work out for me, as I'm not going to switch back and forth between UEFI Secure Boot and Legacy all the time. If they only had a UEFI version of Redo Backup...

73 DE N4RPS
Rob

[N4RPS]

Hello!

"However, on my Toshiba L55D laptop, I couldn't mount the bios_grub partition I created in the 3.0 installer. It couldn't recognize the partition type."

Four things I can think of that could cause this, usually by installers detecting disk partitioning inconsistencies, and/or NVRAM change permissions, and OEM specific code requirements

1)GUID and MBR on the same disk.
2)Old style Award BIOS 16bit requirements (If you are attempting dual boot legacy options)
3)HD path missing in NVRAM for the new boot loader. (the most likely cause, and common for the base Debian installer)
4)case sensitivity OEM bug

Being a Toshiba there may be an OEM pre-boot overlay called HWsetup which may have to be configured to match the windows boot and EFI systems changes. Just more MS junk redundancy. Also worth noting that Windows computers that have the UEFI but no standard BIOS have separate programs that run the POST tests and setup automatically at system startup so setting up Linux Lite to run by itself, could require obtaining a mobo specific BIOS from the OEM because in some cases the files will disappear without Windows remaining on the drive, or a new flash of the BIOS, via jumper or battery removal may be necessary. I'm not an Ubuntu guy, but check to see if the HD path is there or not before you do anything else. If it isn't you may need to use rEFInd to solve it.

Trinidad

Thank you for your diagnosis. However, with no spare time at the moment to research this further, I'll just keep THAT particular machine on 2.8 for the time being.

Of course, as always, if and when I find a workaround, I'll share it with the community...

73 DE N4RPS
Rob