[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090413055135.GB25511@1wt.eu>
Date: Mon, 13 Apr 2009 07:51:35 +0200
From: Willy Tarreau <w@....eu>
To: Solar Designer <solar@...nwall.com>
Cc: owl-users@...ts.openwall.com
Subject: Re: Success report using Owl 64-bit + VirtualBox 2.2.0
Hi Alexander,
On Mon, Apr 13, 2009 at 05:35:45AM +0400, Solar Designer wrote:
> On Sat, Apr 11, 2009 at 09:10:20PM +0200, Willy Tarreau wrote:
> > I'm simply sending you a big kudos again for your live CD. I was
> > looking for a way to do 64-bit builds once in a while. I've just
> > installed the recent VirtualBox 2.2.0 on my 32-bit slackware, and
> > with it I can run a 64-bit distro. Guess what I'm running in it ?
>
> Thank you for posting this. FWIW, I am using QEMU, which is smaller
> than VirtualBox. It runs x86-64 code (including Owl ISOs) on 32-bit
> x86 just fine as well - I happened to test this on some occasions.
Hmmm I did not think about QEMU. From your description, it seems that
it can run 64-bit code on a 32-bit CPU, which is even more interesting
for me, as I have an unused Atom-based machine...
> Indeed, this kind of emulation is slow, and x86-64 CPUs are cheap, so
> there's little reason for doing things in this way.
With Virtualbox, you need a 64-bit CPU. It makes use of the hardware
virtualisation to run the code in native 64-bit mode while the rest
of the system runs in 32-bit mode. That's what I find interesting. My
system is 32-bit, but the hardware supports 64-bit and I can use both
simultaneously.
> > Your 64-bit live CD is just the *only* live distro around offering
> > a C compiler in a 64-bit environment. I'm now using it to ensure
> > that haproxy cleanly builds both in 32 and 64bit environments, and
> > this is by far the most convenient solution I have found. And as an
> > added bonus, it boots very quickly ;-)
>
> OK, that's yet another reason for us to make an official x86-64 ISO.
> As you know, those we have so far are unofficial, which is wrong.
I know, that was part of the reason for my post ;-)
> > I know that this usage is far from being the main target of Openwall
> > but since it's the only one offering such useful features and that
> > level of quality and user-friendliness, I wanted to send a big "thank
> > you guys" for the amazing work you have done there !
>
> You're welcome. Owl is quite selective about who its friends are. ;-)
Perhaps, but such friends are very happy with this type of instant-on
full-featured distro which do not take 5 minutes to start a useless
graphical environment :-)
> > If I may add a very minor suggestion : if in future builds you could
> > create the /us/src/.rpm.d/* directories, it would be even easier to
> > use the live CD to build RPMs. Right now I managed to do that using
> > a few mount --bind tricks. But as you see, this is not a showstopper.
>
> I don't think merely pre-creating those directories on the CD would
> change a thing - they would be read-only.
I could then just mount a tmpfs there, as I did.
> Indeed, we could point .rpm.d
> to under /ram with a symlink and run "rpminit" - is that what you want?
I did not know about rpminit. It's pretty convenient. In fact, since /ram
is limited, making .rpm.d just a directory allows one to simply mount a
tmpfs in it if needed. I've tried as root but I had to force HOME=/root
because strangely, HOME=/ for root. Otherwise it worked pretty well,
thanks for the tip !
In fact, I now think that there's no need to create .rpm.d at all,
since simply mounting a tmpfs in /root (and fixing HOME) is enough
to run rpminit.
> (Please see the rpminit(1) man page on Owl.) /ram is a bit too small,
> though. When we use the live CD to build any software (usually kernel
> modules, the kernel, or low-level tools for the system being installed),
> we normally mount an instance of tmpfs for that.
OK.
> For example, you can use:
>
> useradd -m rpm
> mount -t tmpfs tmpfs ~rpm -osize=100M,mode=700,uid=rpm,gid=rpm
> su - rpm
> rpminit
>
> I've just tested this under QEMU.
>
> Mounting a tmpfs right on /usr/src wouldn't be great as it would hide
> the kernel headers, as well as Owl packages and sources.
I know, but I did not know I could move it, reason why I asked for a subdir
instead of having to move all that around ;-)
> (It is
> somewhat wrong that we install the kernel headers under /usr/src rather
> than introduce a glibc-kernheaders package, though.)
Well, it's a live CD, what's most important on a live CD is that the tools
work as expected, not that they're perfectly tidy ;-)
> Perhaps we should switch to using tmpfs instead of a RAM disk for /ram.
Yes it would be really nice. As an added bonus, tmpfs is resizable using
"mount -o remount,size=".
> Then a /usr/src/rpm.d symlink to /ram would make more sense.
yes indeed then.
Cheers,
Willy
--
To unsubscribe, e-mail owl-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
