bug#30021: system build: unable to parse multi-line device-mapping

bug#30021: system build: unable to parse multi-line device-mapping

[Vagrant Cascadian]

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

After several weeks of not using a machine, and updating guix to

guix (GNU Guix) c04ffadbed7412545555b8be6b78f23eed150d26


Running "guix build system /etc/config.scm" resulted in:

  guix system: error: failed to load '/etc/config.scm':
  /etc/config.scm:23:9: /etc/config.scm:23:9: In procedure allocate-struct: Wrong type argument in\
  position 2: 3


This roughly corresponded to my mapped device section in
/etc/config.scm:

  (mapped-devices
   (list (mapped-device
          (source (uuid "c106e43e-0479-4135-a1a8-b5221312bf74"))
          (target "cryptic")
          (type luks-device-mapping))))

Moving it all into a single line worked around the issue, but is a good
deal harder to read:

  (mapped-devices (list (mapped-device (source (uuid "c106e43e-0479-4135-a1a8-b5221312bf74")) (target "cryptic") (type luks-device-mapping))))


My guess is it has something to do with some commits relating to
validating mapped devices:

  42ff7d3be642d66ba567f64882a1f2301b1a7bd9
  mapped-devices: 'luks-device-mapping' checks its source device.

  4ca90ff5976434a2b6e758df38df54387ae70c1b 
  mapped-devices: Add 'location' and 'check' fields.


Hope that helps!

live well,
  vagrant

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

bug#30021: system build: unable to parse multi-line device-mapping

[Mark H Weaver]

Hi,

Vagrant Cascadian <vagrant@debian.org> writes:

> After several weeks of not using a machine, and updating guix to
>
> guix (GNU Guix) c04ffadbed7412545555b8be6b78f23eed150d26
>
>
> Running "guix build system /etc/config.scm" resulted in:
>
>   guix system: error: failed to load '/etc/config.scm':
>   /etc/config.scm:23:9: /etc/config.scm:23:9: In procedure allocate-struct: Wrong type argument in\
>   position 2: 3
>
>
> This roughly corresponded to my mapped device section in
> /etc/config.scm:
>
>   (mapped-devices
>    (list (mapped-device
>           (source (uuid "c106e43e-0479-4135-a1a8-b5221312bf74"))
>           (target "cryptic")
>           (type luks-device-mapping))))

I ran into the same problem.

> Moving it all into a single line worked around the issue, but is a good
> deal harder to read:
>
>   (mapped-devices (list (mapped-device (source (uuid "c106e43e-0479-4135-a1a8-b5221312bf74")) (target "cryptic") (type luks-device-mapping))))
>
>
> My guess is it has something to do with some commits relating to
> validating mapped devices:
>
>   42ff7d3be642d66ba567f64882a1f2301b1a7bd9
>   mapped-devices: 'luks-device-mapping' checks its source device.
>
>   4ca90ff5976434a2b6e758df38df54387ae70c1b 
>   mapped-devices: Add 'location' and 'check' fields.

You're right that it has to do with those commits, but the work around
simply involves forcing a recompilation of /etc/config.scm.  *Any*
change to config.scm would have fixed the problem, or alternatively you
could have deleted ~/.cache/guile/ccache.  In any case, you can now
reformat the mapped device section as it was before, and it will
continue to work.

What happened here is that commit 4ca90ff5 added two fields to the
<mapped-device> record type.  For efficiency reasons, the
'mapped-device' record constructor (used in /etc/config.scm) is an
*inlined* procedure.  Unfortunately this means that the compiled version
of /etc/config.scm in ~/.cache/guile/ccache was still creating the old
record type.  Guile is not able to detect this case, so the cache must
be manually invalidated somehow.

      Mark

bug#30021: system build: unable to parse multi-line device-mapping

[Mark H Weaver]

Vagrant Cascadian <vagrant@debian.org> writes:

> Running "guix build system /etc/config.scm" resulted in:
>
>   guix system: error: failed to load '/etc/config.scm':
>   /etc/config.scm:23:9: /etc/config.scm:23:9: In procedure allocate-struct: Wrong type argument in\
>   position 2: 3

I forgot to mention that there's already a bug filed for this issue:

  https://bugs.gnu.org/29881

I'm closing this bug now.

     Thanks,
       Mark