Ошибки после обновления на Centos 8 Stream

После обновления Centos 8 Stream, ядро переехало на версию:

# uname -a
Linux srv.local 4.18.0-492.el8.x86_64 #1 SMP Tue May 9 17:56:55 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux</

Так как я ставил из репозитория PowerTools, то модуль у меня собирается через dkms. Выбрал этот способ по причине отсутствия в EPEL kmod-модулей под "свежие" ядра. Так вот перестал собираться модуль dkms-wireguard под новое ядро. В логе наблюдаем следующие ошибки:

/var/lib/dkms/wireguard/1.0.20220627/build/compat/compat.h:412:19: error: redefinition of ‘ktime_get_coarse_boottime_ns’
/var/lib/dkms/wireguard/1.0.20220627/build/queueing.h:85:34: error: ‘struct sk_buff’ has no member named ‘headers_end’; did you mean ‘headers’?

Из-за чего не стартовал WireGuard - сервер, что и понятно, отсутствовал модуль ядра:

Jun 02 09:28:19 srv.local systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Jun 02 09:28:19 srv.local wg-quick[742]: [#] ip link add wg0 type wireguard
Jun 02 09:28:19 srv.local wg-quick[781]: Error: Unknown device type.
Jun 02 09:28:19 srv.local wg-quick[787]: Unable to access interface: Protocol not supported
Jun 02 09:28:19 srv.local wg-quick[742]: [#] ip link delete dev wg0
Jun 02 09:28:19 srv.local wg-quick[806]: Cannot find device "wg0"
Jun 02 09:28:19 srv.local systemd[1]: wg-quick@wg0.service: Main process exited, code=exited, status=1/FAILURE
Jun 02 09:28:19 srv.local systemd[1]: wg-quick@wg0.service: Failed with result 'exit-code'.
Jun 02 09:28:19 srv.local systemd[1]: Failed to start WireGuard via wg-quick(8) for wg0.
[root@git ~]# dnf reinstall wireguard-dkms wireguard-tools

После нескольких часов поиска нашел патчи под исходники wireguard-linux-compat

Выкладываю уже пропатченные файлы (патчи в архиве тоже присутствуют). Распаковываем, заменяем содержимое каталога /var/lib/dkms/wireguard/1.0.20220627/ содержимым архива wireguard-1.0.20220627_patched.tar.gz и собираем модуль ядра заново.

#/usr/lib/dkms/dkms_autoinstaller start
dkms: running auto installation service for kernel 4.18.0-492.el8.x86_64Sign command: /lib/modules/4.18.0-492.el8.x86_64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j4 KERNELRELEASE=4.18.0-492.el8.x86_64 -C /lib/modules/4.18.0-492.el8.x86_64/build M=/var/lib/dkms/wireguard/1.0.20220627/build.....
Signing module /var/lib/dkms/wireguard/1.0.20220627/build/wireguard.ko
Cleaning build area...
wireguard.ko.xz:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.18.0-492.el8.x86_64/extra/
Adding any weak-modules
depmod....
dkms autoinstall on 4.18.0-492.el8.x86_64/x86_64 succeeded for wireguard
 Done.

Всё, можно запускать сервис на новом ядре

На Centos 7 словил ошибку при загрузке:

[  184.074953] dracut-initqueue[376]: Warning: dracut-initqueue timeout - starting timeout scripts
[  186.859431] dracut-initqueue[376]: Warning: dracut-initqueue timeout - starting timeout scripts
[  189.759215] dracut-initqueue[376]: Warning: dracut-initqueue timeout - starting timeout scripts

По итогу загрузка сваливается в аварийный режим.
Анализ ситуации показал что проблема с тем, что по какой-то причине слетел blkid у аппаратного рейда.

Для исправления грузимся с какого-нибудь RescueCD или просто в rescue-режиме.
Смотрим список дисков и UUID к ним

# blkid
/dev/mapper/centos-root: UUID="36caf83d-20ab-4983-b8e6-1ddfe7f2633d" TYPE="xfs"
/dev/md126p3: UUID="FHjjDY-wiFe-BAfw-CcUH-GGkP-28Yo-4oHopp" TYPE="LVM2_member" PARTUUID="fe254018-fbf0-40bb-bbea-2674df0576e9"
/dev/sdb: TYPE="isw_raid_member"
/dev/sda: TYPE="isw_raid_member"
/dev/md126p1: SEC_TYPE="msdos" UUID="DE48-29CA" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="90327271-34e8-487f-b6ae-d6b4f9ea467a"
/dev/md126p2: UUID="d250e0cd-6781-4e4b-bdf6-e325b584a20d" TYPE="xfs" PARTUUID="32ee359f-e0ae-46e8-a2ac-dc63aa8bd8e3"
/dev/mapper/centos-swap: UUID="a423e56a-02f6-43f4-9322-38a0b4fc6193" TYPE="swap"
/dev/mapper/centos-home: UUID="65b4a2e9-b1a8-4ce1-a0c4-419f821dd3a5" TYPE="xfs"
/dev/md126: PTTYPE="gpt"

Монтируем файловую систему:

# mkdir /mnt
# mount /dev/centos/root /mnt
# mount /dev/md126p2 /mnt/boot
# mount /dev/md126p1 /mnt/boot/efi
# mount -o bind /proc /mnt/proc
# mount -o bind /sys /mnt/sys
# mount -o bind /dev /mnt/dev
# mount -t tmpfs run /mnt/run
# chroot /mnt /bin/bash

Смотрим конфиг GRUB:

# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rd.md.uuid=b3d02332:50fc13a7:62834a03:db1a8076 rd.lvm.lv=centos/root rd.md.uuid=5e22aaa6:7b8f5b46:63a6fb19:e13b8ee5 rd.lvm.lv=centos/swap rhgb quiet rootdelay=3"
GRUB_DISABLE_LINUX_UUID="true"
GRUB_DISABLE_RECOVERY="true"

Затем смотрим что у нас в mdadm.conf

# cat /etc/mdadm.conf
ARRAY /dev/md/imsm0 metadata=imsm UUID=5e22aaa6:7b8f5b46:63a6fb19:e13b8ee5
ARRAY /dev/md/Volume0 container=/dev/md/imsm0 member=0 UUID=b3d02332:50fc13a7:62834a03:db1a8076

Тут вроде все совпадает, но так ли это по факту, проверим вывод сканирования.

# mdadm --detail --scan
ARRAY /dev/md/imsm0 metadata=imsm UUID=5e22aaa6:7b8f5b46:63a6fb19:e13b8ee5
ARRAY /dev/md/Volume0 container=/dev/md/imsm0 member=0 UUID=aad02332:50fc13a7:038caa84:7a3b14bc

А вот и отличия. UUID отличается, поэтому берем текущий и прописываем в /etc/default/grub и /etc/mdadm.conf После чего нам необходимо обновить конфиги GRUB

grub2-mkconfig -o /etc/grub2.cfg
grub2-mkconfig -o /etc/grub2-efi.cfg
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

Ну и можно перегружаться