Installer crash: 'uuid->string' is passed #f in lieu of a UUID

  • Done
  • quality assurance status badge
Details
8 participants
  • andi
  • David Wilson
  • Tim Magee via web
  • Leo Famulari
  • Ludovic Courtès
  • Mathieu Othacehe
  • Mathieu Othacehe
  • Tim Magee
Owner
unassigned
Submitted by
Tim Magee
Severity
important
T
T
Tim Magee wrote on 25 Nov 2020 18:26
GuixSD 1.2.0 installer fails with exception when formatting drive
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
300530410.943064.1606325189191@mail.yahoo.com
I attempted to intall GNU Guix using the 1.2.0 GuixSD installation image. The install failed with an exception when formatting the hard drive. Here follows the backtrace:

----------------------------------------------------------------------------------------------------------------------------------------

The installer has encountered an unexpected problem. The backtrace is displayed below. Please report it by email to <bug-guix@gnu.org>.

In ./gnu/installer/parted.scm:
  1258:19 19 (user-partition->file-system _)
In gnu/system/uuid.scm:
    317:2 18 (uuid->string . _)
In ice-9/boot-9.scm:
  1669:16 17 (raise-exception _ #:continuable? _)
  1667:16 16 (raise-exception _ #:continuable? _)
  1667:16 15 (raise-exception _ #:continuable? _)
  1667:16 14 (raise-exception _ #:continuable? _)
  1667:16 13 (raise-exception _ #:continuable? _)
  1667:16 12 (raise-exception _ #:continuable? _)
  1667:16 11 (raise-exception _ #:continuable? _)
  1667:16 10 (raise-exception _ #:continuable? _)
  1667:16  9 (raise-exception _ #:continuable? _)
  1667:16  8 (raise-exception _ #:continuable? _)
  1669:16  7 (raise-exception _ #:continuable? _)
  1764:13  6 (_ #<&compound-exception components: (#<&error> #<&origin: "match"> #<&message message: "no matching pattern"> #<&irritants irritants: (#f ext4)> #<&exception-with-kind-and-arg...>)
In ice-9/eval.scm:
    619:8  5 (_ #(#(#<directory (guile-user) 7f10d0fb6f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key args)> f...>) ...))
    619:8  4 (_ #(#(#(#<directory (guile-user) 7f10d0fb6f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key args)> f...>) ...))
In ice-9/ports.scm:
   463:17  3 (call-with-output-file _ _ #:binary _ #:encoding _)
In ice-9/eval.scm:
    691:9  2 (_ #(#(#<directory (guile-user) 7f10d0fbf00> match-error ("match" "no matching pattern" (#f ext4))) #<output: /tmp/last-installer-error 19>))
    159:9  1 (_ #(#(#<directory (guile-user) 7f10d0fbf00> match-error ("match" "no matching pattern" (#f ext4))) #<output: /tmp/last-installer-error 19>))
In unknown file:
           0 (make-stack #t)
ice-9/eval.scm:159:9: Throw to key `match-error' with args `("match" "no matching pattern" (#f ext4))'.

----------------------------------------------------------------------------------------------------------------------------------------

@nckx on the IRC recommend I include the output of fdisk -l in my bug report. So here goes:

Disk /dev/sda: 931.53GiB, 100020104886016 bytes, 1953525168 sectors
Disk model: WDC WDS100T2B0A-
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 425B5102-51E0-4994-BC78-FBE09F62D9E3

Device       Start        End    Sectors   Size Type
/dev/sda1     2048    1126399    1124352   549M EFI System
/dev/sda2  1126400    1132543       6144     3M BIOS boot
/dev/sda3  1132544    8943615    7811072   3.7G Linux swap
/dev/sda4  8943616 1953523711 1944580096 927.3G Linux filesystem
M
M
Mathieu Othacehe wrote on 26 Nov 2020 09:58
(name . Tim Magee)(address . timothy@eastlincoln.net)(address . 44872@debbugs.gnu.org)
87ft4wijeb.fsf@gnu.org
Hello,

Thanks for the bug report and sorry for the inconvenience.

Toggle quote (3 lines)
> In gnu/system/uuid.scm:
>     317:2 18 (uuid->string . _)

It looks like the UUID extraction of an "ext4" partition failed. Did you
use automatic or manual partitioning?

Thanks,

Mathieu
T
T
Tim Magee wrote on 27 Nov 2020 04:12
Fw: bug#44872: GuixSD 1.2.0 installer fails with exception when formatting drive
(name . 44872@debbugs.gnu.org)(address . 44872@debbugs.gnu.org)
443965706.1205124.1606446725138@mail.yahoo.com
Toggle quote (1 lines)
> It looks like the UUID extraction of an "ext4" partition failed. Did you
use automatic or manual partitioning?


I used automatic partitioning this time. But it failed with an exception when I had previously tried manual partitioning as well. Though I believe it was a different error then.
M
M
Mathieu Othacehe wrote on 27 Nov 2020 21:03
control message for bug #44872
(address . control@debbugs.gnu.org)
87o8jir2il.fsf@cervin.i-did-not-set--mail-host-address--so-tickle-me
severity 44872 important
quit
T
T
Tim Magee wrote on 28 Nov 2020 06:27
Re: bug#44872: GuixSD 1.2.0 installer fails with exception when formatting drive
(address . 44872@debbugs.gnu.org)
27a49c91-3145-b97a-95d9-80147893aa1a@eastlincoln.net
I successfully installed GNU Guix.

The work around I used for this bug is I simply ran `sudo dd
if=/dev/zero of=/dev/sda`. Basically, I think the existence of an old
GPT partition table is causing problems on a new install though I'm not
sure why.

Unfortunately, this computer is my daily driver and I need it working so
I can't run any more tests at this time.
A
A
andi wrote on 29 Nov 2020 20:02
GuixSD 1.2.0 installer fails with exception when formatting drive
(address . 44872@debbugs.gnu.org)
20201129190234.qgulysw6dyjkj6vd@wrt
I did run into a similar issue and it turned out to be me selecting
/dev/sr0 in the device selection dialog instead of the actual VM disk.
M
M
Mathieu Othacehe wrote on 1 Dec 2020 10:46
(name . Tim Magee)(address . timothy@eastlincoln.net)(address . 44872@debbugs.gnu.org)
87sg8p3lkd.fsf@gnu.org
Hey Tim,

Toggle quote (7 lines)
> I successfully installed GNU Guix.
>
> The work around I used for this bug is I simply ran `sudo dd
> if=/dev/zero of=/dev/sda`. Basically, I think the existence of an old
> GPT partition table is causing problems on a new install though I'm not
> sure why.

Nice you found a work-around. I think I already hit this issue myself
without being able to reproduce it. Do you remember what was the
previous GPT layout of your drive? Maybe the distribution previously
installed?

Thanks,

Mathieu
T
T
Tim Magee via web wrote on 22 Dec 2020 03:13
GuixSD 1.2.0 installer fails with exception when formatting drive
(address . 44872@debbugs.gnu.org)
7f1b419166e0.fead5d496026745@guile.gnu.org
I previously had GNU Guix installed with an encrypted home partition but the main partition unencrypted.
L
L
Ludovic Courtès wrote on 15 Apr 2021 10:59
control message for bug #47297
(address . control@debbugs.gnu.org)
87im4ndit3.fsf@gnu.org
block 47297 by 44872
quit
L
L
Ludovic Courtès wrote on 22 Apr 2021 15:38
control message for bug #44872
(address . control@debbugs.gnu.org)
875z0e1lsh.fsf@gnu.org
retitle 44872 Installer crash: 'uuid->string' is passed #f in lieu of a UUID
quit
L
L
Ludovic Courtès wrote on 22 Apr 2021 16:48
Re: bug#44872: GuixSD 1.2.0 installer fails with exception when formatting drive
(name . Tim Magee)(address . timothy@eastlincoln.net)
87y2daz87n.fsf@gnu.org
Hi,

Tim Magee <timothy@eastlincoln.net> skribis:

Toggle quote (29 lines)
> In ./gnu/installer/parted.scm:
>   1258:19 19 (user-partition->file-system _)
> In gnu/system/uuid.scm:
>     317:2 18 (uuid->string . _)
> In ice-9/boot-9.scm:
>   1669:16 17 (raise-exception _ #:continuable? _)
>   1667:16 16 (raise-exception _ #:continuable? _)
>   1667:16 15 (raise-exception _ #:continuable? _)
>   1667:16 14 (raise-exception _ #:continuable? _)
>   1667:16 13 (raise-exception _ #:continuable? _)
>   1667:16 12 (raise-exception _ #:continuable? _)
>   1667:16 11 (raise-exception _ #:continuable? _)
>   1667:16 10 (raise-exception _ #:continuable? _)
>   1667:16  9 (raise-exception _ #:continuable? _)
>   1667:16  8 (raise-exception _ #:continuable? _)
>   1669:16  7 (raise-exception _ #:continuable? _)
>   1764:13  6 (_ #<&compound-exception components: (#<&error> #<&origin: "match"> #<&message message: "no matching pattern"> #<&irritants irritants: (#f ext4)> #<&exception-with-kind-and-arg...>)
> In ice-9/eval.scm:
>     619:8  5 (_ #(#(#<directory (guile-user) 7f10d0fb6f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key args)> f...>) ...))
>     619:8  4 (_ #(#(#(#<directory (guile-user) 7f10d0fb6f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key args)> f...>) ...))
> In ice-9/ports.scm:
>    463:17  3 (call-with-output-file _ _ #:binary _ #:encoding _)
> In ice-9/eval.scm:
>     691:9  2 (_ #(#(#<directory (guile-user) 7f10d0fbf00> match-error ("match" "no matching pattern" (#f ext4))) #<output: /tmp/last-installer-error 19>))
>     159:9  1 (_ #(#(#<directory (guile-user) 7f10d0fbf00> match-error ("match" "no matching pattern" (#f ext4))) #<output: /tmp/last-installer-error 19>))
> In unknown file:
>            0 (make-stack #t)
> ice-9/eval.scm:159:9: Throw to key `match-error' with args `("match" "no matching pattern" (#f ext4))'.

Apparently what happens here is that ‘read-partition-uuid’, called by
‘user-partition->file-system’, returns #f, and that value is then passed
to ‘uuid->string’.

There are two ways ‘read-partition-uuid’ can return #f:

1. the partition doesn’t have one of the types listed in
‘%partition-uuid-readers’;

2. the partition does not exist or is EIO (see use of ‘ENOENT-safe’ in
‘partition-field-reader’).

So most likely the problem is #2.

Now, when we reach this code (from ‘user-partitions->configuration’),
partitions have been created. I wonder if there’s a possibility that
the kernel hasn’t yet updated /dev by the time we reach this?

‘free-parted’ is supposed to avoid that though.

WDYT, Mathieu?

Ludo’.
L
L
Ludovic Courtès wrote on 23 Apr 2021 00:40
Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
(name . Tim Magee)(address . timothy@eastlincoln.net)
87lf9at022.fsf_-_@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (14 lines)
> Apparently what happens here is that ‘read-partition-uuid’, called by
> ‘user-partition->file-system’, returns #f, and that value is then passed
> to ‘uuid->string’.
>
> There are two ways ‘read-partition-uuid’ can return #f:
>
> 1. the partition doesn’t have one of the types listed in
> ‘%partition-uuid-readers’;
>
> 2. the partition does not exist or is EIO (see use of ‘ENOENT-safe’ in
> ‘partition-field-reader’).
>
> So most likely the problem is #2.

I pushed a change so that ‘read-partition-uuid’ & co. will no longer
swallow ENOENT, so we at least get more accurate error reports:


Ludo’.
L
L
Leo Famulari wrote on 17 May 2021 16:42
(no subject)
(name . GNU bug tracker automated control server)(address . control@debbugs.gnu.org)
YKKA8znk4iCdZbEp@jasmine.lan
unblock 47297 with 47567
unblock 47297 with 44872
close 47297
D
D
David Wilson wrote on 6 Jun 2021 01:08
Re: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
(address . 44872@debbugs.gnu.org)
87fsxvsyek.fsf@daviwil.com
Hi Guix!

I also just hit this issue while using the graphical installer on a
machine that previously had Guix installed on it via the shell-driven
manual installation flow. I'm working on a video to show how to install
Guix using the graphical installer so it's a big blocker for me hit this
seemingly impassable error.

Is there any other workaround you can think of that might help the code
resolve the UUID of the partition correctly? I'm not sure how these
things are supposed to work but I'm happy to try any ideas you may have!
I'd also be happy to make any speculative tweaks to the source that you
recommend.

On my side, I've tried deleting and recreating the target partition a
few times using both the graphical installer and `cfdisk', nothing seems
to help.

Let me know what I can do to help diagnose and fix this issue!

Thanks,

David
M
M
Mathieu Othacehe wrote on 7 Jun 2021 08:20
Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
(name . David Wilson)(address . david@daviwil.com)(address . 44872@debbugs.gnu.org)
8735tunqla.fsf@gnu.org
Hello David,

Toggle quote (6 lines)
> I also just hit this issue while using the graphical installer on a
> machine that previously had Guix installed on it via the shell-driven
> manual installation flow. I'm working on a video to show how to install
> Guix using the graphical installer so it's a big blocker for me hit this
> seemingly impassable error.

It's great that you are making a video about the installer!

Toggle quote (2 lines)
> Let me know what I can do to help diagnose and fix this issue!

The problem here is probably caused by the "free-parted" procedure
returning before all the partitions are properly created by the kernel.

You could maybe try to run a custom installer image with the hideous
attached patch to confirm this theory.

Thanks,

Mathieu
Attachment: diff
D
D
David Wilson wrote on 8 Jun 2021 18:33
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 44872@debbugs.gnu.org)
87a6o071vh.fsf@daviwil.com
Hi Mathieu!

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (6 lines)
> The problem here is probably caused by the "free-parted" procedure
> returning before all the partitions are properly created by the kernel.
>
> You could maybe try to run a custom installer image with the hideous
> attached patch to confirm this theory.

I built a new installer image with the fix you provided and it
unfortunately didn't resolve the issue. I did see the sleep occur after
I confirmed the partitioning dialog, so the patch is definitely in
place.

I spent a lot of time on Sunday investigating this and I'm pretty
confused as to why it's happening. It seems that for some reason
`read-partition-uuid' is returning `#f' for one of my partitions in the
installer but I'm not sure which one it is. Is it the case that it
should only be looking at the partitions that I'm mounting?

Take a look at these logs from a `guix repl' session (sorry for the
image, couldn't copy text from that machine):


The two partitions that I'm setting as mount points in the graphical
installer are:

- /dev/nvme0n1p1: An existing vfat EFI partition created for the
original Windows install on this machine
- /dev/nvme0n1p6: A fresh ext4 partition that I created and formatted
myself in the shell with `cfdisk' and `mkfs.ext4'.

As you can see from the logs, both `read-partition-uuid' and
`uuid->string' are both returning the expected outputs. I've
double-checked the UUIDs with `cfdisk' and they match up perfectly.

The reason why I think this isn't related to `free-parted' is because
I'm not actually creating or changing any of the partitions in the
partitioning page; the only setting I change is to set the mount point
of /dev/nvme0n1p6 to `/'. The EFI partition is already detected and
set to mount at /boot/efi.

Any thoughts on what else I can try? I'm happy to try anything since I
have a very reliable repro in front of me :)

Thanks!

David
M
M
Mathieu Othacehe wrote on 9 Jun 2021 17:57
(name . David Wilson)(address . david@daviwil.com)(address . 44872@debbugs.gnu.org)
87a6nzxc7h.fsf@gnu.org
Hey David,

Toggle quote (5 lines)
> Take a look at these logs from a `guix repl' session (sorry for the
> image, couldn't copy text from that machine):
>
> https://0x0.st/-_no.jpg

Thanks for the very valuable information here! I managed to reproduce a
very similar crash in Qemu by simulating your hard drive layout:

Toggle snippet (17 lines)
mathieu@meije ~$ fdisk -l guix-system.img
Disk guix-system.img: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7477884D-53F7-484F-BE53-D09EFE1DA63F

Device Start End Sectors Size Type
guix-system.img1 2048 534527 532480 260M EFI System
guix-system.img2 534528 567295 32768 16M Microsoft reserved
guix-system.img3 567296 11053055 10485760 5G Microsoft basic data
guix-system.img4 11053056 13150207 2097152 1G Windows recovery environment
guix-system.img5 13150208 15247359 2097152 1G Linux filesystem
guix-system.img6 15247360 20971486 5724127 2.7G Linux filesystem

I'm using manual partitioning with the first partition mounted as the
ESP partition and the sixth partition as the root directory.

The backtrace and the messages log file are attached. I'll try to find
some spare time to understand what's going on.

Thanks,

Mathieu
Attachment: last-installer-error
Attachment: messages
D
D
David Wilson wrote on 9 Jun 2021 18:44
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 44872@debbugs.gnu.org)
875yyn6l9d.fsf@daviwil.com
Hey Mathieu,

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (7 lines)
> I'm using manual partitioning with the first partition mounted as the
> ESP partition and the sixth partition as the root directory.
>
> The backtrace and the messages log file are attached. I'll try to find
> some spare time to understand what's going on.
>

Awesome, glad you were able to reproduce it! The stack trace you
attached is consistent with what I've seen. I'm curious to learn
what you discover when you have a chance to look into it!


Thanks,

David
M
M
Mathieu Othacehe wrote on 12 Jun 2021 09:49
(name . David Wilson)(address . david@daviwil.com)(address . 44872@debbugs.gnu.org)
87pmwred5f.fsf@gnu.org
Hello David,

Toggle quote (3 lines)
>> I'm using manual partitioning with the first partition mounted as the
>> ESP partition and the sixth partition as the root directory.

My issue here is that those partitions were never formatted. The
read-partition-uuid method returns #f on unformatted partitions, causing
the installer crash.

I fixed this issue with f5d9d6ec68f78f5651bd5a698f489ab57bf77d5d. The
rationale is that any partition that will be mounted and not formatted
("Format the partition? No) must have a valid UUID. The installer
now prevents going further if this is not the case.

That said, I think you are experiencing a different issue. The REPL
commands you ran show that your nvme0n1p1 and nvme0n1p6 partitions have
valid UUIDs.

That's why I also pushed this commit:
1a0a18d0ccc6cb6c7f4e42a0d659340f13b206c5 that prints in the syslog the
internal <user-partitions> list, hoping that it will help us understand
what's going on.

It would be great if you could build a new installer image on top of
master, try reproducing the crash and attach the content of the
"/var/log/messages" file. You can for instance scp it to another machine
of your local network running an SSH server.

I'm not sure if you are aware of this feature, but generating
uncompressed ISO9660 image is a serious time saver when debugging the
installer:

Toggle snippet (3 lines)
guix system image -t uncompressed-iso9660 gnu/system/install.scm

Thanks,

Mathieu
D
D
David Wilson wrote on 12 Jun 2021 15:53
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 44872@debbugs.gnu.org)
871r97195g.fsf@daviwil.com
Hey Mathieu, thanks for looking into this!

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (9 lines)
> I fixed this issue with f5d9d6ec68f78f5651bd5a698f489ab57bf77d5d. The
> rationale is that any partition that will be mounted and not formatted
> ("Format the partition? No) must have a valid UUID. The installer
> now prevents going further if this is not the case.
>
> That said, I think you are experiencing a different issue. The REPL
> commands you ran show that your nvme0n1p1 and nvme0n1p6 partitions have
> valid UUIDs.

Your change seems to have exposed the real (and totally unexpected)
problem! For some reason, the installer is trying to get the UUID of
a partition on my USB stick that contains the installer.

It seems that for some reason the installer has automatically picked a
mount point of `/boot/efi' for `/dev/sda2' in addition to the mount
points on my actual hard drive. I now see an error dialog saying that
it can't retrieve the UUID of /dev/sda2 when I try to proceed past the
partitioning page. If I clear the mount point for /dev/sda2, I am now
able to proceed to the page to with the generated system configuration!

At this point I think I should be able to proceed with making the
installation video I was working on, I'll just let viewers know that
they may need to clear that mount point if the same thing happens for
them.

Toggle quote (8 lines)
> I'm not sure if you are aware of this feature, but generating
> uncompressed ISO9660 image is a serious time saver when debugging the
> installer:
>
> --8<---------------cut here---------------start------------->8---
> guix system image -t uncompressed-iso9660 gnu/system/install.scm
> --8<---------------cut here---------------end--------------->8---

I wasn't aware, thanks for letting me know! Creating the image was a
lot faster this time :)

David
M
M
Mathieu Othacehe wrote on 12 Jun 2021 18:53
(name . David Wilson)(address . david@daviwil.com)(address . 44872@debbugs.gnu.org)
87bl8bhvnr.fsf@gnu.org
Hey,

Toggle quote (7 lines)
> It seems that for some reason the installer has automatically picked a
> mount point of `/boot/efi' for `/dev/sda2' in addition to the mount
> points on my actual hard drive. I now see an error dialog saying that
> it can't retrieve the UUID of /dev/sda2 when I try to proceed past the
> partitioning page. If I clear the mount point for /dev/sda2, I am now
> able to proceed to the page to with the generated system configuration!

Oh, I understand! The installation device is not detected by the
non-install-devices procedure, as it often happens. Hence, the
create-special-user-partitions finds two ESP partitions. The one on your
main hard drive and the one on the installation ISO.

Reading the UUID of the ESP partition of the installation ISO returns
false, not sure why, but this is not the central issue.

I improved the install device detection with
154a4e046281c28e39b5016e965d3d937a2ea4a1 by removing the device with the
default Guix System image ISO label.

This is quite fragile and if someone has a better idea, please feel free
to share it :). In the meantime, it should completely fix your issue.

Thanks a lot for your help,

Mathieu
D
D
David Wilson wrote on 13 Jun 2021 00:26
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 44872@debbugs.gnu.org)
87y2bezpm6.fsf@daviwil.com
Hey Mathieu!

Mathieu Othacehe <othacehe@gnu.org> writes:

Toggle quote (4 lines)
> I improved the install device detection with
> 154a4e046281c28e39b5016e965d3d937a2ea4a1 by removing the device with the
> default Guix System image ISO label.

Works perfectly for me now, the USB installation device doesn't show up
in the device list anymore!

I've installed Guix about 5 times after building an image from the
latest changes, works perfectly for me both with encrypted and
unencrypted root partitions.

Thanks a lot for your help!

David
M
M
Mathieu Othacehe wrote on 17 Jun 2021 12:24
(name . David Wilson)(address . david@daviwil.com)(address . 44872-done@debbugs.gnu.org)
87zgvoaiwq.fsf@gnu.org
Hey,

Toggle quote (4 lines)
> I've installed Guix about 5 times after building an image from the
> latest changes, works perfectly for me both with encrypted and
> unencrypted root partitions.

Great, I improved the installation device detection again with:
e12be802e02b3345a753e7ec1287852a7337a0a5.

I think we can close that one.

Thanks,

Mathieu
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 44872@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44872
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch