pra-porteus-initrd + обычное aufs ядро

[ander]

Итог

Обычное aufs ядро - это без специального вкомпиления в файл ядра (т.е. не модулем) поддержки устройств и ФС
Изначально в pra-porteus-initrd в зачатке это есть - но модули ядра грузятся все (а правильно было бы udev).
Теперь есть добавочный initrd-udev.xz

Может, я чего-то недопонимаю, но зачем вообще на этапе initrd грузить много модулей?
Модули файловых систем - понятно, надо найти файлы для дальнейшей загрузки - да и то, зачем все?  Никто puppy на экзотические fs ставить не будет, нужны iso, fat, ntfs и ext2 - для чтения вроде бы достаточно, ну и squashfs и aufs, чтобы свой корень собрать.
Если предполагается сетевая загрузка, тут малость сложнее, поскольку неизвестно, какое сетевое устройство есть в наличии и надо перебрать все возможные.
А вот всеми остальными модулями вполне может заняться udev уже потом, после завершения этапа initrd.

[neobht]

В последнее время фат сменяется на exfat все чаще. Кроме того, многие используют также btrfs, xfs, reiserfs.
Ну и плюс для контроллеров usb, ide, sata и тд. нужны модули.
Остальные - да, не нужны.

[sfs]

Все модули грузятся только потому что выбрать нечем
Да - нужно только модули чтобы увидеть раздел загрузки и ФС на нем - но это не мало
Причем почему-то загруженные в инитрд модули остаются в итоговой системе

[sfs]

Мне все-таки по душе pra6406-test4 M44+uird, особенно как они pfs-ки жмут. Сейчас на нем.
uird для M44 на initrd никак не поменять? (пробовал, не вышло: "Похоже, что файлы расположены на какой-то не такой ФС, попробуйте поместить их куда-то там")

Можно , но будет не совсем красиво. uird , вроде за счет udev, загружает нужные модули ядра; pra-porteus-initrd все (этот костыль я дописал - хорошо бы улучшить)
Вот рабочий пример http://www.puppyrus.org/~melvik/puppyrus/ftp/puppyrus/puppyrus-a64/kernel/4.1.8-1-MANJARO/menu-bigk.lst
Нужно добавить в initrd модулей ядра co сделанным depmod (можно слоёным initrd) чтобы увиделся загрузочный носитель  + squashfs.ko

Сделал

Код

title ▒▒ PRA64. manj44 + pra-porteus-initrd (загрузка с hdd etx4)
set d=pra64
find --set-root --ignore-floppies --ignore-cd /%d%/initrd.xz
kernel /%d%/vmlinuz-4.4-x86_64  dir=%d%  quiet load=Xfce
initrd  /%d%/initrd.xz /%d%/initrd-mj44+a.xz

http://www.puppyrus.org/~melvik/puppyrus/ftp/puppyrus/puppyrus-a64/kernel/4.4.0-1-MANJARO/initrd-mj44+a.xz
С сд не работает (надо еще каких-то модулей ядра). С других ФС и ПК не проверял (может и не заработать)

Делал так:
Загрузился с UIRD, переписал загруженные модули, почистив список руками от специфики моего железа
Сделал Initrd с этими модулями ядра и depmod
Подсунул портеусу

Есть мысль использовать модули ядра от uird с портеус-инитрд:
Загрузить все. Собрать aufs. Выгрузить все модули, которые выгрузятся перед chroot
Наверное правильнее для этой задачи заюзать udev
Честно говоря, я точно не знаю кто анализирует железо и подгружает нужные для этого железа модули ядра
Наверное udev анализирует сообщения ядра и подгружает ....

[neobht]

sfs, вот смотрю я ваши конфигурационные меню загрузчика и впадаю в ступор "зачем все это здесь? охренеть!!!".

и совсем недавно вы мне писали про сложность какого-то "+" для пользователя. Да любой пользователь(не спец) просто открыв все это может в обморок упасть и больше никогда это не открывать.

[sfs]

Почистил выше все не относящееся к теме. Так не пугает ? 

[neobht]

так значительно лучше.

[DdShurick]

Может, я чего-то недопонимаю, но зачем вообще на этапе initrd грузить много модулей?

Совершенно верно, но лучше на этапе initrd вообще не загружать модули.

А вот всеми остальными модулями вполне может заняться udev уже потом, после завершения этапа initrd.

Вот именно, у меня в Richy так и сделано.

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

Голова и руки есть? Соберите ядро с вкомпиленными необходимыми модулями.

Причем почему-то загруженные в инитрд модули остаются в итоговой системе

Это элементарно. Ядро и его модули остаются в итоговой системе потому что switch-root меняет корень системы, но не ядро.

Выгрузить все модули, которые выгрузятся перед chroot

Зачем?

[ander]

Совершенно верно, но лучше на этапе initrd вообще не загружать модули.

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

А изначальная идея в начале топика была, насколько понял - грузить любое ядро.

(это потом хвост в отдельную тему выделили)

[DdShurick]

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

Разве таких ядер мало? Кстати, в любом случае потребуется пересобирать ядро с патчем aufs, заодно можно и модули вкомпилить.

А изначальная идея в начале топика была, насколько понял - грузить любое ядро.

Обратимся к классике:

Код

#!/bin/sh
#(c) Copyright 2007 Barry Kauler, www.puppylinux.com
....................
###################LOAD MODULES TO ACCESS DRIVES#####################
echo -n "Загрузка драйверов для доступа к дискам" > /dev/console #STEP ONE

#100214 one config of 2.6.33 has base floppy and ps/2 mouse support not builtin...
[ "`modinfo floppy 2>/dev/null`" != "" ] && modprobe floppy
[ "`modinfo psmouse 2>/dev/null`" != "" ] && modprobe psmouse

#w462 if present, load it. enables recognition of drives attached to parallel port.
[ "`modinfo ppa 2>/dev/null`" != "" ] && modprobe ppa #also loads parport.ko

ELSPCI="`elspci -l`" #jesses great little utility.
#v403 pcmcia drive support. i think this may need extra delay though...
if [ "`echo "$ELSPCI" | grep '060700'`" != "" ];then
 modprobe yenta_socket
 #...may have to add on a couple of seconds, need to test with a pcmcia drive.
 #v412 yeah, my pccard-usb adaptor needs delay before elspci recognises 0C0310 (ohci-hcd) interface...
 sleep 2
fi
#v423 k2.6.29.6 dmesg has warning that ehci-hcd should load before uhci-hcd and ohci-hid
# this is contrary to my understanding all these years, but oh well, let's do it...
[ "`echo "$ELSPCI" | grep '0C0320'`" != "" ] && modprobe ehci-hcd

MODALIASES="`cat /sys/bus/pci/devices/*/modalias`" #important, save to variable before loop.
for ONEMODALIAS in $MODALIASES
do
  modprobe -v $ONEMODALIAS #-v means verbose.
  [ $? -eq 0 ] && echo -n "." > /dev/console
done

#091222 some mmc/sd interfaces need this...
#(above code loop may have loaded sdhci/sdhci_pci or tifm_core/tifm_7xx1)
[ "`lsmod | grep '^sdhci'`" != "" ] && modprobe mmc_core && modprobe mmc_block
[ "`lsmod | grep '^tifm'`" != "" ] && modprobe mmc_core && modprobe mmc_block && modprobe tifm_sd
..........................

Здесь модули подгружаются на стадии init, достаточно положить необходимый минимум модулей в /lib/modules архива initrd.gz. Основной и единственный недостаток это мёртвая привязка initrd.gz к ядру.

[ander]

Обратимся к классике:

Код

#!/bin/sh
#(c) Copyright 2007 Barry Kauler, www.puppylinux.com
....................

Здесь модули подгружаются на стадии init, достаточно положить необходимый минимум модулей в /lib/modules архива initrd.gz. Основной и единственный недостаток это мёртвая привязка initrd.gz к ядру.

Ну да, такое вполне разумно - грузятся только модули, необходимые для доступа к остальной системе на диске, флешке или SD карте.
Правда, зачем-то psmouse еще затесался.
А чтобы избежать мертвой привязки, можно попробовать средствами загрузчика давать ядру два инитрд - один с инитом и утилитами, второй только с нужными модулями.  Сам пока не пробовал, но вроде бы grub такое позволяет.
Только в таком случае инит должен грузить именно те модули ядра, что ему дадут, а не жестко внутри прописанные.

[sfs]

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

Причем почему-то загруженные в инитрд модули остаются в итоговой системе

Это элементарно. Ядро и его модули остаются в итоговой системе потому что switch-root меняет корень системы, но не ядро.

Выгрузить все модули, которые выгрузятся перед chroot

Зачем?

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

В pra-porteus-initrd есть хитрый трюк для cryptsetup - временно монтируется 000-kernel
Если скрипт от Бари рабочий - тут его можно и применить. Тогда pra-porteus-initrd останется универсальным и ядронезависимым

Трюк с несколькими инитрд работает в grub2 и grub4dos

Посмотрел скрипт - главное там:

Код

MODALIASES="`cat /sys/bus/pci/devices/*/modalias`" #important, save to variable before loop.
for ONEMODALIAS in $MODALIASES
do
  modprobe -v $ONEMODALIAS #-v means verbose.
  [ $? -eq 0 ] && echo -n "." > /dev/console
done

Посмотрел modalias - там что-то малопохожее на название модуля pci:v00008086d00000C00sv00001043sd00008534bc06sc00i00
но modprobe ошибок не выдает. Надо пробовать...

initrd-mj44+a.xz не находит модули дистрибутива, жалуется на неподдерживаемое загрузочное устройство.

PRA64. manj44 + pra-porteus-initrd (загрузка с hdd etx4)

А у Вас  hdd etx4 ? И initrd  /%d%/initrd.xz /%d%/initrd-mj44+a.xz ?
Значит пока или повторить на своем железе:

Делал так:
Загрузился с UIRD, переписал загруженные модули, почистив список руками от специфики моего железа
Сделал Initrd с этими модулями ядра и depmod
Подсунул портеусу

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

[ander]

Посмотрел modalias - там что-то малопохожее на название модуля pci:v00008086d00000C00sv00001043sd00008534bc06sc00i00

Зато это похоже на то, что выдает modinfo <модуль>.ko
Видимо, это вшитая в модуль информация об устройствах, с которыми он может работать.

[sfs]

Рецепт BK : MODALIASES="`cat /sys/bus/pci/devices/*/modalias`" - у меня в initrd не сработал

Доработал тему загрузки и потом выгрузки всех модулей из inirtd. На уровне идеи - конечно костылище и увеличивает время загрузки, но зато работает и возможно на любом железе (кто попробует - отпишитесь)
http://www.puppyrus.org/~melvik/puppyrus/ftp/puppyrus/puppyrus-a64/kernel/4.4.0-1-MANJARO/

Код

title  PRA64. manj44 + pra-porteus-initrd 
set d=pra64
kernel /%d%/vmlinuz-4.4-x86_64 %bl%   dir=%d%  nVidia-340.96-k-;xorg-1.17;Syst
initrd  /%d%/initrd160123a.xz /%d%/initrd-mj44+.xz

Если initrd-mj44+.xz с модулями ядра нет - работает как раньше. Добавлены правки ander
т.е. можно юзать initrd160123a.xz везде

Проанализировал тему busybox mdev
Получается работать будет только если ядро скомпилено с * Support for uevent helper - не катит
Надо бы попробовать приживить udev182...

[I-Jurij]

...Доработал тему загрузки и потом выгрузки всех модулей из inirtd.
...работает и возможно на любом железе...
initrd160123a.xz

К файловым системам это относится? На фат32 не прокатило.