ext4 VBR left in the cold

Post here if you found a bug or something really not expected in the program
Post Reply
andreii
Posts: 3
Joined: Fri Dec 03, 2010 4:53 pm

ext4 VBR left in the cold

Post by andreii » Fri Dec 03, 2010 5:08 pm

OS ........... Fedora 14 (x86_64)
Package ... fsarchiver-0.6.10-1.fc14.x86_64

The test system has GRUB installed in the VBR (sda4) instead of MBR (sda).

BUG #1
Fsarchiver doesn't care saving the VBR like it does with the rest of the ext4 partition when doing something like:
fsarchiver savefs /my-ext4-image.fsa /dev/sda4

BUG #2
Worst than that, Fsarchiver overwrites (with what ?) a perfectly working VBR when restoring the previously created image:
fsarchiver restfs /my-ext4-image.fsa id=0,dest=/dev/sda4

admin
Site Admin
Posts: 550
Joined: Sat Feb 21, 2004 12:12 pm

Re: ext4 VBR left in the cold

Post by admin » Mon Dec 06, 2010 1:13 pm

This is not a bug. The idea is that fsarchiver saves things at a high level (file level for instance) instead of low level (block level) because it's possible to restore data on a different configuration. In the current version you can then restore a file-system on a larger or smaller partition for that reason.

In fsarchiver-0.7-beta the partition table is saved in a flexible way as well: it understands the partition table using libparted and it can be recreated with modifications, instead of just dumping the MBR. Then it will be possible to implement options to change the size of a partition of to save and "msdos" partition table and to restore the same disk layout using "gpt" for instance.

In the current situation, the administrator has to reinstall grub by hand unfortunately. Ideally we want to develop a simple grub-installer that would allow fsarchiver to reinstall grub properly and then to provide that full service in a flexible way.

With the coming UEFI firmwares (replacement of old PC BIOS) it should not be a problem anymore. The firmware just reads the boot loader (grub2 for instance) as a normal file on a special FAT partition which is flagged as the system EFI partition on the GPT partition table. No more hidden data in special blocks involved. Just saving and restoring a FAT filesystem will be required to preserve the ability to boot after a full disk restore. It means we have to implement support for fat in fsarchiver but it should be quite easy as long as we don't want to preserve the low level stuff involved in booting Windows 9x systems. So at least we have a good and simple solution for the long term.

andreii
Posts: 3
Joined: Fri Dec 03, 2010 4:53 pm

Re: ext4 VBR left in the cold

Post by andreii » Tue Dec 07, 2010 10:15 am

admin wrote: In the current situation, the administrator has to reinstall grub by hand unfortunately. Ideally we want to develop a simple grub-installer that would allow fsarchiver to reinstall grub properly and then to provide that full service in a flexible way.
Too tehnical for me... A simple question though:

Why the VBR is taken care of in case of NTFS partitions and is ignored instead for ext4 partitions ?

admin
Site Admin
Posts: 550
Joined: Sat Feb 21, 2004 12:12 pm

Re: ext4 VBR left in the cold

Post by admin » Tue Dec 07, 2010 1:06 pm

It just that the nkntfs program does the correct thing automatically to make the partition bootable.

Post Reply