Hi all,

I finally decided to upgrade to an SSD, but I don't want to do a clean install onto it, I'd rather just migrate my whole system over to the new drive. I'm running Gentoo with linux kernel 4.1.18.

I made a new /boot partition and a new / partition on the SSD, both large enough to hold everything on the old drive. I rsynced everything with

and everything completed OK except for 5-6 errors due to xattrs. I no longer have those errors logged anywhere, but it was something similar to
I just ignored them and moved on.

I then mounted the new boot partition on the new root partition, mounted proc, dev, sys, etc, and chrooted into the new drive. In chroot I did grub-install and grub-mkconfig. Then I shut everything down and powered the machine off.

I unplugged the old HDD and powered it back on with the new one. Grub appeared, but as soon as it started booting I got a kernel panic. I don't understand how that could happen. The following are the only things that are different:

1. My root partition used to be a RAID0 array spanning two drives.
2. /boot used to be ext2 and is now ext4
3. / used to be ext3 and is now ext4
4. The corresponding changes were made to /etc/fstab

None of these should matter, since rsync just copied everything to the new partitions. I know grub works on the new drive. I know no hardware has changed other than the SSD, and I know the kernel is configured correctly.

Where could I have gone wrong? Should I double-check the grub configuration? Maybe I didn't have all the right rsync options? Some mysterious kernel configuration required to boot from an SSD (but not required to mount it for the initial rsync)?

I'm stumped. Thanks!

Did you ran grub-install & grub-mkconfig on the same SATA port which you used when trying to boot?

What panic code kernel indicates during the boot?

Yes. After shutting down, I left the SSD plugged into the same SATA port, but unplugged the old HDDs from their SATA ports. In /etc/fstab, I updated the UUIDs for the new partitions. Since grub did load, I assume the grub installation was fine. I do not, however, know if the configuration was still valid after removing the other HDDs, or if grub's drive/partition numbering might have changed. My understanding of grub has always been weak.

I didn't take a picture of it, but I can do that when I get home.

Let me know if you think of anything else. Thanks!

Grub installation is fine, however it may point to the wrong port.
I'd boot from live media and run grub-mkconfig (in chroot environment) ones more with unplugged HDD
.

Did you rsync from live media?

Is there any reason not to use Clonezilla for this task? About three weeks ago, I upgraded to a 1 TB Mushkin SSD and used option 2 in Clonezilla. All of the OSes booted up flawlessly. The original GPT drive had Windows 10, Fedora, Gentoo, Debian, Arch, and CentOS. Clonezilla cloned everything, including the swap space in less than an hour.

Yep, that did it. I unplugged the old drives, plugged in the new one, booted from an Arch live USB I had lying around, ran grub-install and grub-mkconfig again on the SSD, and rebooted. Booted up just fine.

I also just learned another tangentially-related thing that I never knew. My plan now is to take the old HDDs, format them and make new partitions, and use one for /home and one for backup. The new SSD just barely had enough room to fit all of / and the rsync completed fine. However, df -h now says:
As root, I can create or append to files, but as a normal user, I can't because the disk is full. Turns out that it's standard procedure for 5% of a disk to be reserved. In the event that a normal user gets out of control and fills a disk, there's still 5% left for root to use (http://serverfault.com/questions/315...-but-it-is-not).

Nope, straight from my installation running off the old HDDs.

Probably not. Clonezilla might be a better idea. I just like learning the more basic tools.

Thanks for the help, all! I'm going to mark this as solved.