0

Today I booted up an Ubuntu computer I last used when it was working fine 2 weeks ago, and now every kernel I have (4.15.x and 4.13.x) panics at the beginning of boot, including in recovery mode.

I can't read most of the kernel panic trace but the message is not syncing: Attempted to kill init!.

I checked the RAM with Memtest86+, and fsck the boot disk: both are fine, it is not solely a hardware issue as I can use the hardware with a Live USB.

I figured I would fix it by updating in a chroot from a Live USB. That doesn't work

root@ubuntu-mate:/# apt update
Segmentation fault (core dumped)
root@ubuntu-mate:/# python3
Illegal instruction (core dumped)
root@ubuntu-mate:/# ptrace
Illegal instruction (core dumped)
root@ubuntu-mate:/# gcc
Illegal instruction (core dumped)
root@ubuntu-mate:/# debsums
Illegal instruction (core dumped)    
root@ubuntu-mate:/# dpkg
Illegal instruction (core dumped)

(ping, node and bash work fine for some reason, but shared libraries shouldn't cause this)

Those programs are installed for amd64 and they're running in a chroot on the very same amd64 hardware, on a very slightly older (4.15.29 < 4.15.33) kernel than they were intended for. The Live USB and the original Ubuntu installation are both Ubuntu MATE 18.04.1 LTS, and they both have libc6 version 2.27-3ubuntu1, which should be the same ELF interpreter ld-2.27.so.

If I copy the Live USB's Python 3 to the chroot it doesn't work:

Illegal instruction (core dumped)

And if I copy the original system's Python 3 to the Live system, it also doesn't work

Illegal instruction (core dumped)

If this were simply the original systems binaries being out of date relative to the CPU firmware, then one of these binaries should run in the other environment.

The two python3s have different checksums but the two ld.sos have the same checksums.

If I run init in the chroot (I don't know what that would actually do) the message is

Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 540: 
elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) ==
R_X86_64_RELATIVE' failed!

It's hard to tell from the code since I'm not familiar with glibc symbols, but I guess reloc->r_info is not 8 (R_X86_64_RELATIVE) for my system's ELF binaries.

What's going on, and how can I recover the ability of my old system to interpret binaries?

the PPA list (not that any of these should be causing inconsistency in ld.so)

 
** /etc/apt/sources.list.d/atom.list:
deb [arch=amd64] https://packagecloud.io/AtomEditor/atom/any/ any main

** /etc/apt/sources.list.d/atom.list.save:
deb [arch=amd64] https://packagecloud.io/AtomEditor/atom/any/ any main

** /etc/apt/sources.list.d/dr-graef-ubuntu-pure-lang_bionic-bionic.list:
deb http://ppa.launchpad.net/dr-graef/pure-lang.bionic/ubuntu bionic main

** /etc/apt/sources.list.d/google-chrome.list:
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main 

** /etc/apt/sources.list.d/google-chrome.list.save:
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main 

** /etc/apt/sources.list.d/nilarimogard-ubuntu-webupd8-bionic.list:
deb http://ppa.launchpad.net/nilarimogard/webupd8/ubuntu artful main

** /etc/apt/sources.list.d/nilarimogard-ubuntu-webupd8-bionic.list.save:
deb http://ppa.launchpad.net/nilarimogard/webupd8/ubuntu artful main

** /etc/apt/sources.list.d/nodesource.list:
deb https://deb.nodesource.com/node_8.x bionic main

** /etc/apt/sources.list.d/nodesource.list.save:
deb https://deb.nodesource.com/node_8.x bionic main

** /etc/apt/sources.list.d/skype-stable.list:
deb [arch=amd64] https://repo.skype.com/deb stable main

** /etc/apt/sources.list.d/skype-stable.list.save:
deb [arch=amd64] https://repo.skype.com/deb stable main

** /etc/apt/sources.list.d/snaipewastaken-ubuntu-ppa-artful.list:
deb http://ppa.launchpad.net/snaipewastaken/ppa/ubuntu zesty main

** /etc/apt/sources.list.d/snaipewastaken-ubuntu-ppa-artful.list.save:
deb http://ppa.launchpad.net/snaipewastaken/ppa/ubuntu zesty main

** /etc/apt/sources.list.d/vivaldi.list:
deb http://repo.vivaldi.com/stable/deb/ stable main

** /etc/apt/sources.list.d/vivaldi.list.save:
deb http://repo.vivaldi.com/stable/deb/ stable main
cat
  • 1,672
  • My inclination would be to boot with Live USB and run fsck (file system check) on the hard disk / SSD. You may be able to boot in recovery mode and run fsck too but I've never run fsck so can't say for sure. – WinEunuuchs2Unix Oct 15 '18 at 00:06
  • cpuid detects up to SSE4.2 and AVX in the Live USB as the original system's firmware also did, so I don't think it's about programs having compiled support for AVX/SSE – cat Oct 15 '18 at 00:07
  • @WinEunuuchs2Unix already fsck'd the drive, read the question :) can't boot into recovery mode, the kernel panics at the initial part of boot, i mentioned it too – cat Oct 15 '18 at 00:08
  • Sorry I missed the fsck, couldn't see the forest through the trees... – WinEunuuchs2Unix Oct 15 '18 at 00:15
  • Very strange situation. Are you sure that python3 is not overridden? Which PPAs do you have on problematic system? Did you run debsums on the system (from chroot or directly) to check its consistency? – N0rbert Oct 15 '18 at 07:37
  • @N0rbert python3 is as it comes from the official repository, see edits to many parts of the question, we don't have debsums because it crashes with Illegal instruction – cat Oct 15 '18 at 13:14

0 Answers0