LINUX.ORG.RU

Не инициализируются устройства при сетевой загрузке Ubuntu ... initrd.img

 , ,


0

1

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

Если есть совсем другой способ, буду благодарен за подробную инструкцию. Однако, пробовал через debootstrap и chroot на i386 системе - не получилось.

В итоге запилил следующее.

0) Клиентская бездисковая машина - сервер на базе Intel Xeon E5

1) Установил минимальный Ubuntu 14.04.5 LTS Server amd64 с загрузочной флэшки и репозитория в интернете. Затем настроил свои скрипты и прикладной софт. Проверил - работает, идет мониторинг этой машины на удаленном zabbix-сервере.

2) Отредактировал /etc/initramfs-tools/initramfs.conf

BOOT=ram

3) Добавил скрипт ram, как рекомендовано здесь но с изменениями, подробно описанными здесь там поэтапно описаны мемуары моей борьбы, есть вопросы но нет ответов

4) На работающей системе создал initrd.img для сетевой загрузки

mkinitramfs -o /home/user1/initrd.img

5) Выключил клиентскую машину, отсоединил диск, примонтировал на рабочей машине, почистил ненужное и упаковал целиком, вместе с директорией boot.

find . -print0 | cpio --null -ov --format=newc | gzip -9 > /путь с архиву/rootfs.cpio.gz
6) Скопировал всё на третью машинуу в каталог /../../tftpboot - это PXE-сервер на базе старой писишки. Забегая вперёд, поскольку родное ядро категорически не хотело грузиться, заимствовал ядро linux из сетевой сборки netboot.tar.gz. Остальное не знаю как применить, не пригодилось.

Получилось следующее

/../../tftpboot/
pxelinux.cfg/
             default
initrd.img
linux
pxelinux.0
rootfs.cpio.gz

файл default настроен так

timeout 0
default default
label default
    kernel linux
    append initrd=initrd.img boot=ram rooturl=ftp://10.0.1.1/rootfs.cpio.gz
7) Настроил DHCP и TFTP на основе dnsmasq

8) Включаю целевую бездисковую машину,

стартует получение IP по DHCP, получен IP, загружены pxelinux.0 linux initrd.img стартовал скрипт ram но остановился на строке configure_networking, с ошибкой

ipconfig: no devices to confugure
/init: .: line 222: can't open 'run/net-*.conf'
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000200
...

содержимое этого скрипта-ram с отладочным кодом и неудачными попытками

retry_nr=0

do_rammount()
{

log_begin_msg "configure_networking"

# Вешается внутри этой функции
    configure_networking

    E=$?
    #if [ $E ]; then
	log_begin_msg "ERROR=$E"
    #fi
log_end_msg

    /bin/sleep 30

log_begin_msg "mkdir -p /tmp/rootfs"
    mkdir -p /tmp/rootfs
log_end_msg

    cd /tmp/rootfs
      IP=`echo "${rooturl}"|sed -e 's/^[^0-9.]*\([0-9.]*\)\/\(.*\)$/\1/'`
    FILE=`echo "${rooturl}"|sed -e 's/^[^0-9.]*\([0-9.]*\)\/\(.*\)$/\2/'`
#Это осталось от попыток качать образ tftp и ftp клиентами, которых не нашлось. Но до закачки всё равно пока не доходит из-за отсутствия устройств.

log_begin_msg "wget ftp://$IP:69/$FILE -O /tmp/rootfs/$FILE"
    wget ftp://$IP:69/$FILE -O /tmp/rootfs/$FILE
log_end_msg

#log_begin_msg "echo get "$FILE"|ftp "$IP
#    echo "get $FILE"|ftp $IP
#log_end_msg

log_begin_msg "mkdir -p ${rootmnt}"
    mkdir -p ${rootmnt}
log_end_msg

log_begin_msg "mount -t tmpfs -o size=6G none ${rootmnt}"
    mount -t tmpfs -o size=6G none ${rootmnt}
log_end_msg

log_begin_msg "gzip -dc /tmp/rootfs/rootfs.cpio.gz|cpio -idm -"
    cd ${rootmnt}
    gzip -dc /tmp/rootfs/rootfs.cpio.gz|cpio -im -
log_end_msg
}

