GNU bug report logs - #41350
[PATCH 0/3] Use native qemu to build vm-image.

Previous Next

Full log

View this message in rfc822 format

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 41350 <at> debbugs.gnu.org
Subject: [bug#41350] [PATCH 0/3] Use native qemu to build vm-image.
Date: Tue, 19 May 2020 09:22:53 +0200

Mathieu Othacehe writes:

Hello Mathieu,

Thanks for chiming in, I meant to CC you...  :-)

>> Cross-building a vm-image used to be done using a cross-qemu, e.g, qemu-ARM.
>> That does not work for the Hurd, as there is no qemu-HURD.
>
> Yes that's an issue.

Yes...luckily I think we found a way to use qemu-NATIVE to build
packages for the Hurd.  Now to see if this can be put into digestible
form.

>> This patch switches to cross building vm-images using a native qemu vm.  If
>> there a reason for using qemu-TARGET we may want to make this switch
>> conditional for cross building to the Hurd?
>
> Well first this 'vm-image' thing should be done in (gnu system image) as
> soon as I have sorted out the bootloader issue. So the solution we will
> find to overcome this Hurd issue will be temporary I hope.

Can you elaborate a bit on that?  Do you think it makes sense to continue
this temporary path some more (as it starts to work right now), or can we
better abandon it and work the permanent solution?  How could I contribute?

> About using qemu-TARGET, let say you are on an armhf machine and you
> want to cross-build an x86-64 image. I fear that using a native, armhf
> Grub to install an x86-64 Grub won't work.

Ah...right, that's helpful information.

> So maybe, it would be better to do that only for the architectures
> without an available qemu-TARGET (only the Hurd for now)?

OK -- I have changed patch 2 and 3, and am sending a new patch set.

>> ...the problem is now avoided by removing the sqlite dependency when
>> cross-building by not registering closures and postponing the loading of (gnu
>> store database) and thus (sqlite3).
>
> When I produce a system without register closures, once booted, "guix
> build" something does not work. I don't know if its possible for
> guix-daemon to work without its database. An option could be to generate
> this database if its absent, at first boot?

Ah, OK.  I'm using this "solution" to use #:register-closures? #f now
for the Hurd only and we'll hit the problem that causes later.  We can
then, s discussed on IRC, sqlite3 databases are indeed platform
independent and we could use something like guix/scripts/pack.scm's
store-database.  WDYT?

>>     ./pre-inst-env guix system vm-image --target=i586-pc-gnu --no-grafts \
>>         gnu/system/examples/bare-hurd.tmpl
>>
>> now produces a pretty nice hurd VM :-)
>
> Great to see you so close :)

Yes...

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.