Kernel panic at boot and many programs segfault / core dump
up vote
0
down vote
favorite
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
boot 18.04 kernel chroot segmentation-fault
asked Oct 15 at 0:00
cat
8911238
|
show 1 more comment
up vote
0
down vote
favorite
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
boot 18.04 kernel chroot segmentation-fault
asked Oct 15 at 0:00
cat
8911238
My inclination would be to boot with Live USB and runfsck(file system check) on the hard disk / SSD. You may be able to boot in recovery mode and runfscktoo but I've never runfsckso can't say for sure.
– WinEunuuchs2Unix
Oct 15 at 0:06
cpuiddetects 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 at 0: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 at 0:08
Sorry I missed thefsck, couldn't see the forest through the trees...
– WinEunuuchs2Unix
Oct 15 at 0:15
Very strange situation. Are you sure that python3 is not overridden? Which PPAs do you have on problematic system? Did you rundebsumson the system (from chroot or directly) to check its consistency?
– N0rbert
Oct 15 at 7:37
|
show 1 more comment
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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
boot 18.04 kernel chroot segmentation-fault
asked Oct 15 at 0:00
cat
8911238
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
boot 18.04 kernel chroot segmentation-fault
boot 18.04 kernel chroot segmentation-fault
asked Oct 15 at 0:00
cat
8911238
asked Oct 15 at 0:00
cat
8911238
edited Dec 1 at 4:56
asked Oct 15 at 0:00
cat
8911238
asked Oct 15 at 0:00
cat
8911238
asked Oct 15 at 0:00
cat
8911238
8911238
My inclination would be to boot with Live USB and runfsck(file system check) on the hard disk / SSD. You may be able to boot in recovery mode and runfscktoo but I've never runfsckso can't say for sure.
– WinEunuuchs2Unix
Oct 15 at 0:06
cpuiddetects 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 at 0: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 at 0:08
Sorry I missed thefsck, couldn't see the forest through the trees...
– WinEunuuchs2Unix
Oct 15 at 0:15
Very strange situation. Are you sure that python3 is not overridden? Which PPAs do you have on problematic system? Did you rundebsumson the system (from chroot or directly) to check its consistency?
– N0rbert
Oct 15 at 7:37
|
show 1 more comment
My inclination would be to boot with Live USB and runfsck(file system check) on the hard disk / SSD. You may be able to boot in recovery mode and runfscktoo but I've never runfsckso can't say for sure.
– WinEunuuchs2Unix
Oct 15 at 0:06
cpuiddetects 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 at 0: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 at 0:08
Sorry I missed thefsck, couldn't see the forest through the trees...
– WinEunuuchs2Unix
Oct 15 at 0:15
Very strange situation. Are you sure that python3 is not overridden? Which PPAs do you have on problematic system? Did you rundebsumson the system (from chroot or directly) to check its consistency?
– N0rbert
Oct 15 at 7:37
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 at 0:06
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 at 0: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 at 0:07
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 at 0: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 at 0:08
@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 at 0:08
Sorry I missed the
fsck, couldn't see the forest through the trees...– WinEunuuchs2Unix
Oct 15 at 0:15
Sorry I missed the
fsck, couldn't see the forest through the trees...– WinEunuuchs2Unix
Oct 15 at 0: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 at 7:37
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 at 7:37
|
show 1 more comment
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1083787%2fkernel-panic-at-boot-and-many-programs-segfault-core-dump%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1083787%2fkernel-panic-at-boot-and-many-programs-segfault-core-dump%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 runfscktoo but I've never runfsckso can't say for sure.– WinEunuuchs2Unix
Oct 15 at 0:06
cpuiddetects 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 at 0: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 at 0:08
Sorry I missed the
fsck, couldn't see the forest through the trees...– WinEunuuchs2Unix
Oct 15 at 0:15
Very strange situation. Are you sure that python3 is not overridden? Which PPAs do you have on problematic system? Did you run
debsumson the system (from chroot or directly) to check its consistency?– N0rbert
Oct 15 at 7:37