Installer does not handle FAT16 file systems

Hi folks,

I'm trying to install from the GNU GUIX 1.0.0 ISO, which I've copied to

USB. I pick the graphical installer, run through the language,

timezone, and keyboard choices. Then I either pick "guided" or "guided

with encryption" partition scheme, and I choose one big partition

instead of separate /home. Then the error appears.

I've attached a scaled down photo of the trace, as that was the easiest

way to get it off of the system I'm running on (which isn't networked

at the time of error). For clarity, the error message is:

ice-9/eval.scm:159:9: Unhandled fat16 fs-type

My hardware is a Dell Latitude E7450 and I'm trying to use a (currently

GPT-partitioned) Samsung SSD PM871 mSATA 256GB disk. If the installer

is confused by the existing FAT16 partition, that's the EFI partition.

Presumably I could work around it by repartitioning and removing the

EFI partition before running the installer. If so, should I switch to

an MBR partition table? Or is there a fix, or another workaround?

Thanks for your help,

Graham.

retitle 35722 Installer does not handle FAT16 file systems

severity 35722 important

Hello,

Graham Lee <graham@iamleeg.com> skribis:

I tried in a VM to provide a disk with a FAT16 partition to reproduce

this bug. I could hit this particular error when choosing the “manual”

partitioning method and then selecting the FAT16 partition. However I

could not reproduce the bug when choosing the “guided” methods.

I think we don’t need the installer to be able to create FAT16

partitions; we merely need it to recognize and gracefully handle them

when they exist (which I think is quite unusual: the EFI System

Partition seems to be FAT32 usually, no?).

Anyway I think this is fixed by commit

628d09ae53047ea666f4f84ae5e5be911647fe8c, which Danny just pushed. :-)

Thanks,

Ludo’.

Yeah, but I fixed it by adding the file system type--which is kinda a sledgehammer

approach. We really don't want to include every file system known to man in the

installer. In this case we had fat32 already--which uses the same package as

fat16 anyway.

Maybe it would be better long term to make it impossible to edit those

entries that we don't know how to handle, while still not crashing/restarting

the installer.

Right now, gnu/installer/newt/partition.scm:604 (listbox-action) will fail

because partition->user-partition fails. The former should probably be

modified such that it just shows an error message dialog (without

stacktrace) and lets the user continue on his way after he dismisses it.

Unfortunately, I don't know enough about newt to do that myself.

The naming throws me off, too. What's a user-partition compared to a

partition? *scratches head*

partition-filesystem-user-type does some manual mapping of parted

file system names to "user" names (that's what actually fails).

Sounds like a lot of extra complexity to me. Is it worth it?

Or just not let the user select "Format this partition" if we don't know how to

format it.

Also not let the user specify a mount point if we don't know how to mount it.

Hi,

Thanks Danny, I appreciate you pushing a fix. I will find out how to make an updated installer and try again :).

Just to clear up, though, I was going through the guided partitioning, so didn’t either select to format the partition or try to mount it. It was already there, I have no opinion on it except that if it disappears my EFI probably breaks :). But this means that I’m not sure the fixes you described above would have helped in my situation. Also I would expect to install EFI-based GRUB so if I want to do that from the GUIX installer (and not, say, boot some other GNU/Linux installer to install GRUB), I would need to mount the FAT16 partition, or I [or the guided partitioning system] would need to know to recreate it as FAT32.

I understand that there are firmwares out there (I don’t know about mine) that won’t recognise small FAT partitions unless they are FAT16. On the other hand, the UEFI specification seems to expect the partition to be FAT32. So this is a case of different things working in theory and in practice. Also in practice: mkfs.fat will make small filesystems FAT16 by default, and some distros (notably, Fedora, which is what my target machine currently runs) don’t tell it otherwise. So even if the EFI partition is always FAT32 in theory, there will be practical cases where it’s FAT16.

Thanks again,

Graham.

Root cause analysis:

(user-partitions (append

(auto-partition disk #:scheme scheme)

(create-special-user-partitions

(disk-partitions disk))))) <---

(define (create-special-user-partitions partitions)

"Return a list with a <user-partition> record describing the ESP partition

found in PARTITIONS, if any."

(filter-map (lambda (partition)

(and (esp-partition? partition)

(partition->user-partition partition))) <----

partitions))

I think create-special-user-partitions and the form above is automatically

trying to keep existing UEFI ESP partitions of the user.

And partition->user-partition failed for (existing) fat16 partitions.

So the fix of adding fat16 was definitely the right one for that specific

file system type.

It should be fine now.

Hi Graham,

On Tue, 14 May 2019 18:37:38 +0100

Graham Lee <graham@iamleeg.com> wrote:

Thanks, good to know. So the bug was much worse and would basically have

prevented anyone that has this kind of EFI from using our guided partitioning.

It would have.

(I still think that it would be better not to do the silly

"parted file system type -> user file system type" dance in the first place

but maybe there is a good reason for it. In any case, it should work now)

For the record (and for future problems like that), I went and implemented

everything we need for fat16:

When actually that would have been enough:

Yes.