I just got a 256 GB SSD, which will be mounted internally, but I'm trying to transfer the data that'll reside on it via USB cable and test adapter (like an external enclosure without the actual enclosure), prior to being able to mount the device inside the machine (didn't realize that a new SATA drive wouldn't include a SATA data cable, so it'll wait until payday to go inside the box, where I presume I won't have this problem).
Problem is, when I boot to Parted Magic (June 2013 version, the last one that still runs on my Pentium II/288 MiB RAM laptop, hence the one I have in immediately usable form), I can't get the drive to stay connected even long enough to finish partitioning and formatting, never mind clone the data from my Kubuntu, Mepis, and shared home partitions to their future homes on the SSD. It seems to stay mounted fine in Kubuntu 14.04 (I did all the partitioning and formatting in KDE Partition Manager), but I can't transfer mounted partitions with a cloning utility (including KDE Partition Manager or gparted copy/paste partition); as I understand it, even dd requires that both partitions be unmounted when copying an entire partition (and dd at command line still makes me nervous; cross up just a little and you can clone your empty drive over your installed OS and not realize it until afterward).
This is on my Core2Quad system, with MSI P6NGML motherboard (about six years old, and not cutting edge then); the ports are, as far as I know, USB 2.0; every reference I've found online to problems like this appears to be with USB 3 ports, but I presume it's the same issue: the drive is powering down even while it's mounted on the Live OS I'm trying to use to clone the partitions, causing write errors that terminate (for instance) Clonezilla. The drive is a Transcend SSD340, SATA 300 256 GB (should be backward compatible with even SATA 1.0 controllers, right?) and the test connector I'm using is only about a year old, so ought to be at least SATA 2.0.
Complicating this situation is that only one of the two front panel USB ports works (I've never been able to get the single-connector wires for the other port connected in the proper order on the motherboard header; they're different color coding from the ones on the working port and the header pins might or might not be wired in the opposite order as well), and all my back panel USB ports are filled (and the wire tangle back there makes it a PITA to temporarily replace one of them); that means I can't readily boot Kubuntu from USB while the SSD is connected (I should be able to do so once the SSD is internal, so if nothing else works in a few days, I'll be able to finish the data transfer then).
Related question: am I correct in understanding that SATA drive order is dependent on which motherboard connector is used, i.e. to get the new SSD to become /dev/sda and ensure the existing 1 TB SATA drive is /dev/sdb, I'll need to connect the SSD to SATA0 (as well as updating fstab accordingly)? Currently, Kubuntu is on a PATA drive, which Kubuntu sees as /dev/sda (even though every other OS I've booted sees the SATA 1 TB as /dev/sda and the PATA drive as /dev/sdb) -- how can I ensure that the PATA drive gets pushed down to /dev/sdc after I'm booting from the SSD; will just correct fstab entry do that?
Problem is, when I boot to Parted Magic (June 2013 version, the last one that still runs on my Pentium II/288 MiB RAM laptop, hence the one I have in immediately usable form), I can't get the drive to stay connected even long enough to finish partitioning and formatting, never mind clone the data from my Kubuntu, Mepis, and shared home partitions to their future homes on the SSD. It seems to stay mounted fine in Kubuntu 14.04 (I did all the partitioning and formatting in KDE Partition Manager), but I can't transfer mounted partitions with a cloning utility (including KDE Partition Manager or gparted copy/paste partition); as I understand it, even dd requires that both partitions be unmounted when copying an entire partition (and dd at command line still makes me nervous; cross up just a little and you can clone your empty drive over your installed OS and not realize it until afterward).
This is on my Core2Quad system, with MSI P6NGML motherboard (about six years old, and not cutting edge then); the ports are, as far as I know, USB 2.0; every reference I've found online to problems like this appears to be with USB 3 ports, but I presume it's the same issue: the drive is powering down even while it's mounted on the Live OS I'm trying to use to clone the partitions, causing write errors that terminate (for instance) Clonezilla. The drive is a Transcend SSD340, SATA 300 256 GB (should be backward compatible with even SATA 1.0 controllers, right?) and the test connector I'm using is only about a year old, so ought to be at least SATA 2.0.
Complicating this situation is that only one of the two front panel USB ports works (I've never been able to get the single-connector wires for the other port connected in the proper order on the motherboard header; they're different color coding from the ones on the working port and the header pins might or might not be wired in the opposite order as well), and all my back panel USB ports are filled (and the wire tangle back there makes it a PITA to temporarily replace one of them); that means I can't readily boot Kubuntu from USB while the SSD is connected (I should be able to do so once the SSD is internal, so if nothing else works in a few days, I'll be able to finish the data transfer then).
Related question: am I correct in understanding that SATA drive order is dependent on which motherboard connector is used, i.e. to get the new SSD to become /dev/sda and ensure the existing 1 TB SATA drive is /dev/sdb, I'll need to connect the SSD to SATA0 (as well as updating fstab accordingly)? Currently, Kubuntu is on a PATA drive, which Kubuntu sees as /dev/sda (even though every other OS I've booted sees the SATA 1 TB as /dev/sda and the PATA drive as /dev/sdb) -- how can I ensure that the PATA drive gets pushed down to /dev/sdc after I'm booting from the SSD; will just correct fstab entry do that?
Comment