fdupoux/fsarchiver

'archive-id in header does not match' on FAT32 file systems

jean-christophe-manciot opened this issue · 1 comments

jean-christophe-manciot commented

Ubuntu 20.04
fsarchiver 30c9e23

FAT32 file-system archived with fsarchiver 0.8.6-git (20191230):

# fsarchiver -V
fsarchiver 0.8.6-git (20191230)
# fsarchiver archinfo Efi-FAT32.fsa
====================== archive information ======================
Archive type: 			filesystems
Filesystems count: 		1
Archive id: 			5e6f60dc
Archive file format: 		FsArCh_002
Archive created with: 		0.8.6-git
archreader.c#329,archreader_read_header(): archive-id in header does not match: archid=[5e6f6a3e], expected=[5e6f60dc]
Archive creation date: 		2020-03-11_21-57-47
Archive label: 			<none>
Minimum fsarchiver version:	0.6.4.0
Compression level: 		11 (zstd level 11)
Encryption algorithm: 		none

===================== filesystem information ====================
Filesystem id in archive: 	0
Filesystem format: 		vfat
Filesystem label: 		FAT32 
Filesystem uuid: 		7916B3CB
Original device: 		/dev/sdc1
Original filesystem size: 	510.98 MB (535801856 bytes)
Space used in filesystem: 	14.15 MB (14839808 bytes)

No such issue with Ext4 file-system archived with fsarchiver 0.8.6-git (20191230):

# fsarchiver -V
fsarchiver 0.8.6-git (20191230)
# fsarchiver archinfo Ext4.fsa
====================== archive information ======================
Archive type: 			filesystems
Filesystems count: 		1
Archive id: 			5e6ed95c
Archive file format: 		FsArCh_002
Archive created with: 		0.8.6-git
Archive creation date: 		2020-03-11_21-57-48
Archive label: 			<none>
Minimum fsarchiver version:	0.6.4.0
Compression level: 		11 (zstd level 11)
Encryption algorithm: 		none

===================== filesystem information ====================
Filesystem id in archive: 	0
Filesystem format: 		ext4
Filesystem label: 		Ext4
Filesystem uuid: 		30c45b81-890d-47ac-85c1-971537b7bae5
Original device: 		/dev/sdc3
Original filesystem size: 	97.93 GB (105152544768 bytes)
Space used in filesystem: 	34.60 GB (37155958784 bytes)

No such issue with FAT32 file-system archived with fsarchiver 0.8.6-git --1 year ago--:

# fsarchiver archinfo Efi-FAT32-old.fsa
====================== archive information ======================
Archive type: 			filesystems
Filesystems count: 		1
Archive id: 			5c9eabdc
Archive file format: 		FsArCh_002
Archive created with: 		0.8.6-git
Archive creation date: 		2019-03-21_17-28-28
Archive label: 			<none>
Minimum fsarchiver version:	0.6.4.0
Compression level: 		21 (zstd level 21)
Encryption algorithm: 		none

===================== filesystem information ====================
Filesystem id in archive: 	0
Filesystem format: 		vfat
Filesystem label: 		FAT32
Filesystem uuid: 		7916B3CB
Original device: 		/dev/sdb1
Original filesystem size: 	510.98 MB (535805952 bytes)
Space used in filesystem: 	7.74 MB (8114176 bytes)

The archives are created with the command:

fsarchiver -j $cpu_threads -v -o -A -Z 11 savefs <filename>.fsa /dev/<sdxn>

I'm positive no archive can be corrupted as they are checked regularly.

This issue is most probably linked to this unsolved one.

Something have probably been changed in the code between 2019-03-21 and 2019-12-30 in the way the FAT32 file-systems are handled.

jean-christophe-manciot commented

I believe I may have found another potential explanation: some archives are made on Debian with fsarchiver built in that specific environment (bullseye - same fsarchiver commit);

  • if I try archinfo with fsarchiver built on Ubuntu, I get the error.
  • If I try archinfo with fsarchiver built on Debian, I get no error.

Does the archive-id depend on some fsarchiver binary specific UUID or equivalent random number?
In other words, is it compulsory to extract an archive with the same fsarchiver that was used to make it?