[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Apr 2009 05:35:45 +0400
From: Solar Designer <solar@...nwall.com>
To: Willy Tarreau <w@....eu>
Cc: owl-users@...ts.openwall.com
Subject: 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 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.
