New SSD drive. Copied files from old from new drive. Of course, things go sideways. Now have non-booting system.
(Did you know that the DD command also duplicates the UUID of one drive to the other, resulting in you having two drives with the same UUID after reboot? I didn’t! Fun! Disaster! Ruin!)
Depending on what EFI file I point the motherboard at, I either get GRUB halting with a “can’t find @/boot/grub2/…” error or I can get past the GRUB menu but the system just hangs with no progress and no disk activity.
I have painstakingly checked and re-checked that the new drive UUID is updated everywhere I think I should be updated.
The OpenSUSE FSTAB uses “subvol=@/…” lines which I don’t understand. Do I need to create these BTRFS subvolumes manually?
Yes, I knew that. The “dd” command copies everything in the partition, which includes the UUID.
Your problem is likely because both disks are present at the same time. The UUID is supposed to be unique, but in this case it isn’t.
You might want to check whether there is a “btrfs” command to change the UUID. I’m not using “btrfs”, so I haven’t checked that.
Have you tried removing the old drive? Or removing the data cable for the old drive, so that it isn’t visible? It might at least be worth testing if that allows booting.
The OpenSUSE FSTAB uses “subvol=@/…” lines which I don’t understand. Do I need to create these BTRFS subvolumes manually?
If you used “dd”, the subvolume structure is also copied.
I’m not sure where you want to go with this. If you really want to use both disk and keep the duplicate UUIDs, then you should change all references to use the device-id or device-name of the one that you want to boot. And that might require recreating the “initrd”.
Do not do it with btrfs. It does not care about device name, it identifies file system by on-disk information. In this case both devices will appear identical so it is unpredictable which one will be picked (do not forget that on boot devices are scanned asynchronously). Actually you probably will not be able to mount second copy at all, but you may also corrupt filesystem under some conditions.
Never ever let two devices that are clones of the same btrfs be present on a system.
copies that file to the other file block by block (using cp in this case would be more appropriate imho).
And:
dd if=/dev/sda1 of=/dev/sdd3
copies the whole partition, including a file system that may be on it and thus including a volume label in that file system if there is one.
And:
dd if=/dev/sda of=/dev/sdf
copies all the contents of the mass-storage device, including the partition table (when there is one) and all the partitions (or just what might be called "empty space by one who knows more about the contents of the device).
And combinations of the “type” of input and output are also valid:
dd if=/dev/sdb1 of=/data/clone-of-sdb1
creates a file with all the blocks of the partition (when there is space enough). This (and all cases above) thanks to the rule “in Unix everything is a file”.
dd has no knowledge about any structure that may be present in what it copies. It only copies blocks. This is popular known as “cloning” and you nor the system can tell the difference between the two clones.
Ding! Winner! This is exactly what happened. On BOTH drives.
Fortunately, I have backups. I re-formatted to BTRFS the partition on the new drive where OpenSUSE goes. I copied all files from the backup. But now I am having the hang problem I described, above.
Do I need to re-make those “subvolume” references named in FSTAB? If so, how?
Just part of file name. File name is literally “@/boot/grub2/x86_64.efi”. So you must have exactly the same file hierarchy. I think it is created as subvolume by installer.
You can simply boot from live media and reinstall bootloader, it may be more simple. But I am not sure how deep various openSUSE tools are tied to this convention (i.e. will they correctly work without this top-level “@”).
I have to say that it’s very discouraging and frustrating that even after keeping regular backups on multiple drives, the effort is still pointless. If a person can’t copy their backup to a new hard drive and get working again, what’s the point?
The OpenSUSE installer is quite nearly useless for help. It only offers options: “Installation, Upgrade, and Rescue System” All that “Rescue System” does is provide a CLI. I tried “Upgrade” but it can’t even recognize that I OpenSUSE is already on the drive.
I need to understand this “@” in the path to x86_64.efi. Is this in the grub.cfg somewhere? Why is it there and why is the path not just /boot/grub2/… ?
If you are going to use dd to backup you must understand it. doing a partition by partition backup may not work depending on which way the drive is partitioned ie MBR or EFI
for MBR using grub code you need at least the first 1 meg of the first track to assure getting all the stuff you may need
Maybe best to use a more friendly tool like clonezilla to backup.
Personally I don’t worry about the system and only back my data. system can always be reinstalled
This stage is behind us now. Both volumes were destroyed because of the duplicate UUIDs.
Personally I don’t worry about the system and only back my data. system can always be reinstalled
… except for all your addititional software, your settings, your configuration, your fine-adjustments and work-arounds, plus hours of wasted time …
Fortunately, I keep /home on a separate hard drive and all that was destroyed was the OS. But I’m baffled as to why after copying all the backed-up files I cannot get it working.
When reformatting to “btrfs”, you should have made all of the subvolumes. I’m not sure of the details on how to do that.
And then you should have mounted all of the subvolumes before copying files.
I’m still using “ext4”. I tried “btrfs”, and it seems to allow me to do a lot of things that I have no interest in doing, while making it harder to do what I am interested in doing.
A correction. The error message is wrong and confused me. It is not a FILE that the error is about, it is a directory and the path is “@/boot/grub2/x86_64-efi” Note the difference: DASH efi not DOT efi
Nevertheless, that directory x86_64-efi does exist, except for the strange “@” which I am trying to figure out.
All personal setting are in /home Most if not all system settings are in /etc. You lose only installed programs which only takes minuets to restore if you miss a few either you don’t need them or you can add on the fly.
Not at all sure why you changed file systems in the middle of trying to restore. It just adds to the confusion.
Ah - what I meant was that I erased the hosed partition back to a clean, empty one. It was BTRFS before (the OpenSUSE default) and that’s what I formatted it to again.
Does anyone know how to fix the BTRFS subvolume issue? There are no examples in any BTRFS guide I have read.
What is the “@” for? Is that required for naming subvolumes?
Why does the OpenSUSE fstab file have multiple lines pointing a real directory to a subvolume of the same path? Why not just use the directory … ??? I don’t undstand what these subvolumes are supposed to be for or why this “@” is appearing in the GRUB error message.