technology

you should be able to use the dd utility to make a byte for byte copy of the data to its new home.

You could do this, and it will work, and it is the fastest way to transfer data from one drive to another, but it is not the ideal way to go about this, for a couple reasons. Most filesystems contain metadata about damaged regions on the drive which will be incorrect when directly copied to a new drive. This won't break anything, but it can cause perfectly good regions of the new drive to be marked damaged when they aren't. Second, dd will do a dumb copy, without any kind of sanity checking. If there is any corruption in the current filesystem, or individual files stored within it, dd will happily duplicate this corruption without informing you (because it is only concerned with block devices, it does not even understand what a filesystem is).

When transferring a large number of files to a new drive, I recommend formatting the new one directly first. Allow the filesystem drivers / utilities to initialize the new filesystem on the new drive directly, in case they set any tuning parameters at this time. Then use a utility like rsync to transfer the files from the old filesystem to the new one. Instead of directly imaging the new drive, this will essentially have the filesystem driver walk the entire filesystem, and you will actually get warnings about unreadable / corrupted files, checksum mismatches / etc. encountered along the way - which is a very nice to know before overwriting the old drive and eliminating recovery options.

I have been hit by bit rot like this in the past. I have a large music library with many infrequently accessed files. The type where undetected corruption could lie dormant for years. A small handful of them were corrupted, but I only discovered this when attempting to copy them to a new drive. dd would have missed this. Not a tragedy or anything, but it was news to me!

@tactical_trans_karen@hexbear.net

Any software recommendations for the migration?

Even though it has been a while since I used Fedora personally, I like to keep a Fedora installation USB handy for stuff like this. You can boot it to the desktop, cancel the installer, and as long as you have an internet connection, you can install tools like gparted (a very useful GUI partition table editor) and efibootmgr (needed to create / delete EFI boot entries. Often needed if you move the ESP, or if your UEFI firmware thinks it moved because the drive numbering changed). The rest are more-or-less common utilities like mkfs / dd / rsync / cp etc With a "LiveUSB" installer like Fedora, all this can be done from the comfort of a desktop environment with the ability to copy/paste text and inspect which files are where, and access the internet for documentation / advice. Bear in mind, gparted is more-or-less specifically a partition table editor. It can also do some things like move / resize filesystems, but this might require you to install additional utilities for that filesystem, and even still many of these more advanced functions are not supported beyond simply formatting the filesystems. It won't do higher level stuff like move files from one drive to another.

I'm afraid of breaking GRUB (or whatever boot loader Fedora uses).

It's good to know a little bit about how this works. There are two common PC boot mechanisms - BIOS and UEFI. BIOS is obsolete and Microsoft has mandated UEFI since Windows 7 I think (it still supported BIOS, but vendors couldn't ship with that setup). I'll assume you have a UEFI setup. There should be one "EFI System partition" (ESP) which exists on the drive you're least likely to discard. Ideally the 2TB m2 in this case. The ESP is formatted FAT32 and has a couple extra flags set in the GPT partition table (you can see these / toggle them in gparted). A lot of installers will make this small, like 1GB, but I recommend making it a bit bigger - maybe 4, or 10GB.

In the ESP, you can install an arbitrary number of boot loaders - GRUB being one of them, the Windows loader being another. These can typically be restored in the case they are deleted (though I don't know how to do that on Windows). They might have a handful of extra configuration files lying around with them (GRUB usually has a configuation file of its own), but as far as the UEFI firmware is concerned, it is only looking for an ELF executable to load and transfer control to. The canonical default is located at \EFI\BOOT\BOOTX64.EFI but OS installers will create additional entries pointing to executable files located in their own directories within the ESP. Some Linux distributions will also put kernels here, which can either be booted directly by the UEFI firmware, or to allow the OS to be loaded from exotic filesystems not directly supported by GRUB (sickos like me who have root on bcachefs, or people who have root on a RAID or LVM logical volume). You can access these entries and boot them directly from your UEFI firmware, in addition to adjusting the boot priority.

When installing the OS (or simply installing a bootloader like GRUB), this is managed automatically, but in the case the ESP changes locations, or these files are moved, these entries (stored in "EFI variables" in the motherboard's EEPROM) need to be updated manually. This is what efibootmgr is for. If, after moving things around, the machine doesn't boot properly, don't panic. These things can usually be repaired. Also, the ESP is relatively easy to create a back-up of. It is a small, dumb filesystem with no ownership or permissions or symlinks or any other sneaky shit to screw you up. Just copy the files onto a thumb drive or something.

Is there a simple way to just migrate both OS's exactly as they are?

I can't speak for Windows, but for Linux the operation basically entails copying the files to a new filesystem (ensuring group/user IDs, permissions, symlinks, timestamps, attributes etc. are preserved. In other words, using the --archive parameter of either cp or rsync, NOT simply dragging and dropping the files in a file browser), chrooting into the new filesystem, updating /etc/fstab if neccessary (likely), and then running grub-install, grub-mkconfig (with appropriate parameters) to update the boot loader.

Anyone know the order in which to proceed with this?

What I would do (bear in mind, everyone's situation is unique, and this might overlook something which is important for you but not for me) is this.

Grab whatever precious files live on Windows and back them up. If you are too lazy to do a proper backup (like me), copy them to the Linux filesystem which we're trying to preserve / duplicate.

If the ESP is already on the 2TB m2 drive, leave it alone, if it isn't, create one there along with your new Linux partition(s). Make SURE you are operating on the correct drive. Quintuple check this! In the past, it has been recommended to split Linux into several partitions - particularly to have a separate /boot and /home, but with filesystems like btrfs which support subvolumes, having one big filesystem with multiple subvolumes is more flexible. You don't need to worry about allocating 500GB for root and only needing 150GB in practice.

Copy the Linux files to the new filesystem (taking care that they go into the correct subvolumes / individual partitions if you're using them). Deliberately mount the old filesystems READ-ONLY to mitigate the potential for disaster. We should ONLY be copying files at this stage.

Turn off the machine, remove the old Linux drive, boot back into the Fedora installer, mount the new filesystem, chroot into it, and do the boot-loader install / configuration steps. Ensure it boots. Troubleshoot it until it boots. Once it boots, ensure everything is good and proper. Only then, plug the old drive in and proceed to the additional destructive steps. I would just install Windows fresh and, finally, format the left-over 2TB (the old Linux drive) as storage only once you've triple-checked everything made it to the new filesystem(s).

When you install Windows, it will replace GRUB as the default UEFI boot entry, but both bootloaders will be installed alongside one another, and you can switch the boot order either in your UEFI firmware (path of least resistance, usually), or using a tool like efibootmgr to make GRUB the default. At this point, GRUB might not have an entry to boot Windows. This can be fixed by running grub-mkconfig one more time, which will detect the new Windows install and include it in the updated GRUB configuration.