mount dev, proc, sys in a chroot environment?












76














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?










share|improve this question















migrated from stackoverflow.com Jul 19 '10 at 0:35


This question came from our site for professional and enthusiast programmers.















  • 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
    Jul 18 '10 at 19:18






  • 2




    @Jonathan Leffler: that doesn't sound like an issue for what he is doing.
    – Zifre
    Jul 19 '10 at 1:02










  • @JonathanLeffler a root user in a chroot can always escape the chroot anyway.
    – LtWorf
    May 10 '16 at 11:41
















76














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?










share|improve this question















migrated from stackoverflow.com Jul 19 '10 at 0:35


This question came from our site for professional and enthusiast programmers.















  • 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
    Jul 18 '10 at 19:18






  • 2




    @Jonathan Leffler: that doesn't sound like an issue for what he is doing.
    – Zifre
    Jul 19 '10 at 1:02










  • @JonathanLeffler a root user in a chroot can always escape the chroot anyway.
    – LtWorf
    May 10 '16 at 11:41














76












76








76


48





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?










share|improve this question















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?







linux debian chroot






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 11 '14 at 17:30









Pro Backup

3271622




3271622










asked Jul 18 '10 at 19:06









Patrick

7402920




7402920




migrated from stackoverflow.com Jul 19 '10 at 0:35


This question came from our site for professional and enthusiast programmers.






migrated from stackoverflow.com Jul 19 '10 at 0:35


This question came from our site for professional and enthusiast programmers.














  • 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
    Jul 18 '10 at 19:18






  • 2




    @Jonathan Leffler: that doesn't sound like an issue for what he is doing.
    – Zifre
    Jul 19 '10 at 1:02










  • @JonathanLeffler a root user in a chroot can always escape the chroot anyway.
    – LtWorf
    May 10 '16 at 11:41


















  • 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
    Jul 18 '10 at 19:18






  • 2




    @Jonathan Leffler: that doesn't sound like an issue for what he is doing.
    – Zifre
    Jul 19 '10 at 1:02










  • @JonathanLeffler a root user in a chroot can always escape the chroot anyway.
    – LtWorf
    May 10 '16 at 11:41
















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
Jul 18 '10 at 19:18




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
Jul 18 '10 at 19:18




2




2




@Jonathan Leffler: that doesn't sound like an issue for what he is doing.
– Zifre
Jul 19 '10 at 1:02




@Jonathan Leffler: that doesn't sound like an issue for what he is doing.
– Zifre
Jul 19 '10 at 1:02












@JonathanLeffler a root user in a chroot can always escape the chroot anyway.
– LtWorf
May 10 '16 at 11:41




@JonathanLeffler a root user in a chroot can always escape the chroot anyway.
– LtWorf
May 10 '16 at 11:41










5 Answers
5






active

oldest

votes


















42














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.






share|improve this answer





















  • 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
    Mar 30 '17 at 9:08












  • @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
    – Jonas
    May 23 '17 at 15:37










  • Maybe the sys type of file system appears (today) to not exist anymore?
    – uprego
    Apr 25 at 11:36



















95














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 -t sysfs sys sys/
mount -o bind /dev dev/


I can confirm they worked for me.






share|improve this answer



















  • 2




    They also seemed to work for me in ubuntu.
    – isaaclw
    Sep 28 '12 at 21:01






  • 3




    In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
    – Thomas
    May 30 '16 at 8:42










  • Please include the link to the source.
    – styrofoam fly
    Dec 4 at 18:34










  • @styrofoamfly Added.
    – gacrux
    Dec 5 at 19:45



















9














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





share|improve this answer

















  • 17




    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
    Jul 19 '10 at 0:31










  • They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
    – AzP
    Oct 3 at 22:53



















0














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






share|improve this answer































    -1














    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.






    share|improve this answer























    • 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.
      Mar 9 '16 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
      Mar 31 '16 at 12:43










    • 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é
      Dec 11 '16 at 18:58













    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f165116%2fmount-dev-proc-sys-in-a-chroot-environment%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    42














    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.






    share|improve this answer





















    • 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
      Mar 30 '17 at 9:08












    • @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
      – Jonas
      May 23 '17 at 15:37










    • Maybe the sys type of file system appears (today) to not exist anymore?
      – uprego
      Apr 25 at 11:36
















    42














    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.






    share|improve this answer





















    • 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
      Mar 30 '17 at 9:08












    • @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
      – Jonas
      May 23 '17 at 15:37










    • Maybe the sys type of file system appears (today) to not exist anymore?
      – uprego
      Apr 25 at 11:36














    42












    42








    42






    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.






    share|improve this answer












    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jul 19 '10 at 1:02









    Zifre

    1,15521326




    1,15521326












    • 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
      Mar 30 '17 at 9:08












    • @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
      – Jonas
      May 23 '17 at 15:37










    • Maybe the sys type of file system appears (today) to not exist anymore?
      – uprego
      Apr 25 at 11:36


















    • 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
      Mar 30 '17 at 9:08












    • @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
      – Jonas
      May 23 '17 at 15:37










    • Maybe the sys type of file system appears (today) to not exist anymore?
      – uprego
      Apr 25 at 11:36
















    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
    Mar 30 '17 at 9:08






    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
    Mar 30 '17 at 9:08














    @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
    – Jonas
    May 23 '17 at 15:37




    @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
    – Jonas
    May 23 '17 at 15:37












    Maybe the sys type of file system appears (today) to not exist anymore?
    – uprego
    Apr 25 at 11:36




    Maybe the sys type of file system appears (today) to not exist anymore?
    – uprego
    Apr 25 at 11:36













    95














    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 -t sysfs sys sys/
    mount -o bind /dev dev/


    I can confirm they worked for me.






    share|improve this answer



















    • 2




      They also seemed to work for me in ubuntu.
      – isaaclw
      Sep 28 '12 at 21:01






    • 3




      In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
      – Thomas
      May 30 '16 at 8:42










    • Please include the link to the source.
      – styrofoam fly
      Dec 4 at 18:34










    • @styrofoamfly Added.
      – gacrux
      Dec 5 at 19:45
















    95














    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 -t sysfs sys sys/
    mount -o bind /dev dev/


    I can confirm they worked for me.






    share|improve this answer



















    • 2




      They also seemed to work for me in ubuntu.
      – isaaclw
      Sep 28 '12 at 21:01






    • 3




      In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
      – Thomas
      May 30 '16 at 8:42










    • Please include the link to the source.
      – styrofoam fly
      Dec 4 at 18:34










    • @styrofoamfly Added.
      – gacrux
      Dec 5 at 19:45














    95












    95








    95






    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 -t sysfs sys sys/
    mount -o bind /dev dev/


    I can confirm they worked for me.






    share|improve this answer














    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 -t sysfs sys sys/
    mount -o bind /dev dev/


    I can confirm they worked for me.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 5 at 19:41

























    answered Apr 26 '12 at 6:10









    gacrux

    1,27611211




    1,27611211








    • 2




      They also seemed to work for me in ubuntu.
      – isaaclw
      Sep 28 '12 at 21:01






    • 3




      In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
      – Thomas
      May 30 '16 at 8:42










    • Please include the link to the source.
      – styrofoam fly
      Dec 4 at 18:34










    • @styrofoamfly Added.
      – gacrux
      Dec 5 at 19:45














    • 2




      They also seemed to work for me in ubuntu.
      – isaaclw
      Sep 28 '12 at 21:01






    • 3




      In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
      – Thomas
      May 30 '16 at 8:42










    • Please include the link to the source.
      – styrofoam fly
      Dec 4 at 18:34










    • @styrofoamfly Added.
      – gacrux
      Dec 5 at 19:45








    2




    2




    They also seemed to work for me in ubuntu.
    – isaaclw
    Sep 28 '12 at 21:01




    They also seemed to work for me in ubuntu.
    – isaaclw
    Sep 28 '12 at 21:01




    3




    3




    In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
    – Thomas
    May 30 '16 at 8:42




    In my case (also Ubuntu) I needed a "mount -o bind /dev/pts dev/pts", too.
    – Thomas
    May 30 '16 at 8:42












    Please include the link to the source.
    – styrofoam fly
    Dec 4 at 18:34




    Please include the link to the source.
    – styrofoam fly
    Dec 4 at 18:34












    @styrofoamfly Added.
    – gacrux
    Dec 5 at 19:45




    @styrofoamfly Added.
    – gacrux
    Dec 5 at 19:45











    9














    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





    share|improve this answer

















    • 17




      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
      Jul 19 '10 at 0:31










    • They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
      – AzP
      Oct 3 at 22:53
















    9














    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





    share|improve this answer

















    • 17




      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
      Jul 19 '10 at 0:31










    • They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
      – AzP
      Oct 3 at 22:53














    9












    9








    9






    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





    share|improve this answer












    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






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jul 19 '10 at 0:05









    robert

    1,074710




    1,074710








    • 17




      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
      Jul 19 '10 at 0:31










    • They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
      – AzP
      Oct 3 at 22:53














    • 17




      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
      Jul 19 '10 at 0:31










    • They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
      – AzP
      Oct 3 at 22:53








    17




    17




    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
    Jul 19 '10 at 0:31




    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
    Jul 19 '10 at 0:31












    They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
    – AzP
    Oct 3 at 22:53




    They've added some new ones, based on systemd. Perhaps it's a good idea to add them.
    – AzP
    Oct 3 at 22:53











    0














    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






    share|improve this answer




























      0














      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






      share|improve this answer


























        0












        0








        0






        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






        share|improve this answer














        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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Apr 18 '16 at 10:35









        DavidPostill

        103k25223257




        103k25223257










        answered Apr 17 '16 at 15:36









        y guy

        113




        113























            -1














            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.






            share|improve this answer























            • 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.
              Mar 9 '16 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
              Mar 31 '16 at 12:43










            • 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é
              Dec 11 '16 at 18:58


















            -1














            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.






            share|improve this answer























            • 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.
              Mar 9 '16 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
              Mar 31 '16 at 12:43










            • 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é
              Dec 11 '16 at 18:58
















            -1












            -1








            -1






            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 31 '16 at 12:42

























            answered Oct 15 '12 at 21:06









            Brian Minton

            365410




            365410












            • 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.
              Mar 9 '16 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
              Mar 31 '16 at 12:43










            • 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é
              Dec 11 '16 at 18:58




















            • 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.
              Mar 9 '16 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
              Mar 31 '16 at 12:43










            • 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é
              Dec 11 '16 at 18:58


















            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.
            Mar 9 '16 at 13:05




            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.
            Mar 9 '16 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
            Mar 31 '16 at 12:43




            @SimonB. I've added a link to a mailing list supporting the idea that /sys should not be bind mounted.
            – Brian Minton
            Mar 31 '16 at 12:43












            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é
            Dec 11 '16 at 18:58






            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é
            Dec 11 '16 at 18:58




















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f165116%2fmount-dev-proc-sys-in-a-chroot-environment%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Сан-Квентин

            Алькесар

            Josef Freinademetz