I have 160GB linux disk (with XBMC) and now i have a new SSD 40GB intel
postville. I have used about 1 GB of data. And i want to clone the 160GB disk
to the 40GB disk and resize it to the maximum 40GB. Is this possible with your
You would need to resize the original system to only use the 40GB size using
something like gparted with a partedmagic cd or something similar. You would
probable be best to do a mbr backup, and the backup then backup the partitions
to restore later.
I have similar question :
My source disk is 160 Gig, on which I have sda1 partition with 30Gig. I want
to cloon my system to others (same type) but with smaller harddisks.
I did already backup this sda1 partition via G4L via FTP server, and then did
a restore on the other machine on which I created in advance an SDA1 partition
of the same size (30Gig). All fine until now.
Question : howto make my second system bootable ?
Should I do a full disk backup (sda instead of sda1) and then try to restore
on the smaller disks systems (how to be sure nothing is lost - and how to fix
Or is there a way to create an MBR correctly fitting the smaller disk after
only restoring the sda1 partition?
What is the OS of the partition?
With old DOS it would just be doing a sys c:.
With Linux, it would just be reinstalling the grub or other boot loader.
Restoring the full MBR and partition table wouldn't work, since it will see
the size is to big.
You might be able to just copy the boot sector part of the sector.
That would be 440 or 446 bytes instead of the 512 bytes that includes the
fsarchiver 7beta has support for doing resizing, but I have not tested it, and
don't know which OS's it would work with.
I'm not a Linux expert, just want to cloon my Linux Ubuntu Lucid Server to
other identical PC's,but with smaller harddisk sizes. Via gparted I reduced
the partition sda1 of the first system to 30Gig, so that it can fit all my
systems and then copied via FTP to another PC - and copy was succesfull I
assume (no final success message seen in G4L at the end of the FTP however as
it justs jumps back in the main menu). Only problem : I don't succeed in
making them boot from it
A Fedora rescue CD did not manage to find any OS - so can't reinstall the MBR
- same problem via fdisk /MBR.
Is there a simple procedure for installing Grub2 or MBR on a system that
contains already an sda1 partition (copied via G4L) ?
Fedora does not use grub2.
If you reduced the size of the partition on the original disk to 30GB, and
there is nothing else on the disk, you should be able to use the g4l to copy
the MBR and restore it. It should work as long as no partition is listed that
goes beyond the destination disk size.
Years ago, I had identical classroom machines, but one disk showed up as
having 32MB less disk space than all the others. So, I just made the partition
layout not use that extra 32M on all machines, and then images worked. I used
a disk image, but that was before MBR backup was added.
sorry for late response - but still had problems because my swap disk was
placed at the end of the disk (I remember having created some extra partitions
before installing Ubuntu - bad idea apparently) , and trying to move it with
gparted destroyed my system (but thanks to g4l I had a backup :-)
finally I found a solution by making a full disk copy with g4l via FTP and RAW
mode (complete disk) to my smaller disk, which does not finish properly as g4l
keeps hanging at 99,99% (due to unsufficient disk space) , but then I rebooted
and fixed the partition table to the correct size of the disk by following the
instructions which I found on following link :http://ubuntuforums.org/showthr
so now I have a properly sized partition table with my original system on a
smaller disk - so I'm happy after all !
only small problem left is following message appearing after booting, and
showing up just before login prompt :
"mountall: Plymouth command failed"
No idea yet what this is, but plenty of posts about it
Currently I have not seen a negative effect of it....
P.S. : I use 64 bit lucid SERVER version
Glad to here you got it working. I believe I mentioned earlier that you can
copy a larger disk to a smaller one as long as you don't use any of the space
above the size of the smaller disk in any way. In one lab, I had 20 identical
machines, but one hard disk was showing with 3 less tracks than all the
others, so I just partitioned them all to no use those last 3 tracks, and
could restore a full disk image to it, but as you said, it would get the write
error at the end since the full disk image (or udpcast) would still try to
copy those last three tracks. But since it was used in the partition table it
You probable could have used gparted to move swap partition within that size
range, and the disk image would have worked.
I've also had people make images to disks that thought were the same size.
80GB to 80GB, but in closer looking, sometimes the sizes are not exactly the
same. Would probable be possible to add some code to check if the destination
disk is smaller than source for a clone operation, but an image file doesn't
include the uncompressed size so one couldn't tell in advance if it would not
Thanks again for the update.
Well - for some unkown reason my attempts to move the swap partition forward
via gparted always made my disk corrupt. Maybe because gparted only supports
ext2 ? Even deleting the empty partition in front of the swap partition made
the disk unreadable.
So that's why I did the opposite : first copy the large disk to the smaller
via G4L (with 99,99% result) , and then adapt the partition table as shown int
he link of my previous post.
thanks for you suggestion - it really helped me to resolve the issue.
Maybe the reason of the problem is the warning in below sfdisk report on the
extended partition - but on the other hand the partitions were originally
created via gparted - so that's weird after all...
echo "58597374,97704114,5" | sudo sfdisk -f -uS /dev/sda -N2 -O
Checking that no-one is using this disk right now ...
BLKRRPART: Device or resource busy
This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.
Disk /dev/sda: 9729 cylinders, 255 heads, 63 sectors/track****
Warning: extended partition does not start at a cylinder boundar****y.
DOS and Linux will interpret the contents differently.
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sda1 * 2048 58595797 58593750 83 Linux
/dev/sda2 58597374 183597373 125000000 5 Extended
/dev/sda3 0 - 0 0 Empty
/dev/sda4 0 - 0 0 Empty
/dev/sda5 58597376 120037375 61440000 83 Linux
/dev/sda2 58597374 156301487 97704114 5 Extended
Warning: partition 1 does not end at a cylinder boundary
Successfully wrote the new partition table
Re-reading the partition table ...
The command to re-read the partition table failed.
Run partprobe(8), kpartx(8) or reboot your system now,
before using mkfs
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
Well, glad it eventually worked. Sometimes the simple solutions don't work.
Thanks again for the feedback.
There are some strange things that happen.
Long ago, I had systems with 98, XP, and Linux.
The 98 was a primary partition, and then sda2 was the extended partition.
xp was sda6, boot was sda7, lvm with root and swap was sda 8.
With this system, on disk was smaller than the others, so the extended
partition did not include those last tracks.
On a test, I tired to make an ext2 partition with those extra tracks on one
machine. sda3 was created and worked fine,
but the XP would no longer boot. 98 worked fine, Linux worked fine, but XP
would no longer boot.
Deleting the partition fixed the process, but didn't figure what was causing
Hello, G4L is very nice piece of SW. I would like to ask something. Now it's
working with whole disks/partitions right?
It would be possible to add ability to work with filesystem (like old Northon
Ghost) for example? That would be great for mirroring to smaller drive.
Suggest partitioning and new partition sizes on smaller drive (user could
change sizes/names/fs) and copy data inside?
Many of the imaging options use dd, which is a bit level copying, and it
doesn't have the option to resize or even have to know the fs to work.
Other options use ntfsclone, which does only backup ntfs partitions, and can
restore to larger partitions, but not to smaller..
There is a new set of options that use fsarchiver and it can make images, and
they can be restored to smaller partitions, but it is a work in progress by
another maintainer, but in the limited testing it seems to work fine.
I plan to back up ( Raw Click n Clone ) two Mushkin 480GB SSD to two WD5003AZEX 500GB drives. One will be Ubuntu 16.04 system, the other Windoze 10 Anniversary edition. As I understand it, cloning from the 480's to the 500's is ok, both for Ubuntu and Windoze. The big question is when I might need to restore from the 500's with the 480 clone copies back to the actual 480 SSD drives, will I have a problem? Or maybe doable with special procedures? I will be using V0.52 .
A disk clone to a smaller disk is a problem IF the partition table uses any of the extra space. Had a classroom that had identical machines, but on machines hard disk reported less space than all the others. If tried to put an image on it that was too big, it would complelely fail, but I I made the partition space not go to the extra track, it would be just fine. Believe it did give a short write for that part of the disk, but since the space wasn't being used, it didn't matter the partition table was still valid, allong with all the partitions.
For some things, the drives needed to exactly the same. Using same number of head and tracks for the early drives, but now it is generally all logical and not physical info anyway.
Don't know if there would be any issues going from an SSD to Regular or back. There were generally issues with the kernel initrd, if you switch for different types (IDE to SATA) or different controllers, since the initrd might not have the support.
Thanks for the quick answer!!!
1) So cloning from the 480 SSD to the 500 HD should be ok, unless initrd creates a problem. Since it boots from the CD, in my ignorance it seems that initrd should be associated with the CD? Or is this something that once loaded from the CD, then can't make sense of the other disks? Since both SSD and HD connect to the same hardware, should be ok / look the same to G4L?
2) With the 480 SSD copied to the 500 HD, does the copy stop short of the end of the 500 at the actual data end, or does it keep plugging away to fill the final 20 with... ??? something?
3) Considering the above possiblities, if the copy stops short, then it will likely copy back ok? If the copy fills the extra space with ???, then the ??? doesn't get used on the return copy (short write / lost only garbage)? Or the ??? is a wrench in the cogs?
4) Is there any way to test the copy other than to attempt to restore from the HD to the SSD (thus possibly destroying the original drive)?
5) Is there another selection or method in G4L that would be better for this situation?
6) Possibly even another piece of software that would be better in this case?
Got the email earlier, but have no clue what Bump... is suppose to mean or ask?
Kind of a refresh, to draw attention back to the message.
Using the dd command to copy images requires that the disk be the same size or destination be larger. You can copy a larger disk to a smaller disk, but the partition size must be equal to or less than the smaller disk. Example. If I have a disk with 10000 tracks, but actual partitions use to track 9500, I could copy that image to a disk with 9500 tracks (assuming other settings are the same). It will get an error of short write, but the partition table will work. If partition is outside of bonds, it fails since disk will not allow settings that don't fit.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.