After the update to install kernel 4.15.0-72-generic my computer will not boot. On boot, all I see is the purple screen with:
Loading Linux 4.15.0-72-generic ...
Loading initial ramdisk ...
and nothing happens. Just sits there. I've waited about 5-10 minutes on occasion but to no avail.
I've checked a number of logs in /var/log but not found anything.
If I go into the advanced options and select kernel
4.15.0-70-generic, the computer boots normally.
This has previously been bugged on Launchpad [Bug 1856387],but have been advised to also lodge a bug on bugzilla.
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-72-generic 4.15.0-72.81
ProcVersionSignature: Ubuntu 4.15.0-70.79-generic 4.15.18
Uname: Linux 4.15.0-70-generic x86_64
USER PID ACCESS COMMAND
/dev/snd/controlC0: tony 1977 F.... pulseaudio
Date: Sat Dec 14 21:53:14 2019
InstallationDate: Installed on 2018-09-16 (454 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 04f2:b59e Chicony Electronics Co., Ltd
Bus 001 Device 002: ID 046d:c063 Logitech, Inc. DELL Laser Mouse
Bus 001 Device 004: ID 8087:0aaa Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: GIGABYTE Sabre 17WV8
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-70-generic root=UUID=9455257c-d3b7-4d61-853d-ab0b0ee40013 ro acpi=off
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.vendor: American Megatrends Inc.
dmi.board.asset.tag: Tag 12345
dmi.board.name: Sabre 17WV8
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.product.name: Sabre 17WV8
dmi.product.version: Not Applicable
Doing a Bisect (Ubuntu) I have established that the problem arose as a result of commit f723dd269d0740e09af47bb5590ffc4f61766153 as follows:-
git bisect good
f723dd269d0740e09af47bb5590ffc4f61766153 is the first bad commit
Author: Thomas Gleixner <email@example.com>
Date: Thu Nov 7 09:05:00 2019 +0100
x86/timer: Skip PIT initialization on modern chipsets
Recent Intel chipsets including Skylake and ApolloLake have a special
ITSSPRC register which allows the 8254 PIT to be gated. When gated, the
8254 registers can still be programmed as normal, but there are no IRQ0
Some products such as the Connex L1430 and exone go Rugged E11 use this
register to ship with the PIT gated by default. This causes Linux to fail
Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with
apic=debug and send a report.
The panic happens before the framebuffer is initialized, so to the user, it
appears as an early boot hang on a black screen.
Affected products typically have a BIOS option that can be used to enable
the 8254 and make Linux work (Chipset -> South Cluster Configuration ->
Miscellaneous Configuration -> 8254 Clock Gating), however it would be best
to make Linux support the no-8254 case.
Modern sytems allow to discover the TSC and local APIC timer frequencies,
so the calibration against the PIT is not required. These systems have
always running timers and the local APIC timer works also in deep power
So the setup of the PIT including the IO-APIC timer interrupt delivery
checks are a pointless exercise.
Skip the PIT setup and the IO-APIC timer interrupt checks on these systems,
which avoids the panic caused by non ticking PITs and also speeds up the
Thanks to Daniel for providing the changelog, initial analysis of the
problem and testing against a variety of machines.
Reported-by: Daniel Drake <firstname.lastname@example.org>
Signed-off-by: Thomas Gleixner <email@example.com>
Tested-by: Daniel Drake <firstname.lastname@example.org>
(backported from commit c8c4076723daca08bf35ccd68f22ea1c6219e207)
Signed-off-by: You-Sheng Yang <email@example.com>
Acked-by: Stefan Bader <firstname.lastname@example.org>
Acked-by: Connor Kuehl <email@example.com>
Signed-off-by: Stefan Bader <firstname.lastname@example.org>
:040000 040000 9c51f067713006f928684555c3254e89bdc10361 ad4d7a34eed39a733c78e630f4d9125f67e001bb M arch
Sorry, I should have added this as well. I have tried a number of upstream kernels and the problem is still reproducible with v5.5-rc5.
MSI X470 Gaming M7 AC + AMD Ryzen 7 2700 8-Core
NX Mode [Disabled] will cause kernel 4.15.0-72-generic and 4.15.0-74-generic to hang after " Loading initial ramdisk ...". Changing MX Mode to [Enabled] allows it to boot.
This comment may or may not be relevant to this issue. I came here from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856387
Hello, thanks for responding. Sadly, I couldn't find any option for that in the bios. Searched for both NX (amd) and XD (intel).
(In reply to rcpa0 from comment #2)
> MSI X470 Gaming M7 AC + AMD Ryzen 7 2700 8-Core
> NX Mode [Disabled] will cause kernel 4.15.0-72-generic and 4.15.0-74-generic
> to hang after " Loading initial ramdisk ...". Changing MX Mode to
> [Enabled] allows it to boot.
> This comment may or may not be relevant to this issue. I came here from
That's a different problem.
This setting Enables or Disables the no-execute page protection function.
Please open a separate bug for this.
Thomas has proposed a patch to resolve this problem and I have applied these changes at both the identified commit and also at the latest version and in both cases my computer booted successfully.
Also tagged and commented in Launchpad.
I can confirm that I have applied the same patch to 4.15.0-76.86-generic. Without the patch my system failed as described above. With the patch it seems to work.
This is my first post and my first attempt at building a kernel, so I hope this is not considered to be noise.