Running Fedora 39 on FW13 AMD. Fedora froze and then I did a hard shutdown via powerbutton. Now the laptop hangs at boot on dracut-initqueue.
See attached image.
Happens with kernels 6.5.6, 6.6.7, and 6.6.8.
Boot was always fine with each of these kernels.
Any help is much appreciated.
Have you tried to boot with a live usb? If it reaches its target I would try chrooting and investigating further. It could be as simple as needing to regenrate your intrd with dracut, it could also be that your crypt partition is borked. Regardless first step is a live usb or boot into rescue mode and investigate.
You can ask it on the “Ask Fedora” forum on Fedora or/and open a Fedora Bugzilla ticket by selecting component: dracut. You can see [Fedora 39] on the Framework Laptop too.
Thanks both. Booting via USB works.
I am having superblock issues with the LUKS partition. Not sure where I go from here.
If you want to find a workaround or want to see the issue fixed, you can open a Fedora Bugzilla ticket with component: dracut. See this part for the instructions.
Then the maintainers of the dracut RPM package may see your report and suggest what to do. Please remember it’s helpful to report with your environment (Fedora version, dracut RPM version, kernel version by the commands below), and reproducing steps.
$ rpm -q dracut
$ uname -r
If you want to ask question casually to find the workaround or to fix the issue, you can ask it on Ask Fedora.
I am not sure if your issue is already reported in the “Bug URL” below. But I can see some urgent /high issue tickets. You can comment, communicate, and watch the issue tickets there.
$ rpm -qi dracut | grep URL
URL : https://dracut.wiki.kernel.org/
Bug URL : https://bugz.fedoraproject.org/dracut
Edited: the following page is the top page of the dracut RPM package. It may be helpful for you.
https://src.fedoraproject.org/rpms/dracut
What did you do to arrive at this conclusion? Can you unlock the encrypted volume and mount it in the live environment? If you can I would recommend making sure any data you might need to save is backed up before digging any further.
Am I not mounting correctly? Please see below. I have never had this sort of issue before so I am shooting in dark more or less right now.
My suspicion is that somehow the LUKS volume/partition got fried due to a kernel panic or something?
Thank you.
Decrypting LUKS and trying to call it a volume “FED”
liveuser@localhost-live:~4$ sudo cryptsetup luksOpen /dev/nvme0n1p3 FED
Enter passphrase for /dev/nvme0n1p3:
Verifying to see if it has been decrypted…
liveuser@localhost-live:~127$ lsblk --fs
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0
squash 4.0
loop1
ext4 1.0 Anaconda be85788b-98c7-47df-afaf-45dc8fdefb15
├─live-rw
│ ext4 1.0 Anaconda be85788b-98c7-47df-afaf-45dc8fdefb15 1.1G 85% /
└─live-base
ext4 1.0 Anaconda be85788b-98c7-47df-afaf-45dc8fdefb15 1.6G 78% /run/media/liveuser/Anaconda
loop2
DM_sna
└─live-rw
ext4 1.0 Anaconda be85788b-98c7-47df-afaf-45dc8fdefb15 1.1G 85% /
sda iso966 Jolie Fedora-WS-Live-39-1-5 2023-11-01-01-42-46-00
├─sda1
│ iso966 Jolie Fedora-WS-Live-39-1-5 2023-11-01-01-42-46-00 0 100% /run/initramfs/live
├─sda2
│ vfat FAT16 ANACONDA D15C-3620
└─sda3
zram0
[SWAP]
nvme0n1
├─nvme0n1p1
│ vfat FAT32 E6D8-00DE
├─nvme0n1p2
│ ext4 1.0 2f79a188-0f2d-4bc5-bae3-dbcbb7801dbc 553.3M 36% /run/media/liveuser/2f79a188-0f2d-4bc5-bae3-dbcbb7801dbc
└─nvme0n1p3
crypto 2 02cd6065-2b23-4fc8-b34f-021093f5876e
└─FED
Changing fstab to try and mount the FED partition?
FED /dev/nvme0n1p3 ext4 defaults 0 0
Trying to mount…?
liveuser@localhost-live:~$ sudo mount -a
mount: /dev/nvme0n1p3: special device FED does not exist.
dmesg(1) may have more information after failed mount system call.
Thanks for this. Based on my most recent post, I believe the issue might be with my partition/disk, which is why dracut is going haywire.
My meagerly informed hypothesis is a kernel panic or something happened, when I did the hard shut down it messed up the volume/partition. And because of this dracut can’t do its job so I cannot boot because the volume is messed up?
I think I have clearer evidence that there is a filesystem issue with the LUKS partition.
liveuser@localhost-live:~$ sudo cryptsetup -v luksOpen /dev/nvme0n1p3 cryptDrive
No usable token is available.
Enter passphrase for /dev/nvme0n1p3:
Key slot 0 unlocked.
Command successful.
liveuser@localhost-live:~$ sudo mount /dev/mapper/cryptDrive /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/cryptDrive, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
Then, when I do dmesg:
[ 192.468895] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[ 192.469050] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[ 192.469147] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[ 192.472862] ISOFS: Unable to identify CD-ROM format.
[ 192.492152] FAT-fs (dm-2): bogus number of reserved sectors
[ 192.492155] FAT-fs (dm-2): Can't find a valid FAT filesystem
[ 192.498089] hfs: can't find a HFS filesystem on dev dm-2
[ 192.528806] hfsplus: unable to find HFS+ superblock
This is much more informative. Just out of curiosity was this drive pulled from another system, an older Mac perhaps? Also
Why? cryptDrive is not defined anywhere in what you posted. You unlocked the LUKS partition try mounting /dev/mapper/nvme0n1p3 or /dev/nvme0n1p3 instead. If you can unlock it and mount it, this whole issue is likely a grub or intird issue. At that point you can follow these instructions to regenerate your initrd and grub config Working with the GRUB 2 Boot Loader :: Fedora Docs also check the fstab of the actual system if you manage to get it mounted.
You can also check efibootmgr to see if there are odd entires that might be causing an issue.
The SSD is brand new (no prior usage) and it was a fresh install of F39.
I unlocked the LUKS and defined it as cryptDrive.
liveuser@localhost-live:~32$ sudo cryptsetup -v luksOpen /dev/nvme0n1p3 cryptDrive
No usable token is available.
Enter passphrase for /dev/nvme0n1p3:
Key slot 0 unlocked.
Command successful.
liveuser@localhost-live:~$ sudo mount /dev/mapper/cryptDrive /mnt/mydrive
mount: /mnt/mydrive: wrong fs type, bad option, bad superblock on /dev/mapper/cryptDrive, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
Does it seem like my LUKS partition is broken? I am trying to gauge if I need to just reinstall everything or if there is any hope for recovering the partition.
Thank you.
There are a number of rabbit holes you can dive into, in an attempt to save it, but in my experience you would be better off simply reinstalling at this stage. If it happens again there is a very high probability that you are the owner of a defective drive that needs to be replaced. This behavior is usually seen on failing drives, however since nvme drives have a habit of doing so without warning, this is probably the result of the hard power off and some bad luck.
TLDR: Reinstall and configure is probably a quicker way to get back up and running.