Hi David,
Hi Ludo,
On Fri, 9 Sep 2016 00:09:57 +0200
David Craven <da...@craven.ch> wrote:
> I'm testing your new u-boot code. I fixed a few bugs, but there is
> still some work to do... ;-)
>
> guix system vm u-boot-test.scm --no-grub
>
> This should work without giving any errors and boot (it doesn't matter
> that u-boot is built for arm). And after booting there should be the
> extlinux.conf file.
>
> Below is a test operating-system and the stuff I've already fixed.
Nice!
> --- a/gnu/system/grub.scm
> +++ b/gnu/system/grub.scm
> + <menu-entry>
Ludo was against that because it makes other packages aware how the data
structure <menu-entry> is implemented. Can it be avoided?
The only place where it's used externally:
gnu/system/u-boot.scm (copied from gnu/system/grub.scm where it was also used):
(define (u-boot-configuration-file ...)
(define entry->gexp
(match-lambda
(($ <menu-entry> label linux ...
^^^^^^
Probably something like
(? menu-entry? ...)
... (menu-entry-label ...)
... (menu-entry-linux ...)
, right?
> - #$label
> + #$label #$label
Indeed.
I fixed the guix system vm problem by modifying
gnu/system/vm.scm
to say
(package->derivation (operating-system-grub os))
instead of
(operating-system-grub os)
in two places.
Now it failed because someone in gnu/system.scm used grub-configuration-file on
a <u-boot-configuration> :P
So replace the call of grub-configuration-file by
bootloader-configuration-file, add it as follows:
(define* (bootloader-configuration-file config store-fs entries
#:key
(system (%current-system))
(old-entries '()))
((match config
((? grub-configuration? config) grub-configuration-file)
((? u-boot-configuration? config) u-boot-configuration-file))
config store-fs entries #:system system #:old-entries old-entries))
Then it complained about the built-in "format" not knowing "~d" which is used
by gnu/system/u-boot.scm at the bottom. So change that to "~a".
Then it complained about gnu/system/u-boot.scm entry->gexp. Replace "~a/~a ~a"
by "~a/~a".
It then successfully built a VM for me with your config.
@Ludo: Not sure where the step from package to derivation is supposed to be
done (it works at that place - but is it the right place?). In the end, the
build side needs to know the name of the bootloader installation directory in
order to be able to read the image to install in the boot sector etc, right?
And that is a way.
