☰

Удаляет ли ядро ​​записи в /dev на initramfs?

tag-icon • tag-icon linux linux-kernel devices initramfs
Удаляет ли ядро ​​записи в /dev на initramfs?

У меня полностью кастомная, минимальная, встроенная система Linux (vanilla, 3.3.8, i486, Vortex86dx), которая загружается с образа initramfs. Стандартные скрипты дистрибуции не используются, только один файл rcS, который выполняет инициализацию.

У меня есть IDE Flash-диск с двумя разделами: /dev/hda1 и /dev/hda2.

Поскольку это минимальный встроенный дистрибутив для фиксированной системы, в нем есть статический каталог /dev, содержащий /dev/hda1 и /dev/hda2, а UDEV отсутствует.

В момент, когда init вызывает rcS, запись /dev/hda1 больше не присутствует. Никакие другие скрипты, пользовательские приложения или демоны в этот момент не были запущены. /dev/hda1появляетсябыть удаленным ядром(?)

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

Я использую Buildroot для создания каталога /dev с помощью файла device_table_dev.txt. Например:

# IDE Devices
/dev/hda    b   640 0   0   3   0   0   0   -
/dev/hda    b   640 0   0   3   1   1   1   4

Я проверил rootfs.tar.gz из Buildroot output/images. Каталог /dev содержит /dev/hda1:

brw-r-----  1 root root  3,   0 Jul  2 13:44 hda
brw-r-----  1 root root  3,   1 Jul  2 13:44 hda1
brw-r-----  1 root root  3,   2 Jul  2 13:44 hda2
brw-r-----  1 root root  3,   3 Jul  2 13:44 hda3
brw-r-----  1 root root  3,   4 Jul  2 13:44 hda4

Мой список каталогов после загрузки (сделанный из rcS, в верхней части скрипта) на целевой машине выглядит следующим образом:

brw-r-----   1 root   root    3,   0 Jul  2 12:44 hda
brw-r-----   1 root   root    3,   2 Jul  2 12:44 hda2
brw-r-----   1 root   root    3,   3 Jul  2 12:44 hda3
brw-r-----   1 root   root    3,   4 Jul  2 12:44 hda4

/dev/hda1 отсутствует. /dev/hda2 — это раздел на том же диске, но он все еще там. Странно.

Если я запускаю утилиту Busybox "mdev -s", она восстанавливает /dev/hda1 на целевом устройстве и все работает нормально. Например, я могу его смонтировать.

Кто-нибудь когда-нибудь видел подобное поведение?

Удаляет ли ядро ​​записи из /dev?

решение1

Подсистема udevсоздает и монтирует tmpfsфайловую систему во /devвремя загрузки. Содержимое заполняется ядром по мере обнаружения устройств. Поскольку tmpfsнаходится в виртуальной памяти, оно не является постоянным, поэтому ваши изменения не сохраняются при перезагрузках. Даже если у вас /devуже есть, монтирование новой файловой системы скрывает каталог, и создается впечатление, что все ваши специальные устройства были удалены. Это не так, но конечный результат тот же: специальные не там, где вы ожидаете.

Я подозреваю, что вы обнаружите, что ваши записи hdaи hdaXбыли заменены на записи sdaи sdaX. В качестве альтернативы проверьте /proc/devicesи , /proc/partitionsчтобы получить имя, udevназначенное диску.

Иногда может помочь быстрое и грубое решение, например fdisk -l /dev/[sh]d[a-z](работает лучше, если у вас менее 26 дисков каждого типа).

Кстати, схема именования, используемая , udevстандартизирована, и ваш статик /devможет сделать хуже, чем следовать соглашениям. Если udevвы думаете, что это /dev/sda, то придерживайтесь этого. Вы могли бы избежать потенциальных странностей и недоразумений в будущем.

Связанный контент