Initrd и filesystem

Да.

Прекрасно. Не подскажите как сделать, чтобы с меня не трясли натуральную ФС?

Собрать свой initramfs, указав его как root в параметрах ядра.

Но система будет минимальной, только busybox и командная строка, часть утилит, что ты туда поставишь.

Если нужна графическая оболочка - делай как LiveCD система, с squashfs образом, содержащим основную систему, aufs / unionfs для каскадного монтирования.

https://www.system-rescue.org/ – а готовый вариант чем не устраивает?

Спасибо.

Автор, если я правильно понял хочет только ядро и initrd и зачем-то даже Debian Wheezy использует.

https://www.system-rescue.org

У меня, во-первых, даже сайт не загружается. Во-вторых, мне нужно только необходимое мне, т. е. то, что я сам установил на минимальную систему, которую я получил через debootstrap. В-третьих, у меня мания на то, чтобы максимально уменьшить размер этой самой системы. Тот же Alpine Linux, на который я изначально обратил свой взор весит аж полгига. Мой DIY весит четверть гига.

Да, всё верно. А Wheezy я использую потому что LFS собирать мне лень, а в Wheezy есть apt, через который я могу установить всё нужно и нет systemd, который, как я считаю, в live-система совершенно лишний.

systemd, который, как я считаю, в live-система совершенно лишний.

Вот кстати Devuan у меня и грузится быстрее, чем Debian. Оболочка вроде везде XFCE, но, может ошибаюсь.

указав его как root в параметрах ядра.

Я что-то не так делаю?

menuentry "Debian 7 Wheezy" {
	linux /boot/vmlinuz username=debian apparmor=0 root=/boot/initrd.img.gz
	initrd /boot/initrd.img.gz
}

Kernel panic: Unable to VFS: и так далее

https://sourceforge.net/projects/systemrescuecd/files/sysresccd-x86/

Скачивай.

SystemRescueCD 5.32 на базе Gentoo весил вообще 570 Мб.

Это какая-то не понятная минимализация, зачем ты тогда пишешь про ядро и Inird?

Возьми knoppix: https://www.knopper.net/knoppix/index-en.html

Он на debian, образ вести мегабайт 800, с учётом, что там сжато в squashfs внутри сама система 4 Гб или более с кучей софта.

Так же есть инструкции по пересборке.

А то не понятно чем занимаешься, минимальная, но 4 Гб. Очень всё странно.

initramfs, указав его как root в параметрах ядра

Чего-чего? Initramfs указывается параметром ядра initrd=. Параметр ядра root= при этом не используется, а наоборот имитируется /init-ом из initramfs чтением из /proc/cmdline.

А то не понятно чем занимаешься, минимальная, но 4 Гб

Не знаю что там весит 4 гига, мой образ весит 1/4 ГБ

Во-вторых, я уже начал, хочу довести до конца.

Я что-то не так делаю?

Да, не читаешь документацию по ядру.

Ядро ничего про /boot/initrd,img.gz ничего не знает.

А знает оно что-то вроде про /dev/ram0 или как-то так, смотри документацию в Internet.

На этапе работы загрузчика - загрузчик загружает ядро в память, в отдельный сегмент памяти загружает файл initrd и передаёт управление ядру.

Которое умеет получать доступ к сегменту памяти, куда загружен Initrd, если он сжатый - распаковывать его и изначально монтировать его как корневую ФС.

Без чтения документации не доведёшь, а пока судя по root=/boot/initrd.img.gz - ты вообще не понимаешь как происходит загрузка и что делает ядро.

Про какой-то /boot оно узнает только когда уже смонтирует что-то.

Смотри предыдущий комментарий.

Ты тоже иди почитай про разницу между initrd и initramfs.

root=/dev/ram0 или примерно так.

Именно так ядро увидит загруженный загрузчиком в память inird / initramfs.

Если не понимаешь о чём пишешь - не пиши.

А уже в init сценарии в initramfs / initrd не нужно делать switch_root / pivot_root.

Разницы принципиально никакой, в одном случае это файловая система, например ext4, в другом случае - cpio архив, по функционалу одно и тоже.

судя по root=/boot/initrd.img.gz - ты вообще не понимаешь как происходит загрузка и что делает ядро.

Цепочка загрузки: BIOS -> загрузчик -> ядро -> initrd -> init – это я знаю

Я не понимаю как работают аргументы ядра – это факт. Поэтому сейчас сижу и читаю документацию.

У меня, во-первых, даже сайт не загружается.

Прикрылись клаудфларью с ech => попали под блокировку :(

250 Мб в initrd, со скрипом можно, но грузиться это даже на usb3.0 будет долго, а на usb2.0 ещё дольше.

На моменте работы загрузчика он использует прерывания BIOS / UEFI и даже в случае наличия USB 3.0, если говорить про флешку, - грузиться с флешки может на скорости условно USB 1.1.

Это ты тут не понимаешь о чём пишешь. Initramfs видится с одним параметром initrd= а root=/dev/ram0 это для initrd.

Разница в том, что initramfs не тянет целую блочную подсистему и фс а является простейшим ахивчиком.

Без разницы, нюансы в документации. Главный смысл в том, что вместо root=/boot/initrd.img.gz автору нужно указывать соответствующее устройство в /dev, /dev/ram0 или другое - ответы в документации.

Читать документацию я не собираюсь, собирал такие системы давно.

Если у тебя есть желание - напиши автору. А не указывай, что кто-то не прав. Если он не собирается читать за автора документацию.

Если ты собираешься - читай и давай ответы.

И что дальше? Я это понимаю, зачем ты мне это пишешь, я не будут расписывать все нюансы и читать за автора документацию. Главный посыл - логика, что нужно указывать в параметре ядра root= соответствующее устройство, на которое отображается файловая система или куда ядро распакует cpio архив.

Что ты мне пытаешься доказать?

автору нужно указывать соответствующее устройство в /dev, /dev/ram0 или другое

Да, это я уже выяснил. Вопрос: initrd в формате cpio-архив подойдёт в качестве корневой ФС или нужен именно образ с файловой системой внутри?

Главный смысл в том, что вместо root=/boot/initrd.img.gz автору нужно указывать соответствующее устройство

Для initramfs не нужно.

Читать документацию я не собираюсь

В квотезы! (ц)

Да ничего, просто дезу твою тут опровергаю, люди же читают.

Для initramfs не нужно.

Ок, спасибо за уточнение.

Читать документацию я не собираюсь

В квотезы! (ц)

И именно так, за автора - не собираюсь, пускай сам читает.

Мне это сейчас не нужно. Если мне нужно будет собрать систему с ядром и initrd/initramfs, содержащими всю систему, что нужна - прочитаю.

Молодец, твои попытки что-то мне доказать неплохи, но мне неважны.

Тебе анонимус пишет, только почему-то вместо твоих сообщений что-то доказывает мне.

Он готов тебе дальше помогать с чтением документации, обращайся.

Я тебе дал направление, дальше - читай документацию, консультируйся с анонимусом.

В любом случае учиться и разбираться в нюансах тебе.

Просто пакуй cpio архив, указывай его параметром initrd= и всё, он тут времена ядра 2.4 вспомнил или когда там на initramfs ещё не перешли.

linux /boot/vmlinuz initrd=/boot/initrd.img.gz load_ramdisk=1 ramdisk_size=500000 rw root=/dev/ram0

Получаю:

Kernel panic: Unable to mount root fs

initrd в формате cpio

Шо не так?

Главный смысл в том, что вместо root=/boot/initrd.img.gz автору нужно указывать соответствующее устройство

Для initramfs не нужно.

anonymous.

Оставь только

linux /boot/vmlinuz initrd=/boot/initrd.img.gz

Ничего не изменилось.

Не подхватывается фирмварь (комментарий)

Ядро должно поддерживать используемые алгоритмы сжатия для cpio.

initrd.img.gz хоть cpio архив а не какой-нибудь ext2?
Напиши в /init

#!/busybox sh
exec /busybox sh

запакуй со статически скомпилированным busybox в cpio и подсунь ядру.

Какой init? У меня ФС не монтируется.

Initramfs это не фс, а простой cpio архив. Я предлагаю паковать вручную в cpio архив и всё будет работать.

find . |cpio -o -H newc >initramfs.cpio

Проверил на Debian Bookworm:

dpkg -L busybox
ldd /bin/busybox
ldd /lib/x86_64-linux-gnu/libresolv.so.2
ldd /lib/x86_64-linux-gnu/libc.so.6
ldd /lib64/ld-linux-x86-64.so.2
mkdir iniramfs/in/{bin,sbin,etc,proc,sys,dev,lib64,lib,sbin} -p
cp /lib64/ld-linux-x86-64.so.2 iniramfs/in/lib64/
cp /lib/x86_64-linux-gnu/libc.so.6 iniramfs/in/lib
cp /lib/x86_64-linux-gnu/libresolv.so.2 iniramfs/in/lib
cp /bin/busybox iniramfs/in/bin/
cd iniramfs/in/bin/
ln -s busybox sh
ln -s busybox mount
ln -s busybox echo
ln -s busybox ls
ln -s busybox cat
ln -s busybox dmesg
mknod iniramfs/in/dev/console c 5 1
mknod iniramfs/in/dev/null c 1 3
echo "#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
exec /bin/sh" > iniramfs/in/init
chmod +x iniramfs/in/init
cd iniramfs/in/sbin/ && ln -s ../init && cd ../bin && ln -s ../init && cd ../
find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../initramfs.cpio.gz
cp ../initramfs.cpio.gz /boot/

Там busybox динамически собран и нужны 3 библиотеки.

Далее в загрузчике:

        echo    'Loading Linux 6.1.0-35-amd64 ...'
        linux   /boot/vmlinuz-6.1.0-35-amd64
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initramfs.cpio.gz

Проверил, всё загружается, ядро монтирует cpio и запускается sh.

Статический busybox чтобы не пердолиться с ldd:

https://packages.debian.org/sid/busybox-static

Вместо пердолинга с mknod проще

mount -t devtmpfs _ /dev

Но почему не взять это? MiniOS хоть и ~800 МиБ, но там и DE из коробки, и браузер.

а перевести?!

нужна live DIY-система, с которой я смогу редактировать разделы диска и влезать в их ФС

хотя, нет лучше начнём от обратного

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

в чём проблема совсем непонятно

Вот уже сегодня на свежую голову я понял, что проблема скорее всего в sysvinit.

echo '#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
exec /bin/sh' > iniramfs/in/init

Спасибо, сегодня попробую этот скрипт в качестве init.

Ничего ты не понял, не инит.

Читай.

«boot=live» - вот что нужно понять.

Live - подсистема, делающая Дебиан «живым». Она и задаёт, что будет корнем.

То, что вы решил пердолить своё и разобраться в initramfs, опциях ядра и т.д. — хорошо и правильно. Только вы учтите с wheezy и ядром 3.2 может не особо получиться влезть в ФС от свежих дистрибутивов. Если у вас везде wheezy, то хорошо, а иначе в неподходящий момент, когда нужно будет чинить систему узнаете, что на вашей флешке все слишком старое...

Тут костер горит, подкину своих дров.

А зачем тебе вообще нужен BIOS, UEFI - сразу ставь coreboot. и будет лучше, уберешь лишний элемент.

А еще можно грузится через ipxe, там умеет вызывать по сети ядро и initramfs.

Я так делал почти рабочую систему, загружаю по сети установщик CentOS, затем в kickstart прописываю что мне нужно сделать.

Ничего ты не понял, не инит.

Далеко не факт: если загрузиться с init=/bin/sh, оно вполне может загрузиться без kernel panic