ostree/parallel-debian/README-testing-multiroot.md

81 lines
2.7 KiB
Markdown

Experimenting with multiple roots
---------------------------------
<http://wiki.debian.org/QEMU#Setting_up_a_testing.2BAC8-unstable_system>
Follow the steps for making a disk image, downloading the business
card CD, booting it in QEMU and running through the installer.
Test that the image works after installation too, before you start
modifying things below! Remember to remove the -cdrom and -boot
options from the installation QEMU command.
Modifying the image
-------------------
You now have a disk image in debian.img, and the first partition
should be ext4.
The first thing I did was mount the image, and move almost everythig
(/boot, /var, /etc), except lost+found to a new directory "r0".
$ mkdir /mnt/debian
$ modprobe nbd max_part=8
$ qemu-nbd --connect=/dev/nbd0 debian.qcow
$ mount /dev/nbd0p1 /mnt/debian/
$ cd /mnt/debian
$ mkdir r0
$ DIRS="bin boot dev etc lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var"
$ mv $DIRS r0
Now with it still mounted, we need to move on to the next part -
modifying the initrd.
Then I started hacking on the initrd, making understand how to chroot
to "r0". I ended up with two patches - one to util-linux, and one to
the "init" script in Debian's initrd.
See:
0001-switch_root-Add-subroot-option.patch
0001-Add-support-for-subroot-option.patch
$ git clone --depth=1 git://github.com/karelzak/util-linux.git
$ cd util-linux
$ patch -p1 -i ../0001-switch_root-Add-subroot-option.patch
$ ./autogen.sh; ./configure ; make
Now you have a modified "sys-utils/switch_root" binary. Let's next
patch the initrd and rebuild it:
Make a backup:
$ mkdir initrd
$ cp /mnt/debian/boot/initrd.img-3.0.0-1-amd64{,.orig}
Unpack, and patch:
$ zcat /mnt/debian/boot/initrd.img-3.0.0-1-amd64 | (cd initrd; cpio -d -i -v)
$ (cd initrd && patch -p1 -i ../0001-Add-support-for-subroot-option.patch)
Repack:
$ (cd initrd; find | cpio -o -H newc) | gzip > /mnt/debian/boot/initrd.img-3.0.0-1-amd64.new
$ mv /mnt/debian/boot/initrd.img-3.0.0-1-amd64{.new,}
Running hacktree inside the system
----------------------------------
This means that after booting, every process would be in /r0 -
including any hacktree process. Assuming objects live in say
/objects, we need some way for hacktree to switch things. I think
just chroot breakout would work. This has the advantage the daemon
can continue to use libraries from the active host.
Note there is a self-reference here (as is present in Debian/Fedora
etc.) - the update system would at present be shipped with the system
itself. Should they be independent? That has advantages and
disadvantages. I think we should just try really really hard to avoid
breaking hacktree in updates.