GNU bug report logs - #40839
Shepherd activation .GO files are not cross-compiled ... and the Hurd

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40839 in the body.
You can then email your comments to 40839 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Shepherd activation .GO files are not cross-compiled ... and the Hurd
Date: Sat, 25 Apr 2020 11:49:09 +0200

Hello!

The wip-hurd-vm branch cross-builds a VM for the Hurd.  It uses some
dedicated hacks to build the system packages, services, system profile
and shepherd configuration and cross-build them into a qemu image.

We did this to avoid too much struggle up front with parameterizing,
working around, or removing Linux-specifics from "guix system
--target=i586-pc-gnu build,vm,..."

One problem that still remains is that the shepherd's activation .GO
files are not cross-compiled.  Currently, wip-hurd-vm works around that
by having the Shepherd load .SCM files instead of the (wrongly compiled)
.GO files.

After some discussion on IRC, I decided to find out if guix system build
--target=... might not have this bug.  That would make a great case to
start migrating some custom gnu/system/hurd.scm code to "guix system
--target=i586-pc-gnu ..."; we will have to do that some times soon
anyway.

guix system ..., however, shows has the same bug.  You can see that by
doing something like

--8<---------------cut here---------------start------------->8---
10:31:10 janneke <at> dundal:~/src/guix/core-updates [env]
$ timeout 5 ./pre-inst-env guix system build --target=arm-linux-gnueabihf --no-bootloader --no-grafts --verbosity=1 gnu/system/examples/bare-bones.tmpl |& grep shepherd.*go.drv
   /gnu/store/08brf243p0zfkz2d5imsy2swy1pzhpvb-shepherd-networking.go.drv
   /gnu/store/0wyzan9dmv23i4bjv6vlrq9h0zfph6gx-shepherd-console-font-tty4.go.drv
   /gnu/store/0x2mscizw7bhv3da3njhr6h37jmisk7r-shepherd-console-font-tty1.go.drv
   /gnu/store/2r2rc2kp3wfvrlkz7gkhz06ggy0x3g9i-shepherd-term-tty1.go.drv
   /gnu/store/3845nr3gczx6pia83d796r56a89ihhwq-shepherd-term-auto.go.drv
   /gnu/store/3a7mivzyr5cx9kgkxl2g2flv6z9mnb16-shepherd-console-font-tty5.go.drv
   /gnu/store/5190cy2n0kcil0w1ln5f5z7rhnbp0m98-shepherd-file-system--dev-pts.go.drv
   /gnu/store/571pfgfi3q6ql0g1qadpm4ka06w1ckl1-shepherd-syslogd.go.drv
   /gnu/store/5j18jk5x33nkw4fdfdi4wwk03264sc1i-shepherd-nscd.go.drv
   /gnu/store/5kaacb0amw3k7avjj9xahbw50cchs4gc-shepherd-term-tty2.go.drv
   /gnu/store/67idmlz2b4dsbj4s9x2733q4d2vlhql5-shepherd-ssh-daemon-ssh-sshd.go.drv
   /gnu/store/6n8pmflgqpkdcs02876n9f0nd51iggh3-shepherd-term-tty5.go.drv
   /gnu/store/9zrvxc2ii85zczv6yiq0h6z8xbsr69ny-shepherd-term-tty4.go.drv
   /gnu/store/blfzip72s4zwg8rwbs5n5x4m0jamlxzi-shepherd-user-homes.go.drv
   /gnu/store/bwks8ydmfcc4ig47qriwz02ja86lrpkn-shepherd-console-font-tty2.go.drv
   /gnu/store/fgimk2w6zfd11fn1mk1kzab2wh4f548g-shepherd-term-tty3.go.drv
   /gnu/store/g6dy6yqgn5rn6p0vza964kjsrnxymm4r-shepherd-term-tty6.go.drv
   /gnu/store/hhmsgh0plqhb5448kdjjg6cl66l8fnqv-shepherd-file-system--dev-shm.go.drv
   /gnu/store/hhvs8400445b8gs7nfp8sya9c32k3h0q-shepherd-user-processes.go.drv
   /gnu/store/ihnl0bqhz0x88a393bbpxiq52rf0rd5w-shepherd-console-font-tty6.go.drv
   /gnu/store/ki7n8gg54mc9dbzw3i7drpzys2w15033-shepherd-guix-daemon.go.drv
   /gnu/store/nxnzrh2pbhnk2pxw8iggc28096p0vyqk-shepherd-root-file-system.go.drv
   /gnu/store/pw8p4ywnbamfz4ikr6zw9m4clszxakap-shepherd-console-font-tty3.go.drv
   /gnu/store/s3f030pywqps9fmdp0mnldyvmdkmm9d9-shepherd-file-systems.go.drv
   /gnu/store/vkafkq4qpnsijv7my0pw8qdg46ya206y-shepherd-user-file-systems.go.drv
   /gnu/store/vv25y5a8vga2syi716ph75x2xp0pjj7f-shepherd-mcron.go.drv
   /gnu/store/vxp0855svszgk8wix0mml2ahw48jdphx-shepherd-host-name.go.drv
   /gnu/store/x6s7b4il8a8lnwj8sshx786sq1l0mxsm-shepherd-loopback.go.drv
   /gnu/store/xnpg23wpxwyqjmh9vssp29kw2pwaq04x-shepherd-udev.go.drv
   /gnu/store/y5nv3pplsbf9i1mzpg5p0ry0qv1qxq7c-shepherd-file-system--gnu-store.go.drv
   /gnu/store/z0a48zsv23pgy5d89ywj1sm9nwxdrwbq-shepherd-urandom-seed.go.drv
   /gnu/store/znn7813x9p1zn6bdywciqm6yk1qm7r0q-shepherd-virtual-terminal.go.drv
