guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wip blog post: running Guix System on ARM


From: Danny Milosavljevic
Subject: Re: wip blog post: running Guix System on ARM
Date: Thu, 14 Nov 2019 13:12:11 +0100

Hi Julien,

On Wed, 13 Nov 2019 22:21:54 +0100
Julien Lepiller <address@hidden> wrote:

> Hi, attached is a draft for a blog post (or a section in the cookbook)
> for explaining how to install the Guix System on an ARM board. WDYT?

I guess it can't hurt to describe this stuff as it works now, but the goal is 
not
to need to do any of this complicated stuff--and there's no fundamental reason
why one would have to.  There are projects like buildroot which have all the
u-boot configuration (and more--like the partitioning, which also can sometimes
have funny requirements, for example on Allwinner) that Guix could import to
generically install Guix on any ARM board.
Eventually there will be an importer for those.

The kernel module situation is awful.  It would be good if we could automate
it more in the future (if the information is statically available in the first
place).  If the foreign distribution doesn't have it, not much can be done.

I'm not sure what buildroot does--whether we have kernels with different
built-in modules for different modules or what?

Some comments on your draft:

(1) You absolutely can use an existing u-boot to boot Guix (bugs 
nonwithstanding).
Guix only generates "extlinux.conf" and doesn't touch the other u-boot config.
The default u-boot-bootloader installer (as opposed to config installer) is
"do nothing".  So your existing u-boot (for example in NAND flash) would display
a boot menu and then you could boot from SSD or SD, for example.
If this doesn't work, please file a bug report.  Also, the old generations
should be able to be selected, too.  Doesn't it work?

FWIW, I'm also using an existing Grub inside Libreboot to boot Guix on X86,
with exactly the same mechanism (grub.conf generated, grub-install not invoked).

(2) If possible, can you mention that non-exported, non-documented variables
are subject to change?  I mean I like that "@@" is possible, but let's make sure
the user knows that it would be better to contact us for including his stuff
if it's supposed to continue to work.

Attachment: pgpiobmS4xFVR.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]