Сложности создания Debian testing/sid+experimental Live CD/DVD (подводные камни udev, live-*-скриптов & странности последних ядер )

Knoppix

Модераторы: Warderer, Модераторы разделов

Ответить
deblanck
Сообщения: 10
ОС: Debian 7.1 Sid/Experimental

Сложности создания Debian testing/sid+experimental Live CD/DVD

Сообщение deblanck »

Собственно,про то,как на скорую руку собрать себе live cd/dvd на базе Debian,написано достаточно,что бы опустить здесь этот момент и перейти к нескольким интерестным деталям,а именно,к тем моментам,где могут начаться эти самые сложности,вроде срыва загрузки live-образа с флешки или внешнего жесткого диска в busybox, или разного рода ступоров во время,казалось бы,безоблачной загрузки прямо из образа,из меню grub2,а иногда,и при загрузке с оптических приводов.Сразу замечу,что речь идёт об образах,собранных на пакетной базе jessie/sid + experimental,скажем так,из желания иметь под рукой самый свежий набор фитчей и самый полный спектр ПО из репозиториев Debian,с возможностью быстро и красиво развернуть или продемонстрировать всю мощь этой операционой системы при любом удобном случае - несём GNU/Linux в массы,не так ли?.. :penguin:
Итак,следуя обычной предсборочной процедуре,пожалуй одинаковой в этом для любого из методов сборки,от debootstrap-a + chroot + mksquashfs + genisoimage,до скрипто-гуевых комплектов типа BootCD или Remastersys,мы настроим свой /etc/skel и сделаем dist-upgrade в сборочной песочнице до желаемого уровня экспериментальности...,потом почистить,собрать,закатать в образ и вперёд,и вот тут-то и начинает твориться нечто чудное,например:

Код: Выделить всё

...last message error was:
modprobe: module ehci-orion don't found in modules.dep...

или

Код: Выделить всё

module index not found
...
module unknown not found in modules.dep
module swap not found in modules.dep
...
Installation live media not found  in /live/image
...

и на этом,как правило - всё,хотя всё делалось проверенными методами,и воспроизведение процесса сборки на базе чистого current stable приводит к однозначно успешным результатам!
Так в чем же дело?В мейнтейнерах Debian-a,которые стесняются прямо заявить сообществу,мол:"...так и так,ребята,если будете пытаться собирать с ядром из experimental и initramfs-tools из unstable,то ничего не выйдет,поскольку мы специально подстраховались и включили в эти версии пакетов ущербный код,чтоб не повадно было..." - ну,или что-то вроде того,все бы поняли?..Моё личное мнение - так оно по сути и происходит,и,с одной стороны это можно понять,но и нам нужно решить свои текущие задачи,пусть это,хоть трижды прихоть и стократ не по фен-шую...
Вобщем,в процессе экспериментов,было выделенно несколько закономерностей,так как:
1.Сразу принудительно удерживать исходные версии пакетов {initramfs-tools,udev,live-*}

Код: Выделить всё

$#echo "initramfs-tools hold" | dpkg --set-selections
$#echo "udev hold" | dpkg --set-selections
$#echo "live-[...] hold" | dpkg --set-selections
sudo aptitude update && sudo aptitude full-upgrade

если исходным был взят готовый live-dvd stable,обновляемый до testing/sid + experimental (мультимедия,драйвера,прошивки...) - после возможной инсталляции системы с такого образа,её спокойно можно будет апнуть,сняв удерживание :

Код: Выделить всё

echo "pkg install" | dpkg --set-selections
aptitude update && aptitude upgrade

2.Если же исходным материалом послужил install sid-a или имеющаяся установка системы на базе default release:unstable,то сначала можно задействовать возможности aptitude

Код: Выделить всё

aptitude purge initramfs-tools
...
...
[Y/n/q] -> n

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

Код: Выделить всё

dpkg -x pkgname dir
nano dir/DEBIAN/control
dpkg-deb -b dir pkgname

c редакцией control файла и превышением версии,что бы обмануть APT...
3.Всё вышеописанное не будет стоить ничего,если в завершение не выполнить небольшие правки в парочке хуков initramfs-tools,для udev & live,приведя следующие секции кода в соответствие требованиям момента:
for /usr/share/initramfs-tools/hooks/udev

Код: Выделить всё

...

cp /lib/udev/hotplug.functions $DESTDIR/lib/udev/
for program in firmware.agent pci-db usb-db hwdb.bin ata_id edd_id scsi_id; do
  copy_exec /lib/udev/$program /lib/udev
done


for /usr/share/initramfs-tools/hooks/live

Код: Выделить всё

...
# udev dependencies
for FILE in /lib/udev/*_id /lib/udev/*.bin
do
    if [ ! -e "${DESTDIR}/${FILE}" ]
    then
        mkdir -p "${DESTDIR}/lib/udev"
        copy_exec "${FILE}" /lib/udev
    fi
done

после чего обязательно :

Код: Выделить всё

ldconfig -v && depmod -va && udevadm trigger && sysctl -p && update-initramfs -v -t -c -k $(uname -r)


Согласитесь,приведённые выше примеры,вещи далеко не очевидные.Таким хаком мне удалось добиться стабильной загрузки и инсталлябильности образов testing/sid + experimental с внешнего Ж/Д в режиме USB-HDD c ядрами версий 3.10-1-686-pae 3.10-3-686-pae и убунтушным 3.11.4-saucy,однако добиться загрузки ядра версии 3.11-trunk-686-pae и ядер liquorix 3.11-3 всё же не удалось,хотя,мне кажется,что тут уже дело в "сырости" самих этих экспериментальных ядер,видимо не подходящих для включения основными в образы live CD/DVD.Однако,предварительно установленные в собираемую систему,они показывали неплохую производительность,а после тестовых инсталляций созданных с ними в комплекте образов и обновления загрузчика (grub2),замечательно загружались и работали...
P.S:
Мне понадобилось пол-дня,что прийти к этому "научным методом" проб и ошибок,но,может быть,мои скромные выводы помогут кому-нибудь сэкономить время и нервы... :rolleyes:

Спасибо сказали:
Aliech
Сообщения: 954
Статус: дилетант широкого профиля
ОС: Gentoo arm64 musl hardened
Контактная информация:

Re: Сложности создания Debian testing/sid+experimental Live CD/DVD

Сообщение Aliech »

Вы молодец конечно, что что-то сделали... Только зачем?

А вот за это вам фи:
Так в чем же дело?В мейнтейнерах Debian-a,которые стесняются прямо заявить сообществу,мол:"...так и так,ребята,если будете пытаться собирать с ядром из experimental и initramfs-tools из unstable,то ничего не выйдет,поскольку мы специально подстраховались и включили в эти версии пакетов ущербный код,чтоб не повадно было..." - ну,или что-то вроде того,все бы поняли?..Моё личное мнение - так оно по сути и происходит,и,с одной стороны это можно понять,но и нам нужно решить свои текущие задачи,пусть это,хоть трижды прихоть и стократ не по фен-шую...


Угадайте, почему unstable и experimental называются именно ТАК? Мб оттого, что работать всегда прямо, ровно и предсказуемо - не их задача?)
С уважением,
Павел Алиев
Спасибо сказали:
Ответить