It really depends on your requirements…

But a few useful points:

1. Use GPT partition table and not MBR. Everything will be simpler, no need for extended/logical partitions.
2. If you need to be able to do online (mounted) partition resizing, pick btrfs. Ext4 can only grow them online but not shrink.
3. Make sure your partition boundaries are 1 MiB aligned.
4. If you need more advanced setups, consider using LVM.

One small /boot which is also my EFI system partition.

And a partition for / which covers all the rest of the drive.

Partitioning only limits flexibility. At some time you will regret your choice of partition sizes.

i usually have efi boot partition (512mb), / (linux root), /home (i usually make this pretty big) , and swap partition.

Not saying my practice is the best one, but here’s what I do:

• EFI system partition is mounted on /boot
  • kernel is held here. In case of distros like NixOS etc that keep around old kernels, a small ESP might run out of space. I make mine at least 1GB.
• the rest of the disk is one luks2 volume
• inside the encrypted volume, there’s a BTRFS volume
• there’s a subvolume for /home
• and a subvolume for every distro I have (which is usually 1, but sometimes I tinker or switch)
• Kernel command line parameters specify the btrfs subvol with the right distro to boot.
• for NixOS, you need a bootloader (to choose the right kernel). Systemd-boot works well, and its configuration is easily readable. I never figured out how to work with GRUB2, its configuration is just too confusing.
• or if you like Arch, dispense with bootloaders and just use EFISTUB. You can put kernel cmdline params into EFI bootloader options with efibootmgr.

Simple yet complete. Efficient, and extensible - for example, now that everything is a subvolume, I can easily snapshot it, then create backups with rsync off the snapshot, to avoid inconsistent state between backed-up files.

Usually, I do the simplest thing: all the stuff goes on one big ext4 partition. I don’t make a separate partition for /home. I’ll make a swap partition if I can remember but I’ve forgotten to do that before and nothing bad happened. The bootloader goes on a fat32 /boot/efi on the same drive as whatever the Linux install is on. This way I can swap around the drive to different pcs if I have to or easily change/upgrade drives without having to reinstall all my stuff.

This strategy works for dual booting Windows also. I’ll put the windows install all on its own separate drive so it won’t try to erase grub during a disk check or something. That happened one time. Also, by putting Windows and Linux on separate drives you can use the bios to boot between Windows or Linux if you mess up one of the bootloaders.

Depends on your system. Desktop have different requirements than servers.

On both at minimum, I’d keep /home and /var/log separate. Those usually see the most writes, are least controlled, and so long as they’re separate partitions they can fill up accidentally and your system should still remain functional. /tmp and /var/tmp should usually be mounted separately, for similar reasons.

/boot usually keep separate because bootloaders don’t always understand the every weird filesystem you might use elsewhere. It would also be the one unencrypted partition you need to boot off of.

On a server, /opt and /srv would usually be separate, usually separate volumes for each directory within those as well, depending how you want to isolate each application/data store location. You could just use quotas; but mounting separately would also allow you to specify different flags, i.e. noexec, nosuid for volumes that should only ever contain data.

/var/lib/docker and other stuff in /var/lib I usually like to keep on separate mounts. i.e. put /var/lib/mysql or other databases on a separate faster disk, use a different file system maybe, and again different mount options. In distant past, you’d mount /var/spool on a different filesystem with more inodes than usual.

Highly secure systems usually require /var/log/audit to be separate, and needs to have enough space guaranteed that it won’t ever run out of space and lock the system out due to inability to audit log.

Bottom line is its differnet depending on your requiremtns, but splitting unnecessarily is a good way to waste space and nothing else. Separate only if you need it on a different type of device, different mount options, different size guarantees etc, don’t do it for no reason.

1Gb EFI, rest of the disk LUKS with a single BTRFS inside. Use BTRFS subvols to divide things up. Swap as a swap file on BTRFS (be sure to set it as no_cow).

Depends on environment.

Real hardware separate for a server partitions for: /home, /var, swap, sometimes /usr, sometimes /var/log/audit Depends on deployment requirements, and if a system is expected to run after filling up audit.

Real hardware for a at home desktop: /var, swap, maybe /home, or just one partition for / and one for swap.

Cloud: all one partition, put swap in a file if it is needed. Cloud images are easy to grow if it is just one partition. Cloud-init will handle that automatically with the right packages installed, no configuration needed. Swap partitions are unlikely to be the right size as they vary according to memory and memory varies according to instance/guest sizes. Swap makes auto growing root partition harder (cloud-init custom config injection required). Best practice is to size workload and instances to not need swap whenever possible.

• 500mb-600mb fat32 /boot partition
• 40gb - 100gb ext4 or btrfs / partition (if you know you’re gonna install a lot of software, go bigger)
• 1x - 2x ram as swap
• rest of disk as ext4 /home partition

Use zram instead of a SWAP partititon. Zram compresses and keeps in RAM. It’s default on Fedora and a few others iirc.