# Это основная функция
mountroot(){

log_begin_msg "for x in $(cat /proc/cmdline); do"
    for x in $(cat /proc/cmdline); do
	case $x in
	rooturl=*)
		export rooturl=${x#rooturl=}
		;;
	esac
    done
log_end_msg

    /bin/sleep 10

# Это я добавил просто так, т.к. ничего не получалось
log_begin_msg "load_modules"
    load_modules
log_end_msg

    /bin/sleep 10

log_begin_msg "wait_for_udev 10"
    wait_for_udev 30
log_end_msg

    /bin/sleep 10

log_begin_msg "delay=${ROOTDELAY:-180}"
    delay=${ROOTDELAY:-180}
log_end_msg

    /bin/sleep 10

# Этот блок не решает проблему. Устройств как не было , так и не появляются
log_begin_msg "modprobe af_packet;ifdown*;modprobe e1000e;ifup*"
    modprobe af_packet
    ifdown eth3;ifdown eth2;ifdown eth1;ifdown eth0
    #rmmod e1000e; modprobe -r e1000e;
    modprobe e1000e
    ifup eth0; ifup eth1; ifup eth2; ifup eth3
    ls /sys/class/net
log_end_msg

    /bin/sleep 10

# Это тоже добавлено просто так, может поможет, не помогло
log_begin_msg "resolve_device /dev/eth0"
    resolve_device /dev/eth0
log_end_msg

    /bin/sleep 10

log_begin_msg "do_rammount"
    # Досюда доходит, но далее оно повиснет
    do_rammount
log_end_msg

# Досюда и до цикла не доходит

    /bin/sleep 1

log_begin_msg "while [ ${retry_nr} -lt ${delay} ] && [ ! -e ${rootmnt}${init} ]; do"
    while [ ${retry_nr} -lt ${delay} ] && [ ! -e ${rootmnt}${init} ]; do
	/bin/sleep 3
	log_begin_msg "do_rammount"
	    do_rammount
	log_end_msg
	retry_nr=$(( ${retry_nr} + 1 ))
    done
log_end_msg
}

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

vmlinuz-4.

darkenshvein ★★★★★
()
Ответ на: комментарий от darkenshvein

Намекаете, что ядро пересобирать надо? я этого раньше не делал. Других вариантов нет?

Мне не понятно, почему родное ядро, взятое из boot каталога, не захотело грузиться.

И хорошо бы понять включены ли динамические модули в initrd и как их заставить их туда включиться и работать.

MariaRTI
() автор топика
Ответ на: комментарий от darkenshvein

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

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

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

собрать ядро несложно. несколько команд всего.

darkenshvein ★★★★★
()
Ответ на: комментарий от MariaRTI

И хорошо бы понять включены ли динамические модули в initrd и как их заставить их туда включиться и работать.
вроде это: :)
grep -i initrd /boot/config-4.15.0-36-generic
CONFIG_BLK_DEV_INITRD=y

darkenshvein ★★★★★
()
Ответ на: комментарий от darkenshvein

Если так и есть, то странное ОНИ решение придумали... в pxelinux.0 драйвер есть и все что надо грузится, а в ядре linux для сетевой загрузки его нет...

MariaRTI
() автор топика
Ответ на: комментарий от darkenshvein

CONFIG_BLK_DEV_INITRD=y

А конкретный список включенных в INITRD модулей и пакетов как получить?

Но это конфиг c жесткого диска для initrd.img, c BOOT=local, а для BOOT=ram его нет. Они отличаются? Не хочется локальный initrd апдейтить под сетевую загрузку

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

Поправлю сам себя. Первоначальная загрузка по PXE работает под управлением bios, в котором драйвер есть, а как только управление передается ядру, сеть пропадает, т.к. там драйвера нет.

MariaRTI
() автор топика
Ответ на: комментарий от darkenshvein

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

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

А конкретный список включенных в INITRD модулей и пакетов как получить?

lsinitramfs |grep igb.ko к примеру.

Deleted
()
Ответ на: комментарий от MariaRTI

Смотри, по pxe грузится ядро и initrd средствами самого pxe.

Твоя задача - удостовериться что либо в ядре, либо в initrd есть драйвер для сети.

P.S. Когда тебе надоест медленная загрузка ядра и initrd по tftp, посмотри на этот проект http://etherboot.org/wiki/start С его помощью можно грузить ядра откуда угодно (хоть с http://mirror.yandex.ru)

Deleted
()
Ответ на: комментарий от Deleted

Спасибо! Но по гигабитной сети ядро загружается меньше чем за секунду. А вот rootfs это да, ожидается, что будет долго - минуты 3.

Меня сейчас больше беспокоит сборка ядра. Результат совсем не очевиден. Я повторюсь, но сейчас у меня есть родное ядро из каталога boot, которое стопорится при pxe загрузке. Пишет, что ядро не найдено. При пересборке я получу аналогичное ядро, но со статическими драйверами. Оно также может «не найтись» по той же загадочной причине, что и исходное.

А вот ядро linux из выше-упомянутого архива, грузится. Оно чуть меньше, но в чем ещё разница?

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

Я повторюсь, но сейчас у меня есть родное ядро из каталога boot, которое стопорится при pxe загрузке.

