Hello, Actually, 4 questions...
1. I noticed the standard procedure for preparing and launching including applying chroot 755 to the backing file. Is this really necessary? I should think that any file system that is installed into a file should already be jailed or otherwise restricted from accessing the Host computer (or any other) file system, or am I mistaken? 2. I was surprised to see that the downloads at fs.devloop.uk specified the backing file is prepared differently for UML vs KVM. I've been looking, have not yet found what those differences should be and I don't see anything based on the steps used to prepare a UML backing file. 3. I don't see any description anywhere where a CDROM virtual device can be attached to an empty backing file, then run a standard distro "install." Can this work instead of creating backing files which I suspect may cause problems(like whether systemd or sysvinit is used by the distro)? 4. As the subject line describes, because I have run into a variety of problems using the two 64-bit kernels on the UML homepage in combination with the various 64-bit fs at http://fs.devloop.org.uk/, I'm looking to build my own fs (if you want slightly more info on the problems, the description is after my closing salutation). Because I'm running one of the distros that is using systemd, I'd like to take advantage of the relevant features using systemd. I found the following propsed procedure source page http://blog.rus.lt/ mkdir /mnt/bootstrap zypper --root /mnt/bootstrap ar http://ftp.sunet.se/pub/Linux/distributions/opensuse/distribution/12.2/repo/oss/ repo-oss mkdir /mnt/bootstrap/dev mount -o bind /dev /mnt/bootstrap/dev zypper --root /mnt/bootstrap install rpm zypper wget vim kernel-firmware kvm chroot /mnt/bootstrap zypper ar http://ftp.sunet.se/pub/Linux/distributions/opensuse/update/12.2 repo-update zypper ar http://download.opensuse.org/repositories/security/openSUSE_12.2 security zypper ar -f ftp://download.nvidia.com/opensuse/12.2/ nvidia zypper refresh zypper install x11-video-nvidiaG02 rm /etc/systemd/system/default.target ln -s /lib/systemd/system/runlevel5.target /etc/systemd/system/default.target sed 's/id:3:initdefault:/id:5:initdefault:/' -i /etc/inittab Enable NetworkManager Change hostname You'll notice in the steps described above - The file system is still chroot before creating the bootstrap fs (using zypper -root), Then after building the entire fs configuring the entirety as a systemd filesystem name space (ln -s foo bar). I'm curious whether it's actually possible to configure a systemd file system namespace first, in theory the file system namespace is supposed to be all that chroot does plus a lot more. - Somewhat related to my opening first question (1), I'm still curious whether all these steps to isolate the new bootstrap fs are necessary, I don't know if it's just done automatically but in all the other virtualization technologies i've used, this was never necessary, a running process within a VM based on a backing file just didn't have visibility beyond the contents of the file. I see this a concern only if the bootstrap fs is a subdirectory of the same fs the Host is using. Thx, TSU Addendum: I may d/l the 32-bit kernels and fs for testing but so far I have not been able to launch the following 64-bit fs from fs.devloop.org.uk openSUSE 12.1 (No root fs found) Fedora 17 (No console appears as I assumed should happen) Debian Wheezy (kernel too old, other kernel "unable to resolve LABEL=ROOT) So, bottom line is that at least the 64-bit resources won't work... Have read the "Troubleshooting" page and none of those issues apply to these problems ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
