LINUX.ORG.RU
решено ФорумAdmin

Debian 12 загружается в emergency mode или initramfs

 , , , ,


1

1

Здравствуйте

Проблема такая: изначально на моем nvme была установлена винда и debian 12, которым я пользовался постоянно.

Захотел я заменить винду на Nix-OS, в установщике удалил ВСЕ разделы кроме основного debian, nix не установился, выдал лог ошибки, с грустью нажимаю reboot.

После перезагрузки uefi мне сообщает такую новость: «no boot device», grub больше нету, принял решение восстановить grub через установку ещё одного debian12 на диск, все сработало, grub появился, нашел новую систему (nvme0n1p1) и мою старую (nvme0n1p5)

Загружаюсь в nvme0n1p5 - попадаю в emergency mode

загрузился в nvme0n1p1, создал efi раздел с флагом boot(nvme0n1p2), в /mnt вмонтировал /dev/nvme0n1p5, /dev, /proc, /sys. Зашел в chroot, и начал делать следующее:

roman@bmhwdx9:~$ sudo mount /dev/nvme0n1p5 /mnt
roman@bmhwdx9:~$ sudo mount --bind /dev /mnt/dev;sudo mount --bind /proc /mnt/proc;sudo mount --bind /sys /mnt/sys
roman@bmhwdx9:~$ lsblk -o NAME,UUID,SIZE
NAME        UUID                                   SIZE
nvme0n1                                          476,9G
├─nvme0n1p1 9a698793-2ce3-435b-9f7e-763d9d7f7a0b 124,5G   # свежеустановленный debian12
├─nvme0n1p2 9973-C7CF                              512M   # efi раздел который сделал через gdisk
└─nvme0n1p5 03e73689-43c5-4898-9b9b-a852881e623a 351,9G   # именно этот раздел с основной системой
roman@bmhwdx9:~$ sudo chroot /mnt
[sudo] пароль для roman: 
root@bmhwdx9:/# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=B42E-7563                            /boot/efi      vfat    defaults,noatime 0 2
UUID=03e73689-43c5-4898-9b9b-a852881e623a /              ext4    defaults,noatime,discard 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
root@bmhwdx9:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-35-amd64
Found initrd image: /boot/initrd.img-6.1.0-35-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Debian GNU/Linux 12 (bookworm) on /dev/nvme0n1p1
done
root@bmhwdx9:/# update-initramfs -c -k $(uname -r)
update-initramfs: Generating /boot/initrd.img-6.1.0-35-amd64
W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_11_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_11_toc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_10_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_10_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_cap.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_imu.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_0_toc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sdma_6_0_3.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_mes1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_mes_2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_4_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes_2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_3_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_2_mes_2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_1_mes_2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/gc_11_0_0_mes_2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/smu_13_0_10.bin for module amdgpu
root@bmhwdx9:/# fsck /dev/nvme0n1p5
fsck из util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p5 is mounted.
e2fsck: Cannot continue, aborting.


root@bmhwdx9:/# exit
exit

roman@bmhwdx9:~$ sudo umount /mnt/dev /mnt/proc /mnt/sys /mnt
roman@bmhwdx9:~$ sudo fsck /dev/nvme0n1p5
fsck из util-linux 2.38.1
e2fsck 1.47.0 (5-Feb-2023)
/dev/nvme0n1p5: clean, 617453/23068672 files, 41808719/92258897 blocks 

После всего этого система загружается в BusyBox и initramfs. Если в записи grub поменял с root=uuid=… на root=/dev/nvme0n1p5 илл на UUId этого раздела, тогда systemd пишет depend и система загружается в emergency mode

Честно, я уже не знаю что возможно сделать чтоб восстановить загрузку системы, может быть что-то делаю не так, может кто-то знает где была допущена ошибка. других способов восстановления системы я не нашел.

Перемещено hobbit из general



Последнее исправление: FlatOunce (всего исправлений: 2)

Пока ещё не дочитал, что ты наколобродил. Но уже чувствуется, дров наломал.

UUID=B42E-7563 /boot/efi vfat defaults,noatime 0 2

Нет этого раздела, поэтому система не загружается. То есть, когда удалял винду, ты удалил слишком много.

andytux ★★★★★
()
Ответ на: комментарий от FlatOunce

Просто отредактируй fstab в старой системе. На будущее просто запомни, что надо при таких манипуляциях следить за UUID в fstab и параметрах ядра (root=), избавит от лишних шагов по восстановлению.

anonymous
()
Ответ на: комментарий от FlatOunce

Закомментируй эту строку. Монтирование ЕФИ-раздела для работы системы не нужно, оно нужно только для обновления загрузчика. В данном случае, у тебя загрузчик от другой системы, она его и будет обновлять. Так что, здесь монтирование ЕФИ-раздела может оказаться даже вредным.

andytux ★★★★★
()
Ответ на: комментарий от andytux

да, это действительно сейчас помогло,

сначала указал efi 9973-C7CF раздел, система жива и полностью исправна.

после загрузки закомментировал и все тоже заработало

осталось в grub заменить root=uuid=… на root=/dev/nvme0n1p5 и проблема полностью решена

это оказалось так легко решить, спасибо вам за ваш опыт, andytux и аноним

FlatOunce
() автор топика
Ответ на: комментарий от FlatOunce

осталось в grub заменить root=uuid=

Команда update-grub из загруженной системы это должна сделать. Если не сделает, то 100% остались какие-то проблемы. /boot/efi должен быть смонтирован, разумеется.

anonymous
()
Ответ на: комментарий от mx__

Зависит от данного конкретного УЕФИ. Мне попадался только один УЕФИ, которому требовался флаг ‘boot’. В данный момент, ни на одном из дисков у меня нет флага ‘boot’.

andytux ★★★★★
()
Ответ на: комментарий от mx__

Сначала он установил систему на раздел p5, с загрузчиком. Потом установил систему на раздел p1, со своим загрузчиком. В каждой системе свой конфиг груба, который обновляется только своим update-grub. В принципе, в зависимости от данного конкретного УЕФИ, в нём может остаться загрузочная запись от первого загрузчика. А так-как системы одинаковые, то загрузочные записи будут одноимённые, ещё одно место для путаницы.

andytux ★★★★★
()
Ответ на: комментарий от andytux

А можно увидеть как это выглядит? Вот у меня (правда у меня один дистр) но выглядит это так:

# pwd
/boot/efi

# ls ./*/*/*.EFI -1
./EFI/BOOT/BOOTX64.EFI

#  ls ./*/*/*.efi -1
./EFI/BOOT/fbx64.efi
./EFI/rocky/grubx64.efi
./EFI/rocky/mmx64.efi
./EFI/rocky/shim.efi
./EFI/rocky/shimx64.efi
./EFI/rocky/shimx64-rocky.efi

Иными словами грузится: BOOTX64.EFI и он подгружает grub2: grubx64.efi

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Выглядит практически также, только вместо rocky, ubuntu. Для полноты картины, покажи вывод efibootmgr. А я погадаю над тем, что есть.

/EFI/BOOT/BOOTX64.EFI

Загрузчик по умолчанию. Обычно, его место занимает тот, который установила последняя система. Посмотри по размеру, вполне возможно это копия shimx64.efi.

В каталоге rocky загрузчики, которые установила эта система. Далее, не знаю, как в rocky, буду писать про Убунту.

grubx64.efi - загрузчик грубЕФИ. В этом-же каталоге его конфиг - grub.cfg, в котором всего три строки, указывают, где ему искать остальные модули и основной конфиг. Работвет только при выключенном ‘secure boot’.

shimx64.efi - подписанный загрузчик, работает и с включенным и с выключенным ‘secure boot’. По умолчанию, загрузочная запись в УЕФИ указывает на него. Он уже запускает grubx64.efi.

andytux ★★★★★
()
Ответ на: комментарий от andytux

