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<file>
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.
> :-)
:-)