François Dupoux answerBoot Loaders, partition labels and Fstab support?
They are the major things that block fsarchiver being used instead of partition image. The means to restore a Linux onto any partition type from back up would be good. Also nothing I have read so far says about a meta data block. Something to tell person before extracting what kind of filesystem information has been saved inside fsarchiver and if the current OS has all the features required to extract completely or not.
The tool is so close to perfect its not funny.
Major advantage of fsarchiver over partition image due to the way fsarchiver works it defrags the partition. Major disadvantage compared to parition image that its missing information about the partition itself.
Question I have are you open to have extra support added so fsachiver can be used as a complete OS packer and restore on another machine? Or will it have to be a independant project.
Ok opps missed seeing the uuid and block sizes.fsarchiver has to be used by someone who knows what he is doing.
fsarchiver is supposed to do one thing (do one thing but to it well)
which is archiving and extracting a filesystem with no data or
attribute losses. So it is supposed to save all the files, its
and also the filesystem attributes such as the label, uuid, block
size, ... There are still things to do (support for ACL and advanced
filesystem attributes) but the most important stuff is already
implemented. fsarchiver cannot really do the bootloader installation,
of fstab modifications. Just because the program can't guess the
configuration. For instance, if an user has two harddisks, and the
bios is configured to boot from the second disk (/dev/sdb), how can
fsarchiver know that grub must be installed on the second disk
and not on the first one. It's the same thing with fstab: when you
have several partitions, with several linux flavors installed,
what should we do ?
We can develop advanced options to help the end user to do that by
displaying a list of options, but the program cannot make
assumptions about the disk / partition configuration, so we can't just
do everything instead of the user. I first want to improve
the quality of the code, continue to remove bugs, add missing features
such as the encryption, and then I will think about
working on a Qt GUI, on network support, or advanced installation options.
About the meta-data and what the archive contains ? You can already
use "archinfo" to display basic info about your archive,
but things like that have to be improved anyway.
About the abilities of the running OS to restore the partition: in
general, a recent system will work, but a lot of checks
have to be added to manage all the special cases. For instance,
mounting a filesystem with options such as "xattr" to make
sure we will be able to archive/extract the extended attributes, and
things like that. This will require a lot of tests,
a large amount of time, so I will do it gradually.
A lot of important features are implemented, but there is still a lot
of things to do, to manage the corner cases, debug, optimise the speed
and the memory, ...
Ok good news that safe guards for extraction are under development. With xattr word of advice when packing record the largest size of the xattr in the compressed filesystem. Xfs suports 64 kb xattr yet ext2 and ext3 is based on block size so it can be as small as 4kb. Then there are some with unlimited size xattr.
Big thing with fstab and bootloader is being able to record in archive number 1 where the fstab is hidding what compress partition its on so after restore you can correct it. Same with bootloader.
Both could be covered by including a good attach notes. When you have many distributions inside one pack set having a good description of what is inside would be kinda useful at times. Recording like device location the partition had to start off with. Yes there are still people who don't use uiid or labels for mounting there drives.
Processing multiple fstabs is not a major headache if you know where they all are. Ok more generic would be clearly taging what partition contains the /etc directory on a per installed distribution base for Linux and bsd. Allowing when doing mass deployment extraction system to extract and auto alter like hostname and the like.
Big headache is really not knowing where the /etc is and how the boot loader should be configured. Night mares of jumping across systems is invalid settings.
Processing fstabs just come to mind as kinda required when you change the file-system under a OS. Same with the notes thing again recording what the file-system type was to start off with.
Really I should have asked for /etc not fstab. Not thinking big picture.
You have done a good job so far. Yes I do expect some sections to land in the GUI interface like reapplying boot loader and editing fstab if needed. Notes at the package stage make correcting problems at extraction simple.