131

I'm trying to create a Linux image with custom picked packages.
What I'm trying to do is to hand craft the packages I'm going to use on an XO laptop, because compiling packages takes really long time on the real XO hardware, if I can build all the packages I need and just flash the image to the XO, I can save time and space.

When I tried to install some packages, it failed to configure due to missing the proc, sys, dev directories. So, I learned from other places that I need to "mount" the host proc, ... directories to my chroot environment.

I saw two syntax and am not sure which one to use.

In host machine:

  mount --bind /proc <chroot dir>/proc

and another syntax (in chroot environment):

  mount -t proc none /proc

Which one should I use, and what are the difference?

Improve this question
3
  • 1
    Beware: granting access to the disk devices means that you lose some of the benefits of 'chroot()'. In particular, the determined can read files outside of their section of the file system if you are not careful.
    – Jonathan Leffler
    Commented Jul 18, 2010 at 19:18
  • 5
    @Jonathan Leffler: that doesn't sound like an issue for what he is doing.
    – Zifre
    Commented Jul 19, 2010 at 1:02
  • 1
    @JonathanLeffler a root user in a chroot can always escape the chroot anyway.
    – LtWorf
    Commented May 10, 2016 at 11:41

7 Answers 7

Reset to default
64

For /proc and /sys, I suppose you could use either method. They are both special file systems so they can be recreated any number of times (the bind mount method uses the exact same mount as the host system, whereas the other method uses a new mount). I've always seen the bind mount recommended in guides, so I'd use that. As far as I know, there is no real important difference.

However, /dev is usually a tmpfs mount that is managed by udev, so it has to be the actual same file system as on the host machine. That means that you would need to use the bind mount method.

If this chroot is going to be around for awhile, you can put these entries in /etc/fstab on the host system to simplify things.

Improve this answer
3
  • 1
    I would like to ask if it make sense to copy (bind) the proc/sys from host to some other machine ? Why should they match that machine ?
    – ransh
    Commented Mar 30, 2017 at 9:08
  • 1
    @ransh it make sens if you bind /proc to $chrootdir/proc , you will have possibility to handles proccess and whats going on inside /proc of both systems from both systems ; e.g: from chroot you can check if a program is running on the host ... etc
    – Yunus
    Commented May 23, 2017 at 15:37
  • Maybe the sys type of file system appears (today) to not exist anymore?
    – 174140
    Commented Apr 25, 2018 at 11:36
165

The Arch Linux Wiki suggests the following commands:

cd /mnt/arch # or where you are preparing the chroot dir
mount -t proc /proc proc/
mount --rbind /sys sys/
mount --rbind /dev dev/
Improve this answer
7
  • 2
    They also seemed to work for me in ubuntu.
    – isaaclw
    Commented Sep 28, 2012 at 21:01
  • 4
    In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
    – Thomas
    Commented May 30, 2016 at 8:42
  • 1
    Please include the link to the source.
    – styrofoam fly
    Commented Dec 4, 2018 at 18:34
  • 3
    As of 2019, the ArchLinux wiki now does --rbind for sys and dev.
    – Saad Malik
    Commented Jul 12, 2019 at 23:30
  • 1
    dont forget to unmount this when done, i had an issue with this on an alinux2. also command on this was also --rbind. Hmm, now i see @Saad mentioned this already, i had to test at it :-) unix.stackexchange.com/questions/61885/…
    – Brian Thomas
    Commented Nov 2, 2019 at 0:22
17

The Gentoo Handbook specifically calls out these two commands for re-mounting /proc and /dev. I've used them several times.

mount -t proc none /mnt/chroot/proc
mount -o bind /dev /mnt/chroot/dev

I suspect /sys is just a regular folder, so you should be able to make a hard link.

ln /sys /mnt/chroot/sys
Improve this answer
3
  • 19
    You can't hardlink a directory (usually) like you suggest for /sys, and if you use a symlink it'll break as soon as you chroot.
    – Steven Schlansker
    Commented Jul 19, 2010 at 0:31
  • They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
    – AzP
    Commented Oct 3, 2018 at 22:53
  • /sys is not a regular folder, it's a sysfs mount.
    – bit2shift
    Commented Apr 3, 2023 at 19:53
3

There are other pseudo filesystems and tmpfs locations. This is on debian:

/dev/pts 
/run
/run/shm
/proc/sys/fs/binfmt_mist
/var/lib/nfs/rpc_pipefs
/proc/fs/nfsd
/proc/bus/usb

It should be okay to mount the usbfs, rpc_pipefs and devpts pseudo-filesystems from within the chroot. I reccomend not binding /proc to the chroot's /proc, since the kernel has the concept of namespaces, and can actually put different things in the chroot's proc.

Update: according to this mailing list thread, /sys should not be bind mounted, especially if the chrooted processes is using its own network namespace.

It's a bad idea to mount the system's /var or /run onto the chroot, if the chroot has its own pid namespace.

Improve this answer
3
  • Speculation? On superuser (and other stack-forums) it's usually better to hold off, or research and answer with linked sources, if you're unsure. This is to avoid risking spreading misguided hints. Sorry if disappoint and good luck!
    – Simon B.
    Commented Mar 9, 2016 at 13:05
  • @SimonB. I've added a link to a mailing list supporting the idea that /sys should not be bind mounted.
    – Brian Minton
    Commented Mar 31, 2016 at 12:43
  • 1
    With pid namespace, you're talking about more advanced user namespace features we can find on modern linux kernels (i.e. the features "containers" are based on), while when we use the term chroot, we refer to the traditional file namespace change (and nothing else).
    – Johan Boulé
    Commented Dec 11, 2016 at 18:58
3

I was trying to reset the grub password on my laptop via a live USB, so I needed to use chroot as well.

The target system was Ubuntu 16.04 and I was working off an Elementary live USB. These commands worked for me to set up chroot:

mount /dev/nvme0n1p1 /mnt
mount -t proc proc /mnt/proc
mount -t sysfs /sys /mnt/sys
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts

From here I was able to chroot in and update-grub /dev/nvme0n1 to fix the password.

Before adding the last two --bind mounts, update-grub threw many errors about not finding devices but picked up the Linux partitions, missing the last Windows one. I guess the Windows part is just a quirk of my system, though.

Remember to umount /mnt/dev/pts, then umount /mnt/dev and the rest before unmounting /mnt.

For more context, this chroot tip might help.

Improve this answer
2

It may be worth noting in this popular question, that Arch Linux has made a script arch-chroot; download arch-install-scripts-15-1-any.pkg.tar.xz

This which takes care of various related problems both in Arch-Linux and Manjaro , where I used it successfully, too. Possibly more Arch-derivates like Parabola are compatible just as well.

While a simple standard chroot into a secondary Manjaro installation will not allow you to run

pacman --sync linux

(the silver bullet after a system crash), replacing the line with

arch-chroot /run/media/*YOURSELF*/manja-disk2

will enable you to fix your secondary Arch-derivate installation via

pacman --sync linux

like a charm. The bash script arch-chroot takes care of /dev /sys /proc and much more, which are left alone by the standard chroot.

see also: Using arch-chroot

Improve this answer
0

Easiest way is to use a for loop:

cd /

for i in proc sys dev; do mount -o bind $i /folder/$i; done
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .