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 [email protected] and reply
to the automated confirmation request that will be sent to you.