I dan’t know if this is still valid but I used to be told to have different partitions for your system, logs and data (home directories) … and have the swap-partition located in between them.
This was to limit the distance the head has to move when reading from your system starts swapping.
But if you use a SSD drive, that is not valid anymore of course :-)
Nowadays you don’t even need a /boot unless you’re doing full disk encryption and I actually recommend keeping /boot on / if you’re doing BTRFS root snapshots. Being able to include your kernel images in your snapshots makes rollbacks painlessly easy.
UEFI forum made it a requirement for motherboard constructors (hp, dell, msi…) to make their UEFI implementation to be able to at least read fat(12/16/32) filesystems. That is why you need a fat(12/16/32) partition flagged ESP (efi system partition) for holding your boot files.
So, I dont think you can do that unless you fall back to the old outdated BIOS or you have some *nix filesystem in your uefi implementation which I dont trust.
You’re only partially correct. /boot doesn’t have to also be your EFI partition. In fact, most distros by default will separate the two, with the EFI partition mounted at /boot/efi and /boot being a separate ext4 based partition. My suggestion is that, if you’re running BTRFS, you should merge /boot and / as one partition. You’re still free to have a FAT32-based EFI mounted at /boot/efi or better yet /efi.
Full disk encryption can be done without a separate /boot if your bootloader is modern enough. It’ll ask you for your password before the GRUB/sysyemd-boot/rEFInd OS selection screen.
I’ve made this work on Manjaro and Ubuntu without too much effort. My only mistake was not putting swap in a separate partition, leading to some painful problems when it comes to hibernating the system.
If you use the same LUKS container for the swap file and the root partition, you’ll only need to enter your password once to unlock the single LUKS container. The UEFI bootloader can then load the kernel and initramfs from the encrypted partition without a separate boot partition.
If all you’re trying to protect against is someone ripping out the SSD and running away with it, you can even go as far as have an encrypted filesystem without ever having to enter any password by leveraging the TPM. A TPM can also help strengthen a password encrypted partition, but the password free encryption makes encryption as easy as Bitlocker on Windows 11. Sadly, there’s not a lot of support for this in most distro installers.
Shrinking partitions is quite annoying already because you have to do that offline, and my LUKS+BTRFS setup isn’t very well suited for advanced partition operations. I’d also need to enter my password twice if I don’t retroactively add LVM to the mix. BTRFS works perfectly fine, but its management tools aren’t as reliable and mature as their ext4 counterparts.
That is why one small (512Mib) ESP and one BTRFS partition occupying the rest of my drive is my go, I can isolate the root (/), var and home partitions using subvolumes.
Users who distro hope may need a separate /home partition.
Aaaand your server just crashed because of a spammy log. You lost the company $222 million overnight, the database is corrupt, and every 9 minutes the company looses another $1 million.
systemd resets the logs when they get big, this isn’t the 2000s anymore. But if you want to limit the size of /var/log, any modern filesystem has disk quotas per-directory
I found out the hard way that this isn’t always true. The vacuum task runs occasionally, but if the logs get spammed hard enough (i.e. faulty hardware) you can get 50GB of log files.
That said, this problem can be prevented using a little extra configuration. I just didn’t expect this to be a problem on a vanilla Ubuntu install, lol.
Aside from the group/user facl, Windows also has ACL inheritance (making changing ACLs for a directory much faster), separate delete permissions (rather than write permissions on the parent directory), permissions regarding who can change permissions (again, rather than write permissions to the parent directory). It can also manage who can alter attributes like “read only”, for example to act as a share locking mechanism.
set/getfacl comes close but doesn’t provide the same freedom of configuration NTFS provides. There’s no “users of group X can temporarily take ownership of a folder and all subfolders” without recursively going through every object, which can be very painful over the network.
Furthermore, the Windows SID system is much more practical for shared networks than the incremental user IDs Linux generates per install. You can centrally allocate user IDs in Linux, but it’s not an integral part of the system like it is on Windows, where even local accounts have unique user IDs.
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.
Tbf, you can mitigate this problem by using lvm or btrfs with subvolumes.
I did that years ago and then kept fiddling with the lfs subvolume sizes. I see absolutely no advantages to make things more complicated than needed.
I dan’t know if this is still valid but I used to be told to have different partitions for your system, logs and data (home directories) … and have the swap-partition located in between them. This was to limit the distance the head has to move when reading from your system starts swapping.
But if you use a SSD drive, that is not valid anymore of course :-)
Kr.
Nowadays you don’t even need a /boot unless you’re doing full disk encryption and I actually recommend keeping /boot on / if you’re doing BTRFS root snapshots. Being able to include your kernel images in your snapshots makes rollbacks painlessly easy.
UEFI forum made it a requirement for motherboard constructors (hp, dell, msi…) to make their UEFI implementation to be able to at least read fat(12/16/32) filesystems. That is why you need a fat(12/16/32) partition flagged ESP (efi system partition) for holding your boot files.
So, I dont think you can do that unless you fall back to the old outdated BIOS or you have some *nix filesystem in your uefi implementation which I dont trust.
You’re only partially correct.
/bootdoesn’t have to also be your EFI partition. In fact, most distros by default will separate the two, with the EFI partition mounted at/boot/efiand/bootbeing a separateext4based partition. My suggestion is that, if you’re running BTRFS, you should merge/bootand/as one partition. You’re still free to have a FAT32-based EFI mounted at/boot/efior better yet/efi.I use systemd-boot and my mount point is /efi. /efi/EFI/ is where my bootloaders live.
If I rollback to an old enough snapshot, I have to reinstall my kernels from a chroot. It’d be cool if I could get around that.
Where’s your /boot?
Separate FAT32 part.
Full disk encryption can be done without a separate /boot if your bootloader is modern enough. It’ll ask you for your password before the GRUB/sysyemd-boot/rEFInd OS selection screen.
I’ve made this work on Manjaro and Ubuntu without too much effort. My only mistake was not putting swap in a separate partition, leading to some painful problems when it comes to hibernating the system.
I’ve heard that you have to put in your encryption pw twice if you do it that way no?
Out of curiosity, what’s stopping you from shrinking the partition and adding a swap partition?
If you use the same LUKS container for the swap file and the root partition, you’ll only need to enter your password once to unlock the single LUKS container. The UEFI bootloader can then load the kernel and initramfs from the encrypted partition without a separate boot partition.
If all you’re trying to protect against is someone ripping out the SSD and running away with it, you can even go as far as have an encrypted filesystem without ever having to enter any password by leveraging the TPM. A TPM can also help strengthen a password encrypted partition, but the password free encryption makes encryption as easy as Bitlocker on Windows 11. Sadly, there’s not a lot of support for this in most distro installers.
Shrinking partitions is quite annoying already because you have to do that offline, and my LUKS+BTRFS setup isn’t very well suited for advanced partition operations. I’d also need to enter my password twice if I don’t retroactively add LVM to the mix. BTRFS works perfectly fine, but its management tools aren’t as reliable and mature as their ext4 counterparts.
That is why one small (512Mib) ESP and one BTRFS partition occupying the rest of my drive is my go, I can isolate the root (/), var and home partitions using subvolumes.
Users who distro hope may need a separate /home partition.
Aaaand your server just crashed because of a spammy log. You lost the company $222 million overnight, the database is corrupt, and every 9 minutes the company looses another $1 million.
Good job.
systemd resets the logs when they get big, this isn’t the 2000s anymore. But if you want to limit the size of /var/log, any modern filesystem has disk quotas per-directory
I found out the hard way that this isn’t always true. The vacuum task runs occasionally, but if the logs get spammed hard enough (i.e. faulty hardware) you can get 50GB of log files.
That said, this problem can be prevented using a little extra configuration. I just didn’t expect this to be a problem on a vanilla Ubuntu install, lol.
deleted by creator
Sorry to ask but why is get/set facl not sufficient for acls on linux?
Aside from the group/user facl, Windows also has ACL inheritance (making changing ACLs for a directory much faster), separate delete permissions (rather than write permissions on the parent directory), permissions regarding who can change permissions (again, rather than write permissions to the parent directory). It can also manage who can alter attributes like “read only”, for example to act as a share locking mechanism.
set/getfacl comes close but doesn’t provide the same freedom of configuration NTFS provides. There’s no “users of group X can temporarily take ownership of a folder and all subfolders” without recursively going through every object, which can be very painful over the network.
Furthermore, the Windows SID system is much more practical for shared networks than the incremental user IDs Linux generates per install. You can centrally allocate user IDs in Linux, but it’s not an integral part of the system like it is on Windows, where even local accounts have unique user IDs.