[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Squeeze installation fdisk bug



On the 02/02/2011 05:21, Siju George wrote:
> On Tue, Feb 1, 2011 at 9:31 PM, tv.debian@googlemail.com
> <tv.debian@googlemail.com> wrote:
>>
>> Regarding "sfdisk -d", if you ran this command with a filesystem already
>> on the source drive you'll run into problems due to the filesystem
>> boundaries being misplaced.
>>
> 
> Thanks for the reply but I did not get it full :-(
> 
> The source drive was /dev/sda It is a running RAID1 partition.
> I connected sdb and did
> 
> #sfdisk -d /dev/sda | sfdisk -f /dev/sdb
> 
> to create identical partitions on sdb and then added it to the RAID device by
> 
> #mdadm -a /dev/md0 /dev/sdb1
> #mdadm -a /dev/md1 /dev/sdb2
> #mdadm -a /dev/md2 /dev/sdb3
> #mdadm -a /dev/md3 /dev/sdb4
> 
> and the RAID devices now look like
> 
> 
>  root@vmsrv:~# cat /proc/mdstat
> Personalities : [raid1]
> md3 : active raid1 sdb4[2] sda4[0]
>       470514552 blocks super 1.2 [2/2] [UU]
> 
> md2 : active raid1 sdb3[2] sda3[0]
>       16599992 blocks super 1.2 [2/2] [UU]
> 
> md1 : active raid1 sdb2[2] sda2[0]
>       976884 blocks super 1.2 [2/2] [UU]
> 
> md0 : active raid1 sdb1[2] sda1[0]
>       291828 blocks super 1.2 [2/2] [UU]
> 
> unused devices: <none>
> root@vmsrv:~#
> 
[snip parted output]

> --Siju
> 

What I was saying is with this method which is widely recommended on
different tutorials over the web (using sfdisk to dump the partition
table to the other disk, when the source disk akready is a raid member
with a filesystem on it) I had a 100% rate of filesystem boundaries
problems preventing the boot whenever fsck kicks in. I think it is due
to the size of the superblocks not being properly accounted for, but
Martin F Krafft surely has a better understanding of the problem than I do.
What I suggested if your problem is due to a similar situation, and it
seems to be given how you set up the partitions on the target disk, you
can either start over but this time slightly shrink the partitions on
the source disk before dumping the table to the target (1MB is enough),
then add the target to the raid, and then use resize2fs on the raid
device to expand the filesystem.

If you want to keep the raid as it is, you can assemble it "ro" or from
a live-cd (don't mount it), and run

e2fsck -cc /dev/md0   (assuming md0 is the right raid device)
resize2fs /dev/md0
e2fsck -fp /dev/md0

It's very time consuming on 500GB partitions (think 10 hours+), but it
solves the problem.

Or start over from scratch following Martin F Krafft advices, it will be
much quicker to restore a backup than to run "e2fsck -cc".

Hope it helps.


Reply to: