On Tue, 02.07.13 10:08, Jean-Marc Pigeon (jmp@xxxxxxx) wrote: > This little project gave satisfactory results with various distributions when > I designed and tested it 2 years ago. First I checked it with a standard > EL6.4 template (400 Megs) under this new kernel (3.9.4, HOST > EL6.4) to see if my tool was > still operational. Everything went perfectly. I was ready to test > FC18. The selected > FC18 template is a very standard one (a 939 MBytes tgz file) which > (and this is a key factor) was proved to be fully working "as is" in an openvz > container (kernel 2.6.32-042stab076.8). "as is" means that Template > was never taylored > to be on openvz container (template is used out of the box in openvz > container) and could > be used to seed a working HOST too. So, as you mentioned earlier you used this recipe to set up your image: https://gist.github.com/fabaff/5512671 This recipe is very broken (which I already told you), and by using this, you create an OS image that changes a number of early boot things in a way that will break things if you then try to boot the same image on bare metal. The things it changes are early-boot things, very low-level stuff. You interfered with much of the most basic OS initialization stuff there (masking sysinit.target!), and if you do this then you really need to know what you are doing. And you should not expect that the same image will then continue to boot on normal hardware. I understand you are new to systemd, but you chose to alter the lowest level bits of the OS, and then were subsequently lost then. This is certainly very understandable, but please accept that this is not our primary use case. We assume that if you touch that kind of low-level stuff, and alter the early-boot dep tree, then you know how to help yourself. The more low-level you go the more expertise you need. We are working on making systemd work out-of-the-box on container managers. libvirt-lxc and systemd-nspawn are relatively nicely integrated with systemd so that things just work without any manual recipe. OpenVZ is not something we test against, and we certainly do not test systems that have been modified to work with OpenVZ but then are attempted to be booted on bare-metal hardware again. >From the systemd side it is our goal to ensure that systemd will work fine on bare metal, inside a VM and in a container, with the exact same image, without any ateration. With nspawn/libvirt-lxc we are very close to that. However, all that work will be incomplete, unless Fedora as a whole starts to care about this (for example, by giving the various container managers a role like a "release architecture", to ensure they just work with unmodified future fedora releases), and unless the various container managers actually start to implement the most basic common interfaces like the ones we documented: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ So, please work with Fedora, with the container vendor of your choice to make all this stuff just work out-of-the-box. And please don't use recipes like the one you linked, they made things worse, not better. You don't need any recipes at all if your container manager just implements the ContainerInterface mini spec... Being able to migrate OS images between VMs, bare metal, containers, in all directions without alteration is absolutely a worthy goal, and not far off, if people actually start caring. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
