Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jean-christophe-manciot opened this issue Mar 12, 2020 · 1 comment

Comments

@jean-christophe-manciot

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
Copy link
Author

jean-christophe-manciot commented Mar 12, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant