[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 5 Jun 2009 17:19:47 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
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.
Alexander
--
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.
