I want to set up Grub menu entry to boot into chrooted system (installed chrooted debootstrap to avoid touching existing system too much).

Currently I do the following to attain it:

  1. Install linux-image and friends inside chrooted environment

  2. Manually remaster initramfs to chroot into the system instead of usual behaviour:

#exec run-init ${rootmnt} ${init} "$@" <${rootmnt}/dev/console >${rootmnt}/dev/console
exec chroot ${rootmnt} ${init} "$@"  <${rootmnt}/dev/console >${rootmnt}/dev/console

3.. Add entry to /boot/grub.cfg:

menuentry 'Chrooted debian Squeeze' {
    linux   /root/squeeze/boot/vmlinuz root=... rw
    initrd  /root/squeeze/boot/initrd-chroot

It works but not easy to set up and needs manual hacking every time initrd should be changed. How to do it better?


I came across the same issue and ended up writing this to make it work painlessly across different systems (debian, ubuntu currently):

Run make_chroot_initrd script to create a new chroot-enabled initrd image from the existing one:

#  ./make_chroot_initrd /chroot/trusty/boot/initrd.img-3.13.0-32-generic
making new initrd: /chroot/trusty/boot/initrd.img-3.13.0-32-generic.chroot

The new image will be exactly the same, except now it can handle a chroot= boot parameter.

With grub2 as bootloader you can add an entry to /boot/grub/grub.cfg:
(or perhaps better /etc/grub.d/40_custom)

menuentry "ubuntu trusty, (linux 3.13.0-32) (chroot)" {
    insmod ext2                       # or whatever you're using ...
    set root='(hd0,7)'                # partition containing the chroot
    set chroot='/chroot/trusty'       # chroot path
    linux   $chroot/boot/vmlinuz-3.13.0-32-generic root=/dev/sda7 chroot=$chroot rw
    initrd  $chroot/boot/initrd.img-3.13.0-32-generic.chroot

(change files/partitions to match yours)

System-wide install

Once you're happy with it you can make the changes permanent
(until initramfs-tools package gets upgraded).
In the chrooted system:

# cd /usr/share/initramfs-tools
# cp -pdrv .  ../initramfs-tools.orig       # backup
# patch -p1 < path_to/boot_chroot/initrd.patch
# rm *.orig */*.orig
# update-initramfs -u

From now on regular initrd image will support chroot booting.
No need to use a separate initrd.chroot which may get out of sync with it then.

See boot_chroot for details.

| improve this answer | |

Why did you switch from run-init to chroot? You shouldn't do that. run-init deletes everything in the initramfs root, then chroots to $rootmnt. You want to keep that behavior.

As for how to avoid having to manually rebuild your initramfs each time, edit the master copy of the init script in /usr/share/initramfs-tools. That should at least work until you upgrade the initramfs-tools package.

A permanent solution would be to patch the init script to recognize a boot argument to append something to rootmnt, and submit that patch for inclusion into debian. Then you can add the argument to grub for entries that should be booted that way.

| improve this answer | |
  • "Why ..." -> Because of it failed (don't remember how exactly) until I simplified it that way. – Vi. Jan 31 '12 at 18:56
  • So there is no existing solution like "apt-get install initrd-chroot" that is designed for such installations. – Vi. Jan 31 '12 at 18:57
  • Ahh, then instead of adding the path to rootmnt, try changing the init variable to run chroot after run-init: init=chroot /root/squeeze ${init}. – psusi Jan 31 '12 at 19:02
  • Then it will mount -n -o move /sys ${rootmnt}/sys and friends will not do what they should... – Vi. Jan 31 '12 at 19:10
  • Tried with fixed mount -o moves and with init=/usr/sbin/chroot /root/squeeze /sbin/init and updated /dev/console redirections. It booted, but somehow weird. Complaining abount /dev, "INIT: Id "5" respawning too fast" and booted slower than usual. – Vi. Jan 31 '12 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.