Terminated
[143]10:31:15 janneke <at> dundal:~/src/guix/core-updates [env]
$ ./pre-inst-env guix build --target=arm-linux-gnueabihf --no-grafts --verbosity=1 /gnu/store/vxp0855svszgk8wix0mml2ahw48jdphx-shepherd-host-name.go.drv
...
/gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
$ 11:27:25 janneke <at> dundal:~/src/guix/core-updates [env]
$ file /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
/gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go: ELF 64-bit LSB shared object no machine, version 1 (embedded), dynamically linked, with debug_info, not stripped
--8<---------------cut here---------------end--------------->8---

Greetings,
janneke

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

Message #8 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 40839 <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Sat, 25 Apr 2020 14:13:49 +0200

Hello Jan,

> /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
> $ 11:27:25 janneke <at> dundal:~/src/guix/core-updates [env]
> $ file /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
> /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go: ELF 64-bit LSB shared object no machine, version 1 (embedded), dynamically linked, with debug_info, not stripped

I strongly suspect this is because we would need to wrap the
"compile-file" call in "scm->go" procedure of (gnu services shepherd)
inside a "with-target".

That would look like:

--8<---------------cut here---------------start------------->8---
(if target
    (with-target target
                 (compile-file #$file #:output-file #$output
                               #:env env))
  (compile-file #$file #:output-file #$output
                #:env env))
--8<---------------cut here---------------end--------------->8---


Now, the tricky part is the value of target, because
#$(%current-target-system) might not be correct in that context.

Mathieu

Message #11 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 40839 <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Sat, 25 Apr 2020 14:32:14 +0200

> The wip-hurd-vm branch cross-builds a VM for the Hurd.  It uses some
> dedicated hacks to build the system packages, services, system profile
> and shepherd configuration and cross-build them into a qemu image.
>
> We did this to avoid too much struggle up front with parameterizing,
> working around, or removing Linux-specifics from "guix system
> --target=i586-pc-gnu build,vm,..."

I have not followed really closely the recent progress on the Hurd, but
I think we may need to synchronize at some point :)

As you have noticed our image creation is very tied to Linux and Intel
x86 compatible machines. I would like in the future that producing images
for other architectures/kernels could be less hacky.

My idea is to:

* Speed up image creation by removing the need to use VM to produce
  images.

* Augment the operating-system record, or provide a new record, that
  encapsulates information related to image layout (partitions,
  bootloader location), target architecture (i586-pc-gnu,
  aarch64-linux, ...).

  This way, one would just have to run `guix system disk-image
  my-board.scm' or `guix system disk-image --board=xxx config.scm', and
  not have to worry about specifying the correct target triplet, kernel
  and bootloader packages.

On the wip-disk-image, I propose the creation of an "image" record in
(gnu image), but I'm still not sure how to interface it.

Thanks,

Mathieu

Message #14 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: 40839 <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Sat, 25 Apr 2020 15:28:23 +0200

[Message part 1 (text/plain, inline)]

Mathieu Othacehe writes:

Hello Mathieu,

> I strongly suspect this is because we would need to wrap the
> "compile-file" call in "scm->go" procedure of (gnu services shepherd)
> inside a "with-target".

> That would look like:
>
> (if target
>     (with-target target
>                  (compile-file #$file #:output-file #$output
>                                #:env env))
>   (compile-file #$file #:output-file #$output
>                 #:env env))

Thank you!  I have tried this in the attached patch, and it seems to
work for me.

I was so puzzled why wrapping scm->go

--8<---------------cut here---------------start------------->8---
(use-modules (system base target))
(define (scm->go file)
  (with-target "i586-pc-gnu"
    (lambda _
     ((@@ (gnu services shepherd) scm->go) file))))
--8<---------------cut here---------------end--------------->8---

did not work; actually reading scm->go makes that pretty clear :-)

> Now, the tricky part is the value of target, because
> #$(%current-target-system) might not be correct in that context.

I did read this, but wanted to try it first anyway.  So, what are you
seeing here, when would this not be OK?  Any other ideas of how to
address this further?

Greetings,
janneke

[0001-services-shepherd-Cross-compilation-fix.patch (text/x-patch, inline)]

From cc9259a87c46cfa0dc2c59dc425b3656c9eecb13 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" <janneke <at> gnu.org>
Date: Sat, 25 Apr 2020 15:20:04 +0200
Subject: [PATCH] services: shepherd: Cross-compilation fix.

Fixes <https://bugs.gnu.org/40839>.
Reported by Jan (janneke) Nieuwenhuizen <janneke <at> gnu.org>
Fix suggested by Mathieu Othacehe <m.othacehe <at> gmail.com>

* gnu/services/shepherd.scm (scm->go): Use `with-target' when cross-compiling.
---
 gnu/services/shepherd.scm | 40 +++++++++++++++++++++++----------------
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index 2f30c6c907..ca4edd80ab 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -25,6 +25,7 @@
   #:use-module (guix store)
   #:use-module (guix records)
   #:use-module (guix derivations)                 ;imported-modules, etc.
+  #:use-module (guix utils)
   #:use-module (gnu services)
   #:use-module (gnu services herd)
   #:use-module (gnu packages admin)
@@ -260,22 +261,29 @@ stored."
 (define (scm->go file)
   "Compile FILE, which contains code to be loaded by shepherd's config file,
 and return the resulting '.go' file."
-  (with-extensions (list shepherd)
-    (computed-file (string-append (basename (scheme-file-name file) ".scm")
-                                  ".go")
-                   #~(begin
-                       (use-modules (system base compile))
-
-                       ;; Do the same as the Shepherd's 'load-in-user-module'.
-                       (let ((env (make-fresh-user-module)))
-                         (module-use! env (resolve-interface '(oop goops)))
-                         (module-use! env (resolve-interface '(shepherd service)))
-                         (compile-file #$file #:output-file #$output
-                                       #:env env)))
-
-                   ;; It's faster to build locally than to download.
-                   #:options '(#:local-build? #t
-                               #:substitutable? #f))))
+  (let ((target (%current-target-system)))
+    (with-extensions (list shepherd)
+      (computed-file (string-append (basename (scheme-file-name file) ".scm")
+                                    ".go")
+                     #~(begin
+                         (use-modules (system base compile)
+                                      (system base target))
+
+                         ;; Do the same as the Shepherd's 'load-in-user-module'.
+                         (let ((env (make-fresh-user-module)))
+                           (module-use! env (resolve-interface '(oop goops)))
+                           (module-use! env (resolve-interface '(shepherd service)))
+                           (if #$target
+                               (with-target #$target
+                                 (lambda _
+                                   (compile-file #$file #:output-file #$output
+                                                 #:env env)))
+                               (compile-file #$file #:output-file #$output
+                                             #:env env))))
+
+                     ;; It's faster to build locally than to download.
+                     #:options '(#:local-build? #t
+                                 #:substitutable? #f)))))
 
 (define (shepherd-configuration-file services)
   "Return the shepherd configuration file for SERVICES."
-- 
2.26.0

[Message part 3 (text/plain, inline)]

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

Message #17 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: 40839 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Sat, 25 Apr 2020 17:53:40 +0200

Hey ho!

Mathieu Othacehe <m.othacehe <at> gmail.com> skribis:

> That would look like:
>
> (if target
>     (with-target target
>                  (compile-file #$file #:output-file #$output
>                                #:env env))
>   (compile-file #$file #:output-file #$output
>                 #:env env))
>
>
> Now, the tricky part is the value of target, because
> #$(%current-target-system) might not be correct in that context.

Yes, that brings us back to <https://issues.guix.gnu.org/issue/29296>.
Time flies!  But now we really need to address it.

Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:

> +  (let ((target (%current-target-system)))
> +    (with-extensions (list shepherd)
> +      (computed-file (string-append (basename (scheme-file-name file) ".scm")
> +                                    ".go")
> +                     #~(begin

The problem here is that ‘%current-target-system’ is not resolved in the
right context.  Though in practice, it’s “good enough” when using ‘guix
system build --target’ though, because ‘%current-target-system’ is bound
once and for all at the beginning.

What about applying this patch, but adding a FIXME comment above ‘let’
pointing at <https://bugs.gnu.org/29296>?

Also, you can avoid duplicating the ‘compile-file’ call by writing it
like this:

  (with-target #$(or target #~%host-type)
    (compile-file …))

Thanks!

Ludo’.

Message #20 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40839 <at> debbugs.gnu.org, Mathieu Othacehe <m.othacehe <at> gmail.com>
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Sat, 25 Apr 2020 19:38:42 +0200

Ludovic Courtès writes:

Hello!

>> Now, the tricky part is the value of target, because
>> #$(%current-target-system) might not be correct in that context.
>
> Yes, that brings us back to <https://issues.guix.gnu.org/issue/29296>.
> Time flies!  But now we really need to address it.

Oh!  Yes, I guess we need that as soon as we unify the hurd VM with the
guix system build?

> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>> +  (let ((target (%current-target-system)))
>> +    (with-extensions (list shepherd)
>> +      (computed-file (string-append (basename (scheme-file-name file) ".scm")
>> +                                    ".go")
>> +                     #~(begin
>
> The problem here is that ‘%current-target-system’ is not resolved in the
> right context.  Though in practice, it’s “good enough” when using ‘guix
> system build --target’ though, because ‘%current-target-system’ is bound
> once and for all at the beginning.
>
> What about applying this patch, but adding a FIXME comment above ‘let’
> pointing at <https://bugs.gnu.org/29296>?

Pushed to core-updates as d2fc76462e72268ee5b04fe53805efc05c35e139,
with...

> Also, you can avoid duplicating the ‘compile-file’ call by writing it
> like this:
>
>   (with-target #$(or target #~%host-type)

...this change too.  Nice, that works (I tried (%current-system), which
did not work).

Thanks!
janneke

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

Message #23 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: 40839 <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Sat, 25 Apr 2020 19:59:18 +0200

Mathieu Othacehe writes:

>> We did this to avoid too much struggle up front with parameterizing,
>> working around, or removing Linux-specifics from "guix system
>> --target=i586-pc-gnu build,vm,..."
>
> I have not followed really closely the recent progress on the Hurd, but
> I think we may need to synchronize at some point :)

Oh no! :)

I haven't been following either...but I did notice that "guix system
reconfigure" may be tricky on the Hurd, given that it does not have
Qemu.  I was actively trying not to think about that, hoping some
solution would present itself.

> As you have noticed our image creation is very tied to Linux and Intel
> x86 compatible machines. I would like in the future that producing images
> for other architectures/kernels could be less hacky.

Yes...the Intel bit isn't really hurting the Hurd efforts yet (sadly),
but I see what you mean.

> My idea is to:
>
> * Speed up image creation by removing the need to use VM to produce
>   images.
>
> * Augment the operating-system record, or provide a new record, that
>   encapsulates information related to image layout (partitions,
>   bootloader location), target architecture (i586-pc-gnu,
>   aarch64-linux, ...).
>
>   This way, one would just have to run `guix system disk-image
>   my-board.scm' or `guix system disk-image --board=xxx config.scm', and
>   not have to worry about specifying the correct target triplet, kernel
>   and bootloader packages.
>
> On the wip-disk-image, I propose the creation of an "image" record in
> (gnu image), but I'm still not sure how to interface it.

Thanks for the ping and the summary: I should really look into that!

I am currently still looking to consolidate all the cross build fixes,
and how to migrate the Shepherd and services hacks into the regular
framework.  I'm guessing that's all stuff that wip-disk-image does not
touch/change.

Greetings,
janneke

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

Message #26 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: ludo <at> gnu.org, 40839 <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Mon, 27 Apr 2020 14:35:05 +0200

Hello Janneke!

I had a look to (gnu system hurd), this is really nice! I think we could
try an explosive mixture of our two branches :)

More seriously, we could do something like:

--8<---------------cut here---------------start------------->8---
(define hurd-disk-image
  (image
   (format 'disk-image)
   (partitions
    (list
     (partition
      (size 'guess)
      (label "Guix_image")
      (file-system "ext2")
      (flags '(boot))
      (initializer (gexp initialize-hurd-root-partition)))))))
--8<---------------cut here---------------end--------------->8---

then we could have some mapping in guix/scripts/system.scm to
associate:

* x86_64-linux -> efi-disk-image
* i586-pc-gnu -> hurd-disk-image

and one could get a hurd disk-image by typing: 

--8<---------------cut here---------------start------------->8---
guix system disk-image --target=i586-pc-gnu my-hurd-os.scm
--8<---------------cut here---------------end--------------->8---

One problem that can arise is the installation of grub. Currently
wip-disk-image does not support legacy Grub (MBR based)
installation.

This is because running grub-install needs root permissions, to mess with
/dev/something in order to write the MBR I guess.

We could also create a Hurd ISO if grub-mkrescue (that is used to make
the ISO bootable), supports the Hurd.

Adding Ludo that might have some insight here.

Thanks,

Mathieu

Message #29 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Jan Nieuwenhuizen <janneke <at> gnu.org>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: ludo <at> gnu.org, 40839 <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Tue, 28 Apr 2020 19:20:36 +0200

Mathieu Othacehe writes:

Hello Mathieu!

> I had a look to (gnu system hurd), this is really nice! I think we could
> try an explosive mixture of our two branches :)

Sure, why not? ;-) I played a bit yesterday with wip-disk-image.  Not
that (gnu system hurd) already lives on core-updates; possibly we can
start playing there?  I tried rebasing wip-disk-image on core-updates
and that was (almost?) painless.

> More seriously, we could do something like:
>
> (define hurd-disk-image
>   (image
>    (format 'disk-image)
>    (partitions
>     (list
>      (partition
>       (size 'guess)
>       (label "Guix_image")
>       (file-system "ext2")
>       (flags '(boot))
>       (initializer (gexp initialize-hurd-root-partition)))))))

Sweet!

> then we could have some mapping in guix/scripts/system.scm to
> associate:
>
> * x86_64-linux -> efi-disk-image
> * i586-pc-gnu -> hurd-disk-image
>
> and one could get a hurd disk-image by typing: 
>
> guix system disk-image --target=i586-pc-gnu my-hurd-os.scm

Oh, that sounds real great.

> One problem that can arise is the installation of grub. Currently
> wip-disk-image does not support legacy Grub (MBR based)
> installation.
>
> This is because running grub-install needs root permissions, to mess with
> /dev/something in order to write the MBR I guess.

Hmm...so we need to do some work, is that bad?

> We could also create a Hurd ISO if grub-mkrescue (that is used to make
> the ISO bootable), supports the Hurd.
>
> Adding Ludo that might have some insight here.

Hopefully -- this is also pretty out of my comfort zone, otoh I am
very motivated to get this going. :-)

I have been wondering about the branch name in combination with its
functionality: can/will/could "wip-disk-image" also be used for
guix system init/reconfigure (we don't have qemu on the Hurd)?

Greetings,
janneke

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

Message #32 received at 40839 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <m.othacehe <at> gmail.com>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: ludo <at> gnu.org, 40839 <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Wed, 29 Apr 2020 10:48:58 +0200

Hello!

>> This is because running grub-install needs root permissions, to mess with
>> /dev/something in order to write the MBR I guess.
>
> Hmm...so we need to do some work, is that bad?

Not sure yet, but I'll investigate it.

>> We could also create a Hurd ISO if grub-mkrescue (that is used to make
>> the ISO bootable), supports the Hurd.
>>
>> Adding Ludo that might have some insight here.
>
> Hopefully -- this is also pretty out of my comfort zone, otoh I am
> very motivated to get this going. :-)
>
> I have been wondering about the branch name in combination with its
> functionality: can/will/could "wip-disk-image" also be used for
> guix system init/reconfigure (we don't have qemu on the Hurd)?

Note that "init" and "reconfigure" options do not use Qemu. "init" will
roughly populate a store directory and install a
bootloader. "reconfigure" will re-install the bootloader with new system
derivation.

While it certainly won't work out of the box for the Hurd, it may be
less tricky than the image support.

I sent a first version of the wip-disk-image to review and rebased it on
master. Now, I'll focus on improving Grub support on this branch (for
MBR based booting), hoping it will help us to get Hurd support later on.

Thanks,

Mathieu

Message #37 received at 40839-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40839-done <at> debbugs.gnu.org
Subject: Re: bug#40839: Shepherd activation .GO files are not cross-compiled
 ... and the Hurd
Date: Sat, 02 May 2020 15:15:17 +0200

Hi!

Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:

> Pushed to core-updates as d2fc76462e72268ee5b04fe53805efc05c35e139,

Closing!

Ludo’.

Previous Next

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