A Layman Learns Linux - Fedora, Formatting, and File Systems
Installing Fedora was a breeze, but formatting and mounting my new hard drive was a laborious affair that required me to read up on Linux filesystems!
In the previous installment, Fedora Linux immediately became the frontrunner for my new daily operating system. I was already familiar with the KDE interface from my time with the Steam Deck, and the handful of important settings that were obfuscated in Mint were now easily accessible. I was riding high and loving Fedora...until I tried to format my first new hard drive.
Part of my issue was that I did not yet understand how the Linux filesystem was organized. This fundamental hierarchy was common to all Unix-based operating systems, and learning the basic concepts was going to be crucial for my next steps.
As a brief disclaimer, this installment is going to feature a lot of jargon, but I'm going to do my best to explain these complex topics—many of which I still do not fully understand—by focusing on the information that is most important for fellow beginners who may also encounter issues with navigating a Linux file system and/or working with hard drives.
1) Drive and Partition Labels
First, I had to read up on how drives and folders/directories actually work in Linux (I'm going to be using the terms folder and directory interchangeably since they are pretty much the same thing: a place that holds files and additional folders/directories). This was crucial because of how Linux treats physical drives. The Fedora file explorer, Dolphin, displayed all of the drives in my PC (whether mounted or unmounted), and they were labeled with their standard friendly, front-facing names. The main OS drive was automatically named Fedora, while all of my Windows drives still had their old names.
The key difference was that, unlike Windows, each drive was not assigned its own individual letter like C:\, D:\, etc. On a system level, each drive was referred to by a device ID that denoted its slot on the motherboard. This identifier included /dev/ (or device) and then the socket name. Fedora was installed onto an NVME SSD at slot 1, so the system internally saw it as /dev/nvme1, while my new drive was plugged into SATA slot 4 was /dev/sdd (for SATA drive, slot D). This wasn't a permanent ID written to the drive, just a temporary label based on where it happened to be plugged in. We'll get into the drive's unique identifier later on.
Furthermore, it turns out that the partition(s), or the major block(s) of data on the drive, were more important than the physical drives themselves, to the point that Fedora treated each partition as a distinct device. I quickly used the lsblk (list block devices) command in the terminal to list out all of my drives and partitions, then I eyeballed the list to find which partition I was going to be working with on my new drive. I found the 3.6Tb partition at /dev/sdd1.
 |
| Wouldn't it be funny if I formatted the wrong 3.6TB drive? |
2) Mounting Partitions in the Linux File System
What then took me a while to understand was that device ID is not, technically speaking, the drive's location within Linux, just where it is on the motherboard. /dev/ exists as a directory in the OS, but is not meant to be accessed like a normal directory. This Reddit thread contains a great explanation for why that is (though I did have to read it very slowly). This meant that I wasn't going to be actually entering and doing anything within /dev/. So where do I access my drives?
This required me to shift my perception of how files and directories can be organized by an operating system. Here's a quick example: on Windows, I stored all of my music in the Music folder on my D:\ drive; thus, its permanent address was D:\Music. From anywhere in the file explorer, I could click My PC, Files (D:), then Music, and boom—done.
Linux was very different because of how it unites all drives and directories under a single system hierarchy/tree. At the top is the root directory, located at the address /. Everything is nested underneath that, not separate from the OS like on Windows. The relevant piece of information here was that all additional drives/partitions are, by default, mounted and accessed under /run/media/[username]. Thus, when mounted, each drive should be accessible by starting at the top, or /, then double-clicking run, then media, then the device ID.
What made this confusing was that Dolphin, KDE's file explorer, showed all of the physical drives on the left pane, similar to what one would find in Windows. When simply hopping back and forth between drives with the mouse, the user experience was almost identical to what I was used to as a lifelong Windows user. However, I wanted to do anything with a drive that didn't involve just clicking my way to a particular file or directory—such as giving the OS or any application information on how to access the drives—I would need to know the drive's current location in the file system, which could actually be freely changed. I told you that I had to do a lot of rethinking during this process!
 |
