2

After reading this answer on bind mount, I got the idea that a bind-mount in Linux is to reproduce part or an entire filesystem under another point in the directory tree.

So when we write the following commands 

mount --rbind /dev dev
mount --rbind /run run

This means to bind the system's /dev and /run to the point locally under dev and run. Meaning the contents of the system's /dev and /run will be replicated under the directories dev and run locally. Also if I make any changes to the dev and run they will not be reflected in the system's /dev and /run. Right ? But the reverse will be true ?

So my question is why are mounts like the following needed before we run 

update-initramfs -u

What information does it need from the /run and /dev directories? If a bind mount is unable to change information then is it just for read only access by default?

Noam M
  • 451
ng.newbie
  • 1,175
  • “if I make any changes to the dev and run they will not be reflected in the system's /dev and /run” — No, it's the opposite. You don't have two separate directory trees, you have two views of the same tree. Any change made on either side is visible in the other side. Read the first paragraph of my answer. – Gilles 'SO- stop being evil' Aug 05 '17 at 23:54

2 Answers2

2

Doing it is only necessary in some special cases, for example when you chroot into another system and you are trying to generate or update an initramfs image.

To understand why we do need to bind these paths you have to know what initramfs is and why we actually need it:

Many Linux distributions ship a single, generic Linux kernel image – one that the distribution's developers create specifically to boot on a wide variety of hardware. The device drivers for this generic kernel image are included as loadable kernel modules because statically compiling many drivers into one kernel causes the kernel image to be much larger, perhaps too large to boot on computers with limited memory. This then raises the problem of detecting and loading the modules necessary to mount the root file system at boot time, or for that matter, deducing where or what the root file system is. [1]

In conclusion: in my environment while generating or updating an initramfs, I have to know what my devices are, e.g: what kind of disks do I have and what kind of tools/modules should I put into my "initramfs" to handle systems booting? where does these data come form?

Paths like /dev contains a lot of useful information about these kind of stuff, that is why we replicate a path like /dev.

From man hier:

/dev Special or device files, which refer to physical devices.

About your other question, as far as I know when you change anything in any of the mounted locations it will reflect the actual file system, you can easily test it yourself:

$ sudo mount --rbind ~/Documents /mnt
$ touch ~/mnt/foo
$ ls ~/Documents/foo
/home/ravexina/Documents/foo
Ravexina
  • 2,638
  • 1
  • 19
  • 33
  • Then can you explain why I answer I linked to says -: Unlike a hard link or symbolic link, a bind mount doesn't affect what is stored on the filesystem. It's a property of the live system. Does it mean that there is no extra file created ? – ng.newbie Aug 05 '17 at 18:47
  • If you read the first lines again: "Any modification on one side is immediately reflected on the other side, since the two views show the same data.", I'm not sure what @Gilles is trying to say using that statement you quoted. – Ravexina Aug 05 '17 at 18:57
  • I believe what he means to say is that unlike hardlinks no files are created on the filesystem, the contents are "automatically" reflected on the mount point. – ng.newbie Aug 06 '17 at 15:14
0

Also if I make any changes to the dev and run they will not be reflected in the system's /dev and /run. Right?

Wrong, at least in general.

Four different kinds of behaviour can be configured for bind mounts with "equal copy" being the default. See man 8 mount:

--make-shared
--make-slave
--make-private
--make-unbindable
Hauke Laging
  • 90,279