GuixSD on eoma68-a20?

GuixSD on eoma68-a20?

[swedebugia]

Hi

I would like to know if there is any interest in this?

It seems to be well on the way to deliver as promised (though the time 
schedule has been updated a couple of times ;-) )

https://www.crowdsupply.com/eoma68/micro-desktop/updates/what-do-1-000-eoma68-a20-pcbs-look-like

Cost 65$
Est. shipping jan 2019.

Could we pre-order some of these owned by the foundation to
be used to to hack on this?

See https://www.crowdsupply.com/eoma68/micro-desktop

-- 
Cheers
Swedebugia

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Hi swedebugia,

On Sat, 8 Dec 2018 17:39:01 +0100
swedebugia <swedebugia@riseup.net> wrote:

> Could we pre-order some of these owned by the foundation to
> be used to to hack on this?
> 
> See https://www.crowdsupply.com/eoma68/micro-desktop

Guix received one but we have so far be unable to get the GuixSD flash
image because something always breaks on Hydra before it's done (for
example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
Note: The latter thing counts as "successful" build.  WTF?).

I have the device here in my hand (I tested it using u-boot only - works fine).

I'm now setting up my own build server and trying to get the flash image
that way - which is ridiculous.

Also, be aware that the Allwinner A20 is really really slow.  There are
ARM computers worth using as a normal PC, but this one isn't.  I tried.

(For example the Allwinner R40 is quite okay to use as a PC - see
Sinovoip Banana Pi M2 Ultra)

I like the concept of easily upgradeable computers, though!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Ricardo Wurmus]

Hi Danny,

> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done (for
> example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
> Note: The latter thing counts as "successful" build.  WTF?).

Is this now better with ci.guix.info (berlin.guixsd.org)?

> I have the device here in my hand (I tested it using u-boot only - works fine).

Oh, so it works out of the box with GuixSD already?

-- 
Ricardo

Re: bug#33676: GuixSD on eoma68-a20?

[Ricardo Wurmus]

Hi Danny,

> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done (for
> example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
> Note: The latter thing counts as "successful" build.  WTF?).

Is this now better with ci.guix.info (berlin.guixsd.org)?

> I have the device here in my hand (I tested it using u-boot only - works fine).

Oh, so it works out of the box with GuixSD already?

-- 
Ricardo

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hi Ricardo,

On Sat, 08 Dec 2018 18:34:04 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> > Guix received one but we have so far be unable to get the GuixSD flash
> > image because something always breaks on Hydra before it's done (for
> > example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
> > Note: The latter thing counts as "successful" build.  WTF?).  
> 
> Is this now better with ci.guix.info (berlin.guixsd.org)?

No idea.  How to I get the flash-image using ci.guix.info ?

I tried "guix system disk-image --system=armhf-linux gnu/system/install.scm" but
that builds a lot of stuff from source.  Let's see whether it will be done before
the sun exploded :)

> > I have the device here in my hand (I tested it using u-boot only - works fine).  
> 
> Oh, so it works out of the box with GuixSD already?

As I said, I've tested it with u-boot only so far.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Sat, 8 Dec 2018 17:39:01 +0100
> swedebugia <swedebugia@riseup.net> wrote:
>
>> Could we pre-order some of these owned by the foundation to
>> be used to to hack on this?
>> 
>> See https://www.crowdsupply.com/eoma68/micro-desktop
>
> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done (for
> example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
> Note: The latter thing counts as "successful" build.  WTF?).

This sounds like two distinct bugs:

* Regarding the lack of disk space: if I'm not mistaken, as things are
  currently implemented, we must specify the size of the disk image
  manually.  I guess we need to increase the size.

* This error that occurs within QEMU is apparently not being propagated
  to the outer build script.  That should be fixed.

> I'm now setting up my own build server and trying to get the flash image
> that way - which is ridiculous.

You seem to be assuming that the problem building the disk image is a
Hydra-specific problem.  Do you have reason to believe so?  I would
guess that these bugs are in the disk image builder.

What do you think?

    Regards,
      Mark

Re: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Sat, 8 Dec 2018 17:39:01 +0100
> swedebugia <swedebugia@riseup.net> wrote:
>
>> Could we pre-order some of these owned by the foundation to
>> be used to to hack on this?
>> 
>> See https://www.crowdsupply.com/eoma68/micro-desktop
>
> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done (for
> example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
> Note: The latter thing counts as "successful" build.  WTF?).

This sounds like two distinct bugs:

* Regarding the lack of disk space: if I'm not mistaken, as things are
  currently implemented, we must specify the size of the disk image
  manually.  I guess we need to increase the size.

* This error that occurs within QEMU is apparently not being propagated
  to the outer build script.  That should be fixed.

> I'm now setting up my own build server and trying to get the flash image
> that way - which is ridiculous.

You seem to be assuming that the problem building the disk image is a
Hydra-specific problem.  Do you have reason to believe so?  I would
guess that these bugs are in the disk image builder.

What do you think?

    Regards,
      Mark

bug#33676: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Sat, 08 Dec 2018 18:34:04 +0100
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> > Guix received one but we have so far be unable to get the GuixSD flash
>> > image because something always breaks on Hydra before it's done (for
>> > example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
>> > Note: The latter thing counts as "successful" build.  WTF?).  
>> 
>> Is this now better with ci.guix.info (berlin.guixsd.org)?
>
> No idea.  How to I get the flash-image using ci.guix.info ?
>
> I tried "guix system disk-image --system=armhf-linux gnu/system/install.scm" but
> that builds a lot of stuff from source.  Let's see whether it will be done before
> the sun exploded :)

I’d suggest trying again, and possibly retrying a bit later so that
substitutes have had a chance to be “baked”.

hydra.gnu.org and now ci.guix.info both provide armhf-linux substitutes.
They have much less armv7 CPU power than x86 but still, it shouldn’t be
that bad.

Ludo’.

Re: bug#33676: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Sat, 08 Dec 2018 18:34:04 +0100
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> > Guix received one but we have so far be unable to get the GuixSD flash
>> > image because something always breaks on Hydra before it's done (for
>> > example lack of disk space - see https://hydra.gnu.org/build/3198097/log/raw .
>> > Note: The latter thing counts as "successful" build.  WTF?).  
>> 
>> Is this now better with ci.guix.info (berlin.guixsd.org)?
>
> No idea.  How to I get the flash-image using ci.guix.info ?
>
> I tried "guix system disk-image --system=armhf-linux gnu/system/install.scm" but
> that builds a lot of stuff from source.  Let's see whether it will be done before
> the sun exploded :)

I’d suggest trying again, and possibly retrying a bit later so that
substitutes have had a chance to be “baked”.

hydra.gnu.org and now ci.guix.info both provide armhf-linux substitutes.
They have much less armv7 CPU power than x86 but still, it shouldn’t be
that bad.

Ludo’.

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

Hi Mark,

On Sat, 08 Dec 2018 15:59:58 -0500
Mark H Weaver <mhw@netris.org> wrote:

> This sounds like two distinct bugs:
> 
> * Regarding the lack of disk space: if I'm not mistaken, as things are
>   currently implemented, we must specify the size of the disk image
>   manually.  I guess we need to increase the size.

Ah, you are right!  https://hydra.gnu.org/build/3194622/log/raw (the usb-image
for i686) also fails - but nobody noticed because we only distribute the iso
image (which determines its size dynamically).

I didn't make the connection that this is a fixed-size guest filesystem before.

> * This error that occurs within QEMU is apparently not being propagated
>   to the outer build script.  That should be fixed.

Yes.

> > I'm now setting up my own build server and trying to get the flash image
> > that way - which is ridiculous.  
> 
> You seem to be assuming that the problem building the disk image is a
> Hydra-specific problem.  Do you have reason to believe so?  I would
> guess that these bugs are in the disk image builder.

Probably!

According to the progress bar it's missing an additional 40% ?  That's... large.

I've increased the size for the time being, but according to the logs
it was at 800 MiB in 2015.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

Hi Mark,

On Sat, 08 Dec 2018 15:59:58 -0500
Mark H Weaver <mhw@netris.org> wrote:

> This sounds like two distinct bugs:
> 
> * Regarding the lack of disk space: if I'm not mistaken, as things are
>   currently implemented, we must specify the size of the disk image
>   manually.  I guess we need to increase the size.

Ah, you are right!  https://hydra.gnu.org/build/3194622/log/raw (the usb-image
for i686) also fails - but nobody noticed because we only distribute the iso
image (which determines its size dynamically).

I didn't make the connection that this is a fixed-size guest filesystem before.

> * This error that occurs within QEMU is apparently not being propagated
>   to the outer build script.  That should be fixed.

Yes.

> > I'm now setting up my own build server and trying to get the flash image
> > that way - which is ridiculous.  
> 
> You seem to be assuming that the problem building the disk image is a
> Hydra-specific problem.  Do you have reason to believe so?  I would
> guess that these bugs are in the disk image builder.

Probably!

According to the progress bar it's missing an additional 40% ?  That's... large.

I've increased the size for the time being, but according to the logs
it was at 800 MiB in 2015.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:

---------------------------------------------------------------------------
@ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
creating raw image of 1024.00 MiB...
Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
Backtrace:
           2 (primitive-load "/gnu/store/c2phacd8p7x3g8ysnzrx09jmnxp?")
In ./gnu/build/vm.scm:
    152:2  1 (load-in-linux-vm _ #:output _ #:qemu _ #:memory-size _ ?)
In ./guix/build/utils.scm:
    616:6  0 (invoke _ . _)

./guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "qemu-system-x86_64" arguments: ("-nographic" "-no-reboot" "-m" "256" "-object" "rng-random,filename=/dev/urandom,id=guixsd-vm-rng" "-device" "virtio-rng-pci,rng=guixsd-vm-rng" "-virtfs" "local,id=store_dev,path=/gnu/store,security_model=none,mount_tag=store" "-virtfs" "local,id=xchg_dev,path=xchg,security_model=none,mount_tag=xchg" "-virtfs" "local,id=tmp_dev,path=tmp,security_model=none,mount_tag=tmp" "-kernel" "/gnu/store/fnpr2q7nwrqs7jb9dx7pd2v47z1g867v-linux-libre-4.19.7/bzImage" "-initrd" "/gnu/store/2rkg1w4v2c87ijk9mwba55whnq4v90dw-raw-initrd/initrd.cpio.gz" "-device" "virtio-blk,drive=myhd" "-drive" "if=none,file=/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image,format=raw,id=myhd" "-enable-kvm" "-append" "panic=1 --load=/gnu/store/hqfz1xq82zgq5z1pm7bqisdr4xjsy95x-linux-vm-loader console=ttyS0" "-net" "nic,model=virtio") exit-status: 1 term-signal: #f stop-signal: #f] 5f6b00>)'.
builder for `/gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv' failed with exit code 1
@ build-failed /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - 1 builder for `/gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv' failed with exit code 1
---------------------------------------------------------------------------

What does it mean?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:

---------------------------------------------------------------------------
@ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
creating raw image of 1024.00 MiB...
Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
Backtrace:
           2 (primitive-load "/gnu/store/c2phacd8p7x3g8ysnzrx09jmnxp?")
In ./gnu/build/vm.scm:
    152:2  1 (load-in-linux-vm _ #:output _ #:qemu _ #:memory-size _ ?)
In ./guix/build/utils.scm:
    616:6  0 (invoke _ . _)

./guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "qemu-system-x86_64" arguments: ("-nographic" "-no-reboot" "-m" "256" "-object" "rng-random,filename=/dev/urandom,id=guixsd-vm-rng" "-device" "virtio-rng-pci,rng=guixsd-vm-rng" "-virtfs" "local,id=store_dev,path=/gnu/store,security_model=none,mount_tag=store" "-virtfs" "local,id=xchg_dev,path=xchg,security_model=none,mount_tag=xchg" "-virtfs" "local,id=tmp_dev,path=tmp,security_model=none,mount_tag=tmp" "-kernel" "/gnu/store/fnpr2q7nwrqs7jb9dx7pd2v47z1g867v-linux-libre-4.19.7/bzImage" "-initrd" "/gnu/store/2rkg1w4v2c87ijk9mwba55whnq4v90dw-raw-initrd/initrd.cpio.gz" "-device" "virtio-blk,drive=myhd" "-drive" "if=none,file=/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image,format=raw,id=myhd" "-enable-kvm" "-append" "panic=1 --load=/gnu/store/hqfz1xq82zgq5z1pm7bqisdr4xjsy95x-linux-vm-loader console=ttyS0" "-net" "nic,model=virtio") exit-status: 1 term-signal: #f stop-signal: #f] 5f6b00>)'.
builder for `/gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv' failed with exit code 1
@ build-failed /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - 1 builder for `/gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv' failed with exit code 1
---------------------------------------------------------------------------

What does it mean?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Danny and Ludovic,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:
>
> ---------------------------------------------------------------------------
> @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
> environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
> creating raw image of 1024.00 MiB...
> Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
> Could not access KVM kernel module: Permission denied
> qemu-system-x86_64: failed to initialize KVM: Permission denied

This indicates that /dev/kvm on hydra.gnunet.org has permissions that
prevent the guix build user from accessing it.

I raised this issue long ago (2015) on the guix-sysadmin mailing list.
In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
0600 and is owned by root, which caused our disk image derivations to
fail.

At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
but that for some reason that didn't seem to work, possibly because it
was being overridden by another rule or startup script.  As far as I
know, we never implemented a proper fix.

Ludovic, for now, can you chmod it again?

     Thanks,
       Mark

Re: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Danny and Ludovic,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:
>
> ---------------------------------------------------------------------------
> @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
> environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
> creating raw image of 1024.00 MiB...
> Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
> Could not access KVM kernel module: Permission denied
> qemu-system-x86_64: failed to initialize KVM: Permission denied

This indicates that /dev/kvm on hydra.gnunet.org has permissions that
prevent the guix build user from accessing it.

I raised this issue long ago (2015) on the guix-sysadmin mailing list.
In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
0600 and is owned by root, which caused our disk image derivations to
fail.

At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
but that for some reason that didn't seem to work, possibly because it
was being overridden by another rule or startup script.  As far as I
know, we never implemented a proper fix.

Ludovic, for now, can you chmod it again?

     Thanks,
       Mark

bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Sat, Dec 08, 2018 at 06:12:14PM +0100, Danny Milosavljevic wrote:
> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done

although the problem seems to lie somewhere else, I would just like to
point out that you can use your account on bayfront to build things for
arm as well - it offloads to the redhill machine. Notice, however, that
this is a single machine building everything from source without using
the hydra or berlin build farms for substitutes.

I can also give you a direct login on redhill if you need it.

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Sat, Dec 08, 2018 at 06:12:14PM +0100, Danny Milosavljevic wrote:
> Guix received one but we have so far be unable to get the GuixSD flash
> image because something always breaks on Hydra before it's done

although the problem seems to lie somewhere else, I would just like to
point out that you can use your account on bayfront to build things for
arm as well - it offloads to the redhill machine. Notice, however, that
this is a single machine building everything from source without using
the hydra or berlin build farms for substitutes.

I can also give you a direct login on redhill if you need it.

Andreas

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

Hi Andreas,

I've tried it now and I get:

dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image --system=armhf-linux gnu/system/install.scm
...
importing file or directory '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
ootstrap-0'...
found valid signature for '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
tstrap-0'
guix offload: error: link: No space left on device
cannot build derivation `/gnu/store/mdc6h56cg0a8i09rh0zbw5kgipwlnvln-binutils-cr
oss-boot0-2.31.1.drv': 1 dependencies couldn't be built

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Mon, Dec 10, 2018 at 11:30:14AM +0100, Danny Milosavljevic wrote:
> I've tried it now and I get:
> dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image --system=armhf-linux gnu/system/install.scm
> ...
> importing file or directory '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
> ootstrap-0'...
> found valid signature for '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
> tstrap-0'
> guix offload: error: link: No space left on device

this is the mysterious error message we have seen before: There is still
plenty of space on all the machines! I think it was related to an ext4
limitation on the number of files, or the number of files inside a single
directory. I ran some garbage collection on bayfront, and it can now offload
and retrieve builds again. Please give it another try!

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

Hello Danny,

On Mon, Dec 10, 2018 at 11:30:14AM +0100, Danny Milosavljevic wrote:
> I've tried it now and I get:
> dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image --system=armhf-linux gnu/system/install.scm
> ...
> importing file or directory '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
> ootstrap-0'...
> found valid signature for '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
> tstrap-0'
> guix offload: error: link: No space left on device

this is the mysterious error message we have seen before: There is still
plenty of space on all the machines! I think it was related to an ext4
limitation on the number of files, or the number of files inside a single
directory. I ran some garbage collection on bayfront, and it can now offload
and retrieve builds again. Please give it another try!

Andreas

bug#33676: GuixSD on eoma68-a20?

[Luke Kenneth Casson Leighton]

hi folks,

good to see there's progress on this.  do make sure to use a UHC Class
10 micro-sd card (the ones that say they are 75-80mbytes/sec), they
will happily run at 20-25mbytes/sec read/write speed, which is about
the same speed as an SSD from around 2012.

you should get a boot to xfce4 or lxde of around 20-25 seconds: again,
comparable with a budget processor from around 5-8 years ago (which is
what this is).  for god's sake don't peddle gnome3 or kde4 at
end-users.  the performance will be absolutely atrocious, absolutely
guaranteed.

yes, the idea is to upgrade (and sell or repurpose the old one).  this
is the *first* in the series.

for building can i recommend using "-Wl,--no-keep-memory" and report
if it helps, here:
https://sourceware.org/bugzilla/show_bug.cgi?id=22831

there is a slow-boil linker problem which is similar to the "640k
should be enough for anybody" - all of the quotes historic quotes
techniques which used to be implemented to make it possible to link
programs where there is not enough virtual or physical memory have
been ripped out because "4GB should be enough for anybody".

firefox now requires a staggering SEVEN GIGABYTES to successfully
link.  this is insane.  please do try that linker option because
otherwise people will believe that 32-bit hardware needs to be
destroyed, due to it being utterly useless.

l.

bug#33676: GuixSD on eoma68-a20?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Sun, Dec 09, 2018 at 04:32:00PM -0500, Mark H Weaver wrote:
> Hi Danny and Ludovic,
> 
> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:
> >
> > ---------------------------------------------------------------------------
> > @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
> > environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
> > creating raw image of 1024.00 MiB...
> > Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
> > Could not access KVM kernel module: Permission denied
> > qemu-system-x86_64: failed to initialize KVM: Permission denied
> 
> This indicates that /dev/kvm on hydra.gnunet.org has permissions that
> prevent the guix build user from accessing it.
> 
> I raised this issue long ago (2015) on the guix-sysadmin mailing list.
> In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
> 0600 and is owned by root, which caused our disk image derivations to
> fail.
> 
> At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
> to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
> but that for some reason that didn't seem to work, possibly because it
> was being overridden by another rule or startup script.  As far as I
> know, we never implemented a proper fix.
> 
> Ludovic, for now, can you chmod it again?
> 
>      Thanks,
>        Mark

time for a crontab hack job?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: bug#33676: GuixSD on eoma68-a20?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

On Sun, Dec 09, 2018 at 04:32:00PM -0500, Mark H Weaver wrote:
> Hi Danny and Ludovic,
> 
> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:
> >
> > ---------------------------------------------------------------------------
> > @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
> > environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
> > creating raw image of 1024.00 MiB...
> > Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
> > Could not access KVM kernel module: Permission denied
> > qemu-system-x86_64: failed to initialize KVM: Permission denied
> 
> This indicates that /dev/kvm on hydra.gnunet.org has permissions that
> prevent the guix build user from accessing it.
> 
> I raised this issue long ago (2015) on the guix-sysadmin mailing list.
> In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
> 0600 and is owned by root, which caused our disk image derivations to
> fail.
> 
> At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
> to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
> but that for some reason that didn't seem to work, possibly because it
> was being overridden by another rule or startup script.  As far as I
> know, we never implemented a proper fix.
> 
> Ludovic, for now, can you chmod it again?
> 
>      Thanks,
>        Mark

time for a crontab hack job?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
>
>> After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:
>>
>> ---------------------------------------------------------------------------
>> @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
>> environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
>> creating raw image of 1024.00 MiB...
>> Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
>> Could not access KVM kernel module: Permission denied
>> qemu-system-x86_64: failed to initialize KVM: Permission denied
>
> This indicates that /dev/kvm on hydra.gnunet.org has permissions that
> prevent the guix build user from accessing it.
>
> I raised this issue long ago (2015) on the guix-sysadmin mailing list.
> In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
> 0600 and is owned by root, which caused our disk image derivations to
> fail.
>
> At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
> to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
> but that for some reason that didn't seem to work, possibly because it
> was being overridden by another rule or startup script.  As far as I
> know, we never implemented a proper fix.
>
> Ludovic, for now, can you chmod it again?

I did that again this morning.

Apparently there was a typo in the udev rules I had written: “=” instead
of “==”…  Should be better now on the next reboot.

Ludo’.

Re: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
>
>> After the change, I get the following on Hydra <https://hydra.gnu.org/build/3253608/log/raw>:
>>
>> ---------------------------------------------------------------------------
>> @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv.bz2
>> environment variable `PATH' set to `/gnu/store/5ka9gmcwcj2919q0cj0wkjng058lwrgq-qemu-minimal-3.0.0/bin:/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin'
>> creating raw image of 1024.00 MiB...
>> Formatting '/gnu/store/4yp6s4jlq2frb2jqzd7q3kp99vzmnpm5-disk-image', fmt=raw size=1073741824
>> Could not access KVM kernel module: Permission denied
>> qemu-system-x86_64: failed to initialize KVM: Permission denied
>
> This indicates that /dev/kvm on hydra.gnunet.org has permissions that
> prevent the guix build user from accessing it.
>
> I raised this issue long ago (2015) on the guix-sysadmin mailing list.
> In that message, I noted that on hydra.gnunet.org, /dev/kvm has mode
> 0600 and is owned by root, which caused our disk image derivations to
> fail.
>
> At the time, Ludovic chmod'd /dev/kvm, and mentioned that he had tried
> to make this persistent via /etc/udev/rules.d/70-persistent-net.rules,
> but that for some reason that didn't seem to work, possibly because it
> was being overridden by another rule or startup script.  As far as I
> know, we never implemented a proper fix.
>
> Ludovic, for now, can you chmod it again?

I did that again this morning.

Apparently there was a typo in the udev rules I had written: “=” instead
of “==”…  Should be better now on the next reboot.

Ludo’.

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

Yessss!

flash-image just successfully built on Hydra.

Can I have the resulting file please?

See https://hydra.gnu.org/build/3255541/log/raw

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

Yessss!

flash-image just successfully built on Hydra.

Can I have the resulting file please?

See https://hydra.gnu.org/build/3255541/log/raw

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hello!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Yessss!
>
> flash-image just successfully built on Hydra.
>
> Can I have the resulting file please?
>
> See https://hydra.gnu.org/build/3255541/log/raw

I believe you can download it by running:

  guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

If you don’t have this .drv, you should be able to build it from commit
cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

See all the details at <https://hydra.gnu.org/build/3255541>.

Ludo’.

Re: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hello!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Yessss!
>
> flash-image just successfully built on Hydra.
>
> Can I have the resulting file please?
>
> See https://hydra.gnu.org/build/3255541/log/raw

I believe you can download it by running:

  guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

If you don’t have this .drv, you should be able to build it from commit
cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

See all the details at <https://hydra.gnu.org/build/3255541>.

Ludo’.

bug#33676: ENOSPC upon offloading

[Ludovic Courtès]

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I've tried it now and I get:
>
> dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image --system=armhf-linux gnu/system/install.scm
> ...
> importing file or directory '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
> ootstrap-0'...
> found valid signature for '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
> tstrap-0'
> guix offload: error: link: No space left on device
> cannot build derivation `/gnu/store/mdc6h56cg0a8i09rh0zbw5kgipwlnvln-binutils-cr
> oss-boot0-2.31.1.drv': 1 dependencies couldn't be built

I looked again at the code and found the issue, now fixed in
adb158b7396cbdcda347fa298978408e531a03fd.

We’ll have to update the ‘guix’ package and deploy it to actually get
the fix.

Thanks,
Ludo’.

ENOSPC upon offloading

[Ludovic Courtès]

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I've tried it now and I get:
>
> dannym@bayfront ~/src/guix$ ./pre-inst-env guix system disk-image --system=armhf-linux gnu/system/install.scm
> ...
> importing file or directory '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-b
> ootstrap-0'...
> found valid signature for '/gnu/store/3qrkj5zqmhnkr953xznmy96fq8i55ia5-glibc-boo
> tstrap-0'
> guix offload: error: link: No space left on device
> cannot build derivation `/gnu/store/mdc6h56cg0a8i09rh0zbw5kgipwlnvln-binutils-cr
> oss-boot0-2.31.1.drv': 1 dependencies couldn't be built

I looked again at the code and found the issue, now fixed in
adb158b7396cbdcda347fa298978408e531a03fd.

We’ll have to update the ‘guix’ package and deploy it to actually get
the fix.

Thanks,
Ludo’.

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

Hi Andreas,

can you check whether dirindex (hashtables for directory) is enabled?

# tune2fs -l /dev/... | grep -o dir_index

See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

Hi Andreas,

can you check whether dirindex (hashtables for directory) is enabled?

# tune2fs -l /dev/... | grep -o dir_index

See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> can you check whether dirindex (hashtables for directory) is enabled?
> # tune2fs -l /dev/... | grep -o dir_index
> See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

It was, and I disabled it. Hopefully this does not break anything...
But does this not mean a big performance hit on /gnu/store/.links?

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> can you check whether dirindex (hashtables for directory) is enabled?
> # tune2fs -l /dev/... | grep -o dir_index
> See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

It was, and I disabled it. Hopefully this does not break anything...
But does this not mean a big performance hit on /gnu/store/.links?

Andreas

bug#33676: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
>> can you check whether dirindex (hashtables for directory) is enabled?
>> # tune2fs -l /dev/... | grep -o dir_index
>> See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
>
> It was, and I disabled it. Hopefully this does not break anything...

Why did you disable it?

> But does this not mean a big performance hit on /gnu/store/.links?

I would expect disabling dir_index to be a big performance hit on Guix
systems, and especially those with a large store, such a build farm
master nodes.

      Mark

Re: bug#33676: GuixSD on eoma68-a20?

[Mark H Weaver]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
>> can you check whether dirindex (hashtables for directory) is enabled?
>> # tune2fs -l /dev/... | grep -o dir_index
>> See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
>
> It was, and I disabled it. Hopefully this does not break anything...

Why did you disable it?

> But does this not mean a big performance hit on /gnu/store/.links?

I would expect disabling dir_index to be a big performance hit on Guix
systems, and especially those with a large store, such a build farm
master nodes.

      Mark

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Hi Andreas,

On Sat, 15 Dec 2018 11:29:06 +0100
Andreas Enge <andreas@enge.fr> wrote:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> > can you check whether dirindex (hashtables for directory) is enabled?
> > # tune2fs -l /dev/... | grep -o dir_index
> > See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html  
> 
> It was, and I disabled it. Hopefully this does not break anything...
> But does this not mean a big performance hit on /gnu/store/.links?

It does mean that because it uses a linear search to find the file names now.

What ext filesystem is it?

https://en.wikipedia.org/wiki/Ext4 says that ext4 supports B trees - which
should have no problems with hash collisions (it uses operator< to construct
a tree -- and not hashes to construct a list).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Hi Andreas,

On Sat, 15 Dec 2018 11:29:06 +0100
Andreas Enge <andreas@enge.fr> wrote:

> On Fri, Dec 14, 2018 at 09:50:26PM +0100, Danny Milosavljevic wrote:
> > can you check whether dirindex (hashtables for directory) is enabled?
> > # tune2fs -l /dev/... | grep -o dir_index
> > See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html  
> 
> It was, and I disabled it. Hopefully this does not break anything...
> But does this not mean a big performance hit on /gnu/store/.links?

It does mean that because it uses a linear search to find the file names now.

What ext filesystem is it?

https://en.wikipedia.org/wiki/Ext4 says that ext4 supports B trees - which
should have no problems with hash collisions (it uses operator< to construct
a tree -- and not hashes to construct a list).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 3987 bytes --]

Hi Ludo,

On Fri, 14 Dec 2018 11:48:52 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

> I believe you can download it by running:
> 
>   guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

I don't have it.

> If you don’t have this .drv, you should be able to build it from commit
> cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

I tried

./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu system install)) (operating-system (inherit installation-os) (bootloader (bootloader-configuration (bootloader u-boot-bootloader) (target #f)))))'

and I get:

[...]
The following package will be installed:
   guile-bootstrap      2.0     /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0

The following derivation will be built:
   /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv
building /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv...
1 package in profile
The following environment variable definitions may be needed:
   export PATH="t-profile-15269/bin${PATH:+:}$PATH"
++ guix package -A guile-bootstrap
++ cut -f 1-2
Backtrace:
In guix/ui.scm:
  1603:12 19 (run-guix-command _ . _)
In ice-9/boot-9.scm:
    829:9 18 (catch _ _ #<procedure fed02558 at guix/ui.scm:615:2 (…> …)
    829:9 17 (catch _ _ #<procedure fed02568 at guix/ui.scm:733:6 (…> …)
In guix/scripts/package.scm:
    914:8 16 (_)
   729:25 15 (process-query _)
In guix/discovery.scm:
    155:3 14 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
    45:26 13 (fold2 #<procedure 1229310 at guix/discovery.scm:155:1…> …)
    45:26 12 (fold2 #<procedure 22f5a0 at guix/discovery.scm:156:19…> …)
In guix/discovery.scm:
   158:33 11 (_ #<package scmutils@20160827 gnu/packages/scheme.scm…> …)
In guix/scripts/package.scm:
   732:39 10 (_ #<package scmutils@20160827 gnu/packages/scheme.scm…> …)
In guix/packages.scm:
   777:17  9 (supported-package? #<package scmutils@20160827 gnu/pa…> …)
In guix/memoization.scm:
    101:0  8 (_ #<hash-table 2bc240 3740/7027> #<package scmutils@2…> …)
In srfi/srfi-1.scm:
   466:18  7 (fold #<procedure fd5d9fe8 at guix/packages.scm:764:10…> …)
In guix/packages.scm:
   768:33  6 (_ _ ("x86_64-linux" "i686-linux" "armhf-linux" "aar…" …))
In guix/memoization.scm:
    101:0  5 (_ #<hash-table 2bc240 3740/7027> #<package mit-scheme…> …)
In guix/packages.scm:
   980:46  1 (thunk)
In gnu/packages/scheme.scm:
   170:30  0 (inputs)

gnu/packages/scheme.scm:170:30: In procedure inputs:
Throw to key `match-error' with args `("match" "no matching pattern" "armhf-linux")'.
++ guix package -p t-profile-15269 -I
++ cut -f 1-2
+ test '' = 'guile-bootstrap    2.0'
+ rm -f t-profile-15269 t-profile-15269-1-link t-guix-package-file-15269
+ rm -rf t-guix-package-15269 t-home-15269
./test-env: line 1: 15250 Terminated              "/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/pre-inst-env" "/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
FAIL tests/guix-package.sh (exit status: 1)
[...]
/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:369:6: In procedure check:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "make" arguments: ("check") exit-status: 2 term-signal: #f stop-signal: #f] 1ebfa0>)'.
builder for `/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed with exit code 1
build of /gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv failed
View build log at '/var/log/guix/drvs/db/f84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv.bz2'.
guix system: error: build failed: build of `/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed

And no image...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 3987 bytes --]

Hi Ludo,

On Fri, 14 Dec 2018 11:48:52 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

> I believe you can download it by running:
> 
>   guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv

I don't have it.

> If you don’t have this .drv, you should be able to build it from commit
> cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.

I tried

./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu system install)) (operating-system (inherit installation-os) (bootloader (bootloader-configuration (bootloader u-boot-bootloader) (target #f)))))'

and I get:

[...]
The following package will be installed:
   guile-bootstrap      2.0     /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0

The following derivation will be built:
   /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv
building /tmp/guix-tests/store/dmmv0dnc8wvx9m12mln90w4b26sdxq5v-profile.drv...
1 package in profile
The following environment variable definitions may be needed:
   export PATH="t-profile-15269/bin${PATH:+:}$PATH"
++ guix package -A guile-bootstrap
++ cut -f 1-2
Backtrace:
In guix/ui.scm:
  1603:12 19 (run-guix-command _ . _)
In ice-9/boot-9.scm:
    829:9 18 (catch _ _ #<procedure fed02558 at guix/ui.scm:615:2 (…> …)
    829:9 17 (catch _ _ #<procedure fed02568 at guix/ui.scm:733:6 (…> …)
In guix/scripts/package.scm:
    914:8 16 (_)
   729:25 15 (process-query _)
In guix/discovery.scm:
    155:3 14 (fold-module-public-variables _ _ _)
In guix/combinators.scm:
    45:26 13 (fold2 #<procedure 1229310 at guix/discovery.scm:155:1…> …)
    45:26 12 (fold2 #<procedure 22f5a0 at guix/discovery.scm:156:19…> …)
In guix/discovery.scm:
   158:33 11 (_ #<package scmutils@20160827 gnu/packages/scheme.scm…> …)
In guix/scripts/package.scm:
   732:39 10 (_ #<package scmutils@20160827 gnu/packages/scheme.scm…> …)
In guix/packages.scm:
   777:17  9 (supported-package? #<package scmutils@20160827 gnu/pa…> …)
In guix/memoization.scm:
    101:0  8 (_ #<hash-table 2bc240 3740/7027> #<package scmutils@2…> …)
In srfi/srfi-1.scm:
   466:18  7 (fold #<procedure fd5d9fe8 at guix/packages.scm:764:10…> …)
In guix/packages.scm:
   768:33  6 (_ _ ("x86_64-linux" "i686-linux" "armhf-linux" "aar…" …))
In guix/memoization.scm:
    101:0  5 (_ #<hash-table 2bc240 3740/7027> #<package mit-scheme…> …)
In guix/packages.scm:
   980:46  1 (thunk)
In gnu/packages/scheme.scm:
   170:30  0 (inputs)

gnu/packages/scheme.scm:170:30: In procedure inputs:
Throw to key `match-error' with args `("match" "no matching pattern" "armhf-linux")'.
++ guix package -p t-profile-15269 -I
++ cut -f 1-2
+ test '' = 'guile-bootstrap    2.0'
+ rm -f t-profile-15269 t-profile-15269-1-link t-guix-package-file-15269
+ rm -rf t-guix-package-15269 t-home-15269
./test-env: line 1: 15250 Terminated              "/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/pre-inst-env" "/tmp/guix-build-guix-0.16.0-4.60b0402.drv-0/source/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
FAIL tests/guix-package.sh (exit status: 1)
[...]
/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:369:6: In procedure check:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "make" arguments: ("check") exit-status: 2 term-signal: #f stop-signal: #f] 1ebfa0>)'.
builder for `/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed with exit code 1
build of /gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv failed
View build log at '/var/log/guix/drvs/db/f84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv.bz2'.
guix system: error: build failed: build of `/gnu/store/dbf84br9nxk0a6d50lsgpcjkl5r4cm1s-guix-0.16.0-4.60b0402.drv' failed

And no image...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Sat, Dec 15, 2018 at 02:04:58PM -0500, Mark H Weaver wrote:
> >> See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
> > It was, and I disabled it. Hopefully this does not break anything...
> Why did you disable it?

Because we get exactly these spurious ENOSPC mentioned in the blog post
on bayfront when the disk is only one third full.

Now I am happy to try out any other combination of flags that solves the
problem.

So should I add dir_index again (is this possible live?), and then
add large_dir?

Andreas

Re: bug#33676: GuixSD on eoma68-a20?

[Andreas Enge]

On Sat, Dec 15, 2018 at 02:04:58PM -0500, Mark H Weaver wrote:
> >> See also https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html
> > It was, and I disabled it. Hopefully this does not break anything...
> Why did you disable it?

Because we get exactly these spurious ENOSPC mentioned in the blog post
on bayfront when the disk is only one third full.

Now I am happy to try out any other combination of flags that solves the
problem.

So should I add dir_index again (is this possible live?), and then
add large_dir?

Andreas

bug#33676: GuixSD on eoma68-a20?

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Fri, 14 Dec 2018 11:48:52 +0100
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> I believe you can download it by running:
>> 
>>   guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv
>
> I don't have it.
>
>> If you don’t have this .drv, you should be able to build it from commit
>> cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.
>
> I tried
>
> ./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu system install)) (operating-system (inherit installation-os) (bootloader (bootloader-configuration (bootloader u-boot-bootloader) (target #f)))))'
>
> and I get:
>
> [...]
> The following package will be installed:
>    guile-bootstrap      2.0     /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0

The solution I proposed only works if you’re using /gnu/store as your
store prefix.  Otherwise you cannot get substitutes from the build
farm.  :-/

> gnu/packages/scheme.scm:170:30: In procedure inputs:
> Throw to key `match-error' with args `("match" "no matching pattern" "armhf-linux")'.

This looks like the issue fixed in
966629a114fd90153784dfdbe5e332e0ac94f1bc.

HTH!

Ludo’.

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Hi Ludo,

> > The following package will be installed:
> >    guile-bootstrap      2.0     /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0  
> 
> The solution I proposed only works if you’re using /gnu/store as your
> store prefix.  Otherwise you cannot get substitutes from the build
> farm.  :-/

I do use /gnu/store , but I think the above was from a "guix" package unit test.

> > gnu/packages/scheme.scm:170:30: In procedure inputs:
> > Throw to key `match-error' with args `("match" "no matching pattern" "armhf-linux")'.  
> 
> This looks like the issue fixed in
> 966629a114fd90153784dfdbe5e332e0ac94f1bc.

Indeed.

Now po4a fails one of the tests.  It's not easy to get the image :)

I'll try some more...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Hi Ludo,

> > The following package will be installed:
> >    guile-bootstrap      2.0     /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0  
> 
> The solution I proposed only works if you’re using /gnu/store as your
> store prefix.  Otherwise you cannot get substitutes from the build
> farm.  :-/

I do use /gnu/store , but I think the above was from a "guix" package unit test.

> > gnu/packages/scheme.scm:170:30: In procedure inputs:
> > Throw to key `match-error' with args `("match" "no matching pattern" "armhf-linux")'.  
> 
> This looks like the issue fixed in
> 966629a114fd90153784dfdbe5e332e0ac94f1bc.

Indeed.

Now po4a fails one of the tests.  It's not easy to get the image :)

I'll try some more...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Hi Luke,

On Tue, 11 Dec 2018 02:04:59 +0000
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> good to see there's progress on this.  do make sure to use a UHC Class
> 10 micro-sd card (the ones that say they are 75-80mbytes/sec), they
> will happily run at 20-25mbytes/sec read/write speed, which is about
> the same speed as an SSD from around 2012.

Yes, I got such a card now, seems to write (including sync) quite quickly
on my laptop at least.

> yes, the idea is to upgrade (and sell or repurpose the old one).  this
> is the *first* in the series.

I understand.

> for building can i recommend using "-Wl,--no-keep-memory" and report
> if it helps, here:
> https://sourceware.org/bugzilla/show_bug.cgi?id=22831

Yeah, we've now added the linker option to several packages.
It improves the situation a lot.

Thanks!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 11821 bytes --]

Now I get:

$ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
$ ./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu system install)) (operating-system (inherit installation-os) (bootloader (bootloader-configuration (bootloader u-boot-bootloader) (target #f)))))' >QQQ3 2>&1
[...]
The following derivation will be built:
   /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
environment variable `PATH' set to `/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
creating raw image of 1265.54 MiB...
Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image', fmt=raw size=1327019190
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0 (GCC)) #1 SMP 1
[    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: linux,dummy-virt
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 16 MiB at 0x4f000000
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv0.2 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] random: get_random_bytes called from start_kernel+0xa0/0x50c with crng_init=0
[    0.000000] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192 d22708 u69632
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 64960
[    0.000000] Kernel command line: panic=1 --load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader console=ttyAMA0
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 214952K/262144K available (9216K kernel code, 1133K rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved, 16384K cma-reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff800000   ( 752 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
[    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
[    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
[    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
[    0.000000] ftrace: allocating 33359 entries in 98 pages
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
[    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
[    0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
[    0.006045] Switching to timer-based delay loop, resolution 16ns
[    0.308537] Console: colour dummy device 80x30
[    0.365555] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
[    0.373670] pid_max: default: 32768 minimum: 301
[    0.426475] Security Framework initialized
[    0.431096] Yama: becoming mindful.
[    0.506448] AppArmor: AppArmor initialized
[    0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.965208] CPU: Testing write buffer coherency: ok
[    0.998104] CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    1.411470] /cpus/cpu@0 missing clock-frequency property
[    1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    1.698318] Setting up static identity map for 0x40100000 - 0x401000a0
[    1.748454] rcu: Hierarchical SRCU implementation.
[    1.926086] EFI services will not be available.
[    1.993192] smp: Bringing up secondary CPUs ...
[    1.994874] smp: Brought up 1 node, 1 CPU
[    1.997851] SMP: Total of 1 processors activated (125.00 BogoMIPS).
[    1.998883] CPU: All CPU(s) started in SVC mode.
[    2.503281] devtmpfs: initialized
[    3.198070] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    3.746420] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    3.775416] futex hash table entries: 256 (order: 2, 16384 bytes)
[    4.121161] pinctrl core: initialized pinctrl subsystem
[    4.513079] DMI not present or invalid.
[    4.901725] NET: Registered protocol family 16
[    5.171532] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    5.247930] audit: initializing netlink subsys (disabled)
[    5.429698] audit: type=2000 audit(3.640:1): state=initialized audit_enabled=0 res=1
[    5.571864] No ATAGs?
[    5.603824] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    5.605465] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    5.716942] Serial: AMBA PL011 UART driver
[    6.689400] 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 54, base_baud = 0) is a PL011 rev1
[    6.818013] console [ttyAMA0] enabled
[...]
[   73.272363] pl061_gpio 9030000.pl061: PL061 GPIO chip @0x09030000 registered
[   73.354536] pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
[   73.383612] pci-host-generic 4010000000.pcie:    IO 0x3eff0000..0x3effffff -> 0x00000000
[   73.405201] pci-host-generic 4010000000.pcie:   MEM 0x10000000..0x3efeffff -> 0x10000000
[   73.413035] pci-host-generic 4010000000.pcie:   MEM 0x8000000000..0xffffffffff -> 0x8000000000
[   73.449129] pci-host-generic 4010000000.pcie: can't claim ECAM area [mem 0x10000000-0x1fffffff]: address conflict with pcie@10000000 [mem 0x10000000-0x3efeffff]
[   73.511869] pci-host-generic: probe of 4010000000.pcie failed with error -16
[   74.049180] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[   74.184595] Serial: AMBA driver
[...]
[   78.969555] Run /init as init process
[   80.062608] hrtimer: interrupt took 110418352 ns
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use '--repl' for an initrd REPL.

loading kernel modules...
[  135.306635] SCSI subsystem initialized
[  136.419610] Unable to handle kernel paging request at virtual address ea0003ff
[  136.432562] pgd = (ptrval)
[  136.434175] [ea0003ff] *pgd=00000000
[  136.443714] Internal error: Oops: 5 [#1] SMP ARM
[  136.448388] Modules linked in: libata(+) scsi_mod
[  136.459458] CPU: 0 PID: 1 Comm: init Not tainted 4.19.11-gnu #1
[  136.461282] Hardware name: Generic DT based system
[  136.477596] PC is at ata_attach_transport+0xd8/0x274 [libata]
[  136.483380] LR is at 0x124
[  136.484240] pc : [<bf05c190>]    lr : [<00000124>]    psr: 60000013
[  136.485268] sp : ce0fdcf0  ip : ea0003ff  fp : ce0fdd1c
[  136.486473] r10: 00000000  r9 : ea00041f  r8 : ea00040f
[  136.487498] r7 : ce3fc8bc  r6 : ce3fc8dc  r5 : ce3fc8cc  r4 : ce3fc800
[  136.488614] r3 : ce0ed040  r2 : 00000000  r1 : c10d3b14  r0 : 00000000
[  136.490476] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  136.492057] Control: 10c5387d  Table: 4e34406a  DAC: 00000051
[  136.494159] Process init (pid: 1, stack limit = 0x(ptrval))
[  136.495663] Stack: (0xce0fdcf0 to 0xce0fe000)
[  136.499157] dce0:                                     00000001 00000000 bf0778c8 c1005dcc
[  136.501950] dd00: bf079000 ffffffff bf078000 00000000 ce0fdd9c ce0fdd20 bf077c10 bf05c0c4
[  136.504080] dd20: c0f1e6b0 bf06f140 c1005dcc ce0fdd38 c01ceb30 bf078000 ce0fdd54 ffffffff
[  136.506036] dd40: c0155458 c01ceb24 ce0fdd7c ce0fdd58 c01bbaac c01553d0 c10067b4 d082000c
[  136.508122] dd60: ce0fdda8 d0820000 d0821000 f28f9aeb ce0fdda4 bf06ef40 bf0778c8 c1005dcc
[  136.510236] dd80: 00000000 bf06ef4c bf06ef40 c1005dcc ce0fde14 ce0fdda0 c01035d8 bf0778d4
[  136.512143] dda0: c0101a0c f28f9aeb ce327600 c0979f74 ce000600 ce000600 ce0fddd4 ce0fddc8
[  136.514144] ddc0: c0979f74 c01ce7d0 ce0fde14 ce0fddd8 c0308ab4 c0979f50 ce0fde04 ce0fdde8
[  136.516233] dde0: c0309c5c c03090e4 00000052 f28f9aeb ce0fdf38 bf06ef40 ce0fdf38 ce3321c0
[  136.518293] de00: bf06f070 bf06ef4c ce0fde3c ce0fde18 c01fb75c c0103594 ce0fde3c ce0fde28
[  136.520436] de20: c02f3410 00000000 ce0fdf38 bf06f040 ce0fdf14 ce0fde40 c01fa210 c01fb6f4
[  136.522398] de40: ffff8000 00007fff bf06ef40 c01f778c ce0fde98 d0820000 c1005dcc c0a08334
[  136.524853] de60: bf06f054 bf06ef44 00000a2c bf071000 014f9cf8 c0c3d374 ffffffff c0c5b674
[  136.526866] de80: c0101204 ce0fc000 ce0fdf14 ce0fde98 bf062024 00000006 bf062054 000000bf
[  136.528885] dea0: 00000000 00000000 6e72656b 00006c65 00000000 00000000 00000000 00000000
[  136.531078] dec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  136.533045] dee0: 00000000 f28f9aeb 7fffffff c1005dcc 00000000 0000000a 014f9cf8 c0101204
[  136.534976] df00: ce0fc000 0000017b ce0fdfa4 ce0fdf18 c01fa9c4 c01f84e4 7fffffff 00000000
[  136.537150] df20: 00000003 ce0fc000 ce0fdf5c d08cf000 00051ca8 00000000 d08f06f3 d08fefc0
[  136.539224] df40: d08cf000 00051ca8 d09201e0 d091ff38 d0909544 0002d000 0002f250 00000000
[  136.541281] df60: 00000000 00000000 0001490c 00000042 00000043 0000003c 0000002a 0000001b
[  136.543248] df80: 00000000 f28f9aeb 00000004 b58dac90 00053e77 0000017b 00000000 ce0fdfa8
[  136.545223] dfa0: c0101000 c01fa8f4 00000004 b58dac90 0000000a 014f9cf8 00000000 015bbf78
[  136.548002] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0 0029b25c 00161fec 00000002
[  136.550771] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2 60000030 0000000a 00000000 00000000
[  136.578059] [<bf05c190>] (ata_attach_transport [libata]) from [<bf077c10>] (ata_init+0x348/0x39c [libata])
[  136.589371] [<bf077c10>] (ata_init [libata]) from [<c01035d8>] (do_one_initcall+0x50/0x214)
[  136.596083] [<c01035d8>] (do_one_initcall) from [<c01fb75c>] (do_init_module+0x74/0x224)
[  136.598342] [<c01fb75c>] (do_init_module) from [<c01fa210>] (load_module+0x1d38/0x2228)
[  136.599851] [<c01fa210>] (load_module) from [<c01fa9c4>] (sys_finit_module+0xdc/0x110)
[  136.601640] [<c01fa9c4>] (sys_finit_module) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
[  136.603227] Exception stack(0xce0fdfa8 to 0xce0fdff0)
[  136.605053] dfa0:                   00000004 b58dac90 0000000a 014f9cf8 00000000 015bbf78
[  136.607122] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0 0029b25c 00161fec 00000002
[  136.608630] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2
[  136.616749] Code: e59fc1a0 e3a0ef49 e28c8010 e28c9020 (e89c000f) 
[  136.631449] ---[ end trace c34b1e9ba28742f3 ]---

And then it hangs seemingly indefinitely.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[Luke Kenneth Casson Leighton]

On Fri, Dec 21, 2018 at 11:11 PM Danny Milosavljevic
<dannym@scratchpost.org> wrote:

> Yeah, we've now added the linker option to several packages.
> It improves the situation a lot.

 GREAT!  i'll cross-reference to the sourceware bug, that's really
good to hear.  it's not perfect: really, ld needs to be massively
improved, bringing back techniques that were deleted from the source
code at least 15 years ago.

l.

bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 00:09, Danny Milosavljevic wrote:
> Now I get:
> 
> $ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
> $ ./pre-inst-env guix system disk-image --system=armhf-linux -e
> '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader
> u-boot) (gnu system install)) (operating-system (inherit
> installation-os) (bootloader (bootloader-configuration (bootloader
> u-boot-bootloader) (target #f)))))' >QQQ3 2>&1
> [...]
> The following derivation will be built:
>    /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
> building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
> environment variable `PATH' set to
> `/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
> creating raw image of 1265.54 MiB...
> Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image',
> fmt=raw size=1327019190
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0
> (GCC)) #1 SMP 1
> [    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> [    0.000000] OF: fdt: Machine model: linux,dummy-virt
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] efi: Getting EFI parameters from FDT:
> [    0.000000] efi: UEFI not found.
> [    0.000000] cma: Reserved 16 MiB at 0x4f000000
> [    0.000000] psci: probing for conduit method from DT.
> [    0.000000] psci: PSCIv0.2 detected in firmware.
> [    0.000000] psci: Using standard PSCI v0.2 function IDs
> [    0.000000] psci: Trusted OS migration not required
> [    0.000000] random: get_random_bytes called from
> start_kernel+0xa0/0x50c with crng_init=0
> [    0.000000] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192
> d22708 u69632
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 64960
> [    0.000000] Kernel command line: panic=1
> --load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader
> console=ttyAMA0
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Memory: 214952K/262144K available (9216K kernel code,
> 1133K rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved,
> 16384K cma-reserved, 0K highmem)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> [    0.000000]     vmalloc : 0xd0800000 - 0xff800000   ( 752 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
> [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
> [    0.000000] ftrace: allocating 33359 entries in 98 pages
> [    0.000000] rcu: Hierarchical RCU implementation.
> [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
> [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> [    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> [    0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps
> every 4398046511096ns
> [    0.006045] Switching to timer-based delay loop, resolution 16ns
> [    0.308537] Console: colour dummy device 80x30
> [    0.365555] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 125.00 BogoMIPS (lpj=250000)
> [    0.373670] pid_max: default: 32768 minimum: 301
> [    0.426475] Security Framework initialized
> [    0.431096] Yama: becoming mindful.
> [    0.506448] AppArmor: AppArmor initialized
> [    0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.965208] CPU: Testing write buffer coherency: ok
> [    0.998104] CPU0: Spectre v2: firmware did not set auxiliary
> control register IBE bit, system vulnerable
> [    1.411470] /cpus/cpu@0 missing clock-frequency property
> [    1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    1.698318] Setting up static identity map for 0x40100000 - 0x401000a0
> [    1.748454] rcu: Hierarchical SRCU implementation.
> [    1.926086] EFI services will not be available.
> [    1.993192] smp: Bringing up secondary CPUs ...
> [    1.994874] smp: Brought up 1 node, 1 CPU
> [    1.997851] SMP: Total of 1 processors activated (125.00 BogoMIPS).
> [    1.998883] CPU: All CPU(s) started in SVC mode.
> [    2.503281] devtmpfs: initialized
> [    3.198070] VFP support v0.3: implementor 41 architecture 4 part 30
> variant f rev 0
> [    3.746420] clocksource: jiffies: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 7645041785100000 ns
> [    3.775416] futex hash table entries: 256 (order: 2, 16384 bytes)
> [    4.121161] pinctrl core: initialized pinctrl subsystem
> [    4.513079] DMI not present or invalid.
> [    4.901725] NET: Registered protocol family 16
> [    5.171532] DMA: preallocated 256 KiB pool for atomic coherent allocations
> [    5.247930] audit: initializing netlink subsys (disabled)
> [    5.429698] audit: type=2000 audit(3.640:1): state=initialized
> audit_enabled=0 res=1
> [    5.571864] No ATAGs?
> [    5.603824] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4
> watchpoint registers.
> [    5.605465] hw-breakpoint: maximum watchpoint size is 8 bytes.
> [    5.716942] Serial: AMBA PL011 UART driver
> [    6.689400] 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 54,
> base_baud = 0) is a PL011 rev1
> [    6.818013] console [ttyAMA0] enabled
> [...]
> [   73.272363] pl061_gpio 9030000.pl061: PL061 GPIO chip @0x09030000 registered
> [   73.354536] pci-host-generic 4010000000.pcie: host bridge
> /pcie@10000000 ranges:
> [   73.383612] pci-host-generic 4010000000.pcie:    IO
> 0x3eff0000..0x3effffff -> 0x00000000
> [   73.405201] pci-host-generic 4010000000.pcie:   MEM
> 0x10000000..0x3efeffff -> 0x10000000
> [   73.413035] pci-host-generic 4010000000.pcie:   MEM
> 0x8000000000..0xffffffffff -> 0x8000000000
> [   73.449129] pci-host-generic 4010000000.pcie: can't claim ECAM area
> [mem 0x10000000-0x1fffffff]: address conflict with pcie@10000000 [mem
> 0x10000000-0x3efeffff]
> [   73.511869] pci-host-generic: probe of 4010000000.pcie failed with error -16
> [   74.049180] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [   74.184595] Serial: AMBA driver
> [...]
> [   78.969555] Run /init as init process
> [   80.062608] hrtimer: interrupt took 110418352 ns
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
> GC Warning: Couldn't read /proc/stat
> Welcome, this is GNU's early boot Guile.
> Use '--repl' for an initrd REPL.
> 
> loading kernel modules...
> [  135.306635] SCSI subsystem initialized
> [  136.419610] Unable to handle kernel paging request at virtual
> address ea0003ff
> [  136.432562] pgd = (ptrval)
> [  136.434175] [ea0003ff] *pgd=00000000
> [  136.443714] Internal error: Oops: 5 [#1] SMP ARM
> [  136.448388] Modules linked in: libata(+) scsi_mod
> [  136.459458] CPU: 0 PID: 1 Comm: init Not tainted 4.19.11-gnu #1
> [  136.461282] Hardware name: Generic DT based system
> [  136.477596] PC is at ata_attach_transport+0xd8/0x274 [libata]
> [  136.483380] LR is at 0x124
> [  136.484240] pc : [<bf05c190>]    lr : [<00000124>]    psr: 60000013
> [  136.485268] sp : ce0fdcf0  ip : ea0003ff  fp : ce0fdd1c
> [  136.486473] r10: 00000000  r9 : ea00041f  r8 : ea00040f
> [  136.487498] r7 : ce3fc8bc  r6 : ce3fc8dc  r5 : ce3fc8cc  r4 : ce3fc800
> [  136.488614] r3 : ce0ed040  r2 : 00000000  r1 : c10d3b14  r0 : 00000000
> [  136.490476] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [  136.492057] Control: 10c5387d  Table: 4e34406a  DAC: 00000051
> [  136.494159] Process init (pid: 1, stack limit = 0x(ptrval))
> [  136.495663] Stack: (0xce0fdcf0 to 0xce0fe000)
> [  136.499157] dce0:                                     00000001
> 00000000 bf0778c8 c1005dcc
> [  136.501950] dd00: bf079000 ffffffff bf078000 00000000 ce0fdd9c
> ce0fdd20 bf077c10 bf05c0c4
> [  136.504080] dd20: c0f1e6b0 bf06f140 c1005dcc ce0fdd38 c01ceb30
> bf078000 ce0fdd54 ffffffff
> [  136.506036] dd40: c0155458 c01ceb24 ce0fdd7c ce0fdd58 c01bbaac
> c01553d0 c10067b4 d082000c
> [  136.508122] dd60: ce0fdda8 d0820000 d0821000 f28f9aeb ce0fdda4
> bf06ef40 bf0778c8 c1005dcc
> [  136.510236] dd80: 00000000 bf06ef4c bf06ef40 c1005dcc ce0fde14
> ce0fdda0 c01035d8 bf0778d4
> [  136.512143] dda0: c0101a0c f28f9aeb ce327600 c0979f74 ce000600
> ce000600 ce0fddd4 ce0fddc8
> [  136.514144] ddc0: c0979f74 c01ce7d0 ce0fde14 ce0fddd8 c0308ab4
> c0979f50 ce0fde04 ce0fdde8
> [  136.516233] dde0: c0309c5c c03090e4 00000052 f28f9aeb ce0fdf38
> bf06ef40 ce0fdf38 ce3321c0
> [  136.518293] de00: bf06f070 bf06ef4c ce0fde3c ce0fde18 c01fb75c
> c0103594 ce0fde3c ce0fde28
> [  136.520436] de20: c02f3410 00000000 ce0fdf38 bf06f040 ce0fdf14
> ce0fde40 c01fa210 c01fb6f4
> [  136.522398] de40: ffff8000 00007fff bf06ef40 c01f778c ce0fde98
> d0820000 c1005dcc c0a08334
> [  136.524853] de60: bf06f054 bf06ef44 00000a2c bf071000 014f9cf8
> c0c3d374 ffffffff c0c5b674
> [  136.526866] de80: c0101204 ce0fc000 ce0fdf14 ce0fde98 bf062024
> 00000006 bf062054 000000bf
> [  136.528885] dea0: 00000000 00000000 6e72656b 00006c65 00000000
> 00000000 00000000 00000000
> [  136.531078] dec0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [  136.533045] dee0: 00000000 f28f9aeb 7fffffff c1005dcc 00000000
> 0000000a 014f9cf8 c0101204
> [  136.534976] df00: ce0fc000 0000017b ce0fdfa4 ce0fdf18 c01fa9c4
> c01f84e4 7fffffff 00000000
> [  136.537150] df20: 00000003 ce0fc000 ce0fdf5c d08cf000 00051ca8
> 00000000 d08f06f3 d08fefc0
> [  136.539224] df40: d08cf000 00051ca8 d09201e0 d091ff38 d0909544
> 0002d000 0002f250 00000000
> [  136.541281] df60: 00000000 00000000 0001490c 00000042 00000043
> 0000003c 0000002a 0000001b
> [  136.543248] df80: 00000000 f28f9aeb 00000004 b58dac90 00053e77
> 0000017b 00000000 ce0fdfa8
> [  136.545223] dfa0: c0101000 c01fa8f4 00000004 b58dac90 0000000a
> 014f9cf8 00000000 015bbf78
> [  136.548002] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
> 0029b25c 00161fec 00000002
> [  136.550771] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2 60000030
> 0000000a 00000000 00000000
> [  136.578059] [<bf05c190>] (ata_attach_transport [libata]) from
> [<bf077c10>] (ata_init+0x348/0x39c [libata])
> [  136.589371] [<bf077c10>] (ata_init [libata]) from [<c01035d8>]
> (do_one_initcall+0x50/0x214)
> [  136.596083] [<c01035d8>] (do_one_initcall) from [<c01fb75c>]
> (do_init_module+0x74/0x224)
> [  136.598342] [<c01fb75c>] (do_init_module) from [<c01fa210>]
> (load_module+0x1d38/0x2228)
> [  136.599851] [<c01fa210>] (load_module) from [<c01fa9c4>]
> (sys_finit_module+0xdc/0x110)
> [  136.601640] [<c01fa9c4>] (sys_finit_module) from [<c0101000>]
> (ret_fast_syscall+0x0/0x54)
> [  136.603227] Exception stack(0xce0fdfa8 to 0xce0fdff0)
> [  136.605053] dfa0:                   00000004 b58dac90 0000000a
> 014f9cf8 00000000 015bbf78
> [  136.607122] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
> 0029b25c 00161fec 00000002
> [  136.608630] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2
> [  136.616749] Code: e59fc1a0 e3a0ef49 e28c8010 e28c9020 (e89c000f) 
> [  136.631449] ---[ end trace c34b1e9ba28742f3 ]---
> 
> And then it hangs seemingly indefinitely.

I just tried on 

Git checkout:
  repository: /home/sdb/src/guix
  branch: HEAD
  commit: d15211c9b5b46b96c5b658329624942b6ff5c917

and got:

building /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv...
@ unsupported-platform
/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv armhf-linux
while setting up the build environment: a `armhf-linux' is required to
build `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv', but I
am a `i686-linux'
builder for `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv'
failed with exit code 1
build of /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv
failed
View build log at
'/var/log/guix/drvs/ng/yvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv.bz2'.
substituting
/gnu/store/1aclmh7jy2j5084kdpbcz5xgmdzvjzzj-fontconfig-2.13.1...
cannot build derivation
`/gnu/store/hr975r813adrn92f2g7f14z39086hnbx-coreutils-8.30.drv': 1
dependencies couldn't be built
killing process 2725
cannot build derivation
`/gnu/store/c56fwipfpdpii95420xcwf3vamy3n2pa-python-3.7.0.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv':
1 dependencies couldn't be built
guix system: error: build failed: build of
`/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv'
failed

-- 
Cheers 
Swedebugia

Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 00:09, Danny Milosavljevic wrote:
> Now I get:
> 
> $ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
> $ ./pre-inst-env guix system disk-image --system=armhf-linux -e
> '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader
> u-boot) (gnu system install)) (operating-system (inherit
> installation-os) (bootloader (bootloader-configuration (bootloader
> u-boot-bootloader) (target #f)))))' >QQQ3 2>&1
> [...]
> The following derivation will be built:
>    /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
> building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
> environment variable `PATH' set to
> `/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
> creating raw image of 1265.54 MiB...
> Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image',
> fmt=raw size=1327019190
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0
> (GCC)) #1 SMP 1
> [    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> [    0.000000] OF: fdt: Machine model: linux,dummy-virt
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] efi: Getting EFI parameters from FDT:
> [    0.000000] efi: UEFI not found.
> [    0.000000] cma: Reserved 16 MiB at 0x4f000000
> [    0.000000] psci: probing for conduit method from DT.
> [    0.000000] psci: PSCIv0.2 detected in firmware.
> [    0.000000] psci: Using standard PSCI v0.2 function IDs
> [    0.000000] psci: Trusted OS migration not required
> [    0.000000] random: get_random_bytes called from
> start_kernel+0xa0/0x50c with crng_init=0
> [    0.000000] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192
> d22708 u69632
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 64960
> [    0.000000] Kernel command line: panic=1
> --load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader
> console=ttyAMA0
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Memory: 214952K/262144K available (9216K kernel code,
> 1133K rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved,
> 16384K cma-reserved, 0K highmem)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> [    0.000000]     vmalloc : 0xd0800000 - 0xff800000   ( 752 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
> [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
> [    0.000000] ftrace: allocating 33359 entries in 98 pages
> [    0.000000] rcu: Hierarchical RCU implementation.
> [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
> [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> [    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> [    0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps
> every 4398046511096ns
> [    0.006045] Switching to timer-based delay loop, resolution 16ns
> [    0.308537] Console: colour dummy device 80x30
> [    0.365555] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 125.00 BogoMIPS (lpj=250000)
> [    0.373670] pid_max: default: 32768 minimum: 301
> [    0.426475] Security Framework initialized
> [    0.431096] Yama: becoming mindful.
> [    0.506448] AppArmor: AppArmor initialized
> [    0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.965208] CPU: Testing write buffer coherency: ok
> [    0.998104] CPU0: Spectre v2: firmware did not set auxiliary
> control register IBE bit, system vulnerable
> [    1.411470] /cpus/cpu@0 missing clock-frequency property
> [    1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    1.698318] Setting up static identity map for 0x40100000 - 0x401000a0
> [    1.748454] rcu: Hierarchical SRCU implementation.
> [    1.926086] EFI services will not be available.
> [    1.993192] smp: Bringing up secondary CPUs ...
> [    1.994874] smp: Brought up 1 node, 1 CPU
> [    1.997851] SMP: Total of 1 processors activated (125.00 BogoMIPS).
> [    1.998883] CPU: All CPU(s) started in SVC mode.
> [    2.503281] devtmpfs: initialized
> [    3.198070] VFP support v0.3: implementor 41 architecture 4 part 30
> variant f rev 0
> [    3.746420] clocksource: jiffies: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 7645041785100000 ns
> [    3.775416] futex hash table entries: 256 (order: 2, 16384 bytes)
> [    4.121161] pinctrl core: initialized pinctrl subsystem
> [    4.513079] DMI not present or invalid.
> [    4.901725] NET: Registered protocol family 16
> [    5.171532] DMA: preallocated 256 KiB pool for atomic coherent allocations
> [    5.247930] audit: initializing netlink subsys (disabled)
> [    5.429698] audit: type=2000 audit(3.640:1): state=initialized
> audit_enabled=0 res=1
> [    5.571864] No ATAGs?
> [    5.603824] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4
> watchpoint registers.
> [    5.605465] hw-breakpoint: maximum watchpoint size is 8 bytes.
> [    5.716942] Serial: AMBA PL011 UART driver
> [    6.689400] 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 54,
> base_baud = 0) is a PL011 rev1
> [    6.818013] console [ttyAMA0] enabled
> [...]
> [   73.272363] pl061_gpio 9030000.pl061: PL061 GPIO chip @0x09030000 registered
> [   73.354536] pci-host-generic 4010000000.pcie: host bridge
> /pcie@10000000 ranges:
> [   73.383612] pci-host-generic 4010000000.pcie:    IO
> 0x3eff0000..0x3effffff -> 0x00000000
> [   73.405201] pci-host-generic 4010000000.pcie:   MEM
> 0x10000000..0x3efeffff -> 0x10000000
> [   73.413035] pci-host-generic 4010000000.pcie:   MEM
> 0x8000000000..0xffffffffff -> 0x8000000000
> [   73.449129] pci-host-generic 4010000000.pcie: can't claim ECAM area
> [mem 0x10000000-0x1fffffff]: address conflict with pcie@10000000 [mem
> 0x10000000-0x3efeffff]
> [   73.511869] pci-host-generic: probe of 4010000000.pcie failed with error -16
> [   74.049180] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [   74.184595] Serial: AMBA driver
> [...]
> [   78.969555] Run /init as init process
> [   80.062608] hrtimer: interrupt took 110418352 ns
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
> GC Warning: Couldn't read /proc/stat
> Welcome, this is GNU's early boot Guile.
> Use '--repl' for an initrd REPL.
> 
> loading kernel modules...
> [  135.306635] SCSI subsystem initialized
> [  136.419610] Unable to handle kernel paging request at virtual
> address ea0003ff
> [  136.432562] pgd = (ptrval)
> [  136.434175] [ea0003ff] *pgd=00000000
> [  136.443714] Internal error: Oops: 5 [#1] SMP ARM
> [  136.448388] Modules linked in: libata(+) scsi_mod
> [  136.459458] CPU: 0 PID: 1 Comm: init Not tainted 4.19.11-gnu #1
> [  136.461282] Hardware name: Generic DT based system
> [  136.477596] PC is at ata_attach_transport+0xd8/0x274 [libata]
> [  136.483380] LR is at 0x124
> [  136.484240] pc : [<bf05c190>]    lr : [<00000124>]    psr: 60000013
> [  136.485268] sp : ce0fdcf0  ip : ea0003ff  fp : ce0fdd1c
> [  136.486473] r10: 00000000  r9 : ea00041f  r8 : ea00040f
> [  136.487498] r7 : ce3fc8bc  r6 : ce3fc8dc  r5 : ce3fc8cc  r4 : ce3fc800
> [  136.488614] r3 : ce0ed040  r2 : 00000000  r1 : c10d3b14  r0 : 00000000
> [  136.490476] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [  136.492057] Control: 10c5387d  Table: 4e34406a  DAC: 00000051
> [  136.494159] Process init (pid: 1, stack limit = 0x(ptrval))
> [  136.495663] Stack: (0xce0fdcf0 to 0xce0fe000)
> [  136.499157] dce0:                                     00000001
> 00000000 bf0778c8 c1005dcc
> [  136.501950] dd00: bf079000 ffffffff bf078000 00000000 ce0fdd9c
> ce0fdd20 bf077c10 bf05c0c4
> [  136.504080] dd20: c0f1e6b0 bf06f140 c1005dcc ce0fdd38 c01ceb30
> bf078000 ce0fdd54 ffffffff
> [  136.506036] dd40: c0155458 c01ceb24 ce0fdd7c ce0fdd58 c01bbaac
> c01553d0 c10067b4 d082000c
> [  136.508122] dd60: ce0fdda8 d0820000 d0821000 f28f9aeb ce0fdda4
> bf06ef40 bf0778c8 c1005dcc
> [  136.510236] dd80: 00000000 bf06ef4c bf06ef40 c1005dcc ce0fde14
> ce0fdda0 c01035d8 bf0778d4
> [  136.512143] dda0: c0101a0c f28f9aeb ce327600 c0979f74 ce000600
> ce000600 ce0fddd4 ce0fddc8
> [  136.514144] ddc0: c0979f74 c01ce7d0 ce0fde14 ce0fddd8 c0308ab4
> c0979f50 ce0fde04 ce0fdde8
> [  136.516233] dde0: c0309c5c c03090e4 00000052 f28f9aeb ce0fdf38
> bf06ef40 ce0fdf38 ce3321c0
> [  136.518293] de00: bf06f070 bf06ef4c ce0fde3c ce0fde18 c01fb75c
> c0103594 ce0fde3c ce0fde28
> [  136.520436] de20: c02f3410 00000000 ce0fdf38 bf06f040 ce0fdf14
> ce0fde40 c01fa210 c01fb6f4
> [  136.522398] de40: ffff8000 00007fff bf06ef40 c01f778c ce0fde98
> d0820000 c1005dcc c0a08334
> [  136.524853] de60: bf06f054 bf06ef44 00000a2c bf071000 014f9cf8
> c0c3d374 ffffffff c0c5b674
> [  136.526866] de80: c0101204 ce0fc000 ce0fdf14 ce0fde98 bf062024
> 00000006 bf062054 000000bf
> [  136.528885] dea0: 00000000 00000000 6e72656b 00006c65 00000000
> 00000000 00000000 00000000
> [  136.531078] dec0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [  136.533045] dee0: 00000000 f28f9aeb 7fffffff c1005dcc 00000000
> 0000000a 014f9cf8 c0101204
> [  136.534976] df00: ce0fc000 0000017b ce0fdfa4 ce0fdf18 c01fa9c4
> c01f84e4 7fffffff 00000000
> [  136.537150] df20: 00000003 ce0fc000 ce0fdf5c d08cf000 00051ca8
> 00000000 d08f06f3 d08fefc0
> [  136.539224] df40: d08cf000 00051ca8 d09201e0 d091ff38 d0909544
> 0002d000 0002f250 00000000
> [  136.541281] df60: 00000000 00000000 0001490c 00000042 00000043
> 0000003c 0000002a 0000001b
> [  136.543248] df80: 00000000 f28f9aeb 00000004 b58dac90 00053e77
> 0000017b 00000000 ce0fdfa8
> [  136.545223] dfa0: c0101000 c01fa8f4 00000004 b58dac90 0000000a
> 014f9cf8 00000000 015bbf78
> [  136.548002] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
> 0029b25c 00161fec 00000002
> [  136.550771] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2 60000030
> 0000000a 00000000 00000000
> [  136.578059] [<bf05c190>] (ata_attach_transport [libata]) from
> [<bf077c10>] (ata_init+0x348/0x39c [libata])
> [  136.589371] [<bf077c10>] (ata_init [libata]) from [<c01035d8>]
> (do_one_initcall+0x50/0x214)
> [  136.596083] [<c01035d8>] (do_one_initcall) from [<c01fb75c>]
> (do_init_module+0x74/0x224)
> [  136.598342] [<c01fb75c>] (do_init_module) from [<c01fa210>]
> (load_module+0x1d38/0x2228)
> [  136.599851] [<c01fa210>] (load_module) from [<c01fa9c4>]
> (sys_finit_module+0xdc/0x110)
> [  136.601640] [<c01fa9c4>] (sys_finit_module) from [<c0101000>]
> (ret_fast_syscall+0x0/0x54)
> [  136.603227] Exception stack(0xce0fdfa8 to 0xce0fdff0)
> [  136.605053] dfa0:                   00000004 b58dac90 0000000a
> 014f9cf8 00000000 015bbf78
> [  136.607122] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
> 0029b25c 00161fec 00000002
> [  136.608630] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2
> [  136.616749] Code: e59fc1a0 e3a0ef49 e28c8010 e28c9020 (e89c000f) 
> [  136.631449] ---[ end trace c34b1e9ba28742f3 ]---
> 
> And then it hangs seemingly indefinitely.

I just tried on 

Git checkout:
  repository: /home/sdb/src/guix
  branch: HEAD
  commit: d15211c9b5b46b96c5b658329624942b6ff5c917

and got:

building /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv...
@ unsupported-platform
/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv armhf-linux
while setting up the build environment: a `armhf-linux' is required to
build `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv', but I
am a `i686-linux'
builder for `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv'
failed with exit code 1
build of /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv
failed
View build log at
'/var/log/guix/drvs/ng/yvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv.bz2'.
substituting
/gnu/store/1aclmh7jy2j5084kdpbcz5xgmdzvjzzj-fontconfig-2.13.1...
cannot build derivation
`/gnu/store/hr975r813adrn92f2g7f14z39086hnbx-coreutils-8.30.drv': 1
dependencies couldn't be built
killing process 2725
cannot build derivation
`/gnu/store/c56fwipfpdpii95420xcwf3vamy3n2pa-python-3.7.0.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv':
1 dependencies couldn't be built
guix system: error: build failed: build of
`/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv'
failed

-- 
Cheers 
Swedebugia

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Please add to your /etc/config.scm to the "services" section:

(service qemu-binfmt-service-type
                     (qemu-binfmt-configuration
                       (platforms (lookup-qemu-platforms "arm"))
                       (guix-support? #t)))

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Please add to your /etc/config.scm to the "services" section:

(service qemu-binfmt-service-type
                     (qemu-binfmt-configuration
                       (platforms (lookup-qemu-platforms "arm"))
                       (guix-support? #t)))

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 09:33, swedebugia@riseup.net wrote:
> On 2018-12-22 00:09, Danny Milosavljevic wrote:
>> Now I get:
>>
>> $ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
>> $ ./pre-inst-env guix system disk-image --system=armhf-linux -e
>> '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader
>> u-boot) (gnu system install)) (operating-system (inherit
>> installation-os) (bootloader (bootloader-configuration (bootloader
>> u-boot-bootloader) (target #f)))))' >QQQ3 2>&1
>> [...]
>> The following derivation will be built:
>>    /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
>> building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
>> environment variable `PATH' set to
>> `/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
>> creating raw image of 1265.54 MiB...
>> Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image',
>> fmt=raw size=1327019190
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0
>> (GCC)) #1 SMP 1
>> [    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
>> [    0.000000] CPU: div instructions available: patching division code
>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
>> [    0.000000] OF: fdt: Machine model: linux,dummy-virt
>> [    0.000000] Memory policy: Data cache writealloc
>> [    0.000000] efi: Getting EFI parameters from FDT:
>> [    0.000000] efi: UEFI not found.
>> [    0.000000] cma: Reserved 16 MiB at 0x4f000000
>> [    0.000000] psci: probing for conduit method from DT.
>> [    0.000000] psci: PSCIv0.2 detected in firmware.
>> [    0.000000] psci: Using standard PSCI v0.2 function IDs
>> [    0.000000] psci: Trusted OS migration not required
>> [    0.000000] random: get_random_bytes called from
>> start_kernel+0xa0/0x50c with crng_init=0
>> [    0.000000] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192
>> d22708 u69632
>> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 64960
>> [    0.000000] Kernel command line: panic=1
>> --load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader
>> console=ttyAMA0
>> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> [    0.000000] Memory: 214952K/262144K available (9216K kernel code,
>> 1133K rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved,
>> 16384K cma-reserved, 0K highmem)
>> [    0.000000] Virtual kernel memory layout:
>> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
>> [    0.000000]     vmalloc : 0xd0800000 - 0xff800000   ( 752 MB)
>> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
>> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
>> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
>> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
>> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
>> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
>> [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
>> [    0.000000] ftrace: allocating 33359 entries in 98 pages
>> [    0.000000] rcu: Hierarchical RCU implementation.
>> [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
>> [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
>> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>> [    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
>> [    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
>> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
>> max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
>> [    0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps
>> every 4398046511096ns
>> [    0.006045] Switching to timer-based delay loop, resolution 16ns
>> [    0.308537] Console: colour dummy device 80x30
>> [    0.365555] Calibrating delay loop (skipped), value calculated
>> using timer frequency.. 125.00 BogoMIPS (lpj=250000)
>> [    0.373670] pid_max: default: 32768 minimum: 301
>> [    0.426475] Security Framework initialized
>> [    0.431096] Yama: becoming mindful.
>> [    0.506448] AppArmor: AppArmor initialized
>> [    0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [    0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [    0.965208] CPU: Testing write buffer coherency: ok
>> [    0.998104] CPU0: Spectre v2: firmware did not set auxiliary
>> control register IBE bit, system vulnerable
>> [    1.411470] /cpus/cpu@0 missing clock-frequency property
>> [    1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> [    1.698318] Setting up static identity map for 0x40100000 - 0x401000a0
>> [    1.748454] rcu: Hierarchical SRCU implementation.
>> [    1.926086] EFI services will not be available.
>> [    1.993192] smp: Bringing up secondary CPUs ...
>> [    1.994874] smp: Brought up 1 node, 1 CPU
>> [    1.997851] SMP: Total of 1 processors activated (125.00 BogoMIPS).
>> [    1.998883] CPU: All CPU(s) started in SVC mode.
>> [    2.503281] devtmpfs: initialized
>> [    3.198070] VFP support v0.3: implementor 41 architecture 4 part 30
>> variant f rev 0
>> [    3.746420] clocksource: jiffies: mask: 0xffffffff max_cycles:
>> 0xffffffff, max_idle_ns: 7645041785100000 ns
>> [    3.775416] futex hash table entries: 256 (order: 2, 16384 bytes)
>> [    4.121161] pinctrl core: initialized pinctrl subsystem
>> [    4.513079] DMI not present or invalid.
>> [    4.901725] NET: Registered protocol family 16
>> [    5.171532] DMA: preallocated 256 KiB pool for atomic coherent allocations
>> [    5.247930] audit: initializing netlink subsys (disabled)
>> [    5.429698] audit: type=2000 audit(3.640:1): state=initialized
>> audit_enabled=0 res=1
>> [    5.571864] No ATAGs?
>> [    5.603824] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4
>> watchpoint registers.
>> [    5.605465] hw-breakpoint: maximum watchpoint size is 8 bytes.
>> [    5.716942] Serial: AMBA PL011 UART driver
>> [    6.689400] 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 54,
>> base_baud = 0) is a PL011 rev1
>> [    6.818013] console [ttyAMA0] enabled
>> [...]
>> [   73.272363] pl061_gpio 9030000.pl061: PL061 GPIO chip @0x09030000 registered
>> [   73.354536] pci-host-generic 4010000000.pcie: host bridge
>> /pcie@10000000 ranges:
>> [   73.383612] pci-host-generic 4010000000.pcie:    IO
>> 0x3eff0000..0x3effffff -> 0x00000000
>> [   73.405201] pci-host-generic 4010000000.pcie:   MEM
>> 0x10000000..0x3efeffff -> 0x10000000
>> [   73.413035] pci-host-generic 4010000000.pcie:   MEM
>> 0x8000000000..0xffffffffff -> 0x8000000000
>> [   73.449129] pci-host-generic 4010000000.pcie: can't claim ECAM area
>> [mem 0x10000000-0x1fffffff]: address conflict with pcie@10000000 [mem
>> 0x10000000-0x3efeffff]
>> [   73.511869] pci-host-generic: probe of 4010000000.pcie failed with error -16
>> [   74.049180] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> [   74.184595] Serial: AMBA driver
>> [...]
>> [   78.969555] Run /init as init process
>> [   80.062608] hrtimer: interrupt took 110418352 ns
>> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
>> GC Warning: Couldn't read /proc/stat
>> Welcome, this is GNU's early boot Guile.
>> Use '--repl' for an initrd REPL.
>>
>> loading kernel modules...
>> [  135.306635] SCSI subsystem initialized
>> [  136.419610] Unable to handle kernel paging request at virtual
>> address ea0003ff
>> [  136.432562] pgd = (ptrval)
>> [  136.434175] [ea0003ff] *pgd=00000000
>> [  136.443714] Internal error: Oops: 5 [#1] SMP ARM
>> [  136.448388] Modules linked in: libata(+) scsi_mod
>> [  136.459458] CPU: 0 PID: 1 Comm: init Not tainted 4.19.11-gnu #1
>> [  136.461282] Hardware name: Generic DT based system
>> [  136.477596] PC is at ata_attach_transport+0xd8/0x274 [libata]
>> [  136.483380] LR is at 0x124
>> [  136.484240] pc : [<bf05c190>]    lr : [<00000124>]    psr: 60000013
>> [  136.485268] sp : ce0fdcf0  ip : ea0003ff  fp : ce0fdd1c
>> [  136.486473] r10: 00000000  r9 : ea00041f  r8 : ea00040f
>> [  136.487498] r7 : ce3fc8bc  r6 : ce3fc8dc  r5 : ce3fc8cc  r4 : ce3fc800
>> [  136.488614] r3 : ce0ed040  r2 : 00000000  r1 : c10d3b14  r0 : 00000000
>> [  136.490476] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
>> [  136.492057] Control: 10c5387d  Table: 4e34406a  DAC: 00000051
>> [  136.494159] Process init (pid: 1, stack limit = 0x(ptrval))
>> [  136.495663] Stack: (0xce0fdcf0 to 0xce0fe000)
>> [  136.499157] dce0:                                     00000001
>> 00000000 bf0778c8 c1005dcc
>> [  136.501950] dd00: bf079000 ffffffff bf078000 00000000 ce0fdd9c
>> ce0fdd20 bf077c10 bf05c0c4
>> [  136.504080] dd20: c0f1e6b0 bf06f140 c1005dcc ce0fdd38 c01ceb30
>> bf078000 ce0fdd54 ffffffff
>> [  136.506036] dd40: c0155458 c01ceb24 ce0fdd7c ce0fdd58 c01bbaac
>> c01553d0 c10067b4 d082000c
>> [  136.508122] dd60: ce0fdda8 d0820000 d0821000 f28f9aeb ce0fdda4
>> bf06ef40 bf0778c8 c1005dcc
>> [  136.510236] dd80: 00000000 bf06ef4c bf06ef40 c1005dcc ce0fde14
>> ce0fdda0 c01035d8 bf0778d4
>> [  136.512143] dda0: c0101a0c f28f9aeb ce327600 c0979f74 ce000600
>> ce000600 ce0fddd4 ce0fddc8
>> [  136.514144] ddc0: c0979f74 c01ce7d0 ce0fde14 ce0fddd8 c0308ab4
>> c0979f50 ce0fde04 ce0fdde8
>> [  136.516233] dde0: c0309c5c c03090e4 00000052 f28f9aeb ce0fdf38
>> bf06ef40 ce0fdf38 ce3321c0
>> [  136.518293] de00: bf06f070 bf06ef4c ce0fde3c ce0fde18 c01fb75c
>> c0103594 ce0fde3c ce0fde28
>> [  136.520436] de20: c02f3410 00000000 ce0fdf38 bf06f040 ce0fdf14
>> ce0fde40 c01fa210 c01fb6f4
>> [  136.522398] de40: ffff8000 00007fff bf06ef40 c01f778c ce0fde98
>> d0820000 c1005dcc c0a08334
>> [  136.524853] de60: bf06f054 bf06ef44 00000a2c bf071000 014f9cf8
>> c0c3d374 ffffffff c0c5b674
>> [  136.526866] de80: c0101204 ce0fc000 ce0fdf14 ce0fde98 bf062024
>> 00000006 bf062054 000000bf
>> [  136.528885] dea0: 00000000 00000000 6e72656b 00006c65 00000000
>> 00000000 00000000 00000000
>> [  136.531078] dec0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [  136.533045] dee0: 00000000 f28f9aeb 7fffffff c1005dcc 00000000
>> 0000000a 014f9cf8 c0101204
>> [  136.534976] df00: ce0fc000 0000017b ce0fdfa4 ce0fdf18 c01fa9c4
>> c01f84e4 7fffffff 00000000
>> [  136.537150] df20: 00000003 ce0fc000 ce0fdf5c d08cf000 00051ca8
>> 00000000 d08f06f3 d08fefc0
>> [  136.539224] df40: d08cf000 00051ca8 d09201e0 d091ff38 d0909544
>> 0002d000 0002f250 00000000
>> [  136.541281] df60: 00000000 00000000 0001490c 00000042 00000043
>> 0000003c 0000002a 0000001b
>> [  136.543248] df80: 00000000 f28f9aeb 00000004 b58dac90 00053e77
>> 0000017b 00000000 ce0fdfa8
>> [  136.545223] dfa0: c0101000 c01fa8f4 00000004 b58dac90 0000000a
>> 014f9cf8 00000000 015bbf78
>> [  136.548002] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
>> 0029b25c 00161fec 00000002
>> [  136.550771] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2 60000030
>> 0000000a 00000000 00000000
>> [  136.578059] [<bf05c190>] (ata_attach_transport [libata]) from
>> [<bf077c10>] (ata_init+0x348/0x39c [libata])
>> [  136.589371] [<bf077c10>] (ata_init [libata]) from [<c01035d8>]
>> (do_one_initcall+0x50/0x214)
>> [  136.596083] [<c01035d8>] (do_one_initcall) from [<c01fb75c>]
>> (do_init_module+0x74/0x224)
>> [  136.598342] [<c01fb75c>] (do_init_module) from [<c01fa210>]
>> (load_module+0x1d38/0x2228)
>> [  136.599851] [<c01fa210>] (load_module) from [<c01fa9c4>]
>> (sys_finit_module+0xdc/0x110)
>> [  136.601640] [<c01fa9c4>] (sys_finit_module) from [<c0101000>]
>> (ret_fast_syscall+0x0/0x54)
>> [  136.603227] Exception stack(0xce0fdfa8 to 0xce0fdff0)
>> [  136.605053] dfa0:                   00000004 b58dac90 0000000a
>> 014f9cf8 00000000 015bbf78
>> [  136.607122] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
>> 0029b25c 00161fec 00000002
>> [  136.608630] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2
>> [  136.616749] Code: e59fc1a0 e3a0ef49 e28c8010 e28c9020 (e89c000f)
>> [  136.631449] ---[ end trace c34b1e9ba28742f3 ]---
>>
>> And then it hangs seemingly indefinitely.
> 
> I just tried on 
> 
> Git checkout:
>   repository: /home/sdb/src/guix
>   branch: HEAD
>   commit: d15211c9b5b46b96c5b658329624942b6ff5c917
> 
> and got:
> 
> building /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv...
> @ unsupported-platform
> /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv armhf-linux
> while setting up the build environment: a `armhf-linux' is required to
> build `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv', but I
> am a `i686-linux'
> builder for `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv'
> failed with exit code 1
> build of /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv
> failed
> View build log at
> '/var/log/guix/drvs/ng/yvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv.bz2'.
> substituting
> /gnu/store/1aclmh7jy2j5084kdpbcz5xgmdzvjzzj-fontconfig-2.13.1...
> cannot build derivation
> `/gnu/store/hr975r813adrn92f2g7f14z39086hnbx-coreutils-8.30.drv': 1
> dependencies couldn't be built
> killing process 2725
> cannot build derivation
> `/gnu/store/c56fwipfpdpii95420xcwf3vamy3n2pa-python-3.7.0.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv':
> 1 dependencies couldn't be built
> guix system: error: build failed: build of
> `/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv'
> failed

I'm on x86_64 hardware running a i686 guix

Tried again and got this:

building
/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv...
@ unsupported-platform
/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv
armhf-linux
while setting up the build environment: a `armhf-linux' is required to
build `/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv',
but I am a `i686-linux'
builder for
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed
with exit code 1
build of /gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv
failed
View build log at
'/var/log/guix/drvs/c9/d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv.bz2'.
guix system: error: build failed: build of
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed


-- 
Cheers 
Swedebugia

Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 09:33, swedebugia@riseup.net wrote:
> On 2018-12-22 00:09, Danny Milosavljevic wrote:
>> Now I get:
>>
>> $ # commit 39c676c4a3507863f4edf20b225ace4cbf646ed6
>> $ ./pre-inst-env guix system disk-image --system=armhf-linux -e
>> '(begin (use-modules (gnu system) (gnu bootloader) (gnu bootloader
>> u-boot) (gnu system install)) (operating-system (inherit
>> installation-os) (bootloader (bootloader-configuration (bootloader
>> u-boot-bootloader) (target #f)))))' >QQQ3 2>&1
>> [...]
>> The following derivation will be built:
>>    /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv
>> building /gnu/store/shgfclh6yy1a03hl0c293s89y3qm9033-disk-image.drv...
>> environment variable `PATH' set to
>> `/gnu/store/cm3j1pzdqhw4s9bg1drwlm3lw3qxzddj-qemu-minimal-3.1.0/bin:/gnu/store/hb2qj35yxmvxzcq99lbfcpija032wdzh-coreutils-8.30/bin'
>> creating raw image of 1265.54 MiB...
>> Formatting '/gnu/store/9wbw2vbpgg3pwlg9xr7jbniyca0nra2q-disk-image',
>> fmt=raw size=1327019190
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Linux version 4.19.11-gnu (nixbld@) (gcc version 5.5.0
>> (GCC)) #1 SMP 1
>> [    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
>> [    0.000000] CPU: div instructions available: patching division code
>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
>> [    0.000000] OF: fdt: Machine model: linux,dummy-virt
>> [    0.000000] Memory policy: Data cache writealloc
>> [    0.000000] efi: Getting EFI parameters from FDT:
>> [    0.000000] efi: UEFI not found.
>> [    0.000000] cma: Reserved 16 MiB at 0x4f000000
>> [    0.000000] psci: probing for conduit method from DT.
>> [    0.000000] psci: PSCIv0.2 detected in firmware.
>> [    0.000000] psci: Using standard PSCI v0.2 function IDs
>> [    0.000000] psci: Trusted OS migration not required
>> [    0.000000] random: get_random_bytes called from
>> start_kernel+0xa0/0x50c with crng_init=0
>> [    0.000000] percpu: Embedded 17 pages/cpu @(ptrval) s38732 r8192
>> d22708 u69632
>> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 64960
>> [    0.000000] Kernel command line: panic=1
>> --load=/gnu/store/ip9p4q62fbgm2r2xnnh8qi5p77k2igas-linux-vm-loader
>> console=ttyAMA0
>> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> [    0.000000] Memory: 214952K/262144K available (9216K kernel code,
>> 1133K rwdata, 2612K rodata, 2048K init, 310K bss, 30808K reserved,
>> 16384K cma-reserved, 0K highmem)
>> [    0.000000] Virtual kernel memory layout:
>> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
>> [    0.000000]     vmalloc : 0xd0800000 - 0xff800000   ( 752 MB)
>> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
>> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
>> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
>> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (10208 kB)
>> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
>> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   (1134 kB)
>> [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 311 kB)
>> [    0.000000] ftrace: allocating 33359 entries in 98 pages
>> [    0.000000] rcu: Hierarchical RCU implementation.
>> [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
>> [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
>> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>> [    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
>> [    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
>> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
>> max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
>> [    0.003589] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps
>> every 4398046511096ns
>> [    0.006045] Switching to timer-based delay loop, resolution 16ns
>> [    0.308537] Console: colour dummy device 80x30
>> [    0.365555] Calibrating delay loop (skipped), value calculated
>> using timer frequency.. 125.00 BogoMIPS (lpj=250000)
>> [    0.373670] pid_max: default: 32768 minimum: 301
>> [    0.426475] Security Framework initialized
>> [    0.431096] Yama: becoming mindful.
>> [    0.506448] AppArmor: AppArmor initialized
>> [    0.535772] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [    0.543395] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [    0.965208] CPU: Testing write buffer coherency: ok
>> [    0.998104] CPU0: Spectre v2: firmware did not set auxiliary
>> control register IBE bit, system vulnerable
>> [    1.411470] /cpus/cpu@0 missing clock-frequency property
>> [    1.428729] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> [    1.698318] Setting up static identity map for 0x40100000 - 0x401000a0
>> [    1.748454] rcu: Hierarchical SRCU implementation.
>> [    1.926086] EFI services will not be available.
>> [    1.993192] smp: Bringing up secondary CPUs ...
>> [    1.994874] smp: Brought up 1 node, 1 CPU
>> [    1.997851] SMP: Total of 1 processors activated (125.00 BogoMIPS).
>> [    1.998883] CPU: All CPU(s) started in SVC mode.
>> [    2.503281] devtmpfs: initialized
>> [    3.198070] VFP support v0.3: implementor 41 architecture 4 part 30
>> variant f rev 0
>> [    3.746420] clocksource: jiffies: mask: 0xffffffff max_cycles:
>> 0xffffffff, max_idle_ns: 7645041785100000 ns
>> [    3.775416] futex hash table entries: 256 (order: 2, 16384 bytes)
>> [    4.121161] pinctrl core: initialized pinctrl subsystem
>> [    4.513079] DMI not present or invalid.
>> [    4.901725] NET: Registered protocol family 16
>> [    5.171532] DMA: preallocated 256 KiB pool for atomic coherent allocations
>> [    5.247930] audit: initializing netlink subsys (disabled)
>> [    5.429698] audit: type=2000 audit(3.640:1): state=initialized
>> audit_enabled=0 res=1
>> [    5.571864] No ATAGs?
>> [    5.603824] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4
>> watchpoint registers.
>> [    5.605465] hw-breakpoint: maximum watchpoint size is 8 bytes.
>> [    5.716942] Serial: AMBA PL011 UART driver
>> [    6.689400] 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 54,
>> base_baud = 0) is a PL011 rev1
>> [    6.818013] console [ttyAMA0] enabled
>> [...]
>> [   73.272363] pl061_gpio 9030000.pl061: PL061 GPIO chip @0x09030000 registered
>> [   73.354536] pci-host-generic 4010000000.pcie: host bridge
>> /pcie@10000000 ranges:
>> [   73.383612] pci-host-generic 4010000000.pcie:    IO
>> 0x3eff0000..0x3effffff -> 0x00000000
>> [   73.405201] pci-host-generic 4010000000.pcie:   MEM
>> 0x10000000..0x3efeffff -> 0x10000000
>> [   73.413035] pci-host-generic 4010000000.pcie:   MEM
>> 0x8000000000..0xffffffffff -> 0x8000000000
>> [   73.449129] pci-host-generic 4010000000.pcie: can't claim ECAM area
>> [mem 0x10000000-0x1fffffff]: address conflict with pcie@10000000 [mem
>> 0x10000000-0x3efeffff]
>> [   73.511869] pci-host-generic: probe of 4010000000.pcie failed with error -16
>> [   74.049180] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> [   74.184595] Serial: AMBA driver
>> [...]
>> [   78.969555] Run /init as init process
>> [   80.062608] hrtimer: interrupt took 110418352 ns
>> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
>> GC Warning: Couldn't read /proc/stat
>> Welcome, this is GNU's early boot Guile.
>> Use '--repl' for an initrd REPL.
>>
>> loading kernel modules...
>> [  135.306635] SCSI subsystem initialized
>> [  136.419610] Unable to handle kernel paging request at virtual
>> address ea0003ff
>> [  136.432562] pgd = (ptrval)
>> [  136.434175] [ea0003ff] *pgd=00000000
>> [  136.443714] Internal error: Oops: 5 [#1] SMP ARM
>> [  136.448388] Modules linked in: libata(+) scsi_mod
>> [  136.459458] CPU: 0 PID: 1 Comm: init Not tainted 4.19.11-gnu #1
>> [  136.461282] Hardware name: Generic DT based system
>> [  136.477596] PC is at ata_attach_transport+0xd8/0x274 [libata]
>> [  136.483380] LR is at 0x124
>> [  136.484240] pc : [<bf05c190>]    lr : [<00000124>]    psr: 60000013
>> [  136.485268] sp : ce0fdcf0  ip : ea0003ff  fp : ce0fdd1c
>> [  136.486473] r10: 00000000  r9 : ea00041f  r8 : ea00040f
>> [  136.487498] r7 : ce3fc8bc  r6 : ce3fc8dc  r5 : ce3fc8cc  r4 : ce3fc800
>> [  136.488614] r3 : ce0ed040  r2 : 00000000  r1 : c10d3b14  r0 : 00000000
>> [  136.490476] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
>> [  136.492057] Control: 10c5387d  Table: 4e34406a  DAC: 00000051
>> [  136.494159] Process init (pid: 1, stack limit = 0x(ptrval))
>> [  136.495663] Stack: (0xce0fdcf0 to 0xce0fe000)
>> [  136.499157] dce0:                                     00000001
>> 00000000 bf0778c8 c1005dcc
>> [  136.501950] dd00: bf079000 ffffffff bf078000 00000000 ce0fdd9c
>> ce0fdd20 bf077c10 bf05c0c4
>> [  136.504080] dd20: c0f1e6b0 bf06f140 c1005dcc ce0fdd38 c01ceb30
>> bf078000 ce0fdd54 ffffffff
>> [  136.506036] dd40: c0155458 c01ceb24 ce0fdd7c ce0fdd58 c01bbaac
>> c01553d0 c10067b4 d082000c
>> [  136.508122] dd60: ce0fdda8 d0820000 d0821000 f28f9aeb ce0fdda4
>> bf06ef40 bf0778c8 c1005dcc
>> [  136.510236] dd80: 00000000 bf06ef4c bf06ef40 c1005dcc ce0fde14
>> ce0fdda0 c01035d8 bf0778d4
>> [  136.512143] dda0: c0101a0c f28f9aeb ce327600 c0979f74 ce000600
>> ce000600 ce0fddd4 ce0fddc8
>> [  136.514144] ddc0: c0979f74 c01ce7d0 ce0fde14 ce0fddd8 c0308ab4
>> c0979f50 ce0fde04 ce0fdde8
>> [  136.516233] dde0: c0309c5c c03090e4 00000052 f28f9aeb ce0fdf38
>> bf06ef40 ce0fdf38 ce3321c0
>> [  136.518293] de00: bf06f070 bf06ef4c ce0fde3c ce0fde18 c01fb75c
>> c0103594 ce0fde3c ce0fde28
>> [  136.520436] de20: c02f3410 00000000 ce0fdf38 bf06f040 ce0fdf14
>> ce0fde40 c01fa210 c01fb6f4
>> [  136.522398] de40: ffff8000 00007fff bf06ef40 c01f778c ce0fde98
>> d0820000 c1005dcc c0a08334
>> [  136.524853] de60: bf06f054 bf06ef44 00000a2c bf071000 014f9cf8
>> c0c3d374 ffffffff c0c5b674
>> [  136.526866] de80: c0101204 ce0fc000 ce0fdf14 ce0fde98 bf062024
>> 00000006 bf062054 000000bf
>> [  136.528885] dea0: 00000000 00000000 6e72656b 00006c65 00000000
>> 00000000 00000000 00000000
>> [  136.531078] dec0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [  136.533045] dee0: 00000000 f28f9aeb 7fffffff c1005dcc 00000000
>> 0000000a 014f9cf8 c0101204
>> [  136.534976] df00: ce0fc000 0000017b ce0fdfa4 ce0fdf18 c01fa9c4
>> c01f84e4 7fffffff 00000000
>> [  136.537150] df20: 00000003 ce0fc000 ce0fdf5c d08cf000 00051ca8
>> 00000000 d08f06f3 d08fefc0
>> [  136.539224] df40: d08cf000 00051ca8 d09201e0 d091ff38 d0909544
>> 0002d000 0002f250 00000000
>> [  136.541281] df60: 00000000 00000000 0001490c 00000042 00000043
>> 0000003c 0000002a 0000001b
>> [  136.543248] df80: 00000000 f28f9aeb 00000004 b58dac90 00053e77
>> 0000017b 00000000 ce0fdfa8
>> [  136.545223] dfa0: c0101000 c01fa8f4 00000004 b58dac90 0000000a
>> 014f9cf8 00000000 015bbf78
>> [  136.548002] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
>> 0029b25c 00161fec 00000002
>> [  136.550771] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2 60000030
>> 0000000a 00000000 00000000
>> [  136.578059] [<bf05c190>] (ata_attach_transport [libata]) from
>> [<bf077c10>] (ata_init+0x348/0x39c [libata])
>> [  136.589371] [<bf077c10>] (ata_init [libata]) from [<c01035d8>]
>> (do_one_initcall+0x50/0x214)
>> [  136.596083] [<c01035d8>] (do_one_initcall) from [<c01fb75c>]
>> (do_init_module+0x74/0x224)
>> [  136.598342] [<c01fb75c>] (do_init_module) from [<c01fa210>]
>> (load_module+0x1d38/0x2228)
>> [  136.599851] [<c01fa210>] (load_module) from [<c01fa9c4>]
>> (sys_finit_module+0xdc/0x110)
>> [  136.601640] [<c01fa9c4>] (sys_finit_module) from [<c0101000>]
>> (ret_fast_syscall+0x0/0x54)
>> [  136.603227] Exception stack(0xce0fdfa8 to 0xce0fdff0)
>> [  136.605053] dfa0:                   00000004 b58dac90 0000000a
>> 014f9cf8 00000000 015bbf78
>> [  136.607122] dfc0: 00000004 b58dac90 00053e77 0000017b 002b39d0
>> 0029b25c 00161fec 00000002
>> [  136.608630] dfe0: bec661d0 bec661c0 0005c7a9 0011d1e2
>> [  136.616749] Code: e59fc1a0 e3a0ef49 e28c8010 e28c9020 (e89c000f)
>> [  136.631449] ---[ end trace c34b1e9ba28742f3 ]---
>>
>> And then it hangs seemingly indefinitely.
> 
> I just tried on 
> 
> Git checkout:
>   repository: /home/sdb/src/guix
>   branch: HEAD
>   commit: d15211c9b5b46b96c5b658329624942b6ff5c917
> 
> and got:
> 
> building /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv...
> @ unsupported-platform
> /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv armhf-linux
> while setting up the build environment: a `armhf-linux' is required to
> build `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv', but I
> am a `i686-linux'
> builder for `/gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv'
> failed with exit code 1
> build of /gnu/store/ngyvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv
> failed
> View build log at
> '/var/log/guix/drvs/ng/yvqxnj2yndvncpfrkmpc6irfz6k09q-gmp-6.1.2.drv.bz2'.
> substituting
> /gnu/store/1aclmh7jy2j5084kdpbcz5xgmdzvjzzj-fontconfig-2.13.1...
> cannot build derivation
> `/gnu/store/hr975r813adrn92f2g7f14z39086hnbx-coreutils-8.30.drv': 1
> dependencies couldn't be built
> killing process 2725
> cannot build derivation
> `/gnu/store/c56fwipfpdpii95420xcwf3vamy3n2pa-python-3.7.0.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv':
> 1 dependencies couldn't be built
> guix system: error: build failed: build of
> `/gnu/store/3v425ipvhz4w2rll3phfzhq5kpaczwg4-python-wrapper-3.7.0.drv'
> failed

I'm on x86_64 hardware running a i686 guix

Tried again and got this:

building
/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv...
@ unsupported-platform
/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv
armhf-linux
while setting up the build environment: a `armhf-linux' is required to
build `/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv',
but I am a `i686-linux'
builder for
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed
with exit code 1
build of /gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv
failed
View build log at
'/var/log/guix/drvs/c9/d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv.bz2'.
guix system: error: build failed: build of
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed


-- 
Cheers 
Swedebugia

bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

Did you reconfigure?

# guix system reconfigure /etc/config.scm

If so, that's weird.

>I'm on x86_64 hardware running a i686 guix

Yeah, "--system" is using qemu to emulate the target architecture and the build
job then runs in there.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: bug#33676: GuixSD on eoma68-a20?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

Did you reconfigure?

# guix system reconfigure /etc/config.scm

If so, that's weird.

>I'm on x86_64 hardware running a i686 guix

Yeah, "--system" is using qemu to emulate the target architecture and the build
job then runs in there.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 09:44, Danny Milosavljevic wrote:
> Please add to your /etc/config.scm to the "services" section:
> 
> (service qemu-binfmt-service-type
>                      (qemu-binfmt-configuration
>                        (platforms (lookup-qemu-platforms "arm"))
>                        (guix-support? #t)))

Thanks.

Added, reconfigured and now it is building away happily. Will report
back how it goes...

-- 
Cheers 
Swedebugia

Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-22 09:44, Danny Milosavljevic wrote:
> Please add to your /etc/config.scm to the "services" section:
> 
> (service qemu-binfmt-service-type
>                      (qemu-binfmt-configuration
>                        (platforms (lookup-qemu-platforms "arm"))
>                        (guix-support? #t)))

Thanks.

Added, reconfigured and now it is building away happily. Will report
back how it goes...

-- 
Cheers 
Swedebugia

bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-23 06:09, swedebugia@riseup.net wrote:
> On 2018-12-22 09:44, Danny Milosavljevic wrote:
>> Please add to your /etc/config.scm to the "services" section:
>>
>> (service qemu-binfmt-service-type
>>                      (qemu-binfmt-configuration
>>                        (platforms (lookup-qemu-platforms "arm"))
>>                        (guix-support? #t)))
> 
> Thanks.
> 
> Added, reconfigured and now it is building away happily. Will report
> back how it goes...

It took a long long time to compile python2.7 and failed a 1 test in the
end.

356 tests OK.
1 test failed:
    test_mmap
39 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gdb test_gl test_imgfile test_ioctl test_kqueue
    test_linuxaudiodev test_macos test_macostools test_msilib test_nis
    test_ossaudiodev test_scriptpackages test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_urllib2net test_urllibnet
    test_winreg test_winsound test_zipfile64
4 skips unexpected on linux2:
    test_bsddb test_bsddb3 test_gdb test_ioctl

Total duration: 55 min 1 sec
Tests result: FAILURE
make: *** [Makefile:878: test] Error 2

Test suite failed, dumping logs.
Backtrace:
           4 (primitive-load "/gnu/store/dbh5r09sm7hw8jjmxvgmjks9h2q…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
   863:16  2 (every1 #<procedure 1e4830 at /gnu/store/diwcb1v9lr156…> …)
In
/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:
   799:28  1 (_ _)
    369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)

/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:369:6:
In procedure check:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program:
"make" arguments: ("test" "-j" "2") exit-status: 2 term-signal: #f
stop-signal: #f] 145fc0>)'.
builder for
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed
with exit code 1
build of /gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv
failed
View build log at
'/var/log/guix/drvs/c9/d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv.bz2'.
guix system: error: build failed: build of
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed

-------------
fail details:

0:27:38 load avg: 1.19 [216/396] test_mmap
test test_mmap failed -- Traceback (most recent call last):
  File
"/tmp/guix-build-python2-2.7.15.drv-0/Python-2.7.15/Lib/test/test_mmap.py",
line 696, in test_large_offset
    self.assertEqual(m[0xFFFFFFF], b" ")
AssertionError: '\x00' != ' '

0:27:40 load avg: 1.18 [217/396/1] test_module -- test_mmap failed

I'm on i386.
Will try again when I succeded in disabling the test.
-- 
Cheers 
Swedebugia

Re: bug#33676: GuixSD on eoma68-a20?

[swedebugia]

On 2018-12-23 06:09, swedebugia@riseup.net wrote:
> On 2018-12-22 09:44, Danny Milosavljevic wrote:
>> Please add to your /etc/config.scm to the "services" section:
>>
>> (service qemu-binfmt-service-type
>>                      (qemu-binfmt-configuration
>>                        (platforms (lookup-qemu-platforms "arm"))
>>                        (guix-support? #t)))
> 
> Thanks.
> 
> Added, reconfigured and now it is building away happily. Will report
> back how it goes...

It took a long long time to compile python2.7 and failed a 1 test in the
end.

356 tests OK.
1 test failed:
    test_mmap
39 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gdb test_gl test_imgfile test_ioctl test_kqueue
    test_linuxaudiodev test_macos test_macostools test_msilib test_nis
    test_ossaudiodev test_scriptpackages test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_urllib2net test_urllibnet
    test_winreg test_winsound test_zipfile64
4 skips unexpected on linux2:
    test_bsddb test_bsddb3 test_gdb test_ioctl

Total duration: 55 min 1 sec
Tests result: FAILURE
make: *** [Makefile:878: test] Error 2

Test suite failed, dumping logs.
Backtrace:
           4 (primitive-load "/gnu/store/dbh5r09sm7hw8jjmxvgmjks9h2q…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
   863:16  2 (every1 #<procedure 1e4830 at /gnu/store/diwcb1v9lr156…> …)
In
/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:
   799:28  1 (_ _)
    369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)

/gnu/store/diwcb1v9lr156sg3q4ww1wvsniw4n6rf-module-import/guix/build/gnu-build-system.scm:369:6:
In procedure check:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program:
"make" arguments: ("test" "-j" "2") exit-status: 2 term-signal: #f
stop-signal: #f] 145fc0>)'.
builder for
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed
with exit code 1
build of /gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv
failed
View build log at
'/var/log/guix/drvs/c9/d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv.bz2'.
guix system: error: build failed: build of
`/gnu/store/c9d3ga47xx8izflj9r1xgf1y6y39yskq-python2-2.7.15.drv' failed

-------------
fail details:

0:27:38 load avg: 1.19 [216/396] test_mmap
test test_mmap failed -- Traceback (most recent call last):
  File
"/tmp/guix-build-python2-2.7.15.drv-0/Python-2.7.15/Lib/test/test_mmap.py",
line 696, in test_large_offset
    self.assertEqual(m[0xFFFFFFF], b" ")
AssertionError: '\x00' != ' '

0:27:40 load avg: 1.18 [217/396/1] test_module -- test_mmap failed

I'm on i386.
Will try again when I succeded in disabling the test.
-- 
Cheers 
Swedebugia

bug#33676: GuixSD on eoma68-a20?

[Marius Bakke]

Is this bug report still relevant?

bug#33676: GuixSD on eoma68-a20?

[Ricardo Wurmus]

Marius Bakke <mbakke@fastmail.com> writes:

> Is this bug report still relevant?

The EOMA68-A20 board still hasn’t been completed, so I think it’s fine
to close this bug report.

-- 
Ricardo

bug#33676: GuixSD on eoma68-a20?

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Is this bug report still relevant?
>
> The EOMA68-A20 board still hasn’t been completed, so I think it’s fine
> to close this bug report.

OK.  There has been quite a lot of work getting Guix System running on
various boards since this was opened, so I don't expect porting to
EOMA68-A20 to be particularily problematic.  Closing for now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]