Begin <1169939445.473733.125610@a34g2000cwb.googlegroups. com>
On 2007-01-27, john.coppens@gmail.com wrote:
> A 5GB disk started failing and before (I hoped) disaster, I did a 'dd'
> of each partition to a new (larger) disk. It went fairly well, but
> after doing it I find strange results:
[snip!]
>
> What did I do wrong, and can I fix this?

You copied the entire filesystem down to its layout, so for all *it*
knows, it is still the previous size. The simple way to fix it is to not
try a bitwise copy like you did with dd, but to create the filesystem(s)
to the right sizes then use a filesystem level tool such as dump/restore
or an archiver (eg tar[1]) to transfer the data and associated metadata.


[1] Be aware of the limitations of the particular tar you're using;
star is a good tar implementation with lots of options.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

On 27 Jan 2007 15:10:45 -0800, john.coppens@gmail.com wrote:

>Hi people.
>
>A 5GB disk started failing and before (I hoped) disaster, I did a 'dd'
>of each partition
>to a new (larger) disk. It went fairly well, but after doing it I find
>strange results:
>
>1) df reports the original sizes:

>
>This simple can't be - 3.27 + 3.80 is larger than the original disk
>where I
>copied from!
>
>What did I do wrong, and can I fix this?
>
>Thanks in advance!

Only use dd to copy from partitions of the exact same size.
Use cpio instead, google for "cpio backup"

zentara

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

You copied the entire filesystem down to its layout, so for all *it*
> knows, it is still the previous size. The simple way to fix it is to not
> try a bitwise copy like you did with dd, but to create the filesystem(s)
> to the right sizes then use a filesystem level tool such as dump/restore
> or an archiver (eg tar[1]) to transfer the data and associated metadata.
>
> [1] Be aware of the limitations of the particular tar you're using;
> star is a good tar implementation with lots of options.

Thanks - I did suspect as much. But I don't think I can access the
original disk anymore
now. It was already making strange noises, and I did the 'dd' as sort
of panic reaction.

Can I adjust the size of the copied image to the actual size of the
new partition
somehow?

John

Begin <1169992981.665221.133970@l53g2000cwa.googlegroups. com>
On 2007-01-28, john.coppens@gmail.com wrote:
[please do include attribution when quoting]
> Thanks - I did suspect as much. But I don't think I can access the
> original disk anymore now. It was already making strange noises, and I
> did the 'dd' as sort of panic reaction.

You could try. And, of course, `backups'.


> Can I adjust the size of the copied image to the actual size of the
> new partition somehow?

Well, you could try and take a dump off the copy, then restore it after
you've set the disk up differently. Or you could venture to use tools
like `growfs', altough those are system dependent. As always, taking
backups before trying stuff like that is a good precaution.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

> Or you could venture to use tools
> like `growfs', altough those are system dependent. As always, taking
> backups before trying stuff like that is a good precaution.
>

Thanks jpd...

I've just noticed that it may be as simple as running resize2fs, which
seems just
the tool I need. I'll try it this a'noon when I go there and can
unmount the
drives.

Groetjes,
John

john.coppens@gmail.com wrote:
> A 5GB disk started failing and before (I hoped) disaster, I did a 'dd'
> of each partition
> to a new (larger) disk. It went fairly well, but after doing it I find
> strange results:
>
> 1) df reports the original sizes:
>
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/hda1 2270080 1857408 295496 87% /
> /dev/hda3 2365300 352328 1890880 16% /usr/local
>
> 2.27 + 2.36 + a swap partition is the original 5 GB drive. On this
> one, there is
> 10 GB available, and the first partition is 4 GB (not 2.27).
>
> 2) fdisk reports correctly:
>
> Device Boot Start End Blocks Id System
> /dev/hda1 * 1 479 3846260 83 Linux
> /dev/hda2 488 498 88357+ 82 Linux swap
> /dev/hda3 499 1245 6000277+ 83 Linux
>
> What did I do wrong, and can I fix this?

Nothing all that incredibly "strange" here. You copied the
filesystems with dd, so as long as the target partitions aren't
smaller than the originals, and are set to the same partition type,
and the source filesystems were unmounted or mounted read-only when
you copied them, you should be in pretty good shape.

Copying a filesystem - e.g. with dd - doesn't grow it, so if the
target partition is larger, the filesystem doesn't automagically grow
to fill the partition. You can grow the filesystem when it's
unmounted (e.g. with resize2fs) or with ext2online while it's mounted.