My point is that you shouldn't have to do this!

I've already done this twice for this box. Its disk is half empty, and the used space is 75% compounding useless bloat:

- 50% of the used space are package sets I never asked for.

- The stuff I did ask for is somehow 2x larger than it needs to be, since they don't randomize binaries in place.

- If they'd actually follow their own filesystem hierarchy standards, and stop using /usr as a build target (very bad things will happen if a crash happens in the middle of that! Why are we making lots of small separate partitions again?!?) then I could just make /var big. Then I would not have to repartition yet again after they introduce /lib/lolz/3gib or whatever in 2027.

Alternatively, if they had a journalling filesystem or still supported soft updates, then I could have one big partition, which would solve it once and for all.

Anyway, I'd argue "take the lan offline, backup the router, repartition and restore" isn't a planned reasonable maintenance task for a router. The fact that its so obviously easily avoidable is really frustrating.

Alternatively, if they just had a "which sets to install?" config option for auto-update (like they do for the OS installer!) then I wouldn't have to do this.

▲

SoftTalker 5 hours ago | parent [-]

Yeah it sucks when partitions that were sized 8-10 years ago are no longer adequate. I've hit the "/usr is too small to complete an upgrade" trap myself. When that happened I rejected the installer's partition suggestions and made /usr substantially larger (this is also necessary if you're going to be building large ports, which also happens under /usr).

So far that has worked for me.

Some people would also argue that using an 8 year old device as a critical path in your LAN is a risk in itself. Taking routers down to do upgrades is pretty common in the enterprise IT world.

	▲	hedora 2 hours ago \| parent [-]
		It’s not just the partition sizing though. The lack of DDNS and clock re-sync are really painful. Similarly, if fsck -y is frequently required, maybe just run that way all the time instead of failing to boot, or fix the root problem. I doubt many sers are taking block level backups for forensic repair in case they need to hand assemble inodes. Anyway, I wish them well. I want a simple, correct and rock solid OS for this sort of use case. The three pillars of computer security are confidentiality, integrity and availability. Hopefully they’ll focus a bit more on the latter two things than they have recently.