Обычно поддержка сети идёт модулями в initrd.

Не надо пересобирать ядро, это совсем крайний вариант.

Deleted
()
Ответ на: комментарий от MariaRTI

Перед тем как погрузиться в сборку нового ядра, решил проверить старое ещё раз.

После изменения прав на 100644 и овнера на root, родное ядро загрузилось и чудо - драйвер e1000e распознался и динамически добавился, но ругнулся несколько раз.

module verification failed: signature and/or required key missing - tainting kernel
Intel(R) PRO/1000 Network Driver 3.4.2.1-NAPI
Copyright ...
Правда сетевых интерфейсов с именами eth* все равно нет. Затем обнаружились сетевые устройства и их МАСи, но их имена писиайные, отличны от eth*, хотя я делал исправление этого.

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

Затем настройка сети завершилась с нулевым кодом ошибки и скрипт прошел дальше, до этапа загрузки rootfs.

wget выдал ошибку, что не может соединиться с удаленным хостом, Connection refused

Сейчас не ясно, есть сеть или нет. Ограничение это wget-а или моя ошибка. Способы с tftp и ftp я пробовал, такие программы не найдены.

MariaRTI
() автор топика
Ответ на: комментарий от darkenshvein

Ну да, файлы (ядро и initrd) подтягиваются средствами PXE. Просто ооочень медленно (особенно initrd при параллельной отдаче на несколько компов). Отсюда и советуют gPXE.

Deleted
()
Ответ на: комментарий от MariaRTI

Сетевые устройства появились, сейчас в таком виде

p11p1 MAC mtu 1500 DHCP RARP
p11p2 MAC mtu 1500 DHCP RARP
p4p1  MAC mtu 1500 DHCP RARP (иногда dhcp бывает на этом интерфейсе)
eth3  MAC mtu 1500 DHCP RARP
eth3 complete (dhcp from 10.0.1.1)

address:10.0.1.144 ...

Дальше пишет для каждого интерфейса скорость 1Gb fullduplex и прочее

Теперь проблема уперлась в способ загрузки rootfs

wget не коннектится

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

Сейчас добавляю Интеловый igb-драйвер для I210 и I350, и все файлы для tftpboot подправлю и пересоберу, кроме пересборки ядра.

Отпишусь, что получилось, но на wget это, очевидно, не повлияет, так что жду советов

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

Connection refused

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

spectr00 ★★★
()
Ответ на: комментарий от spectr00

Промежуточного роутера нет, PXE-сервер на одном свитче с клиентом На сервере роль DHCP и TFTP выполняет dnsmasq

права

# chmod -R 644 /var/lib/tftpboot 
# chmod 755 /var/lib/tftpboot 
# chmod 755 /var/lib/tftpboot/pxelinux.cfg 
# chown -R root:root /var/lib/tftpboot

# service dnsmasq restart

что-то не так?

MariaRTI
() автор топика
Ответ на: комментарий от spectr00

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

wget ftp://10.0.1.1:69/rootfs.cpio.gz
...
     => `rootfs.cpio.gz`
Connecting to 10.0.1.1:69... failed: Connection refused

MariaRTI
() автор топика
Ответ на: комментарий от dhampire

Это понятно. Но tftp нет в initramfs

Сейчас пытаюсь натравить apache2 на каталог /var/lib/tftpboot, чтобы wget по http смог забрать

При попытке зайти на этот сайт, выдает ошибку Forbidden

You don't have permission to access on this server.

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

tftp есть в busybox, но не факт что он есть в initrd.

busybox tftp
BusyBox v1.29.3 () multi-call binary.

Usage: tftp [OPTIONS] HOST [PORT]

Transfer a file from/to tftp server

        -l FILE Local FILE
        -r FILE Remote FILE
        -g      Get file
        -p      Put file
        -b SIZE Transfer blocks of SIZE octets

dhampire ★★★
()
Ответ на: комментарий от MariaRTI

Сейчас пытаюсь натравить apache2 на каталог /var/lib/tftpboot, чтобы wget по http смог забрать

Заставлять апач раздавать большие файлы - очень плохая идея, натрави лучше nginx.

Deleted
()
Ответ на: комментарий от dhampire

Учту. Что-то там про busybox было, вроде бы enable yes

А что насчет апачи. Почему он не хочет этот каталог как DocumentRoot иметь? Вроде бы права идентичны с /var/www/html

MariaRTI
() автор топика
Ответ на: комментарий от Deleted

ОК! просто апач уже стоит, вот я и попробовал корень ему сменить

MariaRTI
() автор топика
Ответ на: комментарий от Deleted

Зынаю, что 21. Пробовал всё. По этому вопросу пока проблема решена. Файл забирается по http. Пойду скрипт переделывать

MariaRTI
() автор топика
Ответ на: комментарий от Deleted

При распаковке полученного архива rootfs.cpio.gz

gzip -dc /tmp/rootfs/rootfs.cpio.gz|cpio -idm -

получил ошибку, что опция -d в cpio не поддерживается

Однако, эта опция нужна для создания каталогов при распаковке и должна работать как раз в copy-in режиме (-i)

Такой хелп выдается как в Ubuntu 14.04.5, так и в Debian-8

 Operation modifiers valid in copy-in and copy-pass modes:

  -d, --make-directories     Create leading directories where needed
      --extract-over-symlinks   Force writing over symbolic links

что не так с cpio в initramfs ?

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

Подправил немного команду, убрал последний дефис

gzip -dc /tmp/rootfs/rootfs.cpio.gz|cpio -idm
В локальной системе работает, а в initramfs выдает ошибку «cpio: not implemented or invalid option -d»

есть подозрение, что не в cpio дело, что-то не так с каталогом в который идет распаковка

этот каталог фактически создается так, вместе с результатом исполнения

mkdir -p /root                         ... done.
mount -t tmpfs -o size=6G none /root   ... done.
дальше gzip, cpio и ошибка

MariaRTI
() автор топика
Ответ на: комментарий от Deleted

а как делать вызовы с указанием откуда вызывается команда, из initramfs или из busybox?

например, находясь в initramfs, так?

busybox tar -xzf /tmp/rootfs/rootfs.tgz

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

а как делать вызовы с указанием откуда вызывается команда, из initramfs или из busybox?

Написана дичь :))

Запусти из initramfs команду cpio --help

Deleted
()
Ответ на: комментарий от MariaRTI

Я распаковал initramfs от бубунты, там действительно cpio из busybox'а:

./cpio
Usage: ./cpio [-V] -i [< archive]
Который не поддерживает опцию -d. Делай другим архиватором.

И в ней busybox собран без поддержки апплета tar:

./busybox tar --help
tar: applet not found

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

Всё оказалось намного проще, но если знать заранее.

Распаковал initrd.img и rootfs.cpio.gz в отдельные директории, скопировал нужные бинарники в initrd /bin В общем, изменил как нужно содержимое обоих каталогов. Затем упаковал обратно.

tar работает. Система загрузилась в память и работает точно также как она работала с диска, даже на zabbix данные шлет, правда не все. каких-то утилит не видит. Дальше буду ковырять и оптимизировать для множества клиентов (gPXE и прочее).

Задача решена. Всем спасибо за помощь!

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

Разобрался. С загрузкой и образом всё по чесноку. Это я сам на каком-то этапе сделал апгрейд всей системы и в результате изменилась конфигурация lm-sensors, вот скрипты и сбоят, а я не сразу заметил.

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

После апгрейда дистрибутава до последнего-137 билда мне удалось исправить то что отвалилось и я радостный начал пересборку всего проекта начисто, т.к. всё от начала до конца стало понятно. Ага, конечно, не тут-то было!

Вот зачем спрашивается эти уроды из убунты поменяли способ упаковки initrd.img между 31 и 137 билдом Ubuntu 14.04.5?

В 31 билде использовался gzip и cpio, а при попытке распаковки initrd.img из 137 билда, пишет что не в gzip формате!

Проверил на нескольких образах, как локальных, так и ram-ных Старые распаковываются, а новые нет.

При этом система грузится с диска нормально!

Каким архиватором он теперь запакован !?

MariaRTI
() автор топика
Ответ на: комментарий от dhampire

Новый ASCII cpio archive (SVR4 with no CRC)

Старый ./initrd.31.img: gzip compressed data, from Unix, last modified: Tue Oct 16 21:49:12 2018

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

MariaRTI
() автор топика
Ответ на: комментарий от dhampire

Что интересно. В конфигурации /etc/initramfs-tools/initramfs.conf

COMPRESS=gzip
MariaRTI
() автор топика
Ответ на: комментарий от dhampire

Смог таки распаковать

 cpio -i -F initrd.img

Внутри также всё кардинально поменялось, до неузнаваемости.

Теперь там вместо компактной файловой системы лежит только /kernel/x86/microcode/GenuineIntel.bin

MariaRTI
() автор топика
Ответ на: комментарий от MariaRTI

Однако всё по старому только в некоторых установленных системах.

Сейчас поставил Ubuntu 16.04.5 LTS amd64 с зеркала яндекса Там оказался 131 билд. Никакого апгреда не делал.

Такая же проблема.

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

Разработчики специально такие трудности создают?

Что делать?

Использовать возможности initramfs невозможно, т.к. распаковка и запаковка выполняются на другой машине.

MariaRTI
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.