Почему /dev не пустой?

ты можешь сам файлы устройств через mknod где угодно создать(кроме какой-нибудь fat, конечно)

Что это за файлы?

Это файлы нод виртуальных устройств.

они нужны для начальной загрузки ядра до этапа Да.

Это минимальный набор на всякий случай.

Файлы устройств. Попробуй сделать cat /dev/random или /dev/urandom в терминале. Или в голой консоли без иксов cat /dev/random > /dev/fb0 =) Остальные файлы погугли, там все подряд, ввод, вывод, консоль и так далее.

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

Ядро Linux может грузиться без initramfs. В случае, если всё нужное для монтирования корневой файловой системы собрано монолитно в ядре. И в этом случае монтирование devfs занимается система инициализации, это может быть как systemd, так и скрипт на баш.

И в момент работы системы инициализации до монтирования /dev скриптам или systemd для корректной работы нужны файлы виртуальных устройств для доступа к жтим устросйствам. Это как минимум /dev/console, /dev/null, /dev/stdin, /dev/stderr.

Вот поэтому в директории /dev есть минимально необходимый набор nod файлов виртуальных устойств.

Аналогично он же есть и в initramfs для корректной работы системы инициализации в initramfs системе.

Это как минимум /dev/console, /dev/null, /dev/stdin, /dev/stderr

В подмонтированном корне VoidLinux /dev абсолютно пустой. Как минимум )

Кстати, проверил, в ArchLinux - тоже.

Только в Ubuntu вижу ровно то, что у автора темы.

В общем, судя по дате/времени создания их у меня - на мой взгляд - это похоже на запчасти от установки Ubuntu. Полагаю, можно удалить. Пойду, попробую )

--------
Попробовал. Удалил всё /mnt/Ubuntu/dev из-под ArchLinux. Загрузился в Ubuntu. Обновил, в т.ч. ядра. Перезагрузрузился на всякий еще раз в Ubuntu, уже с новыми ядрами. Вернулся в Arch - /mnt/Ubuntu/dev всё ещё чистый. Процентов на 99.9% уверен, что это запчасти от её установщика.

нахрена для устройств хранить файлы в памяти?

Прочитай внимательно что я написал. В случае загрузки системы БЕЗ INITRAMFS.

Если у тебя система грузится с Initramfs, то в этом initramfs в директории /dev уже есть файлы устройств console, null, stdint, stdout.

В случае запуска с initramfs в начале отрабатывает система инициализации в Initramfs, которая монтирует devfs в /dev в initramfs, потом монтирует корень в директорию куда будет переключаться ядро, например в /mnt/root, затем в /mnt/root/dev монтирует devfs, выполняет прочие операции и затем делает переключение корня.

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

Вот содержимое /dev на корневой файловой системе в Debian 11:

console
fd
full
null
ptmx
pts
random
shm
stderr
stdin
stdout
tty
urandom
zero

Если у тебя система грузится с Initramfs, то в этом initramfs в директории /dev уже есть файлы устройств console, null, stdint, stdout.

Да я вроде посмотрел внутрь initrd и Arch, и Ubuntu, и Void - ничего там в /dev нет.

Потом посмотрел в Ubuntu'овский вариант rootfs, который они называют ubuntu-base-20.04.1-base-amd64.tar.gz - там тоже /dev пустой.

Сейчас доехал до большой машины - тут у меня еще и Debian установлен. И ставил я его из VoidLinux через debootstrap (т.е. точно без установщика) - там действительно /dev/ заполнен физическими файлами.

Да, наверное, есть какой-то более хитрый секрет, чем просто «мусор после установщика». Сейчас попробую поиграть тщательнее в эту игру на большой машине.

Я не разработчик ядра, но за скормные 500 долларов США готов переслать им твой вопрос)

Что-то пока слабенько наигралось.

Пока так:
1) mknod сам debootstrap и делает на физическом /dev. Там у него для этого setup_devices_simple () и есть в функциях. Единственное, что в голову приходит - это нужно для самого bootstrap, и, наверное, для chroot в него.

2) без initrd, только rootfs+kernel преспокойно загружается с пустым /dev (экспериментировал на Angstrom)

Может позвать кого-нибудь из крупных специалистов по Debian? Zubok? Можете объяснить зачем Debian(&etc) делает /dev/* на физическом диске?

Только в Ubuntu вижу ровно то, что у автора темы.

Не знаю ничего. У меня есть диск с живым корнем Debian 10, с которого я обновлялся на Debian 11, но только с переносом на новый винт (установщиком не пользовался миллион лет, со времен pre-etch). Монтирую корень в /mnt/temp, смотрю ls -l /mnt/temp/dev. Тут пусто. А с чего вы взяли, что файлы реальные? ls -l что говорит? Что прямо это обычные файлы в файловой системе корня, а не ноды устройств?

А с чего вы взяли, что файлы реальные?

100%. Вот, только что debootstrap сделал в новый каталог /deb-stable и сразу получил /deb-stable/dev с реальными файлами/нодами. Из явно попавшегося на глаза - apt без кое-чего из /dev/ становится плохо. Может ради apt на время установки?

Да ты много сказок рассказываешь. То у тебя в дебиане системды никогда не было (хотя она в районе jessie ставилась принудительно), то /dev пустой… Вообще-то файлы там создаются правилами udev, даже под системдой.

А-а-а, ну про debootstrap вообще отдельный разговор. Это создается для установки в контейнер. Как минимум systemd, хочет, чтобы это уже было. Пункт 3: https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/

То у тебя в дебиане системды никогда не было (хотя она в районе jessie ставилась принудительно),

Я уже рассказывал, что принудительная отмена systemd даже описывалась в release Notes: https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en....

Читай документики и не засоряй эфир.

Зашел с другой стороны:

Взял голый rootfs ubuntu-base-20.04.1-base-amd64.tar.gz.

Распаковал в раздел, где стояла нормальная Ubuntu, от установщика «далее-далее-далее», с мусором в /dev (чтобы не менять в gummiboot UUIDы - не создавал заново новый, а просто всё удалил там).

chroot туда, на свежераспакованную, по-настоящему:

# mount --rbind /sys /mnt/Ubuntu/sys && mount --make-rslave /mnt/Ubuntu/sys
# mount --rbind /dev /mnt/Ubuntu/dev && mount --make-rslave /mnt/Ubuntu/dev
# mount --rbind /proc /mnt/Ubuntu/proc && mount --make-rslave /mnt/Ubuntu/proc
# cp /etc/resolv.conf /mnt/Ubuntu/etc/
# PS1='(chroot) # ' chroot /mnt/Ubuntu /bin/bash

Вот теперь получил чистый и пустой /dev в ней. Точно что-то про установщик, так или иначе.

Если ты будешь ставить в --variant=fakechroot, то debootstrap не должен ничего создавать в your_debian/dev, а просто сделает здесь симлинк на /dev

А в gentoo в stage3 заметно больше файлов в /dev, например там есть /dev/hda32 (block 3,32). Вобще не знаю зачем...

без initrd, только rootfs+kernel преспокойно загружается с пустым /dev (экспериментировал на Angstrom)

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

Вот теперь получил чистый и пустой /dev в ней.

Если ты не занимаешься "компиляцией ведра" в монолит то вероятность того, что ты будешь загружаться без initrd находится около нуля и по этому к этой части стандарта относятся довольно пренебрежительно, ибо те кто компулирует вядро могут позаботится о себе сами.

Если ты будешь ставить в --variant=fakechroot, то debootstrap не должен ничего создавать в your_debian/dev, а просто сделает здесь симлинк на /dev

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

Зачем ядру, собранному с CONFIG_DEVTMPFS=y и CONFIG_DEVTMPFS_MOUNT=y, что-то внутри /dev на диске?

Эти устройства имеют фиксированные номера.

https://www.kernel.org/doc/Documentation/admin-guide/devices.txt

Пологаю что это более позднее развитие.

С одной стороны да, но с другой тот кто учил меня линуксу в далёком 2000 году говорил условное "ка бы чего не вышло".

Нет, неправильно. Читай маны по каждому из файлов и вообще unix-ам.

А вообще, время опытов. Если в этот реальный /dev/random засунуть не рандом, а вполне конкретный код, то поломается ли криптография? Будет ли cat /dev/random рандом выдавать или то что там записано? А на разных этапах загрузки системы? Короче интересную ты тему поднял.

установщик убунты rsync’ом копирует содержимое развернутого в память образа лайв-системы на выбранный под рут раздел носителя, так что может попутно и говнеца накинуть :).
монитрование в /dev tmpfs происходит на очень раннем этапе (копнуть бы интирамфс да влом) так что содержимое /dev на рут разделе так и зависает под пеленами намонтированного.

ls -s /dev/full /dev/random :)

Ты лучше расскажи что произойдёт. Я не хочу ночью виртуалку запускать и играться (я уже в кроватке лежу с ноутом на котором оперативки меньше чем на моём смартфоне). Да и книжку я не знаю какую внимательно почитать на эту тему.

Прочитал man random (4) всё равно не понял. Наверное спать пора.

Взял голый rootfs ubuntu-base-20.04.1-base-amd64.tar.gz.

Кстати, забавно на мой взгляд.

Если так делать, то некоторое количество ручных установок не избежать. Если с iproute2, locale, ping, dhcpcd еще более/менее понятно, то на apt install xfce4 он мне притащил целый GNOME паровозом - это прям сильно внезапно было )

Зато /dev на диске по-прежнему чистый и пустой )

---------

Не менее забавно, что grub есть в base. Как бы понятно-нужный iproute2 - нет, а совершенно-ненужный grub - есть.

генерация твоих паролей будет строго логична.

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

следствие вскрыть твои шифрованные каналы станет очень и очень легко (исключая что вскрыватель даже по сильной обкурке совершенно не ожидает ln -s /dev/full /dev/random).

Мда. Позор если так всё плохо. В принципе не должно такое быть возможным.

дык потому при старте в /dev монтируется tmpfs, которая пуста бай-дефаулт и потом в ней создаются все файлы устройств.