0

I have 2 questions:

  • I am not sure to undrestand(from the directories description in Buildroot manual):

    target/ which contains almost the complete root filesystem for the target:everything needed is present except the device files in /dev/ (Buildroot doesn’t run as root and doesn’t want to run as root)

Why buildroot need to be root to create the /dev

  • what i know is that buildroot uses target to generate images/rootfs.tar; is it a simple compression with taror ...? could you please help me find the make target that generate images/rootfs.tar? In case of using NFS why can't we use directly the targetfolder as rootfs what makes "untaring" images/rootfs.tar different than target

Ref: http://free-electrons.com/~thomas/buildroot/manual/html/ch03.html

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
Mouin
  • 1,025
  • 4
  • 19
  • 33
  • 1
    (1) Buildroot, a tool for generating a kernel and root filesystem, is executed on your host system as a normal user without need of superuser privileges. (2) The .tar is an ordinary archive without compression. You can configure/specify compression (and/or filesystem images) using the `make menuconfig` procedure. You do not specify this in the `make` shell command. – sawdust Feb 12 '17 at 00:06
  • @sawdust, thanks for the feedback, Maybe my question was not straight forward. what i need to know is why we can't use `target` as rootfs in buildroot manual it's said that's because it doesn't contain `dev` because Buildroot doesn't run as root, so why it needs root privilege to create it – Mouin Feb 12 '17 at 06:32

1 Answers1

0

I am not sure to undrestand(from the directories description in Buildroot manual):

Buildroot, a tool for generating a kernel and root filesystem, is executed on your host system as a normal user without need of superuser privileges.

Why buildroot need to be root to create the /dev

Buildroot does not use superuser privileges.

what i know is that buildroot uses target to generate images/rootfs.tar; is it a simple compression with taror ...?

The .tar is an ordinary archive without compression.
You can configure/specify compression (and/or select filesystem images) using the make menuconfig procedure.

could you please help me find the make target that generate images/rootfs.tar?

You do not specify this in the make shell command.
You can configure/specify tar and/or cpio archives with optional compression (and/or select filesystem images) using the make menuconfig procedure.

In case of using NFS why can't we use directly the target folder as rootfs

Because it is not suitable as a roofs.
File owners & groups are incorrect (this could be irrelevant for NFS usage).
File permissions may not be correct (e.g. setuid for the busybox binary).
The /dev directory does not have the minimal device nodes that the target kernel requires.

Instead of the required minimal device nodes (e.g. console), the target directory has ordinary files in 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
$

The target kernel cannot use these files when it expects device nodes. Instead of I/O performed through device nodes, ordinary file transfers will be attempted with these files.

The actual dev directory should be: 

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

what makes "untaring" images/rootfs.tar different than target

Buildroot can cleverly create entries for the device nodes and assign the proper owner and group to each filename as it creates the archive (or filesystem image).
This is simply generating binary data in the appropriate format that is inserted with actual archive entries (or to the fs image) written to a file.
Only when it is un-archived (or the filesystem image is mounted) that the "data" is properly interpreted as for device nodes.

sawdust
  • 16,103
  • 3
  • 40
  • 50
  • Thanks again, i just wanna go a bit in details : "Buildroot can cleverly create entries for the device nodes": In my opinion it's the kernel that creates the device nodes [link](http://unix.stackexchange.com/questions/241173/how-are-dev-linux-files-created). "assign the proper owner and group to each filename": could you please explain in which script/Makefile this is done by Buildroot. – Mouin Feb 13 '17 at 10:39
  • If you want to go into details, then put more effort into reading the entire sentence that was written. You and that link refer to actual device nodes. Buildroot is merely constructing a **cpio** or **tar** archive entry for a device node. You cannot archive the actual device node; you can only archive the information *about* the node. Changing owner and group is a standard option of archive programs. – sawdust Feb 14 '17 at 02:39
  • BTW smart people do not not write infantile phrases as *"I wanna..."*. – sawdust Feb 14 '17 at 02:41
  • OK, it seems i am missing a lot of things about device nodes, you mean buildroot prepares informations about devices for the kernel and then the kernel interprets these info and creates the actual device nodes ?. where are these informations (in which file) when /where the kernel read these info, sorry if i ask too much – Mouin Feb 15 '17 at 13:44
  • You're too fixated on *"the kernel"*. **tar** and **cpio** are userspace programs. They can *archive* ordinary files and "special files" (such as device nodes), and then recreate them when *extracting* from those archives. So the kernel is involved, since there is I/O. But the kernel is eventually responsible for performing all the I/O, so what information is conveyed by saying *"the kernel ... creates the actual device nodes"*? Where did that request originate? Hint: it's a userspace program. – sawdust Feb 16 '17 at 00:51