[Bug 1734147] Re: Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models

[i336_]

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 1734147] Re: Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models

[i336_]

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 1518933] [NEW] Illegal instruction in vp9_quantize_b_ssse3() in libvpx on 14.04.2

[i336_]

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