Fix vFAT partition when size is greater than 2Go

[Resolu]

Issue I use a live USB created with debootstick with a FAT partition as larger as possible (greater than 2Go). To handle this, I used this layout:

# gpt or dos partition table
gpt

# ordered list of partitions (with mountpoint, type, size)
partition   /boot/efi       efi     auto
partition   none            bios    auto
partition   none            lvm     1G
partition   /media/sdtools  fat     max

# lvm volumes (with mountpoint, type, size)
lvm_volume  /          ext4    max

# lvm volume group name
lvm_vg_name auto

The image is partitioned like this:

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: C967EE7F-8E99-4481-85A9-CFD9D404E005

Device      Start     End        Sectors     Size    Type
img.dd1    2048    14335     12288        6M      EFI System
img.dd2   14336   16383      2048         1M      BIOS boot
img.dd3   16384   2113535  2097152   1G      Linux LVM
img.dd4   2113536 2121694  8159        4M     Microsoft basic data

Once the image is wrote to the USB key, I can see the last partition has a size of 4Mo with a FAT16 file system. But after resizing, this partition still is in FAT16 but has a size of 2.8Go. FAT16 can't handle partition with a size greater than 2Go. So no file can be written on this partition unless we recreate the file system with FAT32.

Proposal: In case the last partition is FAT and it is large enough to handle FAT32, change it to FAT32.

[eduble]

Hello, thanks for reporting. Actually I did not try to resize vfat partitions with debootstick, I only tried ext4. And looking at the current code in master, the filesystem is actually not resized (the partition is, but the filesystem is not).

I guess you made some effort to setup your proposal, but there are a few things you did not know:

• debootstick tries to generate an image with the system already finalized (as much as possible). So if we must set a FAT32 filesystem, it is better to do it in the image generation procedure (rather than in the init scripts). This is because we have less control on init scripts, since they are running on the target system which we do not know so much: there may be all sorts of subtleties like unavailable command options, etc.
• If you provide files in [chroot_dir]/media/sdtools before you ever call debootstick, you should find them there when you boot the OS. So we cannot just reformat the partition.

So I guess we should:

• Add -F 32 when the filesystem is written in the image generation procedure
• handle vfat partition resizing in init scripts (this could probably be done with tool fatresize)

I can probably find a little time to work on that by the end of next week.

[eduble]

Hi again, Apparently, I cannot create small FAT32 partitions (smaller than 512M) at first. If I specify "-F 32" in this case, a warning is generated and FAT16 is still used. However, it seems that fatresize can automatically convert to FAT32 when needed, so we can work with this.

[eduble]

Hi, I just pushed something, see commit a8b7a9387df159031d725044c122c0c6152ea9f0. Basically, if the last partition or an LVM volume has a FAT filesystem, then I allocate 256M to it in the image. Because fatresize cannot resize smaller volumes. That makes the image file a little bigger. Note that you can use dd option conv=sparse when copying the image to your device (the image generated is a sparse file, so this 256M partition is more or less a big hole in the image file).

[Resolu]

Hello, Thanks to handle this issue. I understand why we must do some operations during the image creation rather than in init scripts.

I try your change, it work well, I have my FAT32 partition after the first boot, thanks !

There is a little issue about the GPT partition table, I get this message when I opened the device with parted (or gparted):

Warning: Not all of the space available to /dev/sdf appears to be used, you can fix the GPT to use all of the space (an extra 2014 blocks) or continue with the current setting?

This is due to the difference between the image size and the USB size. May be it can be fix with (I only try the second one):

sgdisk ${device} --move-second-header

or:

printf "fix\n" | parted ---pretend-input-tty ${device} print

at the end of resize_last_partition function.

I can open an new issue if you prefer.

[eduble]

Hi again, The sgdisk -e trick is already implemented: https://github.com/drakkar-lig/debootstick/commit/9fed384a8cb68f8b15f161d476f6d16308bc480d Of course this can only be done on first boot, since we do not know the size of the device when we create the image. Did you notice that after you booted once?

[Resolu]

Yes I notice that after the first boot, I tried it with two USB key. Parted still have the GPT error message. Once I fixed it with parted, the message does not appear again.

[eduble]

OK, so please open a new issue for that. Thanks