How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

lilsirecho · 2004-05-05 23:38:27

Thanks for the good info.

When you used the partimage, did you clone to a new HDD or some other application or just to have a backup?

kakabaratruskia · 2004-05-06 00:00:00

I just did the backup. Never used it though, so I don't know if the recovery works, but at least it created the image.

lilsirecho · 2004-05-06 00:21:38

One aspect not covered in googling has to do with the partitioning and how the program handles the swap partition which has never been mentioned....

Please advise as to how you utilized the binary to create the partition program active in arch linux.

I am grateful for your interedting reponse.

kakabaratruskia · 2004-05-06 00:41:42

mm...you mean how do I got it to run in arch?. I just unpacked it and made ./partimage. A bit primitve, but worked.

lilsirecho · 2004-05-06 01:09:14

I referenced the libraries necessary for compile of partimage and assume these aren't separately required for the binary method since they may be incorporated into the download.

The binary download references i386 binary download. Is that compatible with i686 arch at this time? I don't know how farback you tried this out......

I am hopeful that it provides the required images. Does the imaging also involve the swap partition?

kakabaratruskia · 2004-05-06 02:45:28

Just try it.

lilsirecho · 2004-05-08 15:14:58

Googling reveals that the partimage program available on the net hasn't been upgraded since the year 2000!!

kakabaratruskia · 2004-05-08 16:27:44

It must be extra stable...

lilsirecho · 2004-05-08 22:34:36

Assuming what you posit is true, I could in fact do the following;

1. Set up HDDB with identical sized partitions to those of HDDA.

2. Initiate the image partition program with no compression and apply it directly to HDDB , partition by partition until all partitions are transferred. (This installs all of HDDA into HDDB without restore function being required or any compression activity).

The above procedure seems valid based on the uncompressed mode provided and the existence of a properly partitioned destination for the partitions addressed by the program.
Performing it in this way is faster, based on the details given in googling partimage.

If I missed something, let me know!!!

lilsirecho · 2004-05-08 22:48:01

If one performs the following command:

cat /proc/partitions.........

One obtains the listing similar to the following; (system related of course)

-----------------------------------------------------------------------------------------------------[root@n6re root]# cat /proc/partitions
major minor #blocks name

3 0 80043264 hda
3 1 40162 hda1
3 2 265072 hda2
3 3 79730595 hda3
3 64 39082680 hdb
3 65 39078081 hdb1
[root@n6re root]#

The listings shown above are not reflected in fstab nor Lilo.conf. in the arch system of disc ID.

What needs to be done to address the partitions such that both partimage and arch are on the same wavelength?? And why does arch have both ensconced within the confines of /proc and /etc/fstab or lilo.conf?

punkass · 2004-05-08 22:49:16

