Your message dated Thu, 20 Aug 2015 16:11:35 +0200
with message-id <20150820141135.GA6531@haze>
and subject line Re: Bug#795500: dosfstools: mkfs.vfat -F32 don't work correctly
has caused the Debian Bug report #795500,
regarding dosfstools: mkfs.vfat -F32 don't work correctly
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
795500: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795500
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dosfstools
Version: 3.0.27-1
Severity: important

Dear Maintainer,

I can't create a FAT32 partition with this command dosfstools: mkfs.vfat -F32.

For example, you can try this :

$dd if=/dev/zero of=OSMC_TGT.img bs=1M count=256
256+0 enregistrements lus
256+0 enregistrements écrits
268435456 octets (268 MB) copiés, 1,05195 s, 255 MB/s
$parted -s OSMC_TGT.img mklabel msdos
$parted -s OSMC_TGT.img mkpart primary fat32 1M 256M
$kpartx -a OSMC_TGT.img
mkfs.fat 3.0.27 (2014-11-12)
unable to get drive geometry, using default 255/63
$mount /dev/mapper/loop0p1 /mnt
$touch /mnt/file.txt
$umount /mnt
$sync
$kpartx -d OSMC_TGT.img
loop deleted : /dev/loop0

Before, I don't have this message : unable to get drive geometry, using default
255/63

Can you help me please ?

Phil



-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dosfstools depends on:
ii  libc6  2.19-18

dosfstools recommends no packages.

dosfstools suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message ---
On Wed, Aug 19, 2015 at 11:57:01PM +0200, Plançon wrote:
>       Ok, i have created a script build.sh :</font><br>
>     <br>
>     $dd if=/dev/zero of=OSMC_TGT.img bs=1M count=256<br>
>     $parted -s OSMC_TGT.img mklabel msdos<br>
>     $parted -s OSMC_TGT.img mkpart primary fat32 1M 256M<br>
>     $kpartx -a OSMC_TGT.img<br>
>     $mkfs.vfat -F32 /dev/mapper/loop0p1<br>
>     $mount /dev/mapper/loop0p1 /mnt<br>
>     $touch /mnt/file.txt<br>
>     $umount /mnt<br>
>     $sync<br>
>     $kpartx -d OSMC_TGT.img<br>
>     <br>
>     If I execute this script on my laptop (sudo build.sh), I have this
>     output :<br>
>     <br>
>     256+0 enregistrements lus<br>
>     256+0 enregistrements écrits<br>
>     268435456 octets (268 MB) copiés, 0,707003 s, 380 MB/s<br>
>     mkfs.fat 3.0.27 (2014-11-12)<br>
>     /dev/mapper/loop0p1: No such file or directory<br>
>     mount: le périphérique spécial /dev/mapper/loop0p1 n'existe pas<br>
>     umount: /mnt : non monté<br>
>     loop deleted : /dev/loop1<br>

There's the problem. As the last line shows, kpartx used loop1, so you
should have used loop1p1 instead. Not a bug in either mkfs.fat or mount,
they both reported correctly that loop0p1 did not exist and of course
umount can't unmount a filesystem that wasn't mounted in the first
place.

I don't know why using a sleep appears to work, but you really have to
use the actual loop device and not simply loop0p1. Have a look at the -v
and -s options of kpartx.


Andreas

--- End Message ---

Reply via email to