I only separate out /home, /boot, and I usually have a separate /steam partition because I have a separate terabyte drive just for games.
this post was submitted on 09 Jul 2023
15 points (94.1% liked)
Arch Linux
7750 readers
2 users here now
The beloved lightweight distro
founded 4 years ago
MODERATORS
I don't even have a separate /home partition but agree with the others.
I know this is really not a good reliability/security decision that I've made but I only separate out the boot partition and I have one big root partition. It's not gotten me into trouble yet because the ext4, xfs, and zfs filesystems are very mature and reliable. My production systems are just my own homelab stuff with nothing critical. The reason I do this is because I've never been good about guesstimating what my partition size needs are and inevitably I cause problems for myself later on down the line by underestimating. I thought that LVM was supposed to help make resizing partitions easy but I don't know enough about LVM since I've never really used it.
On newer machines I stopped even splitting out /boot. Now it's just one big partition and a swap file.
And regular backups. 😅
Same. I use the vanilla partitioning scheme. I put all of my effort on backup and reproducibility of my system. I completely wipe out my system at least every month.
Do you use a different distro or basically put the same one back on?
Hi - I mainly use Arch but also Debian here and there. I'm a sysadmin so its part of my job.
Arch rocks! I use it both on my desktop and VMs. My server uses Proxmox.
Yeah we are moving away from CentOS and into vanilla Debian for our servers and kvm hosts. We haven't tried Proxmox yet, just didn't have the need since we are a smallish shop and have in-house tools to help with vm management. It is very interesting tho and will probably try it in the future.
Idk, I never make separate partitions anymore on fresh Linux installs other than EFI and sometimes swap. Never had any issues
Btrfs with subvols work for me fine. I am as well baking kernel/initrd/cmd args into efi executable
Your wording is hard to understand. Are you asking if you can make /usr its own partition? If that's your question, you can. You need to make sure that "usr" and "fsck" are in HOOKS in /etc/mkinitcpio.conf.
I can see how /usr can balloon in size. My /usr is 22G with 1613 packages installed.
Man you need to check your settings for logging and others. I have a separate /home and /boot my root is about 40g I think but I only retain the last version after upgrade, my Journalctl only holds last 3 boot and it has a total size limit of 1g.
If it helps, I've got btrfs on my 128GB drive with /home and root as subvolumes.
When the volume started to fill, I moved /home to a new drive, should be right for a while now.
my /usr is 10G and /var is 5G, I would say check whats is consuming space on /usr and /var to make sure there isn't a problem, with that said I don't have separate partitions for for this exact reason, I only separate root from boot because I'm running full disk encryption.
Usr is literally just programs. STM programmers, kicad, IDEs, freecad, drawing programs, etc...
10 gb for var is huge. What if you run ‘journalctl --vacuum-time=1d’? If that deletes a lot, you should set up log rotation to delete your logs.
Since the OP doesn't mention this, it's not very likely, but
/var can get pretty large nowadays with flatpaks gaining popularity; also databases & qemu images live inside /var, not to mention the default webroot for apache.
You need a root partition, that is about the only requirement. But the rest I don't really see a point in anymore. Well except for boot, but that one's small and easy to predict it's size.
Can we place /usr files managed through managers in /home?
Why even have separate partitions if you are just going to munge them on each other?
What does having a separate home partition actually but you? And is it worth the cost of running out of disk space on one partition and needing to accruately predict how much you are going to need on each one?
view more: next ›