New Kernel update and not able to mount encrypted fs

Efka · 2019-12-05 11:20:06

Hey guys, im not sure im writing into the right section of this forum but my last update last night broke my system.
I have nvme lvm luks and encrypted boot.
Update changed modules from "ext4" to "i915" and something else ...dont know what was changed as fstab was ok, mkinitcpio was fine but when im starting my pc i know right away that system broke as encryption took ages to proceed ( usually within few secs) After accepting my encryption i was prompted to boot from arch and then fun began - could not find my /new root and dropped into emergency shell. So I ran arch-chroot, all was fine apart MODULES "i915" instead of "ext4" . I was thinking i need to check mkinitcpio.conf file and all was fine apart added one more hook ( for suspend/hibernate ) i think, mkinitcpio -p linux prompted no errors but when i tried to boot again - same issue /dev/mapper/edi-root was not able to be mounted on /new_root ( i believe im stating it right )
I had to fall back to my 5.3.10 kernel to boot it back to my system.
Does anyone have the same issues? If yes - how did you managed to fix it ?
I can live with older kernel its not a biggy but im worried about next pacman -Syu as when i did last time it updated my nvidia drivers so i had to downgrade not only kernel but nvidia crap all together ( as nvidia drivers are somehow tied up with kernel ) otherwise im not able to log into X server.
P.s. big thanks for Arch Linux Archives - without them, i would be lost.

V1del · 2019-12-05 11:56:03

Just sounds like your proper /boot partition wasn't mounted while actually doing the kernel update. If most modules "magically" fail to load that usually means you did upgrade, but the mkinitcpio hook didn't generate the new kernels initramfs in the correct location (most common on UEFI systems where one will most likely want to have the ESP mounted to /boot during the update) when rebooting you actually booted into the old kernel, but that old kernels modules are not present anymore.

Make sure that this is correctly set up, in doubt mount all partitions like you think they should be, then post in [ code ] [ /code ] tags

mount
file /boot/vmlinuz-linux

and your boot loader config and maybe mkinitcpio.conf as well.

Last edited by V1del (2019-12-05 12:14:58)

Efka · 2019-12-05 12:07:16

V1del wrote:

Just sounds like your proper /boot partition wasn't mounted while actually doing the kernel update. If most modules "magically" fail to load that usually means you did upgrade, but the mkinitcpio hook didn't generate the new kernels initramfs in the correct location (most common on UEFI systems where one will most likely want to have the ESP mounted to /boot during the update) when rebooting you actually booted into the old kernel, but that old kernels modules are not present anymore.
Make sure that this is correctly set up, in doubt mount all partitions like you think they should be, then post in [ code ] [ /code ] tags
mount
file /boot/vmlinuz-linux
and your boot loader config.

Thanks for a quick reply, I'm already downgraded to 5.3 Kernel, but I did update on the Live system ... so hows that possible? I do updates like this all the time
I will try to update to the newer kernel but only over the weekend as i have to do some work .

P.s. what you mean by stating ESP ? Encrypted system partition?

V1del · 2019-12-05 12:13:54

EFI System partition is what I usually mean with that, but in your case it would probably be interchangeable

Efka · 2019-12-05 12:24:59

V1del wrote:

EFI System partition is what I usually mean with that, but in your case, it would probably be interchangeable

Understood.
Thanks. So I will wait for my weekend and gonna try to update and inform with the outcome.

gilium · 2019-12-07 01:17:55

I'm experiencing this same issue, using LVM with a volume for / and a volume for /home. I have lts installed as a fallback, so booting to that has made it so I can downgrade to 5.3.13 (last working kernel).

I have no sort of encryption, so it seems it's nothing to do with that portion of it, but rather a problem with LVM and the new kernel

Edit: coming back to add some more detail.

So the kernel update that broke my system is 5.4.1, and 5.4.2 also was broken when I updated to that one.

In emergency shell, I could see that mapper had not mapped my volumes to `/dev/mapper` and I couldn't find them in `/dev/disk/by-uuid` either.

Last edited by gilium (2019-12-07 11:59:57)

gilium · 2019-12-10 15:42:10

Updating in a new reply rather than an edit. I too am running an nvme drive. It appears kernel 5.4 introduced a regression that broke compatibility with Silicon Motion 2263 controllers, which is what mine is.

http://lists.infradead.org/pipermail/li … 28243.html

This is a patch you can apply to fix it if your nvme drive is one of the effected ones.

Efka · 2020-02-16 17:55:43

I have no idea how to do it ( never ever done this before )... nor idea how to get Controller info of my nvme ...trying nvme-cli

A bit of an update:
Phoenix controller on my Samsung 970 evo nvme.

Last edited by Efka (2020-02-16 18:08:45)

Arch Linux

#1 2019-12-05 11:20:06

New Kernel update and not able to mount encrypted fs

#2 2019-12-05 11:56:03

Re: New Kernel update and not able to mount encrypted fs

#3 2019-12-05 12:07:16

Re: New Kernel update and not able to mount encrypted fs

#4 2019-12-05 12:13:54

Re: New Kernel update and not able to mount encrypted fs

#5 2019-12-05 12:24:59

Re: New Kernel update and not able to mount encrypted fs

#6 2019-12-07 01:17:55

Re: New Kernel update and not able to mount encrypted fs

#7 2019-12-10 15:42:10

Re: New Kernel update and not able to mount encrypted fs

#8 2020-02-16 17:55:43

Re: New Kernel update and not able to mount encrypted fs

Board footer