Freeze on "Loading initial ramdisk" on 21.04 (kernel 5.11)

Bug #1924849 reported by MilkBoy
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu
New
Undecided
Unassigned

Bug Description

CPU:
Vendor ID: GenuineIntel
CPU family: 6
Model: 94
Model name: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
Stepping: 3

Microcode:
intel-microcode 3.20201110.0ubuntu1

won't boot at all. Tried proposed updates, but same result; stuck on loading initrd

ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package:
ProcVersionSignature: Ubuntu 5.8.0-50.56-generic 5.8.18
Uname: Linux 5.8.0-50-generic x86_64
ApportVersion: 2.20.11-0ubuntu65
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Sat Apr 17 15:40:20 2021
UpgradeStatus: Upgraded to hirsute on 2021-04-17 (0 days ago)

Revision history for this message
MilkBoy (michael-wikberg) wrote :
description: updated
affects: intel-microcode (Ubuntu) → ubuntu
description: updated
Revision history for this message
MilkBoy (michael-wikberg) wrote :

So, after installing/removing kernels several times, now linux-image-5.11.0-16-generic manages to boot up correctly, even though there seems to be a random 5-20 second longer wait before asking for disk encryption password (compared to 20.10 with 5.8 kernels). I so have no idea what's going on here :D

Revision history for this message
Kurazs Iosif Daniel (kjdro) wrote :

Hello,
 I can also confirm, starting from 2021-May-10 my Ubuntu 20.04 installations wasn't booting. From what i think might be the root cause, is some security update that went in the day before that might have updated something. All i know the next day no matter what kernel version i was choosing the boot always hanged after initrd command. No matter what i was doing i could not get more logs to be prompted.
At one point i managed to reinstall grub, then proceeded to an apt upgrade, which broke my system again, and now i cant fix it by reinstalling grub.

My setup:
2 ssd's the boot and efi partitions are ext2
then i have 2 other partitions both encrypted, that share a vgroup where my root, home, swap partitions are.

I suspect that the problem comes from insufficient testing with encrypted setups.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.