Can not boot with latest kernel (kernel-3.10.0-1062.7.1.el7.x86_64)

Support
1

NethServer Version: 7.7.1908 (final)

After automated upgrade to kernel-3.10.0-1062.7.1.el7.x86_64 my system hangs during boot. Maybe it is important to mention that this is a fully crypted installation. After entering encryption key the boot process starts, but ending here:

grafik
grafik.png853×785 188 KB

I still can boot choosing an older kernel (e.g. 3.10.0-957.27.2.el7.x86_64)!
All updates are in place, only latest kernel not usable.

I already deleted latest kernel manually (yum remove kernel-3.10.0-1062.7.1.el7.x86_64) and tried yum update again, but some issue.

Based on the kernels already installed on this server it was not the first kernel update.
I have no idea how to fix this issue…

2

Any clue from systemctl status sysroot.mount or /run/initramfs/rdsosreport.txt?

3

I found this during the failed boot in rdsosreport.txt:

grafik
grafik.png1057×553 52.1 KB

and systemctl status sysroot.mount shows this:
grafik
grafik.png1033×316 88.3 KB

4

Can you boot with other kernel? If yes I suggest you to reinstall it As here:

5

I did already (see my first post), but same effect!

6

…there’s a mount that times out after 90s (at least) and a dm_crypt queue. :thinking:

Failed to mount /sysroot.

Dependency failed for Initrd Root File System.
Dependency failed for Reload Configuration from the Real Root.

Entering emergency mode.

XFS (dm-1): Mounting V5 Filesystem
sysroot.mount mounting timed out.
Workqueue: kcryptd kcrytd_crypt [dm_crypt]

/bin/mount /dev/mapper/luks-831053f2-b4ab-42db-84a0-6748747ce226 /sysroot -o ro

If a XFS filesystem issue could be suspected, it is strange no error is shown and it works fine with another kernel. In the past we had a case of wrong fstab options triggering mount errors on kernel update, but it is a blind shot. Maybe journalctl -xe (huge log) and fstab content can provide additional clues.

7

VMWare Player, XFS filesystem, no encryption on FS. Kernel boot up without issues.

8

yes on other machines no problem, too. This is my only real HW (supermicro) and encrypted

9

today there was a minor kernel update, but still the same problem. This is output of jounalctl -xe

grafik
grafik.png1042×785 341 KB

and fstab

[root@mail1 etc]# cat fstab

#
# /etc/fstab
# Created by anaconda on Sun Mar 24 17:31:20 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/luks-831053f2-b4ab-42db-84a0-6748747ce226 /                       xfs     defaults,x-systemd.device-timeout=0 0 0
UUID=980b6a61-7bd7-44ce-8584-bc3af59cc6d6 /boot                   xfs     defaults        0 0
UUID=2BA6-7AB1          /boot/efi               vfat    umask=0077,shortname=winnt 0 0
/dev/mapper/luks-3c58166b-f97d-4a64-9a7b-e72558b995b1 swap                    swap    defaults,x-systemd.device-timeout=0 0 0
10

kernel 3.10.0-1062.9.1 has been released.

11

@asl any news?

12

I tested the latest kernel, but same problem. Maybe I have to wait for future kernels?

13

ATP it seems more an issue between kernel and luks…