| Despite the fact that the Places and Devices on the left resembled the way that Windows's file explorer displayed the same items, the actual locations of those directories in Linux was more complicated to determine. |
As hinted above, it turns out that drives aren't technically the things being mounted; it's the partitions on the drive, and these could be mounted almost anywhere that was user accessible. Thus, I should be able to freely mount my new drive, /dev/sdd1, at a location of my choosing. There was already a /mnt/ directory, intended for permanently mounted drives, so I made a new folder in there called Files. The command to mount my new storage partition to this new Files directory was pretty simple: Super User Do mount [device ID] [desired directory]. This is what I typed into the terminal to execute that command:
sudo mount /dev/sdd1 /mnt/Files
This would map the drive's contents to /mnt/Files so that manually navigating to that directory (/, then mnt, then Files) and double clicking it would simply display all of the folders and files available on that drive. The /dev/sdd1 label was not even mentioned in the address bar.
3) Setting Permissions and Mounting on Boot
I had to make myself the owner of the drive and give myself permission to read and write to the directory and all directories inside it, in case that somehow didn't come by default. In the terminal:sudo chown -R Alex /mnt/Files
chown was the command for "change own", and the -R flag (short for Recursive) ensured that all files and directories within /mnt/Files would also be included. To have this drive automatically mount upon boot (as opposed to having to manually mount it and enter my password every time the system restarts), I needed to add the directory the delightfully named fstab, a simple text file whose name is short for “file system table”. This is what the OS reads on boot to determine which drives should be automatically mounted and where.
 |
| These were the default entries in the fstab file, before I started mucking around and adding drives. |
I first looked up my new partition’s UUID (Universal Unique IDentifier) using the blkid (Block IDentification) command:
sudo blkid /dev/sdd1
The console spit out a string of 32 alphanumeric characters which presumably comprised the partition's UUID, so I tracked down the fstab file in the /etc/ directory and added this line to the end:
[UUID] /mnt/Files ext4 defaults 0 0
This told Fedora which specific device to mount (regardless of device ID), its intended mounting location, the partition format, and then a bunch of default settings that I honestly did not research further.
4) Final Troubleshooting
At long last, the drive was fully operational and set to automatically mount on system boot! The final step was to copy all of the data from my external drive to this new internal drive, which I let run overnight.
The new drive worked well for a while, but my good fortune was short lived. One day, it would mount just fine, and then the next, I would receive Input/Output errors when trying to play music from the drive. I removed the drive from fstab and started mounting the drive manually upon boot. That worked for a while, but then, upon trying to use the e2fsck command to check and repair errors, something about a bad superblock came up.
What is a superblock? As best as I can understand, it's a sort of 'header' for the drive that can be found on each platter's first block. It contains some kind of important indexing information. If that was corrupted, then I could probably recover it from one of the other dozen copies. This 15-year-old blog post was linked in many threads on the subject. I followed the instruction and tried the command with every single backup superblock. I got the same result each time. Maybe it was time to start from scratch.
 |
| I wonder how this guy/gal feels about this post being the most commonly cited resource on this topic... |
I opened KDE Partition Manager for simplicity's sake and tried to overwrite the existing volume. Error. restart and try again. Error. I even booted back into Windows for the first time in days for a few last-ditch fixes. The first was to update the BIOS, which was only about a year out of date. No change. My second and final idea was to run a chkdsk to confirm whether or not the disk was truly toast, but no problems were detected. To make the situation even more maddening, Windows even proved capable of reformatting the drive as ExFAT. How could this brand new hard drive work perfectly fine in Windows but not in Linux?
I was about to give up when I remembered the first rule of tech troubleshooting: turn it off, then turn it back on. I did just that, hopped back into Fedora...and the drive was detected! I was able to create a new partition table! The drive accepted a new ext4 partition! This was unbelievable. I gleefully started copying folders over one by one, incredulous. My massive music folder would once again have to be an overnight job, but when I awoke the next morning, it was all there, with proper read and write permissions to boot (pun fully intended).
What changed? I couldn't tell you, but I suspect it was the combination of the BIOS update, which may have helped if the SATA controller was the issue, and the power cycle, which might have reset something that a simple restart could not. Either way, it felt great to be cooking with gas once more.
The last step was to add the drive to fstab (again) and restart to see if I would finally have a functional drive for all of my data automatically mounted after every restart. Lo and behold: there it was, mounted to /mnt/Files and accessible by my media players, office suite, and other apps. I almost fell to my knees. My Fedora setup was finally complete.
* * *
I wrote those last two paragraphs about two weeks ago. I'm quite content with Fedora as my daily driver, though there is still much for me to learn. Future updates will likely be much briefer (and potentially less frequent). With that said, I have a couple small projects coming up that should be interesting, such as using scripts to set up automatic backups and getting my existing printer/scanner working. We'll see how those turn out!