Chroot: Difference between revisions
Dubiousjim (talk | contribs) (Add some content) |
Dubiousjim (talk | contribs) (Some cleanup) |
||
Line 10: | Line 10: | ||
* resetting a forgotten password | * resetting a forgotten password | ||
Chrooting can also be used to create and host a separate virtualized installation of | Chrooting can also be used to create and host a separate virtualized installation of a system. This can be useful for: | ||
* Testing and development, with software that's too risky to deploy on a production system. | * Testing and development, with software that's too risky to deploy on a production system. | ||
* Software can be developed, built and tested in a chroot populated only with its expected dependencies. | * Software can be developed, built and tested in a chroot populated only with its expected dependencies. | ||
* Can run legacy software or other software whose supporting libraries or data files can't be installed in the host system. | * Can run legacy software or other software whose supporting libraries or data files can't be installed in the host system. | ||
* | * Open file descriptors (for files, pipelines and network connections) can be "carried into" the chroot by running programs, making it unnecessary for those programs' working files to be visible inside the chroot directory. This can help separate privileges or design sandboxes. Note that chroot is not a secure way to contain a hostile process with root privileges. See Wikipedia's [https://en.wikipedia.org/wiki/Chroot#Limitations discussion of some of chroot's limits]. | ||
Here are some other resources: | Here are some other resources: | ||
Line 27: | Line 27: | ||
== Preparation == | == Preparation == | ||
<ul> | |||
<li>All the steps in this guide will have to be performed as root user. | |||
<li>If you are using chroot to repair an existing Linux system, it will need to be mounted first. If you don't know the location and/or filetype of the disk(s) where it resides, read the output of <code>fdisk -l</code> or <code>lsblk</code>. We will suppose the broken system is at {{Path|/dev/sdx1}} and its filetype is ext3. Create a directory for mounting this disk, and mount it: | |||
{{Cmd|mkdir -p $CHROOT<br>mount -t ext3 /dev/sdx1 $CHROOT}} | {{Cmd|mkdir -p $CHROOT<br>mount -t ext3 /dev/sdx1 $CHROOT}} | ||
where <code>$CHROOT</code> | where <code>$CHROOT</code> evaluates to the path you want to chroot into (for example, {{Path|/mnt}}). | ||
If the system directory is encrypted or in a LVM group or anything like that, we'll leave it to you to figure out what steps to take to prepare it and mount it. | |||
<li>If there are separate filesystems for other directories (such as {{Path|/boot}}, {{Path|/var}}, {{Path|/usr}}, {{Path|/home}}), mount them too: | |||
{{Cmd|mount /dev/sdx2 $CHROOT/boot<br>mount /dev/sdx3 $CHROOT/var<br>mount /dev/sdx4 $CHROOT/usr}} | {{Cmd|mount /dev/sdx2 $CHROOT/boot<br>mount /dev/sdx3 $CHROOT/var<br>mount /dev/sdx4 $CHROOT/usr}} | ||
For many repair tasks, you may not need to mount the broken system's {{Path|/home}} directory. If you do have {{Path|/boot}} on a separate partition, it's essential to have it mounted before working with GRUB, performing a kernel upgrade, or anything of that sort. It's also possible to mount some of these filesystems ''after'' you've chrooted, and in some cases mounting {{Path|/boot} in particular after chrooting has worked better with GRUB. If you can, though, it's smarter to mount these beforehand. The reason is that if you do it from inside the chroot, the outside/host environment won't know about the mounted filesystems, so if you forget to umount them before exiting the chroot, the system won't know to umount them when it shuts down, either. That could damage those filesystems. | For many repair tasks, you may not need to mount the broken system's {{Path|/home}} directory. | ||
If you do have {{Path|/boot}} on a separate partition, it's essential to have it mounted before working with GRUB, performing a kernel upgrade, or anything of that sort. It's also possible to mount some of these filesystems ''after'' you've chrooted, and in some cases mounting {{Path|/boot}} in particular after chrooting has worked better with GRUB. If you can, though, it's smarter to mount these beforehand. The reason is that if you do it from inside the chroot, the outside/host environment won't know about the mounted filesystems, so if you forget to umount them before exiting the chroot, the system won't know to umount them when it shuts down, either. That could damage those filesystems. | |||
<li>The script presented below will take care of generating or remounting other system directories like {{Path|/dev}}, {{Path|/proc}}, {{Path|/sys}}, {{Path|/tmp}} and so on. | |||
<li>The architecture of the host system you're booted into (e.g., if it's a 32bit LiveCD, that's x86) and the system you want to chroot into must match. You can determine what architecture you're booted into using <code>uname -m</code>. | |||
<li>Before chrooting, be sure any kernel modules you'll need when working inside the chroot have been loaded. For example: | |||
{{Cmd|modprobe dm-mod<br>modprobe dm-crypt}} | {{Cmd|modprobe dm-mod<br>modprobe dm-crypt}} | ||
<li>Set up your network if you'll need it inside the chroot, e.g., to install updated packages. The script presented below will copy the {{Path|/etc/resolv.conf}} from the host system, but will prompt before overwriting an existing {{Path|etc/resolv.conf}} inside the chroot. If you like, you can generate one from scratch by doing: | |||
{{Cmd|echo 'nameserver 8.8.8.8' > $CHROOT/etc/resolv.conf}} | {{Cmd|echo 'nameserver 8.8.8.8' > $CHROOT/etc/resolv.conf}} | ||
<li>If your host system is Alpine or another distribution (like Hardened Gentoo) that uses the grsecurity kernel patches, for some maintenance tasks you'll want to make sure some of the grescurity prohibitions are disabled. For example: | |||
{{Cmd|sysctl -w kernel.grsecurity.chroot_deny_chmod{{=}}0 # | {{Cmd|sysctl -w kernel.grsecurity.chroot_deny_chmod{{=}}0 # enable suid/sgid<br>sysctl -w kernel.grsecurity.chroot_deny_mknod{{=}}0<br>sysctl -w kernel.grsecurity.chroot_deny_mount{{=}}0<br>sysctl -p}} | ||
For more info, see: | For more info, see: | ||
* http://en.wikibooks.org/wiki/Grsecurity | |||
* http://www.gentoo.org/proj/en/hardened/grsecurity.xml | |||
</ul> | |||
== Performing the chroot == | == Performing the chroot == | ||
Line 98: | Line 106: | ||
</nowiki>}} | </nowiki>}} | ||
Copy that script to some location on your system, such as {{Path|/root/start-chroot}}, run | Copy that script to some location on your system, such as {{Path|/root/start-chroot}}, run <code>chmod +x</code> on it, and then invoke it as: {{Cmd|/root/start-chroot $CHROOT}}, where <code>$CHROOT</code> evaluates to the path you want to chroot into (for example, {{Path|/mnt}}). | ||
'''Comment on Environment variables, extra arguments to start-chroot.''' | '''Comment on Environment variables, extra arguments to start-chroot.''' |
Revision as of 23:53, 20 January 2015
This material is work-in-progress ... Do not follow instructions here until this notice is removed. |
"Changing root" or "chrooting" is a method for zooming in on part of your filesystem, so that, for example, /path will refer to what was formerly accessible at /mnt/path. The "root" in the expression "chroot" refers to the root filesystem /, not to the root user. (Though typically you will need root user privileges in order to chroot.)
A common reason for chrooting is to perform maintenance on existing systems where booting and/or logging in no longer works. One has to boot the hardware somehow, such as with an Installation or Rescue CD or USB; then one mounts the broken system and chroots into it and performs the repairs. Common examples are:
- reinstalling the bootloader
- rebuilding the initramfs image
- upgrading or downgrading packages
- resetting a forgotten password
Chrooting can also be used to create and host a separate virtualized installation of a system. This can be useful for:
- Testing and development, with software that's too risky to deploy on a production system.
- Software can be developed, built and tested in a chroot populated only with its expected dependencies.
- Can run legacy software or other software whose supporting libraries or data files can't be installed in the host system.
- Open file descriptors (for files, pipelines and network connections) can be "carried into" the chroot by running programs, making it unnecessary for those programs' working files to be visible inside the chroot directory. This can help separate privileges or design sandboxes. Note that chroot is not a secure way to contain a hostile process with root privileges. See Wikipedia's discussion of some of chroot's limits.
Here are some other resources:
- What's the proper way to prepare chroot to recover a broken Linux installation?
- ArchLinux wiki on "Change Root"
- ArchLinux Wiki on "Reinstalling GRUB"
- Gentoo Wiki on "Chroot from a livecd"
- Ubuntu wiki on "Basic chroot"
Preparation
- All the steps in this guide will have to be performed as root user.
- If you are using chroot to repair an existing Linux system, it will need to be mounted first. If you don't know the location and/or filetype of the disk(s) where it resides, read the output of
fdisk -l
orlsblk
. We will suppose the broken system is at /dev/sdx1 and its filetype is ext3. Create a directory for mounting this disk, and mount it:mkdir -p $CHROOT
mount -t ext3 /dev/sdx1 $CHROOTwhere
$CHROOT
evaluates to the path you want to chroot into (for example, /mnt).If the system directory is encrypted or in a LVM group or anything like that, we'll leave it to you to figure out what steps to take to prepare it and mount it.
- If there are separate filesystems for other directories (such as /boot, /var, /usr, /home), mount them too:
mount /dev/sdx2 $CHROOT/boot
mount /dev/sdx3 $CHROOT/var
mount /dev/sdx4 $CHROOT/usrFor many repair tasks, you may not need to mount the broken system's /home directory.
If you do have /boot on a separate partition, it's essential to have it mounted before working with GRUB, performing a kernel upgrade, or anything of that sort. It's also possible to mount some of these filesystems after you've chrooted, and in some cases mounting /boot in particular after chrooting has worked better with GRUB. If you can, though, it's smarter to mount these beforehand. The reason is that if you do it from inside the chroot, the outside/host environment won't know about the mounted filesystems, so if you forget to umount them before exiting the chroot, the system won't know to umount them when it shuts down, either. That could damage those filesystems.
- The script presented below will take care of generating or remounting other system directories like /dev, /proc, /sys, /tmp and so on.
- The architecture of the host system you're booted into (e.g., if it's a 32bit LiveCD, that's x86) and the system you want to chroot into must match. You can determine what architecture you're booted into using
uname -m
. - Before chrooting, be sure any kernel modules you'll need when working inside the chroot have been loaded. For example:
modprobe dm-mod
modprobe dm-crypt - Set up your network if you'll need it inside the chroot, e.g., to install updated packages. The script presented below will copy the /etc/resolv.conf from the host system, but will prompt before overwriting an existing etc/resolv.conf inside the chroot. If you like, you can generate one from scratch by doing:
echo 'nameserver 8.8.8.8' > $CHROOT/etc/resolv.conf
- If your host system is Alpine or another distribution (like Hardened Gentoo) that uses the grsecurity kernel patches, for some maintenance tasks you'll want to make sure some of the grescurity prohibitions are disabled. For example:
sysctl -w kernel.grsecurity.chroot_deny_chmod=0 # enable suid/sgid
sysctl -w kernel.grsecurity.chroot_deny_mknod=0
sysctl -w kernel.grsecurity.chroot_deny_mount=0
sysctl -pFor more info, see:
Performing the chroot
The most reliable way to chroot is to use the following script:
Contents of /root/start-chroot
Copy that script to some location on your system, such as /root/start-chroot, run chmod +x
on it, and then invoke it as:
/root/start-chroot $CHROOT
, where $CHROOT
evaluates to the path you want to chroot into (for example, /mnt).
Comment on Environment variables, extra arguments to start-chroot.
It is certainly possible to perform a chroot by hand, without using this script. For some purposes, you can get away with a simpler procedure than the script follows. But it's hard to catalogue in advance when taking shortcuts will get you in trouble, so it's best to just get in the habit of using this script (or doing the same things it does). As you read around in various wikis (perhaps including this one), you will encounter a variety of instructions for how to chroot by hand. These instructions often differ in small details from each other and are usually not as thorough as the above script.
Inside the chroot
Now that you're inside the chroot, you can perform whatever troubleshooting you need to do:
- resintall GRUB to your disk's MBR
- reset a forgotten password
- perform a kernel upgrade (or downgrade)
- rebuild your initramdisk
- fix your /etc/fstab
- reinstall packages using your package manager
- whatever
If you have multiple terminals open on or connected to the running system, the chroot will only be effective in the terminal that you performed it in.