Re: Success report using Owl 64-bit + VirtualBox 2.2.0

Hi Willy,

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.
Indeed, this kind of emulation is slow, and x86-64 CPUs are cheap, so
there's little reason for doing things in this way.

> 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 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. ;-)

> 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.  Indeed, we could point .rpm.d
to under /ram with a symlink and run "rpminit" - is that what you want?
(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.

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.  (It is
somewhat wrong that we install the kernel headers under /usr/src rather
than introduce a glibc-kernheaders package, though.)

Perhaps we should switch to using tmpfs instead of a RAM disk for /ram.
Then a /usr/src/rpm.d symlink to /ram would make more sense.

Alexander

-- 
To unsubscribe, e-mail [email protected] and reply
to the automated confirmation request that will be sent to you.