Да одинаков. Так стоп, что показывает efibootmgr? Не в смысле какую инфу (это понятно) откуда эта инфа берется? В доках что то ни как пойму :(

efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0003,0001,0002,0004
Boot0000* Rocky Linux	HD(1,GPT,f775a141-48d0-4541-bde7-5a40a1b48c53,0x800,0x12c000)/File(\EFI\ROCKY\SHIMX64.EFI)
Boot0001* UEFI:CD/DVD Drive	BBS(129,,0x0)
Boot0002* UEFI:Removable Device	BBS(130,,0x0)
Boot0003* UEFI OS	HD(1,GPT,f775a141-48d0-4541-bde7-5a40a1b48c53,0x800,0x12c000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0004* UEFI:Network Device	BBS(131,,0x0)
mx__ ★★★★★
()
Ответ на: комментарий от mx__

Берётся из /sys/firmware/efi. По наличию этого каталога, можно определить, что система загружена в ЕФИ-режиме. fw_platform_size содержит разрядность УЕФИ. В подкаталоге efivars другие переменные, в том числе и загрузочные записи, которые показывает efibootmgr.

Твой rocky создал две загрузочные записи:

Boot0000* Rocky Linux… - запускает SHIMX64.EFI. Видно, с какого раздела и с какого каталога будет взят загрузчик.

Boot0003* UEFI OS - запускает загрузчик по умолчанию.

В данном случае, система загружена записью ‘0000’: «BootCurrent: 0000». Если по какой-то причине эта запись неисправна, то будет использована следующая по очереди: «BootOrder: 0000,0003,0001,0002,0004». А следующая запускает загрузчик по умолчанию.

Timeout: 1 seconds - таймаут, когда нужно нажать клавишу, чтобы попасть в УЕФИ. Я обычно ставлю 2 секунды, значительно легче поймать.

andytux ★★★★★
()
Ответ на: комментарий от andytux

Берётся из /sys/firmware/efi.

Я тут в другой ветке что то бормотал по этому поводу, чел. написано что он это пишет в сам UEFI, не верится но допустимо.

Ваш вариант вообще не катит ни как. Он про диск (окромя ESP) раздела не в курсе !

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Да, я немного забыл дополнить.

Реально физически всё находится в микросхеме nvram (сам УЕФИ и его переменные). Оттуда они считываются в псевдофайловую систему sysfs. Из неё получают все остальные.

andytux ★★★★★
()
Ответ на: комментарий от andytux

А разве это секурно? Вы как минимум можете узнать по УЕФИ, у компа у которого вынули и пропили давно его хдд, что за ось там стояла и т.д. …

Получается с другой стороны windows самая секурная, там нет вообще ни какой указивки и грузится стандартный загрузщик.

Оттуда они считываются в псевдофайловую систему sysfs. Из неё получают все остальные.

Опять как то путанно :(

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

Всё просто. Всё есть файл.

Из батареи всё в /sys/class/power_supply/*.

Из УЕФИ всё в /sys/firmware/efi/*.

Секретно-ли? Так задумали гиганты мысли: интел, микрософт и т.д.

Никаким стандартным загрузчиком виндовс не грузится, у неё свой загрузчик. Собственно, с чего и началась тема, как запустить виндовс-загрузчик. Хотя, некоторые УЕФИ воссоздают загрузоную запись винды, даже если вообще винды нет.

что за ось там стояла…

Обзови загрузочную запись «ёклмн». Вот не знаю, удастся-ли сделать это в случае с виндой?..

Вот строка из моего УЕФИ: «Boot0000* grub HD(1,MBR,0x66247b3,0x800,0x219800)/File(\EFI\BOOT\GRUBX64.EFI)/dev/sda1». Какая это ОС?..

andytux ★★★★★
()
Последнее исправление: andytux (всего исправлений: 1)
Ответ на: комментарий от andytux

И вообще, вот вы подсказали что SHIMX64.EFI это одно и тоже что и BOOTX64.EFI, я выше писал что так оно и есть.

И какой смысл тогда грузить этот SHIMX64.EFI по левому пути? Не все таки что то тут не то.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Так именно это позволяет иметь несколько загрузчиков.

В случае БИОС, загрузчик может быть только один. В случае УЕФИ, его аналог - загрузчик по умолчанию. Смысл? Хотя-бы как запасной вариант.

andytux ★★★★★
()
Ответ на: комментарий от andytux

По некоторым инфам пишут, в uefi загрузчики могут грузить другие загрузчики. Т.е. мои якобы разные строки (на самом деле)грузят grub2 и там уже выбор …

Вопрос: у вас включен cms?

mx__ ★★★★★
()
Ответ на: комментарий от mx__

«Еврейский ответ»: где?

В соседней теме даже конкретно тебе говорил, об удивившей тебя msdos-разметке.

У меня несколько устройств. Два десктопа - чистый БИОС, никаких cms впринципе ещё не знают.

Два современных, только ЕФИ-режим, cms уже не знают.

в uefi загрузчики могут грузить другие загрузчики…

Самый яркий пример, дуалбут с виндой. УЕФИ запускает грубЕФИ, грубЕФИ запускает bootmgfw.efi (виндовый загрузчик). Но и такой пример, как-бы без загрузчиков. Ядро линукс построено так, что в нём есть ЕФИ-загрузчик. Поэтому, УЕФИ может запустить его без посредников в виде груба или рефинда.

Вы ко мне на «Вы». Не обижайтесь, если я к вам на «ты», я вполне уважительно.

Сравнеие строк моей и твоей. У меня загрузчик не там, где «загрузчики систем». Действительно, он «вне системы». Никакая система о нём не знает, не будет его обновлять, не будет обновлять его конфиг, а значит не испортит. Но если я что испорчу в неё, то всегда есть «системный загрузчик».

andytux ★★★★★
()
Последнее исправление: andytux (всего исправлений: 1)