I have ranted on about the purported support for Gentoo in Amazon EC2; I would like to slightly defend Amazon on this matter saying something that some people might find inflammatory but, I think, we should acknowledge if we strive to improve: Gentoo suck as a guest OS! Now that I pointed at the elephant in the room, let me try to qualify and explain this statement, trying to see what we can do about it.
The first obvious problem is that the standard baselayout we ship with has no idea how to work with vservers and other virtualised environments; we have baselayout-vserver, but last I knew it was a bit behind in features. Actually, we have a very good support for guests in baselayout, version 2, based on OpenRC. Indeed one of the features that the new baselayout brought to the mix was supporting out of the box many different VPS implementations (xen, vserver proper, OpenVZ, and, lately, LXC thanks to Andrian). Unfortunately, almost two years after the addition of OpenRC to the tree, and over three and a half years after the introduction of the first alpha of what became the current situation, we still don’t have it stable, although we’re nearing that date, hopefully.
02 Oct 2006; Roy Marples
+baselayout-1.13.0_alpha1.ebuild:
First alpha cut from the 1.13 branch with BSD and VServer support.
svcdir is now forced – you cannot change it’s location.
If you downgrade back to 1.12 you’ll have to copy /lib/rcscripts/init.d
to your svcdir (/var/lib/init.d by default) and run depscan.sh -u
Even discounting this problem (I actually use OpenRC on all my production systems, and never, or almost never, got problems with that), there are still problems with a number of scripts and configurations that assume presence or work of various real-hardware components that (obviously) we don’t have.
For instance, take the default syslog-ng configuration: it uses the /dev/tty12 device for logging… it doesn’t check whether the device exists before opening it for write, and the end result is that it can create a standard file with the log printed on it if you don’t remember to disable it after install (yes I noticed this just the other day after months of having the vservers running, shame on me!). On the other hand, metalog (which requires an option to run in vservers, since it will fail to start if it cannot access the kernel, and it obviously cannot do that within a vserver — and only the currently-unstable version has the option to do that) uses /dev/tty10 by the default configuration… just to show that we can’t even agree on the devices to use!
And of course there is the one big issue: our system set is too big! This means we end up bringing in a lot of stuff that is definitely not useful on vservers by default (like the kernel sources) just because we need them for the default case of real hardware. I guess one solution here would be to reduce the system set and then use the additional sets available in Portage 2.2 to handle the real-hardware cases (in the default stage… and from that an emerge -C &x40;hwboot would give you a virtualizable-system)… but alas that’s something that never got enough momentum to become reality.
In general, though, Gentoo could become a much better OS to work as guest… we should all try to work on improving that step by step, bit by bit… remember: report whatever you feel is wrong with Gentoo packaging on our bugzilla after making sure there isn’t a report already. Don’t assume somebody else will see your problem, don’t assume that you’ll be the only one with that problem, *please report it*… just try to keep an open mind that maybe it’ll be marked as an invalid bug because you should have done some extra configuration… on the other hand, we really should make it easier to use Gentoo as a guest operating system.