1

Topic: GParted failure copying FAT32 partition

My attempt to copy a FAT32 partition failed. I use the partition to share data between Windows and Linux on a multi-boot computer. Here is the output:

=====================================================

GParted 0.14.1 --enable-libparted-dmraid

Libparted 3.1
Copy /dev/sdb14 to /dev/sdd (start at 1.19 TiB) 00:12:23 ( ERROR )

calibrate /dev/sdb14 00:00:01 ( SUCCESS )

path: /dev/sdb14
start: 947,979,648
end: 1,055,647,214
size: 107,667,567 (51.34 GiB)
check file system on /dev/sdb14 for errors and (if possible) fix them 00:00:37 ( SUCCESS )

dosfsck -a -w -v /dev/sdb14

dosfsck 3.0.14 (23 Jan 2023)
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
68:99/8f, 69:41/5b, 70:56/73
Not automatically fixing this.
Boot sector contents:
System ID ""
Media byte 0xf8 (hard disk)
512 bytes per logical sector
32768 bytes per cluster
33 reserved sectors
First FAT starts at byte 16896 (sector 33)
2 FATs, 32 bit entries
6742016 bytes per FAT (= 13168 sectors)
Root directory start at cluster 322 (arbitrary size)
Data area starts at byte 13500928 (sector 26369)
1681893 data clusters (55112269824 bytes)
63 sectors/track, 255 heads
63 hidden sectors
107667567 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdb14: 9079 files, 93331/1681893 clusters
create empty partition 00:00:02 ( SUCCESS )

path: /dev/sdd6
start: 2,554,079,232
end: 2,661,748,735
size: 107,669,504 (51.34 GiB)
set partition type on /dev/sdd6 00:00:00 ( SUCCESS )

new partition type: fat32
copy file system of /dev/sdb14 to /dev/sdd6 00:11:04 ( SUCCESS )

using internal algorithm
copy 51.34 GiB
finding optimal block size

copy 16.00 MiB using a block size of 1.00 MiB 00:00:02 ( SUCCESS )

16.00 MiB of 16.00 MiB copied
1.50937 seconds
copy 16.00 MiB using a block size of 2.00 MiB 00:00:00 ( SUCCESS )

16.00 MiB of 16.00 MiB copied
0.939042 seconds
copy 16.00 MiB using a block size of 4.00 MiB 00:00:01 ( SUCCESS )

16.00 MiB of 16.00 MiB copied
0.875008 seconds
copy 16.00 MiB using a block size of 8.00 MiB 00:00:01 ( SUCCESS )

16.00 MiB of 16.00 MiB copied
0.574895 seconds
copy 16.00 MiB using a block size of 16.00 MiB 00:00:00 ( SUCCESS )

16.00 MiB of 16.00 MiB copied
0.398392 seconds
optimal block size is 16.00 MiB
copy 51.26 GiB using a block size of 16.00 MiB 00:11:00 ( SUCCESS )

51.26 GiB of 51.26 GiB copied
51.34 GiB (55,125,794,304 B) copied
check file system on /dev/sdd6 for errors and (if possible) fix them 00:00:39 ( SUCCESS )

dosfsck -a -w -v /dev/sdd6

dosfsck 3.0.14 (23 Jan 2023)
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
68:99/8f, 69:41/5b, 70:56/73
Not automatically fixing this.
Boot sector contents:
System ID ""
Media byte 0xf8 (hard disk)
512 bytes per logical sector
32768 bytes per cluster
33 reserved sectors
First FAT starts at byte 16896 (sector 33)
2 FATs, 32 bit entries
6742016 bytes per FAT (= 13168 sectors)
Root directory start at cluster 322 (arbitrary size)
Data area starts at byte 13500928 (sector 26369)
1681893 data clusters (55112269824 bytes)
63 sectors/track, 255 heads
63 hidden sectors
107667567 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdd6: 9079 files, 93331/1681893 clusters
grow file system to fill the partition 00:00:00 ( ERROR )

using libparted
libparted messages ( INFO )

Could not detect file system.

=========================================

Any ideas of why GParted fails to copy the partition would be appreciated.

2

Re: GParted failure copying FAT32 partition

From the gparted_detail.htm log file there appear to be some differences between the boot sector and it's backup.

I suggest that you run "chkdsk /f /r" on the drive letter from Windows and then reboot twice to permit Windows to perform file system consistency checks.

After that you might retry coping the partition.

3

Re: GParted failure copying FAT32 partition

gedakc wrote:

From the gparted_detail.htm log file there appear to be some differences between the boot sector and it's backup.

I suggest that you run "chkdsk /f /r" on the drive letter from Windows and then reboot twice to permit Windows to perform file system consistency checks.

After that you might retry coping the partition.

I have already run chkdsk from the GUI ( Windows 7 ), telling Windows to fix and repair, ie. both options checked. It found no errors. Should a manual "chkdsk /f /r" be doing anything differently ?

What is the "boot sector" and its "backup" ? The partition is not marked as bootable, so I do not see why a "boot sector" comes into play, but I hope you can explain it to me from GParted's standpoint.

4

Re: GParted failure copying FAT32 partition

eldiener wrote:

I have already run chkdsk from the GUI ( Windows 7 ), telling Windows to fix and repair, ie. both options checked. It found no errors. Should a manual "chkdsk /f /r" be doing anything differently ?

Some fixes cannot be performed when the file system is mounted.  That is the reason for the manual "chkdsk /f /r" which should schedule the check for the next computer restart.

eldiener wrote:

What is the "boot sector" and its "backup" ? The partition is not marked as bootable, so I do not see why a "boot sector" comes into play, but I hope you can explain it to me from GParted's standpoint.

Each file system contains important meta data at the start of the partition.  The initial data is often referred to as the "Partition Boot Record" or PBR.  Some file systems also store a backup of this data later in the partition.  The PBR does not necessarily mean the file system has to be used to boot the computer.

5

Re: GParted failure copying FAT32 partition

gedakc wrote:
eldiener wrote:

I have already run chkdsk from the GUI ( Windows 7 ), telling Windows to fix and repair, ie. both options checked. It found no errors. Should a manual "chkdsk /f /r" be doing anything differently ?

Some fixes cannot be performed when the file system is mounted.  That is the reason for the manual "chkdsk /f /r" which should schedule the check for the next computer restart.

eldiener wrote:

What is the "boot sector" and its "backup" ? The partition is not marked as bootable, so I do not see why a "boot sector" comes into play, but I hope you can explain it to me from GParted's standpoint.

Each file system contains important meta data at the start of the partition.  The initial data is often referred to as the "Partition Boot Record" or PBR.  Some file systems also store a backup of this data later in the partition.  The PBR does not necessarily mean the file system has to be used to boot the computer.

I had unmounted the partition under Windows ( by unassigning any drive letter or mount point ) before running the chkdsk from the UI.

Is there a way to fix the backup PBR for this partition using dosfsck or some other tool, by copying the PBR to its backup location  ?

6

Re: GParted failure copying FAT32 partition

eldiener wrote:

Is there a way to fix the backup PBR for this partition using dosfsck or some other tool, by copying the PBR to its backup location  ?

Unfortunately dosfsck does not appear to be able to fix this problem, only detect it.

The dosfsck output provides enough details to identify where the discrepancy is, so if you are handy with a hex editor, you might consider directly fixing the problem.

7

Re: GParted failure copying FAT32 partition

gedakc wrote:
eldiener wrote:

Is there a way to fix the backup PBR for this partition using dosfsck or some other tool, by copying the PBR to its backup location  ?

Unfortunately dosfsck does not appear to be able to fix this problem, only detect it.

The dosfsck output provides enough details to identify where the discrepancy is, so if you are handy with a hex editor, you might consider directly fixing the problem.

I know hex, since I am a programmer, but I do not know what tool I can use and what offset must be specified in order to resolve the problem.

8

Re: GParted failure copying FAT32 partition

hexedit is a good tool to use in GNU/Linux.  You'll need to research the file system specifics to learn the correct locations to update.

9 (edited by eldiener 2013-05-03 18:55:29)

Re: GParted failure copying FAT32 partition

gedakc wrote:

hexedit is a good tool to use in GNU/Linux.  You'll need to research the file system specifics to learn the correct locations to update.

I ran this dosfsck ( v 3.0.14 ) command on the FAT32 partition:

====================

dosfsck -v -V -r /dev/sdb4

====================

It found the differences in the PBR between the original and the backup and asked me what I wanted to do. I chose the first option, which copies the original to the backup. It successfully completed this operation so that when I ran the command again it no longer found those differences.

I then ran gparted again and chose to check the partition. The output of this is:

=============================================================

GParted 0.14.1 --enable-libparted-dmraid

Libparted 3.1
Check and repair file system (fat32) on /dev/sdb14  00:00:39    ( ERROR )
        
calibrate /dev/sdb14  00:00:01    ( SUCCESS )
        
path: /dev/sdb14
start: 947,979,648
end: 1,055,647,214
size: 107,667,567 (51.34 GiB)
check file system on /dev/sdb14 for errors and (if possible) fix them  00:00:37    ( SUCCESS )
        
dosfsck -a -w -v /dev/sdb14
        
dosfsck 3.0.14 (23 Jan 2023)
dosfsck 3.0.14, 23 Jan 2023, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID ""
Media byte 0xf8 (hard disk)
512 bytes per logical sector
32768 bytes per cluster
33 reserved sectors
First FAT starts at byte 16896 (sector 33)
2 FATs, 32 bit entries
6742016 bytes per FAT (= 13168 sectors)
Root directory start at cluster 322 (arbitrary size)
Data area starts at byte 13500928 (sector 26369)
1681893 data clusters (55112269824 bytes)
63 sectors/track, 255 heads
63 hidden sectors
107667567 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdb14: 8809 files, 93197/1681893 clusters
grow file system to fill the partition  00:00:01    ( ERROR )
        
using libparted
libparted messages    ( INFO )
        
Could not detect file system.

=================================================

I believe the issue with the boot sector and its backup has been resolved but gparted still issues an error when running a Check operation. What is the reason for this error ?

10

Re: GParted failure copying FAT32 partition

Would you be able to provide the output from the following two commands?

sudo fdisk -l -u

where one of the options is a lower case "L" and not the number one.

sudo parted /path-to-your-device unit s print

where /path-to-your-device is something like /dev/sda.

11

Re: GParted failure copying FAT32 partition

gedakc wrote:

Would you be able to provide the output from the following two commands?

sudo fdisk -l -u

where one of the options is a lower case "L" and not the number one.

sudo parted /path-to-your-device unit s print

where /path-to-your-device is something like /dev/sda.

Here is the output of the first command:

fdisk -l -u

Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000001

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63   469274714   234637326    7  HPFS/NTFS/exFAT
/dev/sda2   *   469274715  1159025489   344875387+   7  HPFS/NTFS/exFAT
/dev/sda3      1159028673  1384540159   112755743+   f  W95 Ext'd (LBA)
/dev/sda4      3898642432  3907028991     4193280   df  BootIt
/dev/sda5      1159028736  1161134079     1052672   83  Linux
/dev/sda6      1161146133  1163202389     1028128+  83  Linux
/dev/sda7      1163202453  1165306904     1052226   83  Linux
/dev/sda8      1165306968  1167411419     1052226   83  Linux
/dev/sda9      1167411483  1169499869     1044193+  83  Linux
/dev/sda10     1169502208  1171550207     1024000   83  Linux
/dev/sda11     1171552256  1384540159   106493952   bf  Solaris

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x1aeffb21

   Device Boot      Start         End      Blocks   Id  System

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xd5f572fe

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  1928097791   964047872    f  W95 Ext'd (LBA)
/dev/sdb2   *  3281297408  3907029167   312865880    7  HPFS/NTFS/exFAT
/dev/sdb5            4096   104859647    52427776   83  Linux
/dev/sdb6       104992768   209846271    52426752   83  Linux
/dev/sdb7       209848320   314703871    52427776   83  Linux
/dev/sdb8       314705920   419561471    52427776   83  Linux
/dev/sdb9       419563520   524417023    52426752   83  Linux
/dev/sdb10      524419072   626817023    51198976   83  Linux
/dev/sdb11      626819072   729233383    51207156   83  Linux
/dev/sdb12      729235456   831633407    51198976   83  Linux
/dev/sdb13      831635456   947978239    58171392   83  Linux
/dev/sdb14      947979648  1055647214    53833783+   b  W95 FAT32
/dev/sdb15     1055649792  1088417791    16384000   82  Linux swap
/dev/sdb16     1088419840  1190899711    51239936   83  Linux
/dev/sdb17     1190901760  1295710207    52404224   83  Linux
/dev/sdb18     1295712256  1398112255    51200000   83  Linux
/dev/sdb19     1398114304  1498017791    49951744   83  Linux

Here is the output of the second command:

parted /dev/sdb14 unit s print
Error: /dev/sdb14: unrecognised disk label
Model: Unknown (unknown)                                                  
Disk /dev/sdb14: 107667567s
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags: 

I hope this helps.

12

Re: GParted failure copying FAT32 partition

eldiener wrote:

Here is the output of the second command:

parted /dev/sdb14 unit s print
Error: /dev/sdb14: unrecognised disk label
Model: Unknown (unknown)                                                  
Disk /dev/sdb14: 107667567s
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags: 

Please provide the output for the device sdb, not the partition sdb14.

For example,

sudo parted /dev/sdb unit s print

13

Re: GParted failure copying FAT32 partition

gedakc wrote:

parted /dev/sdb unit s print

The output is:

parted /dev/sdb unit s print
Model: ATA WDC WD20EARX-00P (scsi)
Disk /dev/sdb: 3907029168s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start        End          Size         Type      File system     Flags
 1      2048s        1928097791s  1928095744s  extended                  lba
 5      4096s        104859647s   104855552s   logical   ext4
 6      104992768s   209846271s   104853504s   logical   ext3
 7      209848320s   314703871s   104855552s   logical   ext4
 8      314705920s   419561471s   104855552s   logical   ext3
 9      419563520s   524417023s   104853504s   logical   ext4
10      524419072s   626817023s   102397952s   logical   ext3
11      626819072s   729233383s   102414312s   logical   ext4
12      729235456s   831633407s   102397952s   logical   ext3
13      831635456s   947978239s   116342784s   logical   ext3
14      947979648s   1055647214s  107667567s   logical
15      1055649792s  1088417791s  32768000s    logical   linux-swap(v1)
16      1088419840s  1190899711s  102479872s   logical   ext4
17      1190901760s  1295710207s  104808448s   logical   ext4
18      1295712256s  1398112255s  102400000s   logical   ext4
19      1398114304s  1498017791s  99903488s    logical   ext4
 2      3281297408s  3907029167s  625731760s   primary   ntfs            boot, hidden

It looks like parted does not recognize the type of the fat32 partition ( sdb14 ), but when I start gparted it shows that the filesystem is fat32.

14

Re: GParted failure copying FAT32 partition

eldiener wrote:

It looks like parted does not recognize the type of the fat32 partition ( sdb14 ), but when I start gparted it shows that the filesystem is fat32.

That does indeed seem to be the problem.  GParted uses libparted to detect file systems, but if libparted fails to detect the FS, then GParted will use blkid.  In this case it appears that libparted does not recognize the FS, and that blkid does.

Unfortunately since libparted is the library that performs the resize of fat32 file systems, it is critical that it also recognise the FS.

I do not know what might be the reason parted/libparted does not recognize the file system.

15

Re: GParted failure copying FAT32 partition

gedakc wrote:
eldiener wrote:

It looks like parted does not recognize the type of the fat32 partition ( sdb14 ), but when I start gparted it shows that the filesystem is fat32.

That does indeed seem to be the problem.  GParted uses libparted to detect file systems, but if libparted fails to detect the FS, then GParted will use blkid.  In this case it appears that libparted does not recognize the FS, and that blkid does.

Unfortunately since libparted is the library that performs the resize of fat32 file systems, it is critical that it also recognise the FS.

I do not know what might be the reason parted/libparted does not recognize the file system.

Thanks for your efforts. I will bring this issue up with the people who wrote/support 'parted/libparted'.

16

Re: GParted failure copying FAT32 partition

I see that there are 17 partitions on the /dev/sdb hard drive.
I knew that the linux scsi driver supports up to 15 or 16 partitions on a hard drive, including the extended partition and the drive it self (the old ATA driver supports more partitions, but newer distributions use scsi instead, as I remember from older GParted days smile ).
Is this still valid? Is it a matter of parted or fdisk version?

*** It is highly recommended to backup any important files before doing resize/move operations. ***

17

Re: GParted failure copying FAT32 partition

class413 wrote:

I see that there are 17 partitions on the /dev/sdb hard drive.
I knew that the linux scsi driver supports up to 15 or 16 partitions on a hard drive, including the extended partition and the drive it self (the old ATA driver supports more partitions, but newer distributions use scsi instead, as I remember from older GParted days smile ).
Is this still valid? Is it a matter of parted or fdisk version?

If 'parted' is limited to 16 partitions, then I am using the wrong tool. I thought the 16 partition thing was finished years ago. I do know that none of my Linux distros are bothered by more than 16 partitions and I recall reading an article where modern Linux will tolerate over 200 partitions on a single MBR drive.

18

Re: GParted failure copying FAT32 partition

The limitation of 16 partitions in an MSDOS partition table was fixed in parted 3.1.  Some parted packages also contain a patch to remove this limitation, such as Ubuntu.

The GParted Live image is based on Debian SID, which does not yet contain the patch.

19

Re: GParted failure copying FAT32 partition

gedakc wrote:

The limitation of 16 partitions in an MSDOS partition table was fixed in parted 3.1.  Some parted packages also contain a patch to remove this limitation, such as Ubuntu.

The GParted Live image is based on Debian SID, which does not yet contain the patch.

I guess that explains the error I am seeing. I am a relative Linux newbie, but I admit that I am amazed that 'parted' had this limitation still in it up until the latest release.

20

Re: GParted failure copying FAT32 partition

eldiener wrote:

I guess that explains the error I am seeing.

Since the problem occurs with sdb14, this is not impacted by the limit of 16 partitions on an MSDOS partition table.  The failure to recognize the file system on sdb14 is a different problem.

Perhaps you might try running "chkdsk /f /r" on the sdb14 partition (drive letter in Windows), or defragmenting the partition?