* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
@ 2020-04-25 9:49 Jan Nieuwenhuizen
2020-04-25 12:13 ` Mathieu Othacehe
2020-04-25 12:32 ` Mathieu Othacehe
0 siblings, 2 replies; 11+ messages in thread
From: Jan Nieuwenhuizen @ 2020-04-25 9:49 UTC (permalink / raw)
To: 40839
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@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@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@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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-25 9:49 bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd Jan Nieuwenhuizen
@ 2020-04-25 12:13 ` Mathieu Othacehe
2020-04-25 13:28 ` Jan Nieuwenhuizen
2020-04-25 15:53 ` Ludovic Courtès
2020-04-25 12:32 ` Mathieu Othacehe
1 sibling, 2 replies; 11+ messages in thread
From: Mathieu Othacehe @ 2020-04-25 12:13 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: 40839
Hello Jan,
> /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
> $ 11:27:25 janneke@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
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-25 12:13 ` Mathieu Othacehe
@ 2020-04-25 13:28 ` Jan Nieuwenhuizen
2020-04-25 15:53 ` Ludovic Courtès
1 sibling, 0 replies; 11+ messages in thread
From: Jan Nieuwenhuizen @ 2020-04-25 13:28 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: 40839
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-services-shepherd-Cross-compilation-fix.patch --]
[-- Type: text/x-patch, Size: 3452 bytes --]
From cc9259a87c46cfa0dc2c59dc425b3656c9eecb13 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" <janneke@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@gnu.org>
Fix suggested by Mathieu Othacehe <m.othacehe@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
[-- Attachment #3: Type: text/plain, Size: 152 bytes --]
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply related [flat|nested] 11+ messages in thread* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-25 12:13 ` Mathieu Othacehe
2020-04-25 13:28 ` Jan Nieuwenhuizen
@ 2020-04-25 15:53 ` Ludovic Courtès
2020-04-25 17:38 ` Jan Nieuwenhuizen
1 sibling, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2020-04-25 15:53 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: 40839
Hey ho!
Mathieu Othacehe <m.othacehe@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@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’.
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-25 15:53 ` Ludovic Courtès
@ 2020-04-25 17:38 ` Jan Nieuwenhuizen
2020-05-02 13:15 ` Ludovic Courtès
0 siblings, 1 reply; 11+ messages in thread
From: Jan Nieuwenhuizen @ 2020-04-25 17:38 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 40839
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@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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-25 9:49 bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd Jan Nieuwenhuizen
2020-04-25 12:13 ` Mathieu Othacehe
@ 2020-04-25 12:32 ` Mathieu Othacehe
2020-04-25 17:59 ` Jan Nieuwenhuizen
1 sibling, 1 reply; 11+ messages in thread
From: Mathieu Othacehe @ 2020-04-25 12:32 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: 40839
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-25 12:32 ` Mathieu Othacehe
@ 2020-04-25 17:59 ` Jan Nieuwenhuizen
2020-04-27 12:35 ` Mathieu Othacehe
0 siblings, 1 reply; 11+ messages in thread
From: Jan Nieuwenhuizen @ 2020-04-25 17:59 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: 40839
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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-25 17:59 ` Jan Nieuwenhuizen
@ 2020-04-27 12:35 ` Mathieu Othacehe
2020-04-28 17:20 ` Jan Nieuwenhuizen
0 siblings, 1 reply; 11+ messages in thread
From: Mathieu Othacehe @ 2020-04-27 12:35 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: 40839
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
^ permalink raw reply [flat|nested] 11+ messages in thread* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-27 12:35 ` Mathieu Othacehe
@ 2020-04-28 17:20 ` Jan Nieuwenhuizen
2020-04-29 8:48 ` Mathieu Othacehe
0 siblings, 1 reply; 11+ messages in thread
From: Jan Nieuwenhuizen @ 2020-04-28 17:20 UTC (permalink / raw)
To: Mathieu Othacehe; +Cc: 40839
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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd
2020-04-28 17:20 ` Jan Nieuwenhuizen
@ 2020-04-29 8:48 ` Mathieu Othacehe
0 siblings, 0 replies; 11+ messages in thread
From: Mathieu Othacehe @ 2020-04-29 8:48 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: 40839
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-05-02 13:16 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-25 9:49 bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd Jan Nieuwenhuizen
2020-04-25 12:13 ` Mathieu Othacehe
2020-04-25 13:28 ` Jan Nieuwenhuizen
2020-04-25 15:53 ` Ludovic Courtès
2020-04-25 17:38 ` Jan Nieuwenhuizen
2020-05-02 13:15 ` Ludovic Courtès
2020-04-25 12:32 ` Mathieu Othacehe
2020-04-25 17:59 ` Jan Nieuwenhuizen
2020-04-27 12:35 ` Mathieu Othacehe
2020-04-28 17:20 ` Jan Nieuwenhuizen
2020-04-29 8:48 ` Mathieu Othacehe
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).