On Wed, 2013-10-02 at 23:39 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > + mount -o loop ../LiveOS/squashfs.img squashfs > > Heh, this is unfortunate - since I test things inside containers, now I > have to face the loop device in containers issue :)
Yeah, I could have extracted the squashfs file system to the temporary
directory using unsquashfs but that creates a dependency on squashfs
tools and it doesn't avoid the loopback situation lower down because
what's contained in that file system is the image of an ext4 file system
image which then has to be mounted. Damned if you do and damned if you
don't.
> For now I just added b 7:0 to my devices whitelist and loosened the
> apparmor policy. Fedora build did its thing. Then I removed those
> exceptions.
Yeah, that's more or less what I had to do as well. I also had to
remove any drop cap config options. The default Oracle template is
loaded with them. Since that's all I was using a couple of those
containers for anyways, I just left those config options in there. I
don't see any harm in leaving access to a few loopback devices when
that's the purpose of that particular container anyways.
I wasn't totally sure about validity of testing and building containers
within containers but it definitely helped a lot with things like the
Oracle platform. Nice to know you're doing the same thing.
I ran into an error testing under Ubuntu (very similar to the error you
note below) in a container so I tried the same thing on hard iron and
got the same error (reason and fix is also noted below so that's not
what you're seeing below). That did give me more confidence in testing
the containerized container builds.
Could not get OpenSuse to build in a container under Fedora or Ubuntu
due to missing Zypper, so I had to build that on hard iron (yeah, I
could have used KVM or VirtualBox but I had a machine handy) and test on
that as well.
> I did have to remove the devices whitelist entries for 4:0 and 4:1.
> They are for /dev/tty{0,1} - the real ones, which we don't use
> in containers. Since the ubuntu container in which I was testing
> didn't have that, I couldn't grant it to the fedora container, but
> it doesn't need it.
> Other than that, it looks good!
:-)=)
I still wish there was a simpler way to accomplish this but it got the
job done. I'm open to suggestion on how to simplify it.
> There is a weird glitch, when i first start the container, i type
> in username root, then have to hit return again before it shows
> me the password prompt. It doesn't accept the password. Second
> login attempt works fine.
I've seen that happen. Not sure what the cause is there but I've seen
that happen on even some of my containers from earlier templates and
tarballs if I try going through the console (which I rarely do). Seems
to be something to do with those getty's on /dev/console and the
vty /dev/tty?.
> Yum also isn't finding any mirrors, but
> that may be a problem local to me.
Oh... I ran into that a lot while "walking the dog" (regression
testing). Sometimes couldn't find mirrors, sometimes couldn't download
metadata. For me it always seem to boil down to /etc/resolv.conf being
out of whack in the chroot. You'll noticed a number of spots where I'm
running "cp /etc/resolv.conf" to ".../etc/" to touch it up. Generally
right after mounting proc and right before the chroot into the container
to run yum. Find it fix it retest. Find the next one fix it retest...
Sigh...
I actually ran into a gotcha at one spot running on Ubuntu but it was
strictly my fault where I had done a "cp -a /etc/resolv.conf" instead of
a plain "cp /etc/resolv.conf" and it turns out that /etc/resolv.conf was
a symlink on Ubunutu so "cp -a" obligingly created a symlink for me in
the target (that then didn't work in the chroot) causing exactly that
problem. Thought I would never find the cause of THAT problem! But I
just checked and it's definitely NOT in the diff I sent to you. I may
have missed a corner case in there somewhere. Let me know if I did and
I'll catch it up.
> Will test some more tomorrow.
Cool
> Thanks!
I'm starting to poke at some of those other take-aways I came away with
from LinuxPlumbers. There'll be more patches on the horizon. I'm kinda
surprised I haven't heard any pushback from the whole idea of the use of
container directories on devtmpfs like I expected. Can't say people
weren't warned before hand when I do this...
> -serge
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
