mkfs.vfat refuses to work without -I on loop device

[oxygene]

Hi,

I've encountered a strange issue when trying to build a live-build hdd image for the upcoming Debian Stretch release. As one of the last steps, live-build attempts to generate an image file with a FAT partition to boot from. At the beginning we have an empty "binary.img" file. Then, "parted" is used to create a partition table at offset 0. Then, the image file is mounted again using losetup and the -o parameter to specify an offset of one sector. Then, mkfs.vfat is called on the /dev/loop0 device in order to create a new FAT filesystem. However, mkfs.vfat refuses to do this without the -I parameter (error message: Partitions or virtual mappings on device '/dev/loop0', not making filesystem (use -I to override)).

A hexdump on /dev/loop0 reveals that is only contains zeros. However, mkfs.vfat seems to take a glimpse behind the curtains and sees the the original file has a partition table at offset 0!

You can find the relevant live-build code here:
https://github.com/timrchavez/live-build/blob/master/scripts/build/binary_hdd#L202

The error message in mkfs.vfat is generated here:
https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c#L1670

[andreasbombe]

mkfs uses the information provided by udev which you can also see by running lsblk. I can't see how the live-build code would cause the loop device to have children. You might have some background automation accessing the devices when it is set up.

I suggest you check this by inserting lsblk:

    case "${LB_BUILD_WITH_CHROOT}" in
        true)
            Chroot chroot "lsblk ${FREELO}"
            Chroot chroot "mkfs.${MKFS} ${MKFS_OPTIONS} ${FREELO}"
            ;;
    
        false)
            lsblk ${FREELO}
            mkfs.${MKFS} ${MKFS_OPTIONS} ${FREELO}
            ;;
    esac

[oxygene]

That's interesting.

Output of "losetup":

NAME       SIZELIMIT  OFFSET AUTOCLEAR RO BACK-FILE                                                                        DIO
/dev/loop0         0 1048576         0  0 /home/<path_to>/build/chroot/binary.img   0

Output of "lsblk":

NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0       7:0    0  325M  0 loop /home/<path_to>/build/chroot/binary.tmp
└─loop0p1 259:0    0  325M  0 loop 
sda         8:0    0   60G  0 disk 
├─sda1      8:1    0 55.9G  0 part /
└─sda2      8:2    0  4.1G  0 part [SWAP]

And that's after I already forced mkfs.vfat to create the fat fs on /dev/loop0. I'm not familiar with udev. Does it mean that this is possibly a bug in udev? Due to the offset in the bind mount, the partition table should be not visible from within /dev/loop0.

[andreasbombe]

Coming back to this, it seems that mkfs is working as intended and refraining from creating a filesystem on a device that has mappings over it. Whether that is a bug in udev or (much more likely, IMO) some automatism on your system creating those undesired mappings, it appears it isn't the fault of mkfs.

Therefore, I'll close this issue for now.

[oxygene]

Agreed, thanks for pointing out how mkfs makes its decision.

[monakov-y]

It will be very late answer, but this can be fixed by calling partprobe $FREELO after losetup. Kernel somehow retains information about previously created partitions on a loop device with the same name. Even if file was detached by losetup.