Hi all,

As per subject, how can this be done ?
I tried

1) create partition ie fdisk
2) make file systems on /dev/hdb1 & /dev/hdb2
3) use dump & restore
4) use dd to transfer MBR from source (80GByte) to destination
(40GByte)

but when boot up from 40GByte hdd, the GRUB cannot be started.
Also i have taken into consideration the size differences.

Thanks in advance .

Regards
johnny

Red Hat 9 is way out of date and totally unsupported, so I wouldn't bother with that at all and install a supported version.

But anyways:
1. Boot from a live-CD.
2. Create partitions on the new disk.
3. Copy the files from the old partitions to the respective new ones.
4. Mount all the new partitions to a complete tree, including /dev, /sys and /proc.
5. Chroot into that tree and install Grub to the MBR.
6. Power off, detach the old disk and boot.

1 members found this post helpful.

Hi ,

Thanks on the info.
The application runs on Redhat 9.0

Where to find GRUB and how to install on the MBR ?

Rgds
johnny

Grub should already be installed on your system. To install it on the MBR just doas root, after you chrooted into the system.

1 members found this post helpful.

Thanks a million.
Will try this out.

regards
johnny

As already was said RedHat 9.0 is quite old. You may have a very hard time to find hardware where RH9.0 will run.
In this case you may resort to installing RH9.0 in VM (VMWare, VirtualBox, qemu - whatever)

Another option - use statifier (http://statifier.sf.net) or Ermine (http://magicErmine.com) to convert your application into self-containing executable. This executable should be able to run on virtually any Linux distribution without any dependencies

Hi Valery,
Thanks on your idea.
Will work this out.

Hi TobiSGD,

"grub-install /dev/hdb" = works
Unfortunately, when boot up on the hard-disk , "GRUB Hard Disk Error'

Regards
johnny

Hi Folks,

when cloning same partition size , we use
" dd if=/dev/hda1 of=/dev/hdb1 bs=4096 conv=notrunc,noerror " = no error

how to clone bigger partition size to smaller partition size
" dd if=/dev/hda2 of=/dev/hdb2 bs=4096 conv=notrunc,noerror " = inadequate space

appreciate any suggestions how to solve this command = dd

thanks/regards
johnny

You can't do that with dd, simple as that.

Additional info,

The usable data on the larger partition does not exceed the size of the smaller partition.

I tried " dump & restore " = when booted up ,error = "mkrootdev: label / not found".

What other command is able to do the job ?

Thanks/rgds

Wonder if tar would work?

1 members found this post helpful.

I don't recall the incantations off the top of my head, but I should think a combination of 'find' and 'cpio' would be capable of doing it.

To keep things safe, use the instructions for zero-terminated names, so that any "funny" filenames won't be able to hurt the process.

Good luck - and please report back, regardless what the result looks like.

Actually one can do it with dd "if" the partition table of the 80Gn disk uses space no bigger than 40Gb. I have done this a lot of times.

If the systen has been cloned the grub-install must be told where the Grub located. Normally it is in hda1, say then boot up any Linux Live CD, create a mount point, mount hda1and the do the grub-install
A Fedora Live CD can also be used to restore Grub as described in Task B6 of Just booting tips in my signature.

I use the following commands to "move" one partition hda1 to another hdb1. hda1 is the one to read from and hdb1 is the one to write on, assuming hdb1 has been formatted previously
The hdb1 can be different size and have different filing system to hda1. I litertally move every Linux this way and then fix the boot loader as described previously.

Just a warning : If Red Hat has Selinux installed it would not like a change of partition number. After migration the Selinux may have to be disabled. Most server-grade distro has this rigidity built in.

A Linux don't normally need to be cloned and the file copying procedure is adequate. Howver if the operating system itself is being copied then dd should be used because filing copying prcedure could copy mounted folders also.

1 members found this post helpful.

Come to think of it, I should comment a little more fully:

The problem with using dd on your partitions, is that dd reads every byte available, _INCLUDING_ the blank ones you don't need, and then, of course, it wants to also write all that it has read. Which means it tries to stuff the second HD with everything, both data and the intermingled free space.

The command-pair of 'find' and 'cpio', on the other hand, copies files, links and directories - and ignores unallocated space. Hence, you need only find the space for what's actually stored in your filesystem(s). The "downside" of this, is that the filesystems have to be mounted when you copy, since it traverses the file system as such, rather than treating a partition as a stream of bytes, such as 'dd' can do.

I have also looked up some documentation, and it looks to me like the following incantation should work (but: NO GUARANTEES!):

'find -depth -print0 /some/directory |cpio -0admpV /target/directory'

To clarify, for readers: "print0" and "-0" contain zeroes, not capital Os.

One word about output: The instruction "V" tells cpio to print one "." for each file processed. This way, you get a visual progress report, but safeguards the terminal against possible effects of "funny" filenames...

UPDATE: The intervening poster reminded me of something: To avoid filesystems mounted downstream of the source directory, add '-mount' to the arguments for the find command (in front of 'print0' - the program is slightly finicky about order order ;-)

1 members found this post helpful.

Hi folks,

Tried the following steps

mount /dev/hda2 /
mount /dev/hdb2 /hdb2

tar cvf - / | (Cd /hdb2; tar xpf -)

when booted up ,error = "mkrootdev: label / not found" which is similar to dump & restore

Will tried out the cpio command as suggested.

Many thanks/rgds