Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The chroot Technique – a Swiss army multitool for Linux systems

livesys.se

Post reply on HN
Print view View original

81–90 of 123 posts

Re: The chroot Technique – a Swiss army multitool for Linux systems

#81

Post by seba_dos1 »

benou wrote: post #74
thatcherc wrote: post #67

Earlier quoted context omitted.

> you can even chroot into foreign CPU architectures, which is a handy thing to have when you mount your phone's eMMC This sounds very interesting! What's the scenario where you'd do this? Would you be, for example, emulating an ARM processor with qemu on an x86 computer and chrooting into Android on an eMMC?

Here is an example of preparing a debian ARM image on x86 with debootstrap, qemu and chroot: ~# sudo apt install qemu-user-static debootstrap ~# mkdir /tmp/arm ~# debootstrap --foreign --arch=armhf buster /tmp/arm http://deb.debian.org/debian ~# cp /usr/bin/qemu-arm-static /tmp/arm/usr/bin/ ~# chroot /tmp/arm # from that point, you're running ARM! ~# /debootstrap/debootstrap --second-stage

These days (with recent kernels) you don't even have to copy the qemu binary into the rootfs nor use a static binary - these used to be workarounds for things that kernel now handles on its own.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#83

Post by immibis »

aussieguy1234 wrote: post #82

What we all know as Docker and containers is really just fancy chroot. On non Linux systems, it's fancy chroot inside a Linux VM.

Which raises the question of why they need chroot if they have the VM.

Another semi-related but equally odd view: Docker is an operating system and containers are processes.

The difference between Docker and chroot, by the way, is that Docker does a bunch more system calls to ch the root of several other things that are not the filesystem. It also sets up things inside those roots for you by default, so your containers can access the internet, for example.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#84

Post by immibis »

sgt wrote: post #56
whalesalad wrote: post #53

This is why Linux and Unix are so awesome. It’s really all just files.

Not really, but yes there's a lot of files or things that seem to be files. Try plan9 though.

If you want to blow your mind in what's possible in operating-system isolation read about KeyKOS from 1985: https://css.csail.mit.edu/6.858/2014/readings/keykos.pdf

Such systems are rarely very pragmatic, but do show off a bunch of weird concepts.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#85

Post by PaulDavisThe1st »

alphazard wrote: post #65
kccqzy wrote: post #46

Earlier quoted context omitted.

> a read only root with nothing in it A lot of things break if there's no /proc/self. A lot more things break if the terminfo database is absent. More things break if there's no timezone database. Finally, almost everything breaks if the root file system has no libc.so.6. When you write Dockerfiles, you can easily do it FROM scratch. You can then easily observe whether the thing you are sandboxing actually works. > n…

The modern statically linked languages (I'm thinking of Go and Zig specifically) increasingly need less and less of the cruft you mentioned. Hopefully, that trend continues. > no users I mean running as root. I think all processes on Linux have to have a user id. Anything inside a sandbox should start with all the permissions for that environment. If the sandbox process wants to muck around with the users/groups auth…

The things that break in C if /proc/self or the terminfo DB are missing will break in Go and Zig too.

What I think you might mean is something like: "in modern statically linked applications written with languages like Go and Zig, it is much less likely for the them to call on OS services that require these sorts of resources".

Re: The chroot Technique – a Swiss army multitool for Linux systems

#86

Post by ndsipa_pomu »

Used this or at least a very similar technique a few times to fix boot issues.

I've got a version of the mounting command that I think is easier to use:

  for f in proc sys dev run dev/pts ; do mount --bind /$f /mnt/$f ; done
Change the "/mnt/$f" to whatever mountpoint that you're using which would be "/rescue/$f" to align with TFA.

I don't know what difference it makes to have /run mounted, but once you chroot into the mountpoint you can mount the boot partition etc and run whatever grub or mkinitramfs command you need to fix stuff.

I would leave the /boot mounting to later in the process - after you chroot. This way you can easily check /etc/fstab for where the boot partition lives (or if there is one), so you only need to locate the root partition initially which is generally easy to figure out from the disk sizes.

There's extra steps needed however if the system uses LVM.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#88

Post by gerdesj »

jimmaswell wrote: post #78
woleium wrote: post #70

Earlier quoted context omitted.

System Rescue is what i use these days, but to be honest i can’t recall using it in the last couple of year. Virtualization and containers have taken over. https://www.system-rescue.org/

I use my Gentoo installation usb when this comes up

System Rescue used to be Gentoo based and then switched to Arch. You can install both Arch and Gentoo with SR and obviously you can install Arch with a Gentoo install CD and vice versa.

SR also has some rather handy SAM database editing facilities. Mount Windows at /mnt and then enable and reset the Administrator password. Jolly handy for getting super duper user access on a Windows box.

Its been a while since I installed Gentoo but you can probably quite easily add more stuff to your Gentoo install CD. I don't know if Gentoo have added a script to do all the bind mounts but "arch-chroot /bin/bash" is very convenient. I used to forget about /sys.

Re: The chroot Technique – a Swiss army multitool for Linux systems

#89

Post by slicktux »

adrian_b wrote: post #51
slicktux wrote: post #29

Earlier quoted context omitted.

I remember first installing Gentoo…printed the whole manual and followed along. After a failed attempt and second successful install I learned enough to know that I could use a LiveUSB of my choosing and chroot into the install. Good times!

On Gentoo, it is also simple to install a completely new system in a chroot environment, even if it is intended for a computer with a different, but compatible architecture. This is frequently very convenient if you want to install Gentoo by compiling everything from sources on a cheap and small computer, e.g. one with some Intel Atom CPU. Instead of compiling anything on the resource-constrained computer, you instal…

Yes, there’s a few gentoo developers and bug hunters that do exactly that but to find bugs and test updates 8D!

Re: The chroot Technique – a Swiss army multitool for Linux systems

#90

Post by aussieguy1234 »

immibis wrote: post #83
aussieguy1234 wrote: post #82

What we all know as Docker and containers is really just fancy chroot. On non Linux systems, it's fancy chroot inside a Linux VM.

Which raises the question of why they need chroot if they have the VM. Another semi-related but equally odd view: Docker is an operating system and containers are processes. The difference between Docker and chroot, by the way, is that Docker does a bunch more system calls to ch the root of several other things that are not the filesystem. It also sets up things inside those roots for you by default, so your containe…

I found this project to be an interesting POC of how it all actually works.

https://github.com/p8952/bocker

Basically, it runs docker containers using chroot to prove that it's possible.

Docker uses Layered Filesystems (Multiple Filesystems mounted under the same folder on top of one another), something that used to be mostly used when you have a read only Filesystem, like a cdrom, then mount a writeable folder over the same mount point to make that folder writeable.

Bocker does a similar mounting of the layers with chroot to run docker containers.

Post reply on HN