Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 5 Jun 2009 17:19:47 +0400
From: Solar Designer <>
Subject: Re: Success report using Owl 64-bit + VirtualBox 2.2.0

Hi Willy,

On Mon, Apr 13, 2009 at 07:51:35AM +0200, Willy Tarreau wrote:
> 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...

That's correct.  For testing a 64-bit Owl ISO on a 32-bit x86 CPU, the
command is as simple as:

qemu-system-x86_64 -cdrom Owl-current-20090529-x86_64.iso

...and it just works for me (FWIW, in my case the "host system" is
running Owl too, but indeed it doesn't have to).

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

Yes, this is interesting.  Until you mentioned this, I would have
expected that it'd require a 64-bit kernel, not just a 64-bit CPU, in
order to run the guest system's code natively.

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

This did the trick, it seems.  The Owl-current ISO for x86-64 currently
on our FTP mirrors is as official as they get. :-)  Also, it should boot
up even quicker than our previous ISOs did due to your sort-by-inode
trick for copying files to RAM.

> > 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=".

So we did switch to tmpfs in those new ISOs. :-)

I didn't bother to pre-create a /usr/src/.rpm.d symlink, though.
Frankly, I forgot.  Maybe next time.  Also, maybe we should run
something like "su - sources -c rpminit" at bootup.


To unsubscribe, e-mail 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.