My Objective:
Repurpose an obsolete OS Filesystem as pure data storage, removing both the stuff only relevant for the OS and simplifying the directory structure so I don’t have to navigate to <mount point>/home/<username>/<Data folders like Videos, Documents etc.>.

I’m tight on money and can’t get an additional drive right now, so I’d prefer an in-place solution, if that is feasible. “It’s not, just make do with what you have until you can upgrade” is a valid answer.


Technical context:

I’ve got two disks, one being a (slightly ancient) 2TB HDD with an Ubuntu installation (Ext4), the second a much newer 1TB SSD with a newer Nobara installation. I initially dual-booted them to try if I like Nobara and have the option to go back if it doesn’t work out for whatever reason.

I have grown so fond of Nobara that it has become my daily driver (not to mention booting from an SSD is so much faster) and intend to ditch my Ubuntu installation to use the HDD as additional data storage instead. However, I’d prefer not to throw away all the data that’s still on there.

I realise the best solution would be to get an additional (larger) drive. I have a spare slot in my case and definitely want to do that at some point, but right now, money is a bit of a constraint, so I’m curious if it’s possible and feasible to do so in-place.

Particularly, I have different files are spread across different users because I created a lot of single-purpose-users for stuff like university, private files, gaming, other recreational things that I’d now like to consolidate. As mentioned in the objective, I’d prefer to have, say, one directory /Documents, one /Game Files, one /Videos etc. on the secondary drive, accessible from my primary OS.


Approaches I’ve thought of:

  1. Manually create the various directories directly in the filesystem root directory of the second drive, move the stuff there, eventually delete the OS files, user configs and such once I’m sure I didn’t miss anything
  2. Create a separate /data directory on the second drive so I’m not directly working in the root directory in case that causes issues, create the directories in there instead, then proceed as above
  3. Create a dedicated user on the second OS to ensure it all happens in the user space and have a single home directory with only the stuff I later want to migrate
  4. Give up and wait until I can afford the new drive

Any thoughts?

  • @Deckweiss
    link
    15
    edit-2
    5 months ago

    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.

    • @[email protected]OP
      link
      fedilink
      25 months ago

      I feel like you are overthinking this

      Yes, most certainly, but given my own inexperience I figured I’d rather overthink than fuck up because I didn’t know about some detail.

      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.

      Fairly sure the boot partition is on the new SSD, but I’ll check and leave it untouched if I’m not sure.

      Thanks for your advice!

  • LostXOR
    link
    fedilink
    45 months ago

    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).

  • @[email protected]
    link
    fedilink
    35 months ago

    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.

  • @[email protected]
    link
    fedilink
    English
    25 months ago

    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.

    • @[email protected]OP
      link
      fedilink
      25 months ago

      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.

      Yes, the new drive has a boot partition mounted to /boot/efi, according to the Disks utility.

      It’s not clear what issues you’re worried about, but if you’re nervous about breaking the Ubuntu installation[…]

      Actually, that’s a good point. I’m expecting to get rid of the installation anyway, so I don’t need to worry about breaking anything there.

      It’s not clear to me what the goal of option 3 is

      Same as option 2, avoiding breaking a system I’m getting rid of anyway.

      Thanks for pointing out the errors in my line of thought!

  • boredsquirrel
    link
    fedilink
    2
    edit-2
    5 months ago

    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.