0

I'm a complete newbie when it comes to almost everything related to Linux, but I want to try and install Arch Linux on my SSD.

My PC specs are:

  • a320m-a pro max
  • Ryzen 3 3200g
  • Kingston 240 GB SSD
  • 1 TB HDD for media and files
  • 16 GB of RAM.

Should I just follow the installation guide as it is step by step? (https://wiki.archlinux.org/title/Installation_guide), or is there anything I need to add or change since I'm installing Arch Linux on an SSD?

I know close to nothing regarding technical stuff, but I've heard of a term called "trim" for SSDs, and I don't know if the are any extra steps to add to the guide.  Most installation tutorials on YouTube are done on VMs with HDDs as an example so I can't use them for my installation process.

Also, should I partition the disk into swap, EFI system, and Linux filesystem?  If so, how much space is needed for each one?

I intend to use the HDD mentioned above for media and files.  Is there anything that I should do during the installation, or it is like Windows where it'll recognize the HDD and I can just use it without any problems?

Please use beginner-friendly terminology when you explain any of this whole thing because I'm a complete noob who is not tech-savvy enough.  Sorry for my not-so-good English; my main language is Spanish.

2
  • There's no difference between installing on HDD or SSD. Trim, whenever needed, is automatically enabled. Sep 27, 2021 at 10:50
  • In general, broad "advice" topics are better posted on forums – Super User is a Q&A site and prefers more specific questions. Sep 27, 2021 at 11:47

1 Answer 1

0

Should I just follow the installation guide as it is step by step? (https://wiki.archlinux.org/title/Installation_guide), or is there anything I need to add or change since I'm installing Arch Linux on an SSD?

There are no significant differences, except that NVMe disks are named /dev/nvme* rather than /dev/sd*. (Use lsblk -S to find out which device file corresponds to what disk.)

I know close to nothing regarding technical stuff, but I've heard of a term called "trim" for SSDs, and I don't know if the are any extra steps to add to the guide.

"Discard" is the generic Linux term, "Trim" is the command name used by ATA disks, "Unmap" is the equivalent SCSI command, "Deallocate" is the NVMe command, and you'll often hear all four terms used interchangeably.

In all cases it lets the OS indicate that certain sectors are no longer "in use" (don't belong to any files) so that the SSD is free to overwrite that part of flash memory with something else.

Discard/trim can be invoked either periodically (for the entire disk's unused areas) or immediately (as soon as something is deleted).

  • To use it on a schedule, enable the fstrim.timer systemd unit to have the system issue discards for all mounted filesystems once a week or so. (Use 'systemctl' to do this.)

    Some distributions enable fstrim.timer automatically upon install, but others don't. If you want to see if it works in general, you can also manually run fstrim -v on a mounted filesystem.

  • Immediate discard could be enabled through filesystem mount options (in fstab or the rootflags= kernel option), but it's usually not recommended to enable this – mostly because in some Linux filesystems it is synchronous, meaning deletes will wait until the TRIM command finishes, which is slow. (And can be even slower due to many cheaper SSDs being unable to use "queued TRIM", meaning that the TRIM command cannot be interleaved with regular reads/writes, so everything has to stop while the discard is performed.)

You should probably enable fstrim.timer even if you don't have an SSD, as high-capacity SMR HDDs arrange data in a very similar way and at least some manufacturers' HDDs will accept the TRIM command for the same reasons. (Run lsblk -D to check if your devices support discard.) It is also useful on VMs, as many hypervisors use dynamically-sized disk images that grow on demand but usually never shrink – some VM hypervisors do recognize TRIM and mark the corresponding .vhd/.vmdk image areas as free.

Also, should I partition the disk into swap, EFI system, and Linux filesystem? If so, how much space is needed for each one?

One "EFI system partition" is required for UEFI firmware.

(Unless it has the CSM (BIOS-emulation) mode enabled and you specifically intend to boot the system in BIOS-emulation mode. However, you should always choose native UEFI boot mode if it's available – it's not nearly as finicky on new machines as it used to be on 10-year-old devices, and it's soon going to be the only mode available.)

While the requirements for EFI system partition vary (e.g. with GRUB2 you can get away with just a few MB), I think a good minimum baseline is Microsoft's recommendations for OEMs, which is at least 100 MB for the EFI system partition, or at least 260 MB if it's a 4K-sectored disk.

If you plan on using systemd-boot, typically this means putting your kernel (and initramfs) images directly in the EFI system partition, and experimenting with different kernels can quickly eat into the available space, so for an Arch user I'd recommend 500–512 MB.

However, that's the largest it gets – allocating gigabyte is overkill.

Having a swap partition is optional, but you probably should have a small one (say, 1–2 GB). (No, it should not be "two times your RAM" anymore.) Instead of a partition you may be able to use a swap file on your root filesystem, but if you can afford the 2 GB all the time, then a partition is simpler.

On modern systems, there will usually be enough RAM that swap only gets used rarely – e.g. the kernel might occassionally swap out some background processes to make space for page cache (which is more useful). This should have no noticeable impact on your SSD's lifetime.

One exception to this is if you intend to use hibernation (aka "suspend to disk" mode). This does need swap, since that's where Linux stores the hibernation image. As the image is somewhat compressed, 3/4ths of your physical RAM size seems to be a commonly chosen size. However, in practice, hibernation doesn't work very well on Linux.

The Linux "root" partition will contain the entire OS. The OS starts small at first but tends to only grow as you install stuff; 20 GB just for /usr isn't that unusual (plus a few gigabytes for /var/cache, a few more for /var/log, etc.) On a small SSD, using a single partition for the entire / may be more economical than splitting it into / and /home, but that's ultimately your own decision.

I intend to use the HDD mentioned above for media and files. Is there anything that I should do during the installation, or it is like Windows where it'll recognize the HDD and I can just use it without any problems?

If the HDD is brand new and completely empty, you probably won't be prompted to automatically "format" it (create partitions and filesystems) – you'll need to do it manually, through GParted or GNOME Disk Utility or fdisk and mkfs.

Also unlike Windows, you'll need to decide on your own where to "mount" the HDD (a path like /Data or /media/hdd, instead of drive letters) and add the corresponding entry to /etc/fstab. (If you happen to use GNOME, its Disk Utility can do this as well.)

(Although many graphical file manager apps can recognize new filesystems and offer to mount them automatically, this feature is really meant for removable media (things like USB sticks) and won't be very convenient to use with internal HDDs.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .