Report forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Wed, 25 Nov 2020 17:27:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Tim Magee <timothy@eastlincoln.net>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Wed, 25 Nov 2020 17:27:02 GMT) (full text, mbox, link).
Subject: Re: bug#44872: GuixSD 1.2.0 installer fails with exception when
formatting drive
Date: Thu, 26 Nov 2020 09:58:52 +0100
Hello,
Thanks for the bug report and sorry for the inconvenience.
> 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
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Fri, 27 Nov 2020 03:13:02 GMT) (full text, mbox, link).
To: "44872@debbugs.gnu.org" <44872@debbugs.gnu.org>
Subject: Fw: bug#44872: GuixSD 1.2.0 installer fails with exception when
formatting drive
Date: Fri, 27 Nov 2020 03:12:05 +0000 (UTC)
> 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.
Severity set to 'important' from 'normal'
Request was from Mathieu Othacehe <mathieu@cervin.i-did-not-set--mail-host-address--so-tickle-me>
to control@debbugs.gnu.org.
(Fri, 27 Nov 2020 20:04:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Sat, 28 Nov 2020 05:28:02 GMT) (full text, mbox, link).
Subject: Re: bug#44872: GuixSD 1.2.0 installer fails with exception when
formatting drive
Date: Sat, 28 Nov 2020 00:27:19 -0500
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.
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Sun, 29 Nov 2020 19:03:02 GMT) (full text, mbox, link).
Subject: Re: bug#44872: GuixSD 1.2.0 installer fails with exception when
formatting drive
Date: Tue, 01 Dec 2020 10:46:58 +0100
Hey Tim,
> 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
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Tue, 22 Dec 2020 02:14:01 GMT) (full text, mbox, link).
From: Tim Magee via web <issues.guix.gnu.org@elephly.net>
To: 44872@debbugs.gnu.org
Subject: GuixSD 1.2.0 installer fails with exception when formatting drive
Date: Tue, 22 Dec 2020 03:13:47 +0100
I previously had GNU Guix installed with an encrypted home partition but the main partition unencrypted.
Added indication that bug 44872 blocks47297
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Thu, 15 Apr 2021 09:01:02 GMT) (full text, mbox, link).
Changed bug title to 'Installer crash: 'uuid->string' is passed #f in lieu of a UUID' from 'GuixSD 1.2.0 installer fails with exception when formatting drive'
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Thu, 22 Apr 2021 13:40:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Thu, 22 Apr 2021 14:49:01 GMT) (full text, mbox, link).
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Fri, 23 Apr 2021 00:40:53 +0200
Ludovic Courtès <ludo@gnu.org> skribis:
> 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:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=09ce4568f2cc1f87c5a5e0aa1643780c39a73088
Ludo’.
Removed indication that bug 44872 blocks
Request was from Leo Famulari <leo@famulari.name>
to control@debbugs.gnu.org.
(Mon, 17 May 2021 14:44:01 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Sat, 05 Jun 2021 23:09:02 GMT) (full text, mbox, link).
Subject: Re: Installer crash: 'uuid->string' is passed #f in lieu of a UUID
Date: Sat, 05 Jun 2021 16:08:03 -0700
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
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Tue, 08 Jun 2021 00:14:02 GMT) (full text, mbox, link).
Hello David,
> 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!
> 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
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Tue, 08 Jun 2021 09:33:06 -0700
Hi Mathieu!
Mathieu Othacehe <othacehe@gnu.org> writes:
> 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):
https://0x0.st/-_no.jpg
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
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Wed, 09 Jun 2021 15:58:01 GMT) (full text, mbox, link).
Hey David,
> 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:
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
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
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Wed, 09 Jun 2021 09:44:14 -0700
Hey Mathieu,
Mathieu Othacehe <othacehe@gnu.org> writes:
> 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
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Sat, 12 Jun 2021 07:50:01 GMT) (full text, mbox, link).
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Sat, 12 Jun 2021 09:49:00 +0200
Hello David,
>> 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:
--8<---------------cut here---------------start------------->8---
guix system image -t uncompressed-iso9660 gnu/system/install.scm
--8<---------------cut here---------------end--------------->8---
Thanks,
Mathieu
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Sat, 12 Jun 2021 13:54:02 GMT) (full text, mbox, link).
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Sat, 12 Jun 2021 06:53:47 -0700
Hey Mathieu, thanks for looking into this!
Mathieu Othacehe <othacehe@gnu.org> writes:
> 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.
> 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
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Sat, 12 Jun 2021 16:54:01 GMT) (full text, mbox, link).
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Sat, 12 Jun 2021 18:53:12 +0200
Hey,
> 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
Information forwarded
to bug-guix@gnu.org: bug#44872; Package guix.
(Sat, 12 Jun 2021 22:27:02 GMT) (full text, mbox, link).
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Sat, 12 Jun 2021 15:26:25 -0700
Hey Mathieu!
Mathieu Othacehe <othacehe@gnu.org> writes:
> 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
Reply sent
to Mathieu Othacehe <othacehe@gnu.org>:
You have taken responsibility.
(Thu, 17 Jun 2021 10:25:02 GMT) (full text, mbox, link).
Notification sent
to Tim Magee <timothy@eastlincoln.net>:
bug acknowledged by developer.
(Thu, 17 Jun 2021 10:25:02 GMT) (full text, mbox, link).
Subject: Re: bug#44872: Installer crash: 'uuid->string' is passed #f in lieu
of a UUID
Date: Thu, 17 Jun 2021 12:24:05 +0200
Hey,
> 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
bug archived.
Request was from Debbugs Internal Request <help-debbugs@gnu.org>
to internal_control@debbugs.gnu.org.
(Thu, 15 Jul 2021 11:24:06 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.
