On Thu, Apr 09, 2015 at 04:27:17AM -0600, Theo de Raadt wrote: > > But it seems people are expected to build a custom bsd.rd if they > > want something different so I'll bow out of this conversation. > > No, the situation is that less than 1% of the user community > apparently have a secret usage case, but never manage to explain it. >
I manage a bunch of OpenBSD proxies that I would like to be able to build from scratch using automated tools; everything is in place (ansible) except for the base OpenBSD install as I need a separate /var/squid partition to prevent cache / log disasters from filling /var; similar concerns would apply to many other data / log-heavy daemons. On other systems where I don't know how the data will grow, I typically configure them with something close to the auto layout, but a smaller /home, and leave the remaining disk empty. When I get a feel for what the data usage is in /var/<daemon> or /home or /usr/local, I can expand /home or create a new partition and migrate the data. Other reasons to want non-auto partitioning like include: - simpler dump/restore - moving certain parts of hier(7) onto a different device (you can do this as a post-install task if they are empty, but it becomes a pain if it's something that's part of base) A place where the latter can be quite useful is on a virtualised guest, where you can easily make one storage device persistant, and another ephemeral across reboots. Yes, all of this can be done manually, but basically any place I would care to work at is moving towards complete automation of system installs (for *hack*Cloud*spit*, Continuous Delivery, DR, or just plain old laziness). It would be really nice if the OpenBSD installer would handle this in a sane fashion. Note: I don't use the auto-layout except on throwaway test installs as it never seems to give me the layout I need, and except for laptops I would prefer to never use the interactive installer at all.
