GNU bug report logs - #42151
[PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jan Nieuwenhuizen <janneke <at> gnu.org>
Cc: 42151 <at> debbugs.gnu.org
Subject: Re: bug#42151: [PATCH 0/3] offload to Childhurd fails: setting
 synchronous mode: locking protocol
Date: Fri, 03 Jul 2020 15:51:29 +0200

Hi!

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

> Thanks -- it seems that buys us a pretty cheap fix after all, $-wise ;)

Heheh.  :-)

> It turns out that Debian's patch (and thus this patch series) is
> probably OK: It fixes the locking problem on the Hurd, while exposing
> another bug, apparently: "unable to open database file".
>
> It seems there is a compatibility bug/problem/thing with the db.sqlite
> that we produce on GNU/Linux.  While an unpatched sqlite3 on the Hurd
> can read it, and work with it, the unpatched sqlite has locking
> problems.  I found a workaround, though: dumping and loading  the
> database file.
>
> Look...
>
> $ scp childhurd2:/var/guix/db/db.sqlite db.sqlite-orig
> db.sqlite                                                                       100%  144KB   5.8MB/s   00:00    
> 11:30:37 janneke <at> dundal:~/tmp [env]
> $ sqlite3 db.sqlite-orig .dump > db.dump
> 11:30:45 janneke <at> dundal:~/tmp [env]
> $ sqlite3 -init db.dump db.sqlite-init .quit
> -- Loading resources from db.dump
> 11:30:49 janneke <at> dundal:~/tmp [env]
> $ cmp db.sqlite-orig db.sqlite-init 
> db.sqlite-orig db.sqlite-init differ: byte 19, line 1
> [1]11:31:11 janneke <at> dundal:~/tmp [env]
> $ scp db.sqlite-init childhurd2:/var/guix/db/db.sqlite
> db.sqlite-init                                                                  100%  144KB   7.3MB/s   00:00    
> 11:31:21 janneke <at> dundal:~/tmp [env]
> $ guix offload test
> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
> guix offload: Guix is usable on 'localhost' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
> guix offload: 'localhost' is running GNU Guile 3.0.4
> sending 1 store item (0 MiB) to 'localhost'...
> exporting path `/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test'
> guix offload: 'localhost' successfully imported '/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test'
> retrieving 1 store item from 'localhost'...
> guix offload: successfully imported '/gnu/store/gxz6hzyc1cy3m1w9l7f2dk6rcspvymxf-import-test' from 'localhost'
> 11:31:29 janneke <at> dundal:~/tmp [env]
>
> So...about the compatibility problem.  I tried to diff the db.sqlite-orig
> db.sqlite-init binary files: they look completely different.  Not sure
> how to handle this workaround, maybe we can insert a two system* calls
> somewhere when building the disk image?

Weird, weird!

Could you compare ‘db.dump’ created on GNU/Hurd with ‘db.dump’ created
from the same ‘sqlite3 -init’ command on GNU/Linux?  (Perhaps loading
the dump reorders entries or something.)

I think the binary format of the database is supposed to be
architecture-independent and filling it is supposed to be deterministic.

Congrats for getting this far anyway!

Ludo’.

Previous Next

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