Follow-up: 1.3.0 installer couldn't be used again, will submit another bug for the reason why separately.

Using the snapshot 520v5sznglla0z1g3mz6pfsml88b8gxx-image.iso did not have the error 1.3.0 did trying to format/write to the partition and the install was able to complete.

So it seems as if there is an issue with the partitioning software in the 1.3.0 image.


On Fri, Jul 15, 2022 at 10:18 AM sunspark <sunspark@gmail.com> wrote:
Hi, 

I confirm it was with the 1.3.0 installer. 

I have since downloaded the snapshot installer but I haven't tested it yet. However I would need to be careful testing because this time around I have created raw unformatted partitions in Windows disk manager because it annoys me how different Linux disk utilities round numbers differently. The guix installer views 64 GB as 68.7 GB and entering 68.7 there to create a matching 64 creates 63.98 GB instead. 

I suppose I would need to run it twice again with the 1.3 first. Once to see if just formatting a windows created raw partition fixes it and once with a filesystem that isn't ext4 then the snapshot. 

My partition table is standard. 100 meg efi, 128 meg Microsoft reserved partiton, two NTFS partitions, the two ext4s I was attempting to create in unallocated space and a linux swap partition already created. 

Incidentally, the reboot command in F1 doesn't work either. Just black screens. Need to hold the power button down.

Best,
Peter





Sent from my Galaxy


-------- Original message --------
From: Ludovic Courtès <ludo@gnu.org>
Date: 2022-07-15 06:58 (GMT-05:00)
To: Peter <sunspark@gmail.com>
Cc: 56572@debbugs.gnu.org
Subject: Re: bug#56572: failed install on partition, backtrace attached

Hi Peter,

Peter <sunspark@gmail.com> skribis:

> I did manual partitioning because I didn't want to wipe the other
> partitions out.
>
> Set / and /home partitions, formatted as EXT4.
>
> Crashes as soon as it writes the changes, displays the backtrace and
> restarts the installer.

Ouch.  Could you confirm it was with the 1.3.0 installer?

It would seem that the bug comes from ‘read-partition-uuid’ returning #f
in this function:

--8<---------------cut here---------------start------------->8---
(define (user-partition->file-system user-partition)
  "Convert the given USER-PARTITION record in a FILE-SYSTEM record from
(gnu system file-systems) module and return it."
  (let* ((mount-point (user-partition-mount-point user-partition))
         (fs-type (user-partition-fs-type user-partition))
         (crypt-label (user-partition-crypt-label user-partition))
         (mount-type (user-fs-type->mount-type fs-type))
         (file-name (user-partition-file-name user-partition))
         (upper-file-name (user-partition-upper-file-name user-partition))
         ;; Only compute uuid if partition is not encrypted.
         (uuid (or crypt-label
                   (uuid->string (read-partition-uuid file-name) fs-type))))
    `(file-system
       (mount-point ,mount-point)
       (device ,@(if crypt-label
                     `(,upper-file-name)
                     `((uuid ,uuid (quote ,fs-type)))))
       (type ,mount-type)
       ,@(if crypt-label
             '((dependencies mapped-devices))
             '()))))
--8<---------------cut here---------------end--------------->8---

This can happen if a partition you chose to create actually contains
random data or a file system not supported by (gnu build file-systems);
this, in turn, can happen if you chose not to format partitions during
the installation process.

Could it be what happened in your case?

Ludo’.