Comment 195 for bug 1734147
Revision history for this message
| David Lindsay (asmqb7) wrote Re: Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models | #195 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Paul (sabret00the) (#190): All good - stackexchange doesn't make that detail (the fact that the direct URL only loads for you) obvious. Not sure why, I presume to combat spam or something.
--
Hmm. Quoting a bit of #193 (uocc4me / uoccdisp-uone):
> After clobbering the bios during the 17.10 install, I erased 17.10 and installed 16.04. The machine has been running Ubuntu 16.04 just fine for several weeks now (many reboot cycles), although things like hibernate and suspend don't work, presumably because the bios is stuck in legacy mode (can't switch to UEFI).
This (and the rest of the report) seems to disprove the "two full reboots" theory. :(
I wonder what chip models that Mika Westerberg was dealing with (re #169 and #173) and whether they were Winbond or not. The links from those comments are only about the Yoga, there's no mention of the actual vendor type.
If the SPI Flash model is different in Mika's case then maybe there are different solutions for different Flash chips.
--
From #193 allen (krell):
> I think we are off on the wrong track. This is fundamentally a CVE against Insyde Software BIOS and possibly other vendors.
In the same class as the Samsung samsung-laptop bricking in 2013 (https:/
--
From #192 Miguel Alejandro Roche Villarreal (exploud345):
> I have a Acer Aspire E5-511-C5QS with the same issue with BIOS, i try solution from TOXIC (toxicpublic) in #185, but says invalid EFI file path, also i can't try solution from Paul Sladen(#173) because i can't boot Ubuntu, only Grub Shows and allow me to boot my Windows 10 partition, i hope someone finds a solution for Windows
I may be wrong as I'm still learning the intricacies of EFI, but it's possible GRUB is simply confused about your partition structure and you can tell it where to find and boot Linux.
Figuring out where it glitched is beyond the scope of this thread - you'll want to go hunting online for this info - but here is a POTENTIALLY DANGEROUS trick that may make the process easier if you just have the one computer.
You don't have to continually reboot between Windows and GRUB to test things out, you can simply create a new virtual machine in eg virtualbox and point the VM at your computer's hard drive.
The only dangerous part is accidentally selecting to boot Windows in the VM: running two operating systems off of one disk is going to mean corrupted files, as both OSes compete for raw access to the disk (and have increasingly different ideas of what data is where).
So if you can carefully make sure you don't boot Windows from GRUB (and maybe even keep task manager open to kill virtualbox instantly in case you do), I'm reasonably confident (standard disclaimers apply) that you may be able to fiddle around and get GRUB booting Linux.
Booting Linux inside the VM should be safe, as it's the only copy of Linux running off that particular partition. The idea is to figure out what to do in GRUB to make Linux boot, write the commands down, then reboot and apply the commands.
The above being said, standard disclaimers do apply, there are many little unforeseen things that could go wrong with this. I don't know what EFI information Ubuntu saves between reboots; what happens when the system is rebooted from a VM onto bare metal may be worth reasoning through.
I also WOULD NOT recommend getting GRUB to save the EFI information _from inside the VM_ - both because this will rewrite the boot sector and EFI partition and this might give Windows indigestion, and also because virtualbox's EFI setup is going to be different to the real hardware.