Page 1 of 1

duplicate partition label

Posted: Tue Dec 01, 2009 4:09 pm
by archy
Hi , I just tested fsarchiver on a new F12 installation. On the face if it , it looks very impressive.

However, my first attempt at a restore leaves me unbootable and with what seems to be a corrupt partition table.

I'm running Partition Magic 4.6 downloaded yesterday (30 nov 09)
First I did savefs on the unmount root partition of Fedora, /dev/hda2 for PM, (/dev/sda2 when running fed.)

I want a clone of the initial installation to boot to in emergency (eg pkg update screws something)

I used gparted to create resize partitions above hda2 then did restfs to /dev/hda6 using mkfs-ext4 option

This completed without error but "refresh devices" is gparted showed the new partition was only half the size of the original. :?

Second thing I notice is that both have the same partition label.
Final anomally the partition /dev/hda7 showed as "unknown" fs type, despite having just been formatted ext4 as was hda6. (I suspect this to be related)

I thought it was odd that the restore should have changed the partition label but continued.

The reboot failed saying one of the fs had an error and dropped me to emergency console to fix it. I rebooted with making any changes at this time.

Back in P.M. liveCD environment I started gparted and tried to change the label (I suspected and identity crisis during boot). The rename failed. I dropped to command line to do it by hand.

Code: Select all

e2label /dev/hda6 clone  
fails silently. e2label /dev/hda6 shows not change has been made.

tune2fs -L '' /dev/hda6 fails to do anything either, though I hear a disk access labels don't change.

Can you see a way to correct this? It looks like two identical lables causes major low level confusion.


Re: duplicate partition label

Posted: Tue Dec 01, 2009 6:56 pm
by archy
OK, I managed to clear the blockage by reformatting (ie starting again), which cleared the label. It appears to be a bug in tune2fs and e2label , possibly in relation to ext4.

In fact, I think the booting problem was more to do with identical UUIDs than labels but that needs verifying. Doesn't one of those Us stand for "unique"? :P

It may be worth looking at whether setting the partition label is appropriate for restoring the file system (restfs) or maybe including a --nolabel switch if it is going to cause problems.

Either way it's a gotcha which it would be nice to have documented.

Re: duplicate partition label

Posted: Tue Dec 01, 2009 7:55 pm
by mbiebl
I would consider it a feature, that fsarchiver restores the UUID and LABEL. Most distros nowadays use UUID or LABEL in their fstab, so when restorig a system image, it is still bootable.
In your case, where you restore the image to another partition along side the existing partition, a command line switch which allows to override the label switch would be nice.
fsarchiver could also warn if in such a case when there are duplicate LABELs or UUIDs.

Re: duplicate partition label

Posted: Tue Dec 01, 2009 9:16 pm
by archy
Yes , I think this behaviour needs to be defined. If I use the mkfs option for example (as I did in the first instance), I am creating a new uuid but this gets replaced by the uuid of the image.

Since the whole point of a uuid is that it be unique duplicating one should normally be regarded as an error. Although there will be cases where this is the desired result.

Duplicating labels is less of an error except for the bugs in tune2fs and e2label . Whether this project needs to work around bugs elsewhere needs to be looked at.

I suppose if there were -L -U options that were clearly documented that may mean a warning is not required. It is reasonable to assume that the user has read the doc before using this sort of tool.

Anyway. My first test of fsarchiver is a resounding success. Thanks for a great tool.

Re: duplicate partition label

Posted: Tue Dec 01, 2009 9:30 pm
by mbiebl
archy wrote: Since the whole point of a uuid is that it be unique duplicating one should normally be regarded as an error.
Depends. If you use fsarchiver as backup tool and you use the image to restore a (broken) system, then restoring the LABEL / UUID is definitely what you want (this is how I fsarchiver currently use for).

If you use fsarchiver to duplicate/replicate a system, then this behaviour is of course less desirable.