The machine would now boot into Windows – but only into Windows! – the grub menu had disappeared. This did indeed “fix” the startup options. Firstly, a Windows Recovery Disk (bootable CD) was used to “Fix startup options”. The solution to the latter problem proved to be a two-stage process. This “other” operating system seemed to take umbrage to its partitions being moved around and simply refused to boot. Alas, the same could not be said for the dual-boot option into Windows. Once the transfer process was complete, the machine did indeed boot into the grub menu, and the Linux-boot option proved to be functional. The final thing to note is that Clonezilla does not copy any linux-swap partitions so that any required swap partition must be specifically created (using Gparted) on the smaller drive. However, despite the multiple apparent failures – “…critical target error”, “Failed to load file”, “File doesn’t exist”, “Cannot open file for reading” – the program does actually load and run! The DOS-like menu system, with its many options, is similarly daunting, but the detailed instructions, complete with screenshots, from provide an excellent how-to guide. I have never seen so many error messages streaming by when Linux software is loading. While the process, as noted above, is relatively simple, Clonezilla isn’t for the faint of heart. (5) If necessary, Gparted can be run once more to resize the SSD partitions as desired in order to completely fill the available disk space. (4) Clonezilla is then used to restore the saved partitions (using restoreparts) onto the SSD. I took the opportunity to mark /dev/sda1 (the boot partition on the original hard disk) as the boot partition (Gparted – Partition – Manage Flags) on the SSD, hoping that this would allow the machine to boot at the end of the exercise (more on this later). (3) With the SSD installed in the target machine, the second trick is to use the partition manager once more to create the desired partition structure on the SSD. Note that it is necessary to save the partitions (saveparts) rather than making an image of the entire disk(savedisk). (2) One then runs Clonezilla and makes a copy of the individual hard disk partitions (using the saveparts option), storing these temporarily on an external USB drive. Obviously, the partitions must be sized such that the total space required for all the partitions is less than the capacity of the SSD. (1) The first trick is to use Gparted to resize the partitions on the hard drive, shrinking each partition so as to reduce the amount of unused space it contains. I used bootable versions of both these programs, with the full process involving the following steps. However, Clonezilla is a similar disk imaging program, which does support ext4, and so I opted to give this software a try.ĭocumentation available on the web indicated that the task at hand was indeed possible using a combination of Clonezilla and Gparted (the Gnome Partition Editor). Since my current installation of Ubuntu uses ext4, partimage was a non-starter for my present purposes. In the past, I have used partimage to backup disk partitions however, this is an old program and doesn’t support the ext4 file system. So, it’s really just a case of finding the (free) software that will do the job. Now, there really isn’t a good reason for this since, in principle, there is no problem in copying a number of disk partitions from a hard drive, with lots of unused space, to a smaller drive onto which the said partitions will fit. However, free disk imaging programs (especially Windows-based products) typically don’t allow this, and offer to let you purchase a “pro” version that provides such capability as an additional feature. The process should have been easy – just make a disk image of the hard drive, and restore it to the SSD. I recently switched out a 160 GB hard drive on an old laptop computer for a 120 GB solid state drive (SSD).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |