[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#823881: dosfstools: mmd fails right after mkfs.msdos (sectors/tracks mismatch)

On Tue, May 10, 2016 at 01:53:24AM +0200, Cyril Brulebois wrote:
> The version bump from 3.0.28-2 to 4.0-1 led to a new FTBFS on all EFI
> archs for debian-installer (amd64, arm64, i386), where the following
> operations are happening:
> | + mkfs.msdos -C ./tmp/netboot-gtk/grub_efi/efi.img 416
> | mkfs.fat 4.0 (2016-05-06)
> | + mmd -i ./tmp/netboot-gtk/grub_efi/efi.img ::efi
> | Total number of sectors (832) not a multiple of sectors per track (63)!
> | Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
> | + cleanup
> | + [ -z efi-image.7vXUPq ]
> | + rm -f efi-image.7vXUPq
> | + [ -z efi-image.u4utfz ]
> | + rm -rf efi-image.u4utfz
> | config/x86.cfg:38: recipe for target 'x86_grub_efi' failed
> This can be reproduced with:
> | make -C build build_netboot-gtk USE_UDEBS_FROM=sid
> after having added "set -x" at the top of build/util/efi-image in
> src:debian-installer.
> After a quick look, it seems the d-i build system is only passing a
> number of blocks to mkfs.{msdos,fat}, without specifying strange
> parameters for sectors or trackers, so it looks to me that mkfs's
> or mmd's behaviour is buggy.
> Incidently, 832 isn't a multiple of 63, but is a multiple of 64. Could
> there be some off-by-one somewhere?

Not an off-by-one, these are constants. Unless the media parameters can
be established (by HDIO_GETGEO or FDGETPRM ioctls) a set of defaults is
used. In 4.0 (I am also upstream) I massively simplified it to basically
use the common dummy 255/63 values unless the size matches one of the
well-known floppy sizes:


Previously, it would set values based on well-known floppy sizes or use
64/32 as default if the target was either a file or the device major
number truncated to 8 bits matched 2 (floppy) or 7 (loop device) and
otherwise assume it's a hard disk device so use 255/63 if HDIO_GETGEO


Since 416 blocks is a rather odd value, the default is used and that has
changed. I think mtools is overzealous in checking those values and
refusing to work. Still, it probably makes sense to use 64/32 as the
default for smaller filesystem sizes (up to 512 MB possibly) and I'll
prepare a version that implements this.


Reply to: