Buildroot не запускается от имени root и не хочет запускаться от имени root

У меня есть 2 вопроса:

  • Я не уверен, что разберусь (из описания каталогов в руководстве по Buildroot):
    #P2#

Почему buildroot должен быть root для создания /dev

  • что я знаю, так это то, что buildroot использует target для создания images/rootfs.tar; это простое сжатие с помощью tarили ...? не могли бы вы помочь мне найти цель make, которая генерирует images/rootfs.tar? В случае использования NFS, почему мы не можем напрямую использовать папку target как rootfs, что отличает «распаковку» images/rootfs.tar от target

Ссылка: http://free-electrons.com/~thomas/buildroot/manual/html/ch03.html


person Mouin    schedule 11.02.2017    source источник
comment
(1) Buildroot, инструмент для создания ядра и корневой файловой системы, запускается в вашей хост-системе как обычный пользователь без необходимости привилегий суперпользователя. (2) .tar представляет собой обычный архив без сжатия. Вы можете настроить/указать сжатие (и/или образы файловой системы) с помощью процедуры make menuconfig. Вы не указываете это в команде оболочки make.   -  person sawdust    schedule 12.02.2017
comment
@sawdust, спасибо за отзыв, возможно, мой вопрос был не прямолинейным. что мне нужно знать, так это то, почему мы не можем использовать target в качестве rootfs в руководстве по buildroot, сказано, что это потому, что он не содержит dev, потому что Buildroot не запускается от имени пользователя root, поэтому для его создания требуются привилегии root   -  person Mouin    schedule 12.02.2017


Ответы (1)


Я не уверен, что разберусь (из описания каталогов в руководстве по Buildroot):

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


Почему buildroot должен быть root для создания /dev

Buildroot не использует привилегии суперпользователя.


что я знаю, так это то, что buildroot использует target для создания изображений/rootfs.tar; это простое сжатие с тарором...?

.tar — это обычный архив без сжатия.
Вы можете настроить/указать сжатие (и/или выбрать образы файловой системы) с помощью процедуры make menuconfig.


не могли бы вы помочь мне найти цель make, которая генерирует images/rootfs.tar?

Вы не указываете это в команде оболочки make.
Вы можете настроить/указать архивы tar и/или cpio с дополнительным сжатием (и/или выбрать образы файловой системы) с помощью процедуры make menuconfig.


В случае использования NFS, почему мы не можем напрямую использовать целевую папку как rootfs?

Потому что он не подходит в качестве крыши.
Неправильные владельцы и группы файлов (это может быть неактуально для использования NFS).
Права доступа к файлам могут быть неправильными (например, setuid для busybox). binary).
В каталоге /dev нет минимального количества узлов устройств, которое требуется целевому ядру.

Вместо обязательных узлов минимального устройства (например, console) в целевом каталоге есть обычные файлы в dev:

buildroot-2015.05/output/target$ ls -l dev
total 4
-rw--w--w- 1 me swdev    0 Sep 15 16:34 console
lrwxrwxrwx 1 me swdev   10 Aug 14  2015 log -> ../tmp/log
drwxrwxr-x 2 me swdev 4096 May 31  2015 pts
$

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

Фактический каталог dev должен быть:

crw--w--w- 1 root root 5, 1 Sep 15 16:34 console
lrwxrwxrwx 1 root root   10 Aug 14  2015 log -> ../tmp/log
drwxr-xr-x 2 root root 4096 May 31  2015 pts

что отличает «распаковку» images/rootfs.tar от target

Buildroot может умело создавать записи для узлов устройств и назначать надлежащего владельца и группу для каждого имени файла при создании архива (или образа файловой системы).
Это просто генерирует двоичные данные в соответствующем формате, которые вставляются с фактическими записями архива. (или в образ fs), записанный в файл.
Только когда он не заархивирован (или смонтирован образ файловой системы), «данные» правильно интерпретируются как для узлов устройств.

person sawdust    schedule 13.02.2017
comment
Еще раз спасибо, я просто хочу немного рассказать о деталях: Buildroot может умело создавать записи для узлов устройств: на мой взгляд, это ядро ​​создает узлы устройств ссылка. назначьте надлежащего владельца и группу для каждого имени файла: не могли бы вы объяснить, в каком скрипте/Makefile это делается Buildroot. - person Mouin; 13.02.2017
comment
Если вы хотите углубиться в детали, приложите больше усилий, чтобы прочитать все написанное предложение. Вы и эта ссылка ссылаетесь на фактические узлы устройства. Buildroot просто создает запись архива cpio или tar для узла устройства. Вы не можете заархивировать фактический узел устройства; вы можете архивировать только информацию о узле. Смена владельца и группы — стандартная опция программ-архиваторов. - person sawdust; 14.02.2017
comment
Кстати, умные люди не пишут инфантильных фраз типа Хочу.... - person sawdust; 14.02.2017
comment
ОК, кажется, я многое упускаю из виду об узлах устройств, вы имеете в виду, что buildroot подготавливает информацию об устройствах для ядра, а затем ядро ​​интерпретирует эту информацию и создает фактические узлы устройств? где находится эта информация (в каком файле), когда / где ядро ​​читает эту информацию, извините, если я слишком много спрашиваю - person Mouin; 15.02.2017
comment
Вы слишком зациклены на ядре. tar и cpio — это программы пользовательского пространства. Они могут архивировать обычные файлы и специальные файлы (например, узлы устройств), а затем воссоздавать их при извлечении из этих архивов. Так что ядро ​​задействовано, так как есть ввод-вывод. Но ядро, в конечном счете, отвечает за выполнение всех операций ввода-вывода, поэтому какую информацию передает фраза ядро... создает фактические узлы устройства? Откуда возник этот запрос? Подсказка: это программа пользовательского пространства. - person sawdust; 16.02.2017