So, I’m trying to clone an SSD to an NVME drive and I’m bumping into this “dev-disk-by” error when I boot from the NVME (the SSD is unplugged).

I can’t find anyone talking about this in this context. It seems like what I’ve done here should be fine and should work, but there’s clearly something I and the arch wiki are missing.

  • tal@lemmy.todayEnglish
    2·
    3 months ago

    I mean, if you want to start over, that’s your call, but in all honesty, my guess is that all you have to change from your current situation is a line of text in fstab. I don’t believe that changing the cloning method is going to change that.

    EDIT: maybe the UUID is for a swap partition or similar in fstab?

    EDIT2: This guy is describing a very similar sounding situation (though it’s not clear if he unplugged his original drive before trying to use his cloned one, so might have had duplicate UUIDs).

    https://unix.stackexchange.com/questions/751640/systemd-is-eternally-stuck-on-a-start-job-when-i-go-to-boot-from-my-cloned-to-nv

    He thinks that some users have “fixed the problem” by creating a swap partition with gparted.

    Multiple forums have had users with similar issues and they fixed it with a GParted-made Swap partition and adding that partition’s UUID to /etc/fstab like…

    That would, I expect, generate a new UUID for the swap partition via calling mkswap and then they’re putting the UUID into their fstab.

    Just saying that I’d personally do that, confirm that the UUIDs listed in fstab conform to what blkid is saying before starting all over, because I don’t think that dd or another utility for copying disk contents will likely produce a different result.

    • Dark Arc@social.packetloss.ggOPEnglish
      41·
      3 months ago

      Clonezilla just worked. The fstab is unmodified/identical to what dd gave me.

      I really have no idea what clonezilla did differently. Its output was so fast… But yeah, it just worked with that. So I guess I’ll take it.

      Absolutely baffling.

      • s38b35M5@lemmy.worldEnglish
        4·
        3 months ago

        Clonezilla runs lots of tasks after (and before) dd that are in the log file(s) on the live environment before you reboot. I haven’t used it in a while, but I’m confident that one of the tasks is updating grub

        • Dark Arc@social.packetloss.ggOPEnglish
          21·
          3 months ago

          I did update grub via a chroot as one of my troubleshooting steps… So I don’t think that was it either. I actually recall it saying something about skipping updating grub (because it was a GPT system without some special flag set I think).

          I remember seeing it do something to the EFI stuff explicitly and I’m wondering if maybe that’s where it did something I didn’t.

      • gencha@lemm.eeEnglish
        1·
        3 months ago

        Now that you know the safe way out, break it again with dd and figure out the difference 😁

        Moving from SATA to NVMe is a classic way to break the boot process. Most of the time, you want to boot a recovery mode from USB, mount your existing root and efi partitions, and then just reinstall grub.

        If you’ve managed to recover this way only once, you feel a lot more comfortable in the future if shit goes wrong.

        • Dark Arc@social.packetloss.ggOPEnglish
          21·
          3 months ago

          Most of the time, you want to boot a recovery mode from USB, mount your existing root and efi partitions, and then just reinstall grub.

          I did do that FWIW, but it didn’t do it/it wasn’t enough/it still didn’t work.

          If this was a toy system and/or I was back in college and feeling adventurous, I would definitely be more inclined to try and figure out what happened. As it stands, I just want the thing to work 😅