explore the disk layout for the head-start: examine how the HDD is divided into partitions
explore the disk layout for the head-start: examine how the HDD is divided into partitions
Here’s a rephrased version of your message:
Hey everyone, I’ve got a brand new and clean HDD installed in my laptop, and I’m planning to install EndeavourOS (the latest version, probably released in February). Since I don’t have much experience with Linux file systems, I thought it would be helpful if someone could recommend the best option.
On my notebook, I’m trying to keep things organized while working on programming projects. That’s why I need to install various external packages, like VSCode, Jupyter, and other tools. Each of these usually takes up around 300 MB or less. I also store a lot of music, photos, ebooks, and office documents—including package documentation. I often download files and manuals as PDFs.
I’m curious about how to manage all these files if I only have three partitions: / and /home. Wouldn’t that make things look cluttered? If I were using a notebook partition, I’d like some tips.
Also, I’m not very familiar with formatting storage drives from the terminal. It would be great to learn how to do this myself. I’d love to understand the steps, commands, and options so I can use them effectively in the future.
Specifically, I want to know:
- How to format a drive using terminal commands.
- Which file systems are common (like NTFS, FAT32, EXT4)?
- How to partition the drive via terminal.
- How to set up a high-capacity external HDD from the terminal?
Any advice or guidance would be really appreciated!
That's a bold choice for an OS drive. You sure you want to do that? There really should only be three partitions: EFI/boot, swap, and primary. You *do not* touch those first two. The third is where you store all your data. If you absolutely must separate the OS from the data partitions, you can, but very not necessary. The messiness of file storage is mostly down to how well you lay out your directories. Keep stuff organized and it's not messy. https://man7.org/linux/man-pages/man8/parted.8.html
regarding your inquiry: the boot partition concept is similar to Windows, but with a different bootloader setup. It can be optional depending on your RAM setup. The home partition is useful for safety, though not mandatory. With modern snapshot and backup tools, splitting it from the main drive isn't always essential. The main idea is how you manage your data and storage inside your home folder—essentially like the "c:\users\YOUR_USERNAME" directory in Windows. After setting this up, it's wise to use another drive for backups or snapshots. In short, what you need depends on how you handle your files and storage today. If you're new to Linux, starting with Ubuntu can be a good way to get started—explore the folders and follow the guide provided.
Be mindful of how you describe "a boot partition." When UEFI supports /boot, it's not required to keep it separate. You only need a compact EFI filesystem—typically 128MB or less—that's formatted correctly, with the type labeled as "efi." Mounting options are mostly a one-time setup using commands like --efi-directory. Most distributions include a GPT-enabled fdisk utility, making it simpler than older tools. Instead of complex formatting commands, consider adding the filesystem UUID to fstab: mount at /mnt/myExternalDrive, using --noauto and --user for secure access. This way, you can just run "mount /mnt/myExternalDrive" and it will work. You might also set up a symlink in your personal folders for easy access. If you plan dual booting, you can mount an NTFS drive as /mnt/windows and configure it with the right permissions. For organization, create a folder like VideoClips in /mnt/storage and link it with a symlink to your desired location. Keep your storage organized by always placing drives in designated mount points and documenting their paths.
The ideal arrangement isn't fixed. It largely depends on individual tastes. Many have noted that the simplest setup includes: EFI System Partition (ESP) /boot - usually, or simply use the ESP as /boot is no longer strictly necessary on an EFI system; the root (OS) partition - storage area - can be mounted at /home or elsewhere; data must definitely remain separate from the root (OS) partition as a best practice, for instance, reinstalling the OS won't affect your files. Clearly, more complexity brings its own details: if you anticipate running low on RAM, a swap partition might be needed. This can also be set up as a swap file, making it less essential if you don’t have one initially. A swap file offers the benefit of easy size adjustments. Should you plan to expand your storage structure, consider using LVM to format one partition and create multiple virtual partitions inside it. This approach simplifies resizing compared to traditional physical partitions, which can be quite cumbersome. Keep in mind that certain file systems support virtual volumes at the filesystem level, such as btrfs (though I haven’t tested it yet). When dealing with disk encryption, the process becomes more involved. For just the data partition, you might format it as a LUKS-encrypted volume with a filesystem inside. Some file systems support encryption at the filesystem level, but LUKS offers stronger protection, ensuring even the underlying type remains hidden until you unlock it. If you wish to encrypt the OS itself, you have two paths: first format it as a LUKS volume, then add the filesystem inside. This means you’ll need to unlock two partitions separately. Alternatively, you can create a LUKS formatted partition, place an LVM container within it, and add virtual partitions inside. For example, a layout for an NVMe drive at "/dev/nvme0n1" could include: /dev/nvme0n1 ├─/dev/nvme0n1p1: EFI System Partition ├─/dev/nvme0n1p2: /boot └─/dev/nvme0n1p3: LUKS Encrypted └─LVM Volume Group ├─LVM Volume: / └─LVM Volume: /home This arrangement displays only three physical GPT partitions, with the third being an encrypted container. Inside it lies a Logical Volume container, containing two logical volumes—one for the root and another for /home. If you don’t need a /boot partition, ensure the ESP is large enough to hold at least two kernels and their init images (about 1 GB should suffice). I highly recommend this setup, particularly for devices at risk of loss or theft. It may seem complex initially, but with practice it becomes manageable. Although it can feel daunting at first, Linux offers immense adaptability. For beginners, starting simple is wise—skip LUKS and LVM initially and build gradually. Utilize virtual machines for experimentation; they’re a great way to learn. It’s not overly hard, but it can feel overwhelming on first try. There’s a lot to grasp, but this flexibility is what makes Linux powerful. If you’re curious about hands-on learning, exploring it through CLI commands is a solid path. Organizing files later is up to you—just decide what fits your habits. Remember, if you tend to store files in /home, ensure it’s on a separate partition or allocate ample space so you don’t run out of room for updates. Bind mounts can help with this, acting like shortcuts in Windows but functioning as regular folders. They let you reference locations like “/mnt/your-storage-partition/home,” effectively moving files there without changing their path. This method is useful for things like Flatpak apps, which usually live in /var/lib/flatpak and can quickly consume root space. A practical solution is to use bind mounts for critical directories, keeping your system organized and accessible.
I completely disagree with that perspective. The operating system and most user interfaces operate mainly in read-only mode, except for logs and configuration files. Conversely, data files are often writable. Separating these layers helps ensure better integrity and recovery options. For instance, repairing a large storage device usually takes much longer than fixing a small 100MB file. This approach also helps identify which issues impact performance and usability.
In my setup, I typically run *BSDs with a standard partition layout: /small (under a GB), even smaller if I limit myself from root access (which keeps me confined to /root) /var as well). These partitions store machine-generated logs. If I need a large accessible directory under /var—such as a database server—I can link it securely to a more spacious location.
/usr is moderately sized (around 3GB) for typical user applications, while /usr/pkg remains compact (about 2GB). The /home directory is usually sized modestly (around 20GB for a few users), especially when I restrict myself to root.
Machine logs remain intact during power failures, aside from occasional configuration updates in /etc. This means I can boot into a functional system even if it’s running solo. From there, I can assess other partitions and determine how quickly they can be restored.
I often add /0, /1, /2 for additional mounts or external drives. When developing or rebuilding kernels and system tools, I create /Sources and establish symlinks from other parts of the old directory structure (like /usr/src, /usr/pkgsrc, /usr/xsrc).
Additionally, I use /Playpen as an expanded /home with symlinks pointing to various virtual user directories (e.g., /home/Model3). This method allows me to recreate an identical machine simply by bundling key directories onto a freshly partitioned disk. Changes to usage or layout are usually made outside the legacy hierarchy, enabling rapid deployment of a new system in minutes. Most configuration adjustments are handled via /etc/rc.conf, minimizing disruption.
It also allows you to mount specific directories with the "noexec" setting, though these decisions relate more to server security than everyday concerns. I’m curious about experimenting with mounting /home as noexec, treating it as a challenge against user-error driven malware. It seems like applying such a strong restriction might feel excessive—like using a sledgehammer to eliminate an ant.
You also have the ability to read-only mount file systems, set limits per user on individual drives, and more. This is useful when a process consumes excessive disk space in $HOME or attempts to overwrite areas where stricter access controls are needed. If you're resourceful, you can create a compact, more robust system on the root directory and then attach other file systems on top; this provides access to the limited tools you've chosen for the root mount while revealing the full set once everything is mounted. (For example, relying solely on ed(1) on / can be frustrating)
I haven't used "noexec" with "/home" for the same reason as before, but in general I always mount my data volumes with "nodev,nosuid,noexec" and keep a separate one for executables. I also try to limit what goes into "/home" to stay organized and maintain some data discipline. It probably doesn't add much value, but the lack of flags isn't harmful either. SELinux can do interesting things, though—maybe too much for a simple home setup. Unless I really want to dig into it.