bug#58606: Emacs next pgtk crashes when pasting to other app

[Andrew Tropin]

On 2022-10-18 10:52, Andrew Tropin wrote:

> Recently discovered a problem, which reproduces this way:
> - Open a new emacs instance.
> - Yank anything with M-w or select with mouse.
> - Paste yanked text to chromium/icecat.
>
> Both browser and emacs are hanging up for a while and after that Emacs
> crashes with:
>
> --8<---cut here---start->8---
> Fatal error 11: Segmentation fault
> --8<---cut here---end--->8---
>
> sway, emacs-next-pgtk, ungoogled-chromium
>
> --8<---cut here---start->8---
> Generation 75 Oct 17 2022 15:54:07(current)
>   rde 05225a3
> repository URL: https://git.sr.ht/~abcdw/rde
> branch: master
> commit: 05225a3a20e2f3eba9ebaa3df4cdce3e8b0c33c1
>   guix 3ab1438
> repository URL: file:///home/bob/work/gnu/guix
> branch: master
> commit: 3ab14386cd2a3fc4bacf2291ee585a0685aceb17
> --8<---cut here---end--->8---

A little more info:
--8<---cut here---start->8---
Fatal error 11: Segmentation fault
Backtrace:
/home/bob/.guix-home/profile/bin/emacs[0x530c7e]
/home/bob/.guix-home/profile/bin/emacs[0x42645c]
/home/bob/.guix-home/profile/bin/emacs[0x42694b]
/home/bob/.guix-home/profile/bin/emacs[0x52f1f8]
/home/bob/.guix-home/profile/bin/emacs[0x52f269]
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0(+0x11d80)[0x7f7850c45d80]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(+0x27424)[0x7f7857ad4424]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit_valist+0xbeb)[0x7f7857ada21b]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f7857ada722]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(+0x19884)[0x7f7857ac6884]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_object_notify_by_pspec+0xe4)[0x7f7857ac8834]
/gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(+0x3afbcd)[0x7f7858470bcd]
/gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(+0x3de357)[0x7f785849f357]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_closure_invoke+0x16f)[0x7f7857ac24af]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(+0x269e9)[0x7f7857ad39e9]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x735)[0x7f7857ad9d65]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f7857ada722]
/gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(+0x38ac04)[0x7f785844bc04]
/gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgtk-3.so.0(gtk_main_do_event+0x6ea)[0x7f785830c37a]
/gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgdk-3.so.0(+0x3d3c5)[0x7f7857ff93c5]
/gnu/store/3qf7x188z53a8y1b6xpnnkas3mg7g3cq-gtk+-3.24.30/lib/libgdk-3.so.0(+0x9a352)[0x7f7858056352]
/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2/lib/libglib-2.0.so.0(g_main_context_dispatch+0x23b)[0x7f78579ce4cb]
/home/bob/.guix-home/profile/bin/emacs[0x64ade8]
/home/bob/.guix-home/profile/bin/emacs[0x518482]
/home/bob/.guix-home/profile/bin/emacs[0x5188a5]
/home/bob/.guix-home/profile/bin/emacs[0x519758]
/home/bob/.guix-home/profile/bin/emacs[0x519c95]
/home/bob/.guix-home/profile/bin/emacs[0x519e58]
/home/bob/.guix-home/profile/bin/emacs[0x51ebd8]
/home/bob/.guix-home/profile/bin/emacs[0x5f5dd8]
/home/bob/.guix-home/profile/bin/emacs[0x51a3b6]
/home/bob/.guix-home/profile/bin/emacs[0x51fcc3]
/home/bob/.guix-home/profile/bin/emacs[0x52200d]
/home/bob/.guix-home/profile/bin/emacs[0x523c32]
/home/bob/.guix-home/profile/bin/emacs[0x598b07]
/home/bob/.guix-home/profile/bin/emacs[0x50fe9a]
/home/bob/.guix-home/profile/bin/emacs[0x598a61]
/home/bob/.guix-home/profile/bin/emacs[0x50fe3f]
/home/bob/.guix-home/profile/bin/emacs[0x516c83]
/home/bob/.guix-home/profile/bin/emacs[0x516ffa]
/home/bob/.guix-home/profile/bin/emacs[0x42f32a]
--8<---cut here---end--->8---

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Thompson, David]

On Sat, Oct 8, 2022 at 9:40 PM Thompson, David  wrote:
>
> On Sat, Oct 8, 2022 at 11:16 AM zimoun  wrote:
> >
> > Hi Dave,
> >
> > On Thu, 06 Oct 2022 at 09:26, "Thompson, David"  
> > wrote:
> >
> > > Some news: I have updated the gitolite package to use G-expressions.
> > > The package builds and the gitolite system test passes so I pushed
> > > that change to master a little while ago.  That patch has made the
> > > (hopefully) final step in this saga easier. The attached patch
> > > introduces a 'make-gitolite' procedure that can be used to add
> > > arbitrary packages to the wrappers for the gitolite and gitolite-shell
> > > programs.  The return value of this procedure can be used in the
> > > gitolite service configuration to enable the desired optional features
> > > like Redis or git-annex.  The base package inputs are unchanged and
> > > the gitolite system test still passes.
> >
> > Thank you for working on this!  Neat.
> >
> > Well, your proposal LGTM although I do not see the difference between
> > ’make-gitolite’ and a simple ’inherent’ for building a package variant.
> > Yeah, this make-gitolite is probably more handy.
>
> The reason for the constructor is so that extra packages can be easily
> added to the gexp that calls wrap-program.  It would be much harder to
> modify the package in this way without a helper procedure.

Pushed as commit 966118da711506b04c11fbfcac9483d59ed2d912.  This bug
can finally be closed!

- Dave

bug#53857: telegram-desktop: fails to build

[Liliana Marie Prikler]

Am Montag, dem 24.10.2022 um 09:13 -0800 schrieb Christopher Howard:
> I am able to install it normally using the most recent Guix commit.
> 
> On Sun, Oct 23, 2022 at 01:41:41PM +0200, Liliana Marie Prikler
> wrote:
> > Telegram was "recently" updated and is now getting proper
> > substitutes as far as I'm aware.
> > 
> > Does the problem persist?
Good to know.  Closing

bug#58760: Guix System iso too big for cdrom again

[Maxime Devos]

On 24-10-2022 18:08, pelzflorian (Florian Pelz) wrote:

Hello Guix,

[...] The result is that most
packages got slightly bigger and this broke the camel’s back.  From what
Tobias (Cc) wrote, he used the highest compression settings.

So it seems nothing can be done to make the install iso smaller than
700MB and [...]


IIUC, (C) packages in Guix are often compiled with -O2 (and sometimes 
without optimisation, if upstream doesn't set any flags and Guix forgets 
to set some optimisation flags manually).  I think -Os would be worth 
investigating.


>477K/gnu/store/2b3blhwbag1ial0dhxw7wh4zjxl0cqpk-pkg-config-0.29.2
>2.4M 
/gnu/store/3k1h2ifn12rs9a06arpvqzrz5k7bwqm1-linux-libre-headers-5.10.35


I don't think a reference should be kept to those. Maybe it can be 
eliminated.


>302K/gnu/store/6ab3j98gcd02882d1jp9w6kv40fgyspf-wayland-1.20.0

Given that our installer is a TUI, this one looks surprising to me.
Likewise for cairo and opus.

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58760: Guix System iso too big for cdrom again

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Heyo,

pelzflorian (Florian Pelz) 写道：

From what Tobias (Cc) wrote, he used the highest
compression settings.

So it seems nothing can be done to make the install iso smaller


Well…  I used the highest compression setting *for zisofs*.

Zisofs is an ancient (and non-standard :-) little hack that Linux 
supports, and it just happened to be enabled on our kernels 
already.  Plus it's fully transparent to the operating system. 
That's why I wrote that quick little patch: it was an amusing—to 
me—way to shrink our ISO basically for free.


We're the only distro that I've ever seen use it.

But we can go deeper if we choose to, by dropping zisofs and going 
for something like squashfs, which achieves higher compression 
through higher block sizes and better algorithms like XZ.


This is what other distributions with a compressed root file 
system do.


However, it's marginally more work as you have to loop-mount the 
image early during boot, and it doesn't involve obscure kernel 
arcana (boo), and CDs are even more obsolete than they were when I 
wrote that patch (yay), so don't wait for me to do it.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58760: Guix System iso too big for cdrom again

[Csepp]

"pelzflorian (Florian Pelz)"  writes:

> Hello Guix,
>
> thanks to commit
>
> commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
> Author: Tobias Geerinckx-Rice 
> Date:   Mon Apr 6 17:48:21 2020 +0200
>
> vm: Transparently compress iso9660 images.
> 
> * gnu/build/vm.scm (make-iso9660-image): Use the ‘--zisofs’ xorriso
> filter at the highest compression settings for supported directories.
>
> it was possible to burn the Guix System install image to a 700MB CD.
> But it fits no more.  I compared using the du tool (comparison between
> good old Guix version e427593 and bad new Guix version 3734857f (with
> unmerged installer patches) is attached).  The result is that most
> packages got slightly bigger and this broke the camel’s back.  From what
> Tobias (Cc) wrote, he used the highest compression settings.
>
> So it seems nothing can be done to make the install iso smaller than
> 700MB and support this antiquated storage medium, but I thought I’d open
> a bug and ask, because my laptop doesn’t boot from USB, I have more
> CD/Rs than DVD/Rs and I guess they are cheaper than DVD.
>
> Regards,
> Florian
>
> [2. text/plain; install-image-du-commit-e427593]...
>
> [3. text/plain; install-image-du-commit-3734857f]...
>
> [4. text/plain; install-image-du-comparison]...

Are there unnecessary dependencies that could be cut out?

bug#58763: [BUG] gnuzilla: icedove profiles don't work

[florhizome]

Hi,
Using the recent gnome desktop on a Guix system, Icedove seems to be unable to 
restore recent/the last used
configuration. This appears either by upgrade or reboot. (For some time
the configuration was stable, but I'm not sure which of the two killed it.
When I start it from the cli with the argument "-ProfileManager" ,
profiles are listed, but with either one selected, icedove will just
boot like a vanilla configuration.
However this error shows up
"JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't 
find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't 
find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't 
find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error:
Can't find profile directory."
This is kind of weird since the profiles are actually shown.

Since Icedove seems to be a guix product (?) I submit this to guix'
bugtracker as well.
Cheers, florhizome

bug#58760: Guix System iso too big for cdrom again

[pelzflorian (Florian Pelz)]

Hello Guix,

thanks to commit

commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
Author: Tobias Geerinckx-Rice 
Date:   Mon Apr 6 17:48:21 2020 +0200

vm: Transparently compress iso9660 images.

* gnu/build/vm.scm (make-iso9660-image): Use the ‘--zisofs’ xorriso
filter at the highest compression settings for supported directories.

it was possible to burn the Guix System install image to a 700MB CD.
But it fits no more.  I compared using the du tool (comparison between
good old Guix version e427593 and bad new Guix version 3734857f (with
unmerged installer patches) is attached).  The result is that most
packages got slightly bigger and this broke the camel’s back.  From what
Tobias (Cc) wrote, he used the highest compression settings.

So it seems nothing can be done to make the install iso smaller than
700MB and support this antiquated storage medium, but I thought I’d open
a bug and ask, because my laptop doesn’t boot from USB, I have more
CD/Rs than DVD/Rs and I guess they are cheaper than DVD.

Regards,
Florian

239K/gnu/store/00i95b7dlkwy3jxs7zmf26aj2xx9g4k1-guix-icons-0.1
264K/gnu/store/03bfgi532wmcvjiksxl5lfv08d2a-mcron-1.2.1
27K /gnu/store/06xhcadyz7yb6fr4372pwyks0chwd7li-wireless-regdb-2020.11.20
692K/gnu/store/070h6ybqn8jwr27lzmka3zdl9l9p2fyn-ntfs-3g-2021.8.22
129K/gnu/store/091s4h0hv6dsf2hk3124c3k5m3ibf09a-module-import
9.9M/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib
2.3M/gnu/store/0a1cfyj723lpl7akqyacrfx5mnmnypjq-elogind-246.10
124K/gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10
1.3M/gnu/store/0hng3anppzxbcm2vf6qpsp2cawlrqpjw-libnl-3.5.0
68K /gnu/store/0j5vj9ymnd2ln16xsp5fn3x8fjs9d828-module-import
2.0K/gnu/store/0kbdigzidwc57xz7c31q20hp1w7r9hzs-system
1017K   /gnu/store/0wnqkvxm4swkhggvhr2lbggvixqqywqi-findutils-4.8.0
4.0K/gnu/store/0zchy9afz47kbf6h5g816k2ac8mmc4a5-pam.d
98K /gnu/store/17rcyc25v3qal1cnxq30q1r5rvvjf07z-guile-lzma-0.1.1
29K /gnu/store/1angm77m7dscbhdx7hwssijclc3s-openfwwf-firmware-5.2
397K/gnu/store/1b9za8ja26bf0rx6ck802vf0q09w8czx-libfido2-1.9.0
2.3M/gnu/store/1gddq9hrlqsyr2pnbk9lqzm1ljbbl0vi-e2fsprogs-1.46.4
424K/gnu/store/1jsaaqyb7s5z0c07wcm3nvnhhm7fbi3w-libidn-1.37
21K /gnu/store/1p42zcz94ghdxldg55mirqjh3gcsiskq-iso639-languages
450K/gnu/store/1sv35zapdscwkq92vhx2ld0hfcy84ngc-jfsutils-1.1.15
998K/gnu/store/1wc9sy8hm0x7l7n93j67c2z82m3rx7ph-inetutils-2.0
6.0K/gnu/store/1xkw8slx0lnaldaza2p9dn5zya526bfm-etc
3.2M/gnu/store/22n2s0vfvqg9v0as9h7fpdn1i9dmryvi-texinfo-6.7
579K/gnu/store/25nlsljfziysgbhhj9nhwfm4qn5h4b71-liburcu-0.13.1
196K/gnu/store/2b2szj7bkwmw38k8xs0p3bm5shhk62xp-dosfstools-4.2
477K/gnu/store/2b3blhwbag1ial0dhxw7wh4zjxl0cqpk-pkg-config-0.29.2
67K /gnu/store/2i5alw7qcp35x0rn0yqxmvxv3pd6ln3w-libltdl-2.4.6
331K/gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4
1.5M/gnu/store/2lis8khrdk0zzjzs5ydi8rs5h6f6wjr7-shadow-4.9
171K/gnu/store/2nidr0m9g2339xlalqp8k57hz5qjnmdg-guile-readline-3.0.7
275K/gnu/store/2rl0dr9hccvpwg5dh7xw2vhsgnsnnbkr-libthai-0.1.28
2.5M/gnu/store/31ffp5lszf1g7h1zw750w621cm14hxlr-util-linux-2.37.2
1.5M/gnu/store/35lj2sn5p6wfd8h1j11hb2mcvria3cfl-iproute2-5.15.0
2.5M/gnu/store/37zhmvwd0nkprkk576zvf0da8c23nqwb-util-linux-with-udev-2.37.2
455K/gnu/store/3jyi415msv84pgbvn0nhfwjp7y6zqrs9-dbus-1.12.20
2.4M/gnu/store/3k1h2ifn12rs9a06arpvqzrz5k7bwqm1-linux-libre-headers-5.10.35
632K/gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8
81K /gnu/store/3kwgpc5swlpcb5kxvj59w03ljil5i9xv-libdatrie-0.2.13
3.4M
/gnu/store/3vw1ryic3pm4jrv3nw72p5c0b5f2hahx-util-linux-with-udev-2.37.2-lib
525K/gnu/store/3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib
2.5M/gnu/store/3ykcfr1g59gqbwpckg5v375k5iyy5yn3-openssh-8.8p1
989K/gnu/store/4001xfiqqdqmk289s3qq66ll10nqa8d5-cryptsetup-2.3.6
638K/gnu/store/42a19j9rnni49qdhg5fqpv52w95ggyaa-screen-4.8.0
801K/gnu/store/4f304c7dp68hkcp1zi1i07zm8nfvvyp7-bash-static-5.1.8
114K/gnu/store/4ff7h98gn50garnhb9xbf5vj3fm42pd9-kexec-tools-2.0.23
138K/gnu/store/4g1mjb2rwi6pcwp0nrc8zhia0sfq9k45-ca-certificate-bundle
160K/gnu/store/4gcznd9r1r3hlmkb2m7s1a37radgnspn-libtasn1-4.17.0
447K/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39
67K /gnu/store/4j3z5c16814xlldi4zxm99ki6d58ngva-ath9k-htc-firmware-1.4.0
34K /gnu/store/4r6f3a6n82nv48c7nznhhcl19k7pl0ig-libsigsegv-2.13
644K/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8
112K/gnu/store/52ry02pdl17072zcppsc7q0a1abwymmw-libnftnl-1.2.0
21K /gnu/store/53dn0dxvcsjy5b1lx21z0xjslk3s3gdd-locales
3.4M/gnu/store/5583c2za2jsn9g6az79rnksgvigwnsk7-util-linux-2.37.2-lib
1.8M/gnu/store/55q02v1a3qz8n7rlhy3jva9qjkfwj8y0-gawk-5.1.0
59K /gnu/store/58sgs8gxjmzxivzli8bpz77bdchglwcg-nss-mdns-0.14.1
1.4M/gnu/store/5bdkljfxz414w2vwrbqcrfsh54jq4sn2-alsa-utils-1.2.4
86K /gnu/store/5gqdzkw4kmg427bsgzwa5h5vlfi1y7c2-libcbor-0.8.0
16M 

bug#58697: [bug] guix refresh nftables crashes

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  writes:

> On 22-10-2022 03:55, kiasoc5 via Bug reports for GNU Guix wrote:
>> % guix refresh nftables
>> [...]
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> In procedure getaddrinfo: Servname not supported for ai_socktype
>> ```
>
> I can reproduce this locally and don't know the cause.
>

It happens when the origin have both 'mirror://' and 'http://' urls,
current the html updater check for any url match 'http' or 'https', but
when updating it will just pick the first url, so when the first is
'mirror://' this error will come.

This patch should fix it:

>From e9dfdc3a2031c25043cc8b6f4b08656d05024c16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Mon, 24 Oct 2022 16:35:18 +0800
Subject: [PATCH] gnu-maintenance: Don't try html updater on 'mirror://' urls.

This fixes .

* guix/gnu-maintenance.scm (latest-html-updatable-release): Use the first http
or https url for updating.
---
 guix/gnu-maintenance.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/guix/gnu-maintenance.scm b/guix/gnu-maintenance.scm
index 10a6ec05f1..4cd501e492 100644
--- a/guix/gnu-maintenance.scm
+++ b/guix/gnu-maintenance.scm
@@ -806,10 +806,16 @@ (define http-url?
 (define (latest-html-updatable-release package)
   "Return the latest release of PACKAGE.  Do that by crawling the HTML page of
 the directory containing its source tarball."
+  (define (http-url? url)
+(match (string->uri url)
+  (#f #f)
+  (uri (let ((scheme (uri-scheme uri)))
+ (memq scheme '(http https))
   (let* ((uri   (string->uri
  (match (origin-uri (package-source package))
((? string? url) url)
-   ((url _ ...) url
+   ;; We need filter out possibly 'mirror://' urls.
+   ((? list? urls) (first (filter http-url? urls))
  (custom(assoc-ref (package-properties package)
'release-monitoring-url))
  (base  (or custom
-- 
2.37.3

bug#58631: [Shepherd] Indefinite heap growth (memory leak)

[Ludovic Courtès]

Liliana Marie Prikler  skribis:

> Am Donnerstag, dem 20.10.2022 um 11:29 +0200 schrieb Ludovic Courtès:
>> Logging as performed by ‘%service-file-logger’ is quite GC-intensive
>> (but shouldn’t be leaky!); this bit:
>> 
>>  (let ((prefix (strftime default-logfile-date-format
>>  (localtime (current-time)
>>    (format output "~a~a~%" prefix line)
>>    (loop))
>
>  (let ((prefix (strftime default-logfile-date-format
>  (localtime (current-time)
>(format output "~a~a~%" prefix line)
>(loop))
>
> Would it make a difference if you instead wrote
>
>  (let ((prefix (strftime default-logfile-date-format
>  (localtime (current-time)
>(format output "~a~a~%" prefix line))
>  (loop)
>
> ?  Semantically, they're equivalent (perhaps with a wrapping begin
> needed), but the compiler might fail to see this.

I’m confident the compiler does the right thing, and it’s a tail call so
‘prefix’ doesn’t outlive one loop iteration.

Ludo’.

bug#53541: [installer] backtrace during fresh Guix System install after during formatting

[Mathieu Othacehe]

Hey,

> I was able to reproduce it on real hardware, following those
> instructions. The dump is available here if people want to join the
> party: dump.guix.gnu.org/download/installer-dump-304492ff.

So the backtrace suggests that we are trying to open /dev/nvme0n1p1 to
read its superblock:

--8<---cut here---start->8---
   9 (open "/dev/nvme0n1p1" 524288 #)
--8<---cut here---end--->8---

and that it fails because the file does not exist:

--8<---cut here---start->8---
  1780:13  6 (_ #< components: (#<> #< 
origin: "open-fdes"> #< message: "~A"> #< irritants: ("No 
such file or directory")> #<…>)
--8<---cut here---end--->8---

This open call originates from check-user-partitions in (gnu installer
parted). If we arrive here, it means that the file *should* exist.

Looking at the kernel trace, the two last lines are:

--8<---cut here---start->8---
[   72.271204]  nvme0n1: p1 p2 p3 p4
[  127.415648]  nvme0n1: p1 p2
--8<---cut here---end--->8---

so the disk partition table is updated because we move from 4 to 2
partitions. Could it be possible that during a brief period of time the
/dev/nvme0n1p1 file disappears then re-appears?

I'll try to reproduce it a VM to conduct more testing.

Mathieu