Well, it a file system, much like any other one. You can format a disk partition with it, and put files, read files, etc... It is quite new also, compared to f.e. ext2, or FAT32. The gotcha is: it knows much more, than just keeping files on disk. Elsewhere you can read a lot about it, but in a nutshell:
- You can create snapshots of your filesystem
- You can make software raid easily, on the the fly
- You can ship snapshots, and even differential snapshot from one machine to another
I especially love the snapshot, and snapshot shipping feature of it. If you think about it: it makes life much easier in several ways. During making a system wide backup, moving to an other machine, using to chroot into it, update it, restoring it in case something goes wrong... etc.
I found it particularly useful BTRFS in the Qemu scenario, since I was able to copy the ready system to the actual hardware, and also send changes back under Qemu, to do more install work on it (which means compiling).
Apart from being an awesome distro, Gentoo has a nice feature: you can actually build binary packages (yourself). This makes installation much faster on slower machines. For that, I used NFS to share ready built packages from Qemu host system to the PWS, and also distfiles, and the whole portage.
First gotcha: sharing the binary packages over a read-write manner (f.e. over nfs) is a must, since as we will see, there are packages, which can only be built on the real hardware itself. However, they are dependencies for other packages, so even the build machine needs binary packages from time to time, to be able to proceed with other builds.
What I also like about Gentoo, is it's great documentation. I used mainly this article to set up user mode qemu system. A very quick overview on what you can achieve with it: make your system recognize Alpha CPU targeted binary files, and use user mode qemu to translate it to x86 instructions in real time. And you do it, in a chroot environment, which is practically the way, how you install Gentoo to a new system. Nice, and sound! :) So I chrooted into an Alpha stage3 filesystem, carefully created on a BTRFS subvolume (to make it easily portable later on), and... almost nothing worked. Actually bash worked, so at least I had a command line, running on virtual Alpha CPU.
Second gotcha: on all sites, the bin format misc magic header's mask is incorrect. You have to modify to this one:
# echo ':alpha:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x02\x00\x26\x90:\xff\xff\xff\xff\xff\xfe
\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:
/bin/qemu-alpha:' > /proc/sys/fs/binfmt_misc/register
Do you see the red bold part, it is originally FF everywhere I saw. Without it, more modern linux elfs are not working, only SYSV compatible ones. An other hard to find hint: if you
if you echo /proc/sys/fs/binfmt_misc/status, 1= enable, 0=disable, -1=clear
The last one is not very much documented anywhere, however if you need to give a new path, you can now clear the binfmt_misc registrations to make it happen.
Third gotcha: Gentoo uses python a lot, since it's packaging system is written in it. It also has at least two different version of it on every system as of now: v2.7 & 3.6. The v3.6 throws exceptions all around, so building is not working. However if you eselect python set
Fourth gotcha: emerge is getting more and more secure. It drops privileges while compiles, creates sandbox, network sandbox, stc around the compiling and installing process. However, there is still some missing functions in qemu (v4.1) kernel bridge, which prevents to use such things, so you have to add to your /etc/portage/make.conf some FEATURE definitions:
FEATURES="-sandbox -pid-sandbox -network-sandbox -ipc-sandbox"Actually this disables some feature. Removing those features, starts to work! And you can build binary packages, to make it later available for your native hardware.
Fifth gotcha: if you compile in the chroot big packages, like gcc, kernel, etc, you should set in the shell before chrooting into it:
# ulimit -n 15000Not to get such errors, like "too many open files"... when only just a little would have needed to complet the many hours package compile.
Sixth gotcha: anything, that is dependent on cmake, or cmake itself, fails to compile with Illegal Instruction. There must be some bug in qemu. Actually I found some other programs causing unexpected errors, like subversion client, which segmentation faults, but unlike cmake, it is not required to build packages. To still make building happen: you have to build cmake dependent packages on your native machine. Fortunately, with the help of equery command it is quite easy to collect those packages which are directly dependent on cmake. I even wrote a script, which creates a @cmake set for me, to be able to issue such command on the native machine:
# emerge --update --newuse --oneshot --buildpkgonly @cmake
Which builds/updates only the cmake dependent packages, doesn't install those yet (since could cause conflicts), but creates a binary package out of those. On the qemu system, when I update @world, those will be install from binary, et vois la! emerge dependecy graph is satisfied. Later, when all builds are ready, the native system just need to install binary packages. Actually, this is why nfs is a good idea to store/share binary packages between host (I use kerberized NFS4 with integrity check).
