[Bug 1734147] Re: Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models
To Paul (sabret00the), #158: FWIW, if you want everyone to be able to see your askubuntu post you'll need to post a screenshot of it (just attach it - not going to hurt anything...). The question was deleted so it only loads for you. As for the deletion/closure, that sort of thing happens a _lot_ on stackexchange sites; don't take it personally. As for everyone else: I've just reread through this entire thread and thought I'd reiterate some of the highlights: In comment #141 Anthony Wong explained that the SPI Flash is somehow being write-protected. In comments #164, #169 and #173 Paul Sladen (sladen) copied some potentially interesting thoughts from Mika Westerberg regarding the Flash chip vendors/models. It would be very interesting if someone could post how to dig the Flash chip vendor info out of a running system - perhaps via dmidecode? Those with "kickstart-able" machines could then provide this info. (Not sure if this isn't perhaps already happening via email.) The question at this point is whether the write-protect bit is a fuse that can't be unset. If it can be unset, and some convoluted process can be executed to get bricked machines to somehow boot, well, that'll be very interesting. :) One last thing for developers/anybody who might need to coach someone through PXE booting: I found http://brokestream.com/netboot.c some time ago while looking for a tiny PXE server. This one handles DHCP+TFTP (make sure you have no DHCP server or relay running!), happily boots PXELINUX, runs great on Linux and probably other UNIX-likes, and is very simple to use. Presuming 10.42.x.x isn't in use, - ifconfig up 10.42.0.1 - (find broadcast address (not netmask :D) via ifconfig) - ./netboot 10.42.0.1 10.42.0.2 - The last dash translates to a fully ambiguous MAC address, ie so you don't have to specify that too. And 10.42.0.2 is of course the IP the PXE-ing machine will get. Installing syslinux will provide a copy of pxelinux.0 (mine was in /usr/share/syslinux). In any random dir (I used ~), if you create the directory "pxelinux.cfg" and then create the file "pxelinux.cfg/default" with the contents "default vmlinuz initrd=initrd.img" and then copy vmlinuz and initrd.img to the same root dir (~ in my case), everything should work. This PXE info may prove to be irrelevant, but I thought I'd include it just in case it turns out to be useful to have in the thread. It's also good to know that PXE is not hard to do. (It isn't, but most PXE servers presume large-scale enterprise scenarios...) As for where to get a kernel and initrd, https://help.ubuntu.com/community/Installation/MinimalCD provides an ISO file you can mount and copy the "linux" and "initrd.gz" files out of. CTRL+ALT+F2 gives you a console on this ISO. Note that this one contains _no utilities_ but is a workable start to test with. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1734147 Title: Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1734147] Re: Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models
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://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comments=all) and the systemd EFI bricking in 2016 (https://github.com/systemd/systemd/issues/2402). -- >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. ** Bug watch added: github.com/systemd/systemd/issues #2402 https://github.com/systemd/systemd/issues/2402 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1734147 Title: Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1518933] [NEW] Illegal instruction in vp9_quantize_b_ssse3() in libvpx on 14.04.2
Public bug reported: While building Xpra - a VNC-like application that uses video codecs for image transport - from source, I ran into a documented SIGILL. When Xpra starts up, I see: Program received signal SIGILL, Illegal instruction. 0x7fffe9150c27 in vp9_quantize_b_ssse3 () from /usr/lib/x86_64-linux-gnu/libvpx.so.1 (gdb) bt #0 0x7fffe9150c27 in vp9_quantize_b_ssse3 () from /usr/lib/x86_64-linux-gnu/libvpx.so.1 ... Then I `(gdb) disass $pc-32,$pc+32', and... Dump of assembler code from 0x7fffe9150c07 to 0x7fffe9150c47: 0x7fffe9150c07 : rex.B pshufw $0xe,%mm0,%mm7 0x7fffe9150c0c : pmaxsw %xmm7,%xmm8 0x7fffe9150c11 : pshuflw $0xe,%xmm8,%xmm7 0x7fffe9150c17 : pmaxsw %xmm7,%xmm8 0x7fffe9150c1c : pshuflw $0x1,%xmm8,%xmm7 0x7fffe9150c22 : pmaxsw %xmm7,%xmm8 => 0x7fffe9150c27 : pextrw $0x0,%xmm8,(%rdx) 0x7fffe9150c2e : retq 0x7fffe9150c2f : mov%r8,%rdi 0x7fffe9150c32 : mov%rcx,%rdx 0x7fffe9150c35 : mov0x30(%rsp),%rcx 0x7fffe9150c3a : lea (%rdi,%rsi,2),%rdi 0x7fffe9150c3e : lea (%rdx,%rsi,2),%rdx 0x7fffe9150c42 : neg%rsi 0x7fffe9150c45 : pxor %xmm7,%xmm7 I Googled "libvpx illegal instruction" and discovered this bug report - https://trac.ffmpeg.org/ticket/3370 - detailing **exactly the same crash**. (It's where I got the gdb command from, actually.) It wasn't an ffmpeg bug though, it's a WebM bug, and the problem was dutifully pushed upstream to https://bugs.chromium.org/p/webm/issues/detail?id=702 ...where it was apparently fixed. It would seem Ubuntu's version of this package does not include this fix. In my own case, Xpra will compile fine without WebM support and use H264 encoding instead, which actually seems to use less CPU, and is Xpra's default anyway. I'm reporting this issue primarily for the benefit of others. For reference, some of my /proc/cpuinfo: vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Pentium(R) Dual-Core CPU E5200 @ 2.50GHz stepping: 10 microcode : 0xa07 ... flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm ... The full crashdump/basic gdb analysis is attached. It also includes full /proc/cpuinfo at the end. ** Affects: libvpx (Ubuntu) Importance: Undecided Status: New ** Attachment added: "xpra-crash.txt" https://bugs.launchpad.net/bugs/1518933/+attachment/4524031/+files/xpra-crash.txt ** Summary changed: - libvpx illegal instruction + Illegal instruction in vp9_quantize_b_ssse3() in libvpx on 14.04.2 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1518933 Title: Illegal instruction in vp9_quantize_b_ssse3() in libvpx on 14.04.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1518933/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
