Greg Freemyer composed on 2016-03-14 18:58 (UTC-0400):
Felix Miata wrote:
You seem to be overthinking the process into avoidable complications.
1-Shut down
2-Connect new disk >= used size of old[1]
3-Boot something other than anything that lives on the source or target disk
4-Ensure nothing on source or target gets mounted
5-Clone with any true cloner, the entirety of the source, sector by sector, be it with dd, dd_rescue, clonezilla, whatever. I've never used Clonezilla. Mostly I use DFSee[2], but with a failing source I have used dd_rescue.
6-Shut down
7-Remove old disk
8-Move new disk to connector formerly used by old
That's it, as long as you never try to boot either source or target without appropriate configuration modifications while both are connected to the same PC. If you need to do that, then you first need to either wipe one of them (possibly only selectively), or change UUIDs and volume labels on one of them (possibly only selectively).
All that said, I don't often do ("move") as you propose. I almost always want the new to be different in some way, obviating the possibility of cloning an entire disk. In part this is why I use DFSee's large multi-platform tool chest for the bulk of disk configuration processes. The biggest thing it can't do is manage FOSS bootloaders. Typically with a wiped or new disk that can't be initialized via temporary installation in a machine booted to an installed OS, I boot Knoppix to create any initial filesystems that aren't to be provided via cloning, and to configure the first bootloader.
[1] if old is old enough to use legacy 512b sectors, and new has 4k sectors, you may wish to reconsider cloning at all. Better to partition, format, and install at a minimum bootloader, probably plus OS, fresh, then use cp or rsync to copy files; this to avoid potential performance degradation.
[2] DFSee is not FOSS. http://www.dfsee.com/dfsee/
Another caveat with Felix's approach is if you have certain mount paths in your /etc/fstab or possibly in grub it can blow up.
I simplified maybe a bit more than I should by not mentioning: 1-with relatively few exceptions, my fstabs and bootloader stanzas, use LABEL= syntax for everything important, easier for a human brain to manage than UUIDs 2-booting here is always initialized via a boot-flagged primary partition via generic MBR code, usually Grub Legacy
For simple PCs I tried out the various mount by_uuid, by_id, by_path options. But I too tend to do clones like Felix describes.
For whatever reason after some clones I would find myself in a failure state.
Using what cloner? Failures here are virtually always a result of me forgetting something, and easily fixed.
If I were going to do a clone as Felix describes now, the first thing I would do is fix the /etc/fstab to use good old /dev/sdx type of device names.
Shouldn't be necessary with a true clone that is not installed in same system as source disk at the same time, big trouble to skip doing otherwise.
Then after the clone I would evaluate switching back to whatever the old mechanism was. (But I just make stick with /dev/sdx unless that's giving me issues on a specific computer.
Because I'm not usually doing full disk clones, and am nearly always working on multiboot disks, I tend to add and combine certain steps. e.g., 1-boot an installation logically low on disk, clone (or create, if not making an exact full disk clone) the entire partition structure but not the filesystems on the target 2-reboot same installation, configure boot process on a small primary partition on target, often as simply as restoring a partition image, otherwise create new filesystem on the small primary, install Grub Legacy files, run setup from grub> shell, configure initial boot menu 3-reboot same installation, umount all sources, clone the upper source filesystems, exit cloner, change UUIDs and LABELS on targets, mount the clones to edit the fstabs and boot configs as necessary 4-repeat 3, except from a source already cloned, the remainder 5-shut down 6-test 7-fix whatever was forgotten My cloner (DFSee) makes nice logs that function well as partition cataloging, so that even with high partition count per machine, tracking such processes remains simple. Those "catalogs" enable simple enough tracking of what's installed on which hardware even though partition count on working machines here numbers several hundred plus. Most recently created "catalog": http://fm.no-ip.com/Tmp/Dfsee/gx150L11.txt -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org