From: gtaylor@tnetconsulting.net   
      
   On 12/15/23 08:22, Lew Pitcher wrote:   
   > Long ago, I settled on a system recovery process that involved booting   
   > from a Slackware "live" install disk, and using chroot to gain root fs   
   > access to my hard disks.   
      
   N.B. chroot isn't required to access the files on the system being   
   rescued from the rescue media.   
      
   Simply mounting the file system somewhere and then `cd`ing to it is   
   sufficient to access the files.   
      
   `chroot`ing gives a different type of access that seems much more like   
   the system being recovered normally has.  At least from a file path   
   perspective.   
      
   > I've used this on and off over the last 20 years. It never occurred to   
   > me that such a chroot()ed environment might also require bind mounts   
   > to fix up /proc, /sys, and especially /dev.  In my experience, I've   
   > never needed to do so.   
      
      
   It's not that chroot needs the bind mount.  It is that things used   
   inside the chroot (and maybe the chroot process itself) need access to   
   specific files inside of /dev in the chroot.   
      
   Those files can easily be provided by static files or even another devfs   
   (like) mount.   
      
   It's just that it's often viewed as easiest to inherit the files from   
   the real /dev inside of the chroot via a bind mount.   
      
   > /proc and /sys are simple: for most things, you don't need them in the   
   > chrooted environment. Or, perhaps, you only need them when something   
   > /explicitly/ references /proc or /sys; implicit references, such as   
   > mount() calls, work because the overall system still supplies a   
   > referencible source, under the covers.   
      
   Yep.   
      
   I've gotten away with `chroot`ing many times without anything in /proc   
   or /sys in the chroot.  It is highly dependent on what you are wanting   
   to do inside of the chroot.   
      
   > But /dev is a different kettle of fish. You need the files in /dev   
   > in your chroot()ed environment in order to run lilo (or any other   
   > boot-loader setup tool).   
      
   Yep.  You need the contents.  How the contents get there / are created   
   doesn't matter as long as things can find needed files at the dev   
   name that they are expecting.   
      
   I'm I-remember-using-mknod-in-dev-to-get-new-hardware-to-work old.   
      
   > In my recovery process, I've never had to bind mount /dev before   
   > chrooting. And, with your post, I started to wonder why.   
      
   For a very long time Slackware had (enough) static files in dev to bring   
   a system up to single user mode.  For much of it's history it was all   
   static files in dev.  I don't know Slackware's current state about files   
   in dev.   
      
   > I've come to the conclusion that, because of my upgrade process,   
   > I've got a pre-populated /dev that udev then mounts it's tmpfs   
   > over top of.   
      
   That seems reasonable to me.   
      
   > When I installed my first systems, a requisite package (in 14.1, it   
   > is devs-2.3.1-noarch-25.txz) contains both static /dev entries, and a   
   > script to recreate those entries. My upgrade process has carried this   
   > (hidden by udev) /dev directory forward all these years, giving me   
   > a prepopulated /static/ /dev directory when I chroot from the "live   
   > media" boot.   
      
   Yep.   
      
   > And, that solves that quandry.   
   > :-)   
      
   :-)   
      
      
      
   --   
   Grant. . . .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)