[Решено] Отвал namespace NVMe диска после обновления ядра

Доброго дня!

Установлен Arch на NVMe диск, несколько партиций с нумерацией /dev/nvme0n1pX, загрузка через GRUB.

Столкнулся с такой проблемой - после обновления ядра с 5.7.6 на любое более новое выбрасывает ненахождение раздела:
Error: device 'UUID=xxx' not found
mount: /new_root: can't find UUID=xxx.
c консолью rootfs.

при этом blkid в rootfs не показывает ни один раздел с нужного диска (Если, например, есть флешка - её видит).

Не помогает: загрузка fallback образа, пересборка образов и обновление конфига grub'a, загрузка через путь до раздела вместо UUID.
Помогает: откат linux и linux-headers до версии 5.7.6 из кэша.
Ситуация одинаковая с любой версией до 5.7.10 включительно.
Надеюсь на совет.
Есть такое - посмотри топик на BBS - nvme not detected - в подробности не лез ...
PS - следи за ситуацией - исправят.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Есть такое - посмотри топик на BBS - nvme not detected - в подробности не лез …
PS - следи за ситуацией - исправят.

Очень похоже на моё, спасибо, слежу.
Kanogwaith
Установлен Arch на NVMe диск, несколько партиций с нумерацией /dev/nvme0n1pX, загрузка через GRUB.
Также использую NVME диск :
Обновился до Kernel: 5.7.10-arch1-1 - никаких проблем с загрузкой. И до этого с обновлениями проблем не было.
Загрузка через systemd-boot. До этого (года 2 назад) использовал GRUB - так же проблем не было.
Где-то читал что проблема с нумерацией /dev/nvmeXXXXX, после того как производители придумали nvme multipath. Типа в ядро за пару лет ещё не завезли номального исправления. Видел что у одних владельцев никаких проблем, а у других труба совсем неразрешимая.
Kanogwaith
Error: device 'UUID=xxx' not found
mount: /new_root: can't find UUID=xxx.
такие сообщения, конечно, не обязательно обусловлены проблемой NVMe ... но судя по описанному, проблема связана с ядром ... и если исключить проблемы, связанные с systemd, с генерацией образа ядра и др., то скорее всего это связано с NVMe ....
С большой вероятностью должно выкидывать в emergency shell - и если так, то можно кое-что и посмотреть.
Кроме того, можно прописать параметры rd.debug rd.log=all и после попадания в emergency shell посмотреть лог initramfs или в консоле, но удобнее из файла
less /run/initramfs/init.log
Нормальный лог имеет примерно такой вид (скопировал из /run/... в /home/...)
cat ~/TTT/TEMP/init.log
+ unset quiet
+ . /config
+ EARLYHOOKS=udev
+ HOOKS=udev
+ LATEHOOKS=
+ CLEANUPHOOKS=udev
+ run_hookfunctions run_earlyhook 'early hook' udev
+ local hook 'fn=run_earlyhook' 'desc=early hook'
+ shift 2
+ '[' -x /hooks/udev ]
+ unset run_earlyhook
+ . /hooks/udev
+ type run_earlyhook
+ msg ':: running early hook [udev]'
+ '['  '!=' y ]
+ echo :: running early hook '[udev]'
:: running early hook [udev]
+ run_earlyhook
+ kmod static-nodes '--format=tmpfiles' '--output=/run/tmpfiles.d/kmod.conf'
+ systemd-tmpfiles '--prefix=/dev' --create --boot
+ /usr/lib/systemd/systemd-udevd --daemon '--resolve-names=never'
+ udevd_running=1
+ '[' -n  ]
+ run_hookfunctions run_hook hook udev
+ local hook 'fn=run_hook' 'desc=hook'
+ shift 2
+ '[' -x /hooks/udev ]
+ unset run_hook
+ . /hooks/udev
+ type run_hook
+ msg ':: running hook [udev]'
+ '['  '!=' y ]
+ echo :: running hook '[udev]'
:: running hook [udev]
+ run_hook
+ msg ':: Triggering uevents...'
+ '['  '!=' y ]
+ echo :: Triggering uevents...
:: Triggering uevents...
+ udevadm trigger '--action=add' '--type=subsystems'
+ udevadm trigger '--action=add' '--type=devices'
+ udevadm settle
+ '['  '=' y ]
+ '['  '=' premount ]
+ resolve_device /dev/sda3
+ local major minor dev tag 'device=/dev/sda3'
+ '[' -n  ]
+ poll_device /dev/sda3
+ local 'device=/dev/sda3' 'seconds='
+ '[' x '=' x ]
+ seconds=10
+ deciseconds=100
+ sleepinterval=1
+ '[' -b /dev/sda3 ]
+ return 0
+ echo /dev/sda3
+ return 0
+ rootdev=/dev/sda3
+ root=/dev/sda3
+ unset rootdev
+ fsck_root
+ fsck_device /dev/sda3
+ '[' -x /sbin/fsck ]
+ '[' '!' -b /dev/sda3 ]
+ '[' -n  ]
+ msg ':: performing fsck on '"'"'/dev/sda3'"'"
+ '['  '!=' y ]
+ echo :: performing fsck on ''"'"'/dev/sda3'"'"
:: performing fsck on '/dev/sda3'
+ fsck -Ta -C /dev/sda3 --
ArchLinux: clean, 440542/4612096 files, 7541418/18422538 blocks
+ fsckret=0
+ '[' -n 0 ]
+ '[' 0 -ne 255 ]
+ bitfield_has_bit 0 4
+ '[' 0 -eq 4 ]
+ bitfield_has_bit 0 2
+ '[' 0 -eq 2 ]
+ bitfield_has_bit 0 8
+ '[' 0 -eq 8 ]
+ bitfield_has_bit 0 16
+ '[' 0 -eq 16 ]
+ bitfield_has_bit 0 32
+ '[' 0 -eq 32 ]
+ bitfield_has_bit 0 128
+ '[' 0 -eq 128 ]
+ '[' rw '!=' rw ]
+ default_mount_handler /new_root
+ msg ':: mounting '"'"'/dev/sda3'"'"' on real root'
+ '['  '!=' y ]
+ echo :: mounting ''"'"'/dev/sda3'"'" on real root
:: mounting '/dev/sda3' on real root
+ mount -o rw /dev/sda3 /new_root
+ run_hookfunctions run_latehook 'late hook'
+ local hook 'fn=run_latehook' 'desc=late hook'
+ shift 2
+ run_hookfunctions run_cleanuphook 'cleanup hook' udev
+ local hook 'fn=run_cleanuphook' 'desc=cleanup hook'
+ shift 2
+ '[' -x /hooks/udev ]
+ unset run_cleanuphook
+ . /hooks/udev
+ type run_cleanuphook
+ msg ':: running cleanup hook [udev]'
+ '['  '!=' y ]
+ echo :: running cleanup hook '[udev]'
:: running cleanup hook [udev]
+ run_cleanuphook
+ udevadm control --exit
+ udevadm info --cleanup-db
+ stat -c '%D' /
+ stat -c '%D' /new_root
+ '[' 2 '=' 803 ]
+ '[' '!' -x /new_root/sbin/init ]
+ '['  '=' postmount ]
+ rdlogger_stop
+ local 'i=0' pid
+ '[' -e /run/initramfs/rdlogger.pipe ]
+ '[' -n y ]
Можно грубо оцениться где затык ... конечно, не факт, что будет все понятно, но обычно информация собирается по крупицам ...

PS - в этом логе есть две хорошие реперные точки, которые помогут определить примерное место затыка - premount и postmount

EDIT 1 - не заметил эту фразу
Kanogwaith
при этом blkid в rootfs не показывает ни один раздел с нужного диска (Если, например, есть флешка - её видит).
и все-таки похоже, что причина в NVMe
Ошибки не исчезают с опытом - они просто умнеют
https://yadi.sk/a/SuieYBEudRKcFg

Очень извиняюсь, что фотографиями - поскольку диск не монтируется, скопировать некуда.
Информативного, на мой взгляд, тут маловато - куча попыток подключить то, чего не видится, да и всё.
Загрузится с установочного диска arch и проверить что покажет ?? :
lsblk
Загрузочная флешка у меня с версией ядра 5.7.6, там всё в порядке - это и есть мой способ откатить ядро.
Вместо grub не пробовали использовать systemd-boot ?
 
Зарегистрироваться или войдите чтобы оставить сообщение.