Linux

I feel like you are overthinking this.

Option 1 is what I would do. Seems very straight forward. And additionally:

Moving files around or deleting files is a very quick operation, because the filesystem will only edit the "metadata" and not have to copy the whole file bit by bit to a different disk.

Maybe delete the OS files first (everything except /home). So it's not cluttered from the start. Then copy stuff from /home/user/stuff to /

Take special attention to the /boot partition. I don't know which drive the bootloader for your nobora os is installed. It may have been automatically put together with your Ubuntu to your HDD.

Whatever you do, make sure you have a backup! There's always the possibility of screwing something up, no matter how careful you are (or your hard drive deciding to spontaneously self destruct).

Hi.

I have been through a drawer full of old drives of mine and a different drawer full of other people’s old drives that need tested/securely erased/parted out this summer so my instructions might be a little more “foolproof” or seem to have extra steps but here’s how you do what you wanna do:

Plug up the drive

Run “lsblk “ to show all the drives and their file systems. Use the information shown to both recognize your target drive and determine what partitions and file systems are on the drive. Once you recognize your drive, take note of its device name in the format /dev/sdx.

Run “ls -l /dev/disk/by-id/ |grep sdx”, but replace sdx with your drives device name. This will list the drives in the system named for their model and serial numbers and show what devices in your operating system they correspond to. Piping the output through the grep command with “sdx” will only return the one that is your target drive. Take a picture of this with your phone or something. It’s probably too long to remember.

Now do the same thing but in /dev/disk/by-uuid, so “ls -l /dev/disk/bu-uuid | grep sdx”. This will show you the uuid of the file systems on the partitions of your target disk. Uuids are unique identifiers for file systems and will be important later.

Now you need to figure out what the different file systems on your target drive are. This part’s easy, just make a directory in your home folder, it doesn’t matter what it’s called. “mkdir nostromo”. Then make a set of directories in it corresponding to the different file systems you saw in the output of the uuid command. “Cd nostromo” “Mkdir sdx1 sdx2 sdx3 etc”. Do a quick “ls” just to make sure you made the right directories. Refer back to your picture of the uuid output to be sure you made directories for em all.

Now you’re just about to go into the file systems of the drive and confirm what they are and make a plan to extract the payload, but first take a minute to make some assessments about what you have without actually getting your hands dirty: look at the output from lsblk. You can run it again no problem. How many partitions are there on the drive? How big are they? When a partition shows about 100MB in lsblk it’s probably a boot partition. If it shows about 1KB it’s probably a container for other partitions and you don’t need to worry about it. If it’s about the size of your ram or smaller then it’s probably a swap partition (although I think Ubuntu doesn’t use these by default).

Now let’s go in and see what each one is. Start at the lowest numbered one and “mount /dev/sdxN nostromo/sdxN”. You might have to use sudo to do that. Then “ls nostromo/sdxN/“

If you see stuff like “initrd “ or “kernel” it’s probably the Ubuntu boot partition and you won’t have anything to worry about in there. If you see “/root” and “/home” and “/bin” then that’s the Ubuntu root partition and thats pretty promising!

Lather, rinse, repeat till you know what all the file systems of your drive are. Some advice: don’t worry about the 1k container partitions. They’re just there to get past the four primary partition limit. If you mount your old systems swap partition, you won’t be able to browse it with “ls”. Just confirm its swap by running “cat /proc/swaps” and looking for the one you just mounted. Unmount it with “umount /dev/sdxN” just like you mounted it.

Once you have an idea of where your files are, unmount the file systems you’re not worried about with “umount /dev/sdxN” and get ready to find your files on the partition(s) they’re in.

Go into the nostromo/sdxN folders that correspond to the file systems with files you wanna get with “cd nostromo/sdxN” Make a folder called “old” with “mkdir old”. Make sure you’re in the nostromo/sdxN folder you wanna be in with the “pwd” command. If it returns the one you expect then you’re good. Move everything in there into the “old” folder with “mv * old/“. That will error out when it tries to move the “old” folder into itself but now the contents of that drive are in the old folder.

From here you can use terminal or gui tools to move files from the directories in the “old” folder to however you want it organized in the root of the file system. Maybe you want a folder called “recovered” with unsorted swaths of information inside it. Maybe you wanna painstakingly sort things out by media type. The file system is your oyster. When using gui tools sometimes you’ll be asked if you wanna move or copy the files. Move is what you want.

Lather rinse repeat for all the file systems you think have stuff you care about.

Once you found and moved your files, look again tomorrow. You might find more!

After you’re absolutely sure you got em all, delete the old folder with “rm -r old/“.

Once you’ve done that for all the old file systems with files you want on em, see if you can’t consolidate them together in one file system. If you can then delete the file systems and partitions you don’t need and expand the one you plan on using.

Once you’re ready, use the saved partition as a data drive by adding it to your /etc/fstab using the uuid from earlier. A perfectly acceptable mount point is /mnt/data. That will make sure your operating system knows how to find it and mount it every time the computer boots up.

Depending on the DE you use on Nobara, use GNOME Disks or KDE Partitionmanager and just open that thing and look at it.

It may have several partitions you dont need anymore, and /home is separated, containing all your users.

In that case you could just delete the others and resize the home partition to fit the contents.

If you have a / partition, you can still remove the /boot and /boot/efi and maybe swap partition. Then resize the root partition to fill all the space.

You need to mount the disk in your filemanager and use admin:/ to open it with privileged access.

Open a terminal and navigate to /run/media/USERNAME/DRIVENAME

In there do sudo chown -R USERNAME *

Then after you broke everything an OS would need but that you want, move the stuff from the homes to your root folter from the GUI filemanager. Move, not copy.

Afterwards you may want to do some ext4 repair magic, as I dont know how well ext4 likes messing around with partitions.

You haven't provided any info about your partition scheme for either drive, but I assume you've got your bootloader installed in an EFI partition in the newer drive. You will still have an EFI partition on the old drive created by the Ubuntu installer, so just be sure you know which bootloader you're using.

Option 1 and 2 aren't functionally any different. It's not clear what issues you're worried about, but if you're nervous about breaking the Ubuntu installation, you might just want to wait until you can get the new drive.

You also don't give any indication of how much data you have that you want to keep. If the 2tb drive is almost full, you have fewer options than if it is mostly empty or half full. You could resize your EXT4 partition and create a new partition, for example, allowing you to mount a fresh, clean filesystem to a subfolder in your home directory. Once the data migration is finished, you can format the old partitions and mount them somewhere else, or resize the newer partition over them. Be aware that your HDD will eventually fail mechanically, however. Maybe 5 years from now or next week, but they all fail someday.

It's not clear to me what the goal of option 3 is, but it's dependent on how you use your machine. If you want to install a lot of applications or games that you want to run fast, you don't want to migrate a bunch of your data to your newer SSD. If you just want a temporary place to store the data you want to keep until you can format the old drive, I guess this is a fine approach, but creating a dedicated user for this is just adding unnecessary complexity, IMHO.