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 python3
s have different checksums but the two ld.so
s 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
fsck
(file system check) on the hard disk / SSD. You may be able to boot in recovery mode and runfsck
too but I've never runfsck
so can't say for sure. – WinEunuuchs2Unix Oct 15 '18 at 00:06cpuid
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:07fsck
, couldn't see the forest through the trees... – WinEunuuchs2Unix Oct 15 '18 at 00:15debsums
on the system (from chroot or directly) to check its consistency? – N0rbert Oct 15 '18 at 07:37debsums
because it crashes withIllegal instruction
– cat Oct 15 '18 at 13:14