Параметр ядра «recovery»

Безопасный режим как в винде. Доступно несколько утилит для исправления некоторых ошибок.

как в винде

Спорное заявление.

уже посмотрел - загружается какое-то recovery-menu
только откуда? из initrd?
upd: нашел /lib/recovery-mode/recovery-menu

А я и не собирался утверждать :) Заявление о том что кузнечик совсем как огуречик тоже спорно , но как вариант существует :)

кузнечик совсем как огуречик

А я круче могу:

systemd == offtop => true

Вы намекаете что всё-таки виноват Лёня?

Вы намекаете что всё-таки виноват Лёня?

Честно, не в курсах. Но утверждение...

systemd == offtop => true

false => true всегда истинно есличо

Поскажите как обрабатывается параметр recovery.

Не совсем в тему. Сам не пользую всякие новомодные плюхи. На отдельном разделе (lvm) держу SystemRescueCD. Недавно здесь (на ЛОРе) таким же макаром устанавливали clonezilla. (ИМХО) Это гораздо удобнее сомнительных режимов.

линукс.ядро не знает ровным счетом ничего о параметре recovery, соответственно оно его игнорирует.

далее ядро запускает скрипт /init из инитрамдиска, где парсят строчку запуска ядра через /proc/cmdline и чего-то ковыряют в системе потом запускают основной /sbin/init с корневого раздела. вот где-то там и должон ответвлятся режим recovery.

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

да ясно Лёня уже и рековерит

чегойто влезть в свой инитрам не смох

блин тоже час уже не могу initrd.img убунтовский распаковать

распаковывается оно через спец.команду

unmkinitramfs /boot/initrd.img-4.18.0-16-generic ~/куда/надо/

и такое чувство собирается както через жопу

поцаны помогайте, извлекается только дир. kernel почему-то

$ ls
initrd.img-4.18.0-16-generic
$ file initrd.img-4.18.0-16-generic
initrd.img-4.18.0-16-generic: ASCII cpio archive (SVR4 with no CRC)
$ cpio -i -d -H newc < initrd.img-4.18.0-16-generic
56 блоков
$ ls
initrd.img-4.18.0-16-generic  kernel
$ 

распаковывается оно через спец.команду unmkinitramfs

о спасибо, запарился, незаметил

перезагрузился в френдли-рековери - сделано через возможности системд :) прекольно.

и даже не Леня сие творил. хотя коряво в плане резюма, но прекольно.

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

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

даже не Леня сие творил

ниче, еще не вечер, Лёня еще молод и задорен!

посоветуйте хорошую сборку рескуе_сд для линухи

SystemRescueCd

знаю, но опять же нет lshw, удобна сия утилита...

нет lshw

Это странно. Показания разнятся:

Detailed packages list

Да и я помню, что именно lshw пользовал в ней после startx.

значит потеряли :)

смотрю внутри образа squashfs ни в usr/bin ни в usr/share/man/man1/ нет намека на lshw

загружусь в него - проверю - отпишусь авторам.

значит потеряли

Так я пользую предыдущие версии - те что на Gentoo (<= 5.3.2). А не те, что на Arch-е (>= 6.0.0).

ок. качаю :)

нашел свою же редакцию в википедии про переход на арч... значит ковырял

в арче lshw тоже есть - так что думаю надо описаться авторам.

в арче lshw тоже есть

Не знаю, не знаю. Мне обычно своих проблем хватает, зачем мне ещё и чужие. Я про arch.

распаковывается оно через спец.команду unmkinitramfs

А что, lsinitrd(1) в Убунте нету?

А что, lsinitrd(1) в Убунте нету?

есть, но он не распаковывает правильно, видимо что-то добавили новое в ядро насчёт упаковки initrd

В unmkinitramfs какой-то ахтунг.
Напишите что щас к чему пожалуйста если кто в курсе.

есть, но он не распаковывает правильно

В чем это выражается?

pushd $(mktemp -d) && su -c 'lsinitrd --unpack --unpackearly' && ls -l в Федоре выдало

total 4
lrwxrwxrwx  1 root root    7 мар 23 18:05 bin -> usr/bin
drwxr-xr-x  2 root root  140 мар 23 18:05 dev
drwxr-xr-x 11 root root  540 мар 23 18:05 etc
lrwxrwxrwx  1 root root   23 мар 23 18:05 init -> usr/lib/systemd/systemd
lrwxrwxrwx  1 root root    7 мар 23 18:05 lib -> usr/lib
lrwxrwxrwx  1 root root    9 мар 23 18:05 lib64 -> usr/lib64
drwxr-xr-x  2 root root   40 мар 23 18:05 proc
drwxr-xr-x  2 root root   40 мар 23 18:05 root
drwxr-xr-x  2 root root   40 мар 23 18:05 run
lrwxrwxrwx  1 root root    8 мар 23 18:05 sbin -> usr/sbin
-rwxr-xr-x  1 root root 3121 мар 23 18:05 shutdown
drwxr-xr-x  2 root root   40 мар 23 18:05 sys
drwxr-xr-x  2 root root   40 мар 23 18:05 sysroot
drwxr-xr-x  2 root root   40 мар 23 18:05 tmp
drwxr-xr-x  7 root root  140 мар 23 18:05 usr
drwxr-xr-x  3 root root  100 мар 23 18:05 var

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

Там микрокод процессора не мешается случайно? Он отделным cpio-архивом в initrd и может мешать распаковать. Но это в принципе, у Убунты свои заморочки могут быть. mc, кстати, в обычный initrd лазить может.

В чем это выражается?

unmkinitramfs распаковывает всё:

$ unmkinitramfs /boot/initrd.img-4.18.0-16-generic /tmp/111/
$ ls /tmp/111/*
/tmp/111/early:
kernel

/tmp/111/main:
bin  conf  etc  init  lib  lib64  run  sbin  scripts  usr  var
$

$ lsinitrd --unpack --unpackearly /boot/initrd.img-4.18.0-16-generic
$ ls -R
.:
kernel

./kernel:
x86

./kernel/x86:
microcode

./kernel/x86/microcode:
AuthenticAMD.bin
$

AS

mc видит только дир. kernel

Так-с, я выше фигню сморозил: lsinitrd --unpack --unpackearly распаковывает то же, что и lsinitrd --unpack, т. е. все, кроме микрокода. В свою очередь, lsinitrd --unpackearly распаковывает микрокод. К слову, lsinitrd --unpack /boot/initramfs-$(uname -r) ругается в том смысле, что для указания того, где лежит желаемый initrd, надо использовать опцию -f.

Сказанное справедливо для dracut-049-25.git20181204.fc29.x86_64 в Fedora 29.

так ничего он не распаковывает кроме дир. kernel почему-то

Распаковали тут > Как монтировать initrd.img ?

mc видит только дир. kernel

Потому, что это уже не очень обычный initrd, а новомодний, из двух cpio, в первом из которых микрокод, который грузится напрямую самим ядром.