«ВНИМАНИЕ! UUID=xxx не существует. Переход в оболочку!» Где/как я могу изменить это значение xxx? Где оно хранится в конфигурации grub?

Question

У меня есть несколько дисков на моем сервере (для RAID) и несколько загрузочных разделов для тестирования различных дистрибутивов. В какой-то момент у меня был последний (10 buster) Debian 32 бит и последний (10 buster) Debian 64 бит, и по некоторым причинам я решил переместить Debian 64 бит на меньший раздел (с помощью dd, настроив новый UUID и обновив его в /etc/fstab этого раздела), а затем я установил последний (20.1 Ulyssa) Linux Mint Cinnamon на раздел, куда я переместил Debian. Я не ожидал, что это вызовет проблемы, потому что установка Linux Mint запустит update-grub и займет мой новый раздел but для Debian 64, однако в то время мой Debian 64 бит перестал работать. Это означало, что он не может найти корневой раздел.

Есть несколько комментариев по этому поводу: процесс установки Debian довольно хорошо предупреждает меня, что могут быть не-UEFI разделы, которые могут больше не работать, если я попытаюсь установить grub в режиме UEFI (и предлагает запустить в режиме совместимости с BIOS) -) что, похоже, не очень волнует Mint. и поэтому Mint настроил мой grub в режиме UEFI. Однако, странность в том, что он остановил работу моего Debian 64, но не Debian 32.

Я должен признать, что процесс grub никогда не был мне ясен, но я не понимаю, что попытка переустановить и обновить grub из моего Debian 32 не решила проблему, и попытка найти файл с неисправным UUID в /etc и /boot (включая подкаталоги) на обоих разделах (Debian 32 и 64). В конце концов я решил проблему, отредактировав командную строку grub моего Debian 64 при загрузке, а затем переустановив и обновив grub из моего Debian 64.

Однако мне действительно хотелось бы понять, где хранился этот UUID (почему я не смог его найти), и почему я не смог решить эту проблему из своего раздела Debian 32.

EDIT: Чтобы прояснить ситуацию: мне удалось загрузиться, заменив root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx на root=/dev/sdxx, отредактировав параметры ядра из меню grub во время загрузки, и initrd НЕ был изменен в последующем процессе восстановления grub. Однако я не смог найти это значение UUID (ни xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, ни xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) ни в одном несжатом файле в /etc и /boot.

EDIT2: Хорошо... То, что я искал, было в /boot/grub/grub.cfg (спасибо Archemar), но я не нашел этого, потому что я накосячил с регулярным выражением при поиске в

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-?751e-?48b5-?b85e-?df60d20b5d3e' 

Регулярные выражения grep не распознают ?. Мне следовало использовать {0,1} вместо этого... :'(

find /boot /etc -type f -print0 | 
    xargs -0 grep -li 'a9c85b02-\{0,1\}751e-\{0,1\}48b5-\{0,1\}b85e-\{0,1\}df60d20b5d3e' 

Однако это не объясняет, почему это не сработало, когда я переустановил и перенастроил grub из раздела Debian 32. Может ли распознавание других разделов Linux быть основано на анализе этих /boot/grub/grub.cfgразделов??? :-o

Answer 1

Я столкнулся с похожей проблемой в VMware, переместив загрузочный и системный диск с диска 800 ГБ на 16 ГБ, простого копирования раздела и файла (с диска 800 ГБ на 16 ГБ) и удаления диска 800 ГБ было бы недостаточно (ядро загружается нормально, но не удается найти /UUID). (и, к сожалению, в этом случае снимок VMware не оказался полезным в качестве защиты от отката)

• точки монтирования есть, /etc/fstabно есть2 fstab
• равнина fstabнаходится в/etc
• secret /etc/fstabнаходится в initrd.gz(или подобном) /bootразделе загрузочного диска, этот fstab содержит UUID, указывающий на /(корневую файловую систему) ОС.

Либо выполните переустановку initrd, если вы загрузились с этой ОС.

Или, если вы загрузились с другой ОС, initrd.gzэто сжатый gzip cpio, «просто» извлеките fstabфайл, отредактируйте его и поместите обратно в initrd.gz.