admin wrote:1) Support for FAT
About the FAT support: if you can find documentation that says how to preserve the stuff required to boot Windows, or if you can demonstrate how to do that by hand, I can consider adding support for FAT.
For your tests, you need two partitions. One original that you are trying to clone, and an empty partition for your tests. They both have to be primary partitions. Basically the filesystem will be recreated using mkdosfs. You can copy the files between /mnt/part1 and /mnt/part2 using rsync. After that, what do we have to do ? Do we have to copy boot code in the boot sector, or in another sector ? Do we have to update the reference to a block in the boot sector
From the last I researched this topic, Windows uses the VBR (volume boot record aka partition boot record) to store its boot code. Unlike the MBR though, the VBR can vary in size, but I believe it is always located at the start of the partition.
Lots of good info here...
Here is Win95-Me with FAT: "Boot Record is actually 3 sectors long, and is found at Logical Sectors 0 through 2".
WinXP with FAT32
Which also mentions: "Reminder: Don't forget that each FAT32 Boot Record has a Backup Copy (even under Windows 2000 or XP) just a few sectors beyond the original. These correspond to Relative (or Logical) Sectors 6 through 8 (for the Backup copy) of any FAT32 partition on your drive."
WinXP with NTFS
Here is a breakdown of Vista, which uses a VBR of 2048 bytes...
I think the ultimate solution would be to figure out a generic method which determines the VBR size, such that it works for any device/OS (for example a Garmin GPS unit, which partimage can handle). For the kernel or filesystem make command to know where to start the filesystem, this info must be able to be determined. That would avoid having to create different profiles for each OS that might be installed on a partition, and might even work for NTFS the same as it does for FAT. I don't think you need to care what's in the VBR, unless it has a block pointing to one of the boot files (which will change when fsarchiver recreates the fs).
I don't actually have windows installed on any FAT partitions, but if I get a chance I will see what else I can find on the subject. You might even have a look at the partimage code to see how it determines where the filesystem begins. Partimage does process the filesystem (in order to avoid copying unused blocks), so it must know where the VBR is and its size. I know it always copied the VBR successfully.
http://www.partimage.org/Partimage-manu ... .2Fwritten
2) Backup and recreation of the partition table
I am thinking about how to implement a backup/recreation of the partition table. It should really be possible, and we can use libparted for that. It has to support both msdos and gpt disklabels. This way it can dump extended/logical partitions as well as primary.It also provides a support for disklabels other than msdos, like gpt which can be used on normal PCs. I really prefer doing that dynamically (we understand what we copy) instead of statically (we copy a sector), because it will provide more flexibility.
Agreed. That is how sfdisk works, which works well. It outputs a plain text file which is both human- and machine-readable. It can then accept that file to recreate the table. I actually don't know if you need to get into that, as sfdisk does it already, except that it would be nice to have it in one program/archive file. In fact maybe you could borrow some code from sfdisk.
About the boot code which is stored in the MBR.
a) It should not be a problem for disks with just Windows installed. We can just recreate a standard MBR with a partition table, restore the ntfs filesystem. The BIOS will just boot the active partition, no particular action is required.
b) For linux based disks, we can reinstall grub. fsarchiver can have a "--reinstall-grub" command that will chroot in the root filesystem and execute "grub-install /dev/xxx". Fortunately the big majority of Linux Operating Systems are now using grub and not lilo, so we just have to provide support for Grub.
That might be a good approach, providing you can Keep It Simple. Grub sometimes can get very unsimple depending on multiple OSes on the system, and also the complexities of grub v1 vs v2 now. BTW, on SystemRescueCD, grub2-install is v2, and grub-install is v1. (This isn't documented anywhere that I could find.)
Also, I looked into it and the way fsarchiver recreates the filesystem and presumably moves the sector locations of the files, grub WILL need to be reinstalled to the MBR afterward (rather than simply copying the boot code). Grub stores the disk sector of its stage2 file in the MBR boot code, so if that file is moved to a different location on disk, grub will most likely report a file not found error.
So given the fact that fsarchiver is going to break grub when it restores a partition containing grub's files, addressing grub reinstallation in some way is probably a good idea. At the very least, fsarchiver's docs should address it. (Note that with the partimage method, the files are not moved, so grub doesn't break.)
I have updated my wikibook with fsarchiver methods, including the grub breakage issue. Since fsarchiver can't completely replace partimage yet, I wrote it as a dual-method approach, but I made fsarchiver the recommended method for linux filesystems. I recommended against using fsarchiver for NTFS at present because you said elsewhere it wasn't as stable, but I can update that as fsarchiver evolves.
http://en.wikibooks.org/wiki/How_To_Bac ... ng_Systems
Overall I really like fsarchiver's design. I think restoring to smaller partitions than the original and other features is worth the grub breakage.