Thomas Frohwein writes:
> On Sun, May 05, 2019 at 08:57:55PM +0300, cho...@jtan.com wrote:
> [...]
> > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev
> > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the
> > additional filesystems are checked or mounted.
>
> The order of sdX may change if e.g. a USB drive is plugged in during boot. You
> know you _can_ use the device UUID which AFAIK should be much more robust than
> using sdX. I used the following line at some point in an rc.local:
>
> bioctl -c C -l b3914b7ba0818788.a softraid0
I was unaware I could supply UUIDs to bioctl. Thanks.
I'm know of the danger of USB (and SD, etc.) insanity wrt device node
names. I simply make sure to never turn my laptop on with weird shit
plugged in to it. Seems like a safe bet.
> > Before I resign myself to patching /etc/rc in perpetuity, is there a
> > better or more canonical way to activate a second encrypted disc using a
> > key file in /etc before filesystems defined in /etc/fstab are checked or
> > mounted (it becomes /srv)?
>
> That would be rc.local. From rc(8):
>
> Normally, rc.local contains commands and daemons that are not part of
> the stock installation.
The problem with rc.local is that it's not executed until after fsck and
mount have parsed /etc/fstab (or /etc/fstab has been parsed for them;
whatever). If they do this before sd3 exists they at worst abort and at
best don't perform their desired function on the previously-encrypted
block device (ie. the plaintext block device is not scanned and mounted
automagically and my computer boots without a /srv).
> > The patch I use is below. Ignore the date; I've been using this since
> > around 6.2 at least. I feel rather silly saying that you're welcome to
> > use this tiny patch if it's useful, but there it is and you are.
>
> I empathize with your drive to get hands-on with the code to find a solution
> to
> a problem and the desire to share it, but the solution you are proposing
> should
> be discouraged. You are proposing a trivial 1-line patch to a file that isn't
> meant to be patched; ignoring the man page that contains a valid place for
> local customizations.
I completely understand why such a non-standard patch is
capital-W-Wrong. Developers and manglers believing otherwise are the
bane of my existance which is why I'm in NO wise suggesting this should
be immediately incorporated (perhaps I should have made that clearer in
the previous email - if you don't know how OpenBSD boots from init to rc
to getty then this patch is Not For You; it was included mainly so that
those who understood it would be able to skip my waffle and zoom in on
the actual question).
My goals are:
* /etc/rc already handles fsck of plaintext devices mentioned in /etc/fstab.
* /etc/rc already handles mount of plaintext devices mentioned in /etc/fstab.
* I would like to activate an encrypted/RAIDed device before /etc/rc performs
either of those (so that code somebody else has written can do them for me).
* /etc/rc.local is called too late.
Currently I achieve these goals with a simple (for me) patch on a single
machine's /etc/rc. I would love to hear of a better way or, if there
isn't one, try to come up with one that everybody can be happy with.
> For yourself, the closer you stay to the default install especially in regards
> to infrastructure like rc(8), the less likely you will run into bugs that are
> not reproducible by others.
I have no problem with deviating from the standard. I know what I'm
getting myself into and I know how to forge the pieces back together
again :)
I should probably come clean and point out that, having read
/install.sub and /etc/rc et al. inside, outwards and sideways, I'm
pretty sure that no such mechanism to mount RAID volumes prior to
fstab-parsing exists but if I'm wrong then please tell me. Alternatively
if there's any other interest than mine in creating one then I have
opinions and am happy to do the legwork, I only need a bit of a leg up
to make sure I remain within OpenBSD's coding guidelines etc..
Cheers,
'm not you're average noob,
Matthew
