Announcement

Collapse
No announcement yet.

Cloning boot disk to new Samsung 860 EVO 1TB SSD

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by steve7233 View Post
    Ok, I finally got a working system. It seems if you have a BTRFS system then cloning to SSD doesn't seem to work. It looks like Grub II won't install to a BTRFS system if it is on an SSD. I did a fresh install of 19.10 using ext4 instead of BTRFS. The installer crashes when Installing Grub II to BTRFS on an SSD. It didn't crash using ext4. It still wouldn't boot but it seemed to be trying too. I thought maybe the CMOS is getting confused. I entered setup and pushed thee SSD to the top of the boot list and tried again... VICTORY.
    I'm glad you got it working but some of what you're saying here doesn't make sense to me. It would help if you had posted the actual error messages and what you actually did instead of just a general description, but here's the sources of my confusion;

    1. "Cloning" means bit-for-bit duplication of a partition or drive. The file system on it has no impact whatsoever. In fact, the content of any file systems and even the partition table are not exposed to the cloning tool - point being either the cloning worked or it didn't, file system is of no consequence. I use Clonezilla all the time and we clone entire drives with multiple partitions and different file systems. Using dd also wouldn't expose the file system to the tool because its a bit-for-bit copy just like Clonezilla. If you were trying to copy a file system rather than actual cloning the results could be different, but assuming you were using BTRFS in subvolumes as intended, there's no need to use an external tool to copy, simply send the subvolume to the target file system or join two BTRFS file systems together and transfer the entirety of the data from one device to another. This is actually one of the major benefits of BTRFS over EXT4.

    2. GRUB doesn't really "install" to any file system. It installs data into the Master Boot Record (MBR) or partition boot record and copies files to any supported file system for later use. This part installed to the MBR is referred to as "Stage 1". Grub-install writes the stage 1 data into the MBR. If you use GPT instead of MBR, grub needs extra space because the GPT boot record doesn't have enough space for stage 1. This amounts to a few kilobytes but has to be pre-configured before installation. The remainder of grub exists as files in /boot/grub and GRUB supports BTRFS just fine and has for many years. My 6 different bootable SSDs with only BTRFS on them (no EXT4 partitions at all) confirms this as a fact. If you look into /boot/grub/i386-pc/ you will see all the "mod" files that GRUB uses. BTRFS is there along with EXT2, FAT, JFS, XFS, and even ZFS. AFAIK the only configuration of BTRFS that GRUB won't boot from is a multiple device BTRFS file system due to necessary system files not being available to GRUB at boot time, or a whole-device BTRFS file system because no Boot Record or partition table exists on such a device.

    3. Finally, SSD vs. HD: I know of no discernible difference to any file system or installer. The underlying physical part (magnetic platter or silicon chip) of either device is not exposed to any file system or even the BIOS. They both only interact with the drive controller built into either drive via the drive interface (i.e. SATA). As long as your BIOS and file system have drivers that can access the controller, they can access the storage on it. A great example is solid-state hybrid drives. The drive itself has both an SSD and a Hard Drive in a single unit that the BIOS and operating system see as a single device.

    My point to the above is that I feel your conclusions about what caused your difficultly are not accurate or technically correct. I feel, as a source for technical information, the forum should try to be as technically accurate as possible. This is why error messages and details about actions taken are extremely helpful.

    Regardless, glad you're up and running.

    Note re. Clonezilla; if you use Clonezilla in "partclone" mode it will address the file system if supported and only copy sectors containing data to speed up the process. If the file system is not supported, it reverts to dd for a full bit-to-bit copy. BTRFS is one of the dozens of file systems supported by Clonezilla.

    Please Read Me

    Comment


      #17
      Well then the only thing I can think is that the kernel needed something but the old system used the same kernel so that just makes it more of a mystery. Could it have something to do with the fact that the old drives were very old? Maybe something got depreciated. I think I remembered seeing something about a missing dependency when trying to boot the old system via rescue mode. That's one reason for replacing it as the boot drive was starting to fail to boot every once in a while.
      Just to remind users and devs that Ubuntu and its flavors have a long way to go to be as usr friendly as they should be.

      http://www.kubuntu.org/getkubuntu

      Comment


        #18
        I found this Clonezilla tutorial simple and helpful.
        https://www.youtube.com/watch?v=JflYnwe8cTE

        With every computer I buy, I also buy a new SSD. (The Samsung EVOs are excellent, as are the WD Blues.) The first thing I do is clone the existing hard drive. I then remove it, store it in a safe place, and install the new SSD. If I'm really energetic, I'll also clone an image to an external hard drive. I think of this as buying "insurance" in case I screw something up, which I do with some frequency as I can't seem to leave well enough alone.
        "Strange memories on this nervous night in Las Vegas."
        Hunter S. Thompson

        Comment

        Working...
        X