I have found a new program (found here http://www.feyrer.de/g4u/)

that creates and exact byte image of a hard drive gzips it and sents it to a ftp server.
(I just created a temp ftp server on one of my lan machines)

It just turned 7Gigs of files into 2.5Gigs.. worked like a charm.

I have yet to use the image to see how the restore goes..when i do i will post and let you know.

lilsirecho · 2004-05-08 23:00:38

Further considerations:

If the program initiates an image file only...probably so..., then the direct, no compression image file could reside in HDDB when initially set up and run.

Then the restore operation would perform a restore on HDDB from its stored image file under the direction of HDDA partimage program.

If one can get the correct ID arrangement for the imaging, I would think this could work. The data already in HDDB would be overwritten and the original HDDA would not be disturbed in any way.

lilsirecho · 2004-05-08 23:07:16

Punkass !!!!!

Many thanks for the info...mebbe yes, mebbe no.

Reminds me of a phrase; "A big flood? Mebbe yes...Mebbe Noah.

lilsirecho · 2004-05-09 00:09:00

Further considering the use of HDDA to clone HDDB via a direct write of image into HDDB file(s) from partimage in HDDA:

!. What ID is applied to the image file?

2. How can the partition that contains the image on HDDB be overwritten if it contains the image from which it is written?

3. It seems necessary to have a third party involved!!

punkass · 2004-05-09 00:34:35

Also check out Knoppix Live CD, i believe it has some utilities for copying partitions. and since it is a live cd it does not mount any of your drives leaving them available for manipulation.

lilsirecho · 2004-05-09 00:36:36

A third party could be HDDC which just holds the image from HDDA.

Then HDDA directs the image to be installed on HDDB from image on HDDC.

It may in fact be that HDDC needs only one partition to hold the image for all of HDDA's partition images.

lilsirecho · 2004-05-09 03:05:22

Another possibility?

In my system, using ramfs, I can load an image file of 1.450GB or thereabouts into ram.

I can then direct the partition image program to restore HDDB which has the same size partitions as HDDA.

Following the restore, the data in ram is deleted ( at 133mhz per second).

The question then is what happens if , as is the case, the root partition is nearly 80GB in size but only has about 1GB of data stored? What does the program do with empty partition space? Will the program accept the partition data slots and not require accounting for empty areas?

Boot is 38MB, swap is 265MB and root is about 1GB(installed data). I assume the MBR is part of boot(?) and 38MB is allocated (actual less than that) and 265MB is allocated for swap. The end result of analyzing the needs results in needing to use both allocated and "real use" partition requirements. All partitions add up to 80GB but all is not data but allocated space as well.

This approach doesn't include any compression arrangement which entails even further
questions, especially if running in ramfs, which already provides higher speed.

Not being a development guru, nor a linux genius, I often find key issues missing in procedures until it appears out of the blue as an "understood". You may have been there, done that.

I feel that ramfs could be the third party in the clone job but only if just real data is required
due to the greater than ram size of the HDD.

What's next?

lilsirecho · 2004-05-10 06:21:57

Punkass;
Thanks for the Knoppix tip : will look into that possibility. I have a PclinuxOS Live CD but don"t have the data sorted out to determine if it has the same. It's a good LIveCD.

What is needed is a logical image of the entire HD in order that the MBR be included and then a restore function that permits restore on another HD.

In reading details on the g4u method, it isn't clear whether the restore can be directed to other than the HD it was entered from since the drive mentioned in the text is the same it came from into the FTP file.

It references DHCP as required, but it doesn't outline the way it is implemented (required to enter actual DHCP hosts, etc.) I am on fixed eth0 IP and no mention is made of that.

As to using partimage, I would have to load a bunch of libraries and I assume the program wouldn't run if all of them were not detected.

Knoppix may have an answer. PCLinuxOS is mandrake and has the capability of HD install. Then the user can re-master and run makelivecd in mandrake. My desired changes could be done in that manner to at least check out what happens with the change. But then I want the change in arch which brings me to the clone for test purposes and as a backup to the main HD.

Should an image file and restore capability be implemented it is backup as well.

I hope your use of FTP reveals some of the details I cannot verify in g4u.

lilsirecho · 2004-05-10 17:15:04

Punkass; After examining the package list for PCLinuxOS, I find that it contains partimage and all the librairies required, also Synaptic , k3b, lilo, and a program labeled mklivecd is referenced but doesn't seem to be a program in the package list.
However, since the partimage program is provided, it could be used to image arch and restore arch in a new HDD. This is true because the image is a logical image and would retain all the characteristics of the arch program even tho it was run in a mandrake environment.

If the program mklivecd is also present in the installed PCLinuxOS then a new custom LiveCD in mdk is possible but to upgrade to kernel 2.6.5 would require knowledge of the consequent changes needed in the packages to enable the new features of the kernel to be evaluated. The packages provided in PCLinuxOS are labeled in some cases as "tex" and that includes partimage-0.6.2-1tex indicating possible changes.

The partimage program could be run in Kde as well as a GUI.

This is similar to the Knoppix case you mentioned.

-------------------------------------------------------------------------------------------------------

When is a zero always equal to a one?

lilsirecho · 2004-05-12 02:18:52

Now that a program has been identified in PCLinuxOSLiveCD, the partimage program refers to hard hrivs as HDA, HDB,HDC, etc.

Does anyone know if this designation will properly address an arch linux HDD and its partitions?

What does one do with the partitions that have no data such as swap? If you have to partition the new drive the same as the original, it has to be present!

Command ....cat /proc/partitions lists an HDA partition as well as the hda1, hda2,hda3, etc.
Does this partition have to be addressed as well?

The ....cat /proc/partitions... ID's aren't the same as fstab!

Please advise!

lilsirecho · 2004-05-22 02:31:49

Have attempted to run the PCLinuxOS LiveCD partimage on arch kernel 2.6.6 in hda.

As hdb, I used an arch 0.5 base install. Each is on Maxtor 80GB ..133 7200rpm drive.

The original kernel on hda was the arch auto partition scheme as well.

Several attempts to produce image file for the 38MB hda1 partition resulted in error windows stating ....not enough space or wrong permissions on the target file....

Attempts to change the situation were unsuccessful.

The plan was to image the partitions on hdb/part3. Then transfer the image file to hda/part3.

Final operation would then be to " restore" the image file to hdb including MBR.

Not certain if permissions were entered correctly.....It would seem chmod 777 should do it nicely, but not in this case.

lilsirecho · 2004-05-27 06:44:47

I have spent the day in googling for information on the partimage procedures necessary to permit the cloning of my 80GB arch-2..6.6 hdd to a second 80GB hdd.

I utilized KNOPPIX LiveCD to do the job and will describe how I managed to perform it with partimage in KNOPPIX.

The knoppix partimage UI window displays the available partitions using Hdxx nomenclature. As root, enter partimage, and a UI window appears.

In performing the imaging, the arrow keys permit selection of the desired partition to be imaged.

The eventual destination for the partition image is typed into the "image file" entry line by using the "TAB" key to select that entry line.

I performed the imaging of hda1 partition , as selected by the arrow keys, into the "TAB" selected image file which I named "hdb1 partimg1.gz".

Then I left the selection , marked with an asterisk, to perform the image file generation.

You can then press "F5" or "TAB" to the F5 icon and ..enter..to start the process.

The next window asks for a name for the file(optional). Press "F5" again to the next window which describes the content of the operation, and has a "Continue" to permit advance to the actual image production. For the small sized hda1 file (38MB) this operation took a few seconds. The ..enter.. key returns to root prompt.

At this point, selecting "Home" directory will have an entry "hdb1 partimg.gz.000" if no name has been applied in the earlier step, perhaps different if a name was applied, I don't know.

Re-entering partimage as root then permits the selection of the next partition to be imaged, in my case, hda3.

The image file to write was then entered as "hdb3 partimg2.gz". The asterisk remaiuns at the same selection for image generation. The previous steps are followed as described for partition hda and the time required is proportional to the size of the hd3 partition and the computer's basic capabilities. My file was 9+GB and compressed to 3.2GB. The first operational step in the larger files remains dormant on the screen until actual file activity begins and displays activity and time elapsed, etc.

This image file appears in "Home" directory as " hdb3 partimg2.gz.000" as described previously with regard to partition 1.

Cloning is now possible using these two files (at least in my case).

To perform the "restore" function, select hda1 with the arrow keys.

Type in the "image to write/use" , " hdb1 partimg1.gz.000" .

"TAB" cursor to "RESTORE" selection and hold "shift"key" down and press "space bar"

This will enable the asterisk in that selected position.

Press "F5" to progress to next window. Use arrow keys to select hdb1 on the left-side column to enable the image to be entered into the hdbHDD.

Progress to the next windows and enter continue or OK as required. The system returns to root prompt when finished.

Repeat the previous cloning steps for the hda3 partition, using the remaining "hdb3 partimg2.gz.000" entry in the image to use selection line.

Again, select the "RESTORE" with the "TAB" and "Space Bar" and continue as before.

The MBR selection is made with the same procedure, using hda1 as source file, "hdb1 partimg1.gz.000 as the image file to use. The window steps are different and "continue"
is recommended. My use of MBR imaging always ended in an error at the last step, with a comment in the previous step that referred to a mismatch in size/content. I disregarded that and proceeded to test the result. (Notes in googling indicate this can be normal).

I rebooted, selected the hdb drive, and received the llilo prompt for the arch2.6.6 kernel identical to the hda drive lilo. It booted to kde log-in and away we go!

The original hdb drive had arch 0.5 installed and has now been cloned to arch-2.6.6.

I find that the pclinuxoslive cd produces the same files in "Home" and probably would permit the cloning if I hadn't done it already with KNOPPIX. The nomenclature used for the pclinux cd in partimage is not identical to KNOPPIX as well, but I do believe it will perform the cloning.

lilsirecho · 2004-05-27 14:50:37

A small note to correct a statement about the size of the hda3 image file.

I correct the data to state the partition was 3+ GB in data size (80GB total HDD capacity), and the image file generated in .gz format was 987MB.

The process to "restore" took about ten minutes on my athlon 1900+ computer. The hda1
source was 38MB and the .gz about 7MB.

I will probably need to upgrade the hdb drive in pacman -Syu once a week or so to keep it close to current.

lilsirecho · 2004-06-13 01:46:20

One important side issue regarding the use of LiveCD.

The partimage program requires a lot of ...lib....pkgs. Installing these would be a big load for some systems.

Using the Live CD keeps these on the CD along with the partimage program itself which reduces the need for stored programs in your Linux system.

lilsirecho · 2004-06-16 22:56:35

One consequence of a cloned drive is the need to upgrade to keep it current!!!

Arch Linux

#26 2004-05-05 23:38:27

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#27 2004-05-06 00:00:00

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#28 2004-05-06 00:21:38

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#29 2004-05-06 00:41:42

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#30 2004-05-06 01:09:14

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#31 2004-05-06 02:45:28

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#32 2004-05-08 15:14:58

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#33 2004-05-08 16:27:44

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#34 2004-05-08 22:34:36

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#35 2004-05-08 22:48:01

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#36 2004-05-08 22:49:16

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#37 2004-05-08 23:00:38

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#38 2004-05-08 23:07:16

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#39 2004-05-09 00:09:00

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#40 2004-05-09 00:34:35

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#41 2004-05-09 00:36:36

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#42 2004-05-09 03:05:22

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#43 2004-05-10 06:21:57

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#44 2004-05-10 17:15:04

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#45 2004-05-12 02:18:52

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#46 2004-05-22 02:31:49

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#47 2004-05-27 06:44:47

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#48 2004-05-27 14:50:37

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#49 2004-06-13 01:46:20

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

#50 2004-06-16 22:56:35

Re: How to clone arch 2.6.5 in Linux to a newHDD(Cloned success)

Board footer