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

[ander]

Слепил загрузку pra 1601 на manjaro 4.4, i686 разумеется.
В принципе, этот initrd при использовании без второго initrd c модулями, должен работать по старому, но еще не проверял.
У меня pra лежит на sdb1/pra1601g/, там директория kernel, которая в архиве:
sdb1/pra1601/kernel/...
Там рядом с ядром лежат и оба initrd, и 000-kernel.pfs, и menu.lst, только в меню пути скорее всего поправить придется под вашу структуру каталогов.
У меня грузится нормально, разницы между ядрами 3.19 и 4.4 не заметил.

http://www.puppyrus.org/~melvik/puppyrus/ftp/puppyrus/users/ander/manjaro44-i686-kernel.tar.gz

Конечно, надо еще дорабатывать - проприетарные драйвера собрать и рядом с ядром положить, пакеты с модулями виртуалбокса тоже, придумать, как из modules поотфильтровывать пакеты с модулями от другого ядра, и как сделать чтобы тот же виртуалбокс по зависимостям подтягивал нужные модули из папки kernel, ну и тому подобное.

Кстати, смотрел манджаровское ядро 4.5, так там aufs нет.

[sfs]

Проверил 160207 на ноуте - работает

Может все-таки так?

Чего-то сложновато и неудобно kernel/`uname -r`/
Мне кажется лучше base/000-kernel`uname -r`.pfs и если он есть - фильтрануть остальные 000-kernel* , чтобы не грузились ...
Определение видях криво работает и сигнатуры устарели - лучше вообще убрать

Хотя можно сделать чтобы все 3 варианта работали (000-kernel ; kernel/`uname -r`/000-kernel ; 000-kernel`uname -r`)

Фильтр модулей

Код

grep -v 000-kernel /tmp/modules >/tmp/modules2
grep 000-kernel /tmp/modules >/tmp/modules-k
grep 000-kernel`uname -r` /tmp/modules-k >/tmp/modules
cat /tmp/modules2 >>/tmp/modules

Аналогично с nVidia amd-catal

манджаровское ядро 4.5 - странно. Насколько я изучил mandjaro-iso - там без aufs не прокатит

/usr/lib/modules/4.4.1-2-MANJARO/build/vmlinux - зачем оставили? cryptsetup забыли
Чем делали initrd с модулями ядра?

[ander]

Может все-таки так?

Чего-то сложновато и неудобно kernel/`uname -r`/
Мне кажется лучше base/000-kernel`uname -r`.pfs и если он есть - фильтрануть остальные 000-kernel* , чтобы не грузились ...

Хотя можно сделать чтобы все 3 варианта работали (000-kernel ; kernel/`uname -r`/000-kernel ; 000-kernel`uname -r`)

Фильтр модулей

Код

grep -v 000-kernel /tmp/modules >/tmp/modules2
grep 000-kernel /tmp/modules >/tmp/modules-k
grep 000-kernel`uname -r` /tmp/modules-k >/tmp/modules
cat /tmp/modules2 >>/tmp/modules

Аналогично с nVidia amd-catal

Можно, конечно, и так.
Но я когда предлагал с директориями, имел в виду упрощение не initrd, в него не часто залезать приходится, да и не все его правят.
Зато насколько становится просто с точки зрения пользователя установить или убрать ядро.  Распаковал или стер одну директорию и в menu.lst поправил один пункт, и все.  Не надо по всем base/modules/optional лазать, версии ядра сверять.  Да и обновлялка не наткнется на версию ядра, перепутав ее с версией программы.

Определение видях криво работает и сигнатуры устарели - лучше вообще убрать

Значит, что-нибудь придумывать надо.
Что интересно, когда я в процессе экспериментов заталкивал в initrd все модули, то интеловский i915 у меня подгружался в процессе поиска по шинам.
Насколько я понял, все эти "pci:v00008086d00003582sv*sd*bc03sc*i*" с шины это и есть идентификаторы оборудования, а из модуля ядра при помощи modinfo <модуль> | grep alias извлекаются аналогично выглядящие строчки, видимо, это то оборудование, с которым данный модуль может работать.  Все это еще требует экспериментов, но похоже эти строчки можно использовать вместо сигнатур.

манджаровское ядро 4.5 - странно. Насколько я изучил mandjaro-iso - там без aufs не прокатит

Сам удивился - во всех версиях было, а тут нет.

/usr/lib/modules/4.4.1-2-MANJARO/build/vmlinux - зачем оставили? cryptsetup забыли
Чем делали initrd с модулями ядра?

build/vmlinux просто забыл удалить, когда модули в кучу скидывал.  Честно говоря, вообще не знаю, что это такое.
А cryptsetup вроде бы клал, специально же проверял с шифрованной сохраненкой и она работала. Помню, из kernel.pfs от pra его брал, потому что манджаровский оказался динамически слинкованным и потребовал кучу библиотек, начиная с libc.  
А инитрд с модулями делал практически вручную.  Составил список того, что раньше определил как нужное, дополнил тем, что вы в загрузке в linuxrc вписали, поиском по дереву модулей в kernel.pfs нашел полные пути к файлам и потом этот список отправил на вход cpio -pdmv <каталог инитрд>

[sfs]

я когда предлагал с директориями, имел в виду упрощение не initrd, в него не часто залезать приходится, да и не все его правят.
Зато насколько становится просто с точки зрения пользователя установить или убрать ядро.  Распаковал или стер одну директорию и в menu.lst поправил один пункт, и все.

Как я предлагаю - еще проще: навалил в base модулей разных ядер. Какое ядро указал в menu.lst - те модули и подгрузятся. Остальные не помешают +  000-kernel`uname -r - не путаются (это особенно хочется)

[ander]

Наваливать-то придется не только в base (kernel.pfs), но и в optional (видеокарты) и даже в modules (виртуалбокс).
К тому же положить - это полдела, а вот захочется потом убрать?
А тут можно собрать в одно место вообще все, относящееся к конкретной версии ядра, включая даже menu.lst для его запуска.
Над переименованием kernel.pfs в kernel-`uname -r`.pfs надо подумать, путаницы действительно меньше, но надо смотреть, как это в linuxrc реализовать.

[DdShurick]

Как я предлагаю - еще проще: навалил в base модулей разных ядер. Какое ядро указал в menu.lst - те модули и подгрузятся. Остальные не помешают +  000-kernel`uname -r - не путаются (это особенно хочется)

Я это давно сделал в Richy. Тоже мне, первооткрыватель 

[sfs]

Над переименованием kernel.pfs в kernel-`uname -r`.pfs надо подумать, путаницы действительно меньше, но надо смотреть, как это в linuxrc реализовать.

Так отдельную папку переписать на хвост
Дядя Шурик - мы за удобный результат ломаемся, а не за первенство идей 

initrd160207 - iso в vbox нормально (клава в debug и т.п.)
По старой схеме с 000-kernel.pfs Никаких 000-kernel* не загрузил

[DdShurick]

Дядя Шурик - мы за удобный результат ломаемся, а не за первенство идей 

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

[sfs]

Почему не желаем? Здесь ничего удивительного. Есть еще идеи ? Предлагайте

[sfs]

Добавил в initrd160202

Код

# Сделать доступными все драйвера:
kernelpfs="`find $PTH/base/000-kernel.$xzm  2>/dev/null`" \
    || kernelpfs="$(find $PTH/base/000-kernel-`uname -r`.$xzm  2>/dev/null)" \
    || echo $i"^[[1;36m""модули 000-kernel, 000-kernel-`uname -r` отсутствуют""^[[0m"

и

Код

if [ "$(echo "$kernelpfs" |grep `uname -r`)" ] ;then ###sfs грузим модули только своего ядра
    grep -Ev '/000-kernel|/nVidia-|/amd-catalyst-' /tmp/modules >/tmp/modules2
    grep -E  '/000-kernel|/nVidia-|/amd-catalyst-' /tmp/modules >/tmp/modules-k
    grep "`uname -r`\." /tmp/modules-k >/tmp/modules
    cat /tmp/modules2 >>/tmp/modules
fi
# Копирование данных в RAM:

Таким образом - если есть 000-kernel-`uname -r`.pfs - из модулей ядра загрузится только он , и из видеодров загрузятся только для текущего ядра
Вроде - просто и понятно
Если 000-kernel-`uname -r`.pfs - все работает как раньше (без фильтраций на версию ядра)

http://www.puppyrus.org/~melvik/puppyrus/ftp/puppyrus/puppyrus-a64/kernel/4.4.0-1-MANJARO/initrd160210.xz
Протестировал на fat-флэшке и iso
Внес все прочие изменения от ander из  initrd160207 (vfat EXIT UDEV)
Предлагаю протестировать и на этом остановиться

[I-Jurij]

Предлагаю протестировать и на этом остановиться

Не так-то просто разобраться в ваших переговорах.
Можно в следующем посте привести краткий хауту по тестированию:
1. Делаем там-то папки такие-то, кладем в них ядра ...
2. Берем initrd такой-то оттуда, такой-то оттуда...
3. menu.lst где-то такой...

[sfs]

Методика тестирования initrd160212.xz:
1. В любом PRA 32\64 заменяем старый initrd.xz - при загрузке и в работе ничего не должно измениться. Т.е. полностью совместимо. Новые фичи опциональны
2. Выполняем п.1 + переименовываем 000-kernel.pfs в 000-kernel-версия_64.pfs, где "версия" - то что для этого ядра выводит uname -r. _64 - архитектура (для 32 -пусто). Из модулей ядра загрузится только 000-kernel-версия_64.pfs, и из видеодров загрузятся только для текущего ядра. Т.е. не надо в load= noload= писать фильтры для разных ядер
3. Большое ядро. menu.lst - первое из info
При ключе ядра ukm - выгрузит лишние модули ядра Всегда выгружает. Проверять lsmod |wc -l
  3a. Если п.3 не грузит ОС : дописываем initrd  /%d%/initrd160211.xz /%d%/initrd-mj44+с.xz /%d%/initrd-udev.xz
  3b. Если п.3a не грузит ОС : повторяем п.3 , но в строку kernel дописываем параметр kmall. Т.е. будут загружены все модули ядра из /initrd-mj44+с.xz

[I-Jurij]

Так понятно?

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

[ander]

Предлагаю протестировать и на этом остановиться

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

[I-Jurij]

... "версия" - то что для этого ядра выводит uname -r ...

Есть модуль 000-kernel.pfs
Нужно из него сделать 000-kernel-`uname -r`.pfs
Как сделать "uname -r " для ядра, которое еще не загружено?