"...first I'm going to try cloning Jaunty from an internal 80GB hard drive to the 250GB external USB drive to see if the speed is faster than the cloning between the two US external drives. I'll post the results."
Just finished successfully cloning Jaunty from an internal 80GB to a 250GB external USB drive.
Calculating the bitmap took 10:05 mins at 1.88MB per min + copying took 12:58 mins at 630MB per min. Total time taken 23min.
Seems there's could be a USB-to-USB cloning problem unless cloning a Fedora 11 LVM set-up is inherently slower.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Seems there's could be a USB-to-USB cloning problem unless cloning a Fedora 11 LVM set-up is inherently slower." -> It should make no difference to clone LVM or regular partition. Therefore maybe it's USB performance issue or kernel/hardware support issues.
BTW, another new testing release of Clonezilla live is available, so if you have any chance, please give it a try.
Steven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-09-01
Test with CloneZilla 20090831-karmic:
No change, problem still there!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Meanwhile I've been able to boot and use my cloned Jaunty installation on an 250GB external USB drive after some UUID tweaking with tune2fs.
My intention then was to add a cloned Fedora 11 installation to the 250GB external USB drive to be able to dualboot Jaunty/Fedora 11 as required but I've put this on hold until GRUB issues with the Fedora ext4 file system have been solved.
Instead I'm now going to try to clone WinXP Pro SP3 from the master 40GB internal drive to the now empty slave 80GB internal drive prior to binning the 40GB drive.
Many thanks for the help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-09-02
Steven,
I'm not convinced, that an image file (it would be 4 GB large) would help to find what's going wrong. Perhaps rather the hard drive itself.
There is anywhere an area of the partition, in which the amount of mounts without check is stored. Ubuntu has no problems to read the exact data. But maybe there is something wrong on that hard disc, let that data just slip one byte ahead and perhaps Ubuntu is able to correct such an error, how to find what's going on?
Whatever, you showed me ho to help myself, I can live with that:
- Starting Clonezilla
- Choosing the command line
- manual fsck /dev/sda3/
- starting Clonezilla manually /opt/drbl/sbin/clonezilla
- saving the partition
Runs fine that way. OK, it takes a bit longer, so what! If you add a possibility to do an fsck by menue, so the better.
Uh, by the way: It happens from time to time that I type in the wrong key at some menus and I discovered, that there is no possibility to get back, I have to restart. Example: Choosing the hard drive and partition where to save to. Choosing the wrong one and I have to start again from the beginning. Could be more for 'unprofessionals'. ;)
Regards
Pogo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pogo,
Before partclone.xfs is fixed, you have some options to save an image:
1. Enter expert mode, chooe "-q" to force Clonezilla to use partimage instead of partclone.
or
2. Also in the expert mode, turn on the option " --fsck-src-part". This is available in testing Clonezilla live, e.g. 1.2.3-1 or 20090831-karmic.
Steven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-09-03
Steven,
I tried 'partimage via expert mode' as proposed, it works but runs too long and the save file is too large in comparison to the partclone file. Seems I will stay at the old way for the moment.
Pogo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"...first I'm going to try cloning Jaunty from an internal 80GB hard drive to the 250GB external USB drive to see if the speed is faster than the cloning between the two US external drives. I'll post the results."
Just finished successfully cloning Jaunty from an internal 80GB to a 250GB external USB drive.
Calculating the bitmap took 10:05 mins at 1.88MB per min + copying took 12:58 mins at 630MB per min. Total time taken 23min.
Seems there's could be a USB-to-USB cloning problem unless cloning a Fedora 11 LVM set-up is inherently slower.
"Seems there's could be a USB-to-USB cloning problem unless cloning a Fedora 11 LVM set-up is inherently slower." -> It should make no difference to clone LVM or regular partition. Therefore maybe it's USB performance issue or kernel/hardware support issues.
BTW, another new testing release of Clonezilla live is available, so if you have any chance, please give it a try.
Steven.
Test with CloneZilla 20090831-karmic:
No change, problem still there!
Pogo,
The problem is that I can not reproduce the problem here. If you can share the image file, maybe we can reproduce it?
Steven.
Meanwhile I've been able to boot and use my cloned Jaunty installation on an 250GB external USB drive after some UUID tweaking with tune2fs.
My intention then was to add a cloned Fedora 11 installation to the 250GB external USB drive to be able to dualboot Jaunty/Fedora 11 as required but I've put this on hold until GRUB issues with the Fedora ext4 file system have been solved.
Instead I'm now going to try to clone WinXP Pro SP3 from the master 40GB internal drive to the now empty slave 80GB internal drive prior to binning the 40GB drive.
Many thanks for the help.
Steven,
I'm not convinced, that an image file (it would be 4 GB large) would help to find what's going wrong. Perhaps rather the hard drive itself.
There is anywhere an area of the partition, in which the amount of mounts without check is stored. Ubuntu has no problems to read the exact data. But maybe there is something wrong on that hard disc, let that data just slip one byte ahead and perhaps Ubuntu is able to correct such an error, how to find what's going on?
Whatever, you showed me ho to help myself, I can live with that:
- Starting Clonezilla
- Choosing the command line
- manual fsck /dev/sda3/
- starting Clonezilla manually /opt/drbl/sbin/clonezilla
- saving the partition
Runs fine that way. OK, it takes a bit longer, so what! If you add a possibility to do an fsck by menue, so the better.
Uh, by the way: It happens from time to time that I type in the wrong key at some menus and I discovered, that there is no possibility to get back, I have to restart. Example: Choosing the hard drive and partition where to save to. Choosing the wrong one and I have to start again from the beginning. Could be more for 'unprofessionals'. ;)
Regards
Pogo
Pogo,
Before partclone.xfs is fixed, you have some options to save an image:
1. Enter expert mode, chooe "-q" to force Clonezilla to use partimage instead of partclone.
or
2. Also in the expert mode, turn on the option " --fsck-src-part". This is available in testing Clonezilla live, e.g. 1.2.3-1 or 20090831-karmic.
Steven.
Steven,
I tried 'partimage via expert mode' as proposed, it works but runs too long and the save file is too large in comparison to the partclone file. Seems I will stay at the old way for the moment.
Pogo