On Wed, Oct 04, 2017 at 12:18:20PM +0200, Stefan Sperling wrote:
> On Wed, Oct 04, 2017 at 10:57:28AM +0100, Zé Loff wrote:
> > On Wed, Oct 04, 2017 at 10:41:56AM +0100, Zé Loff wrote:
> > >
> > > Hi all
> > >
> > > I connected my laptop's encrypted HDD to my desktop machine to copy some
> > > stuff and when I put it back on the laptop the boot loader no longer
> > > asks for the passphrase and thus I can't boot from it. Any clues? Some
> > > notes:
> > >
> > > - Both machines are amd64 running snapshots, 6.2 #115 (Sep 27) on the
> > > laptop, 6.1 #125 (Oct 1) on the desktop (I had to disable pcppi on the
> > > desktop, so not exactly vanilla).
> > >
> > > - The softraid volume was and still is correctly attached/detached on
> > > the desktop and on a i386 machine running 6.1-release+mtier
> > >
> > > - The metadata changed when connecting to the desktop, roaming from sd1
> > > to sd3. I attached/detached it on the i386 machine to make it roam
> > > back to sd1, just in case, but it expectedly made no difference.
> > >
> > > - I ran installboot on the softraid volume, to no avail.
> > >
> > > - Tried booting bsd.rd from a USB stick, starting an upgrade, dropping
> > > to shell, MAKEDEV sd0 sd1 sd2, attaching the crypto volume and
> > > selecting it as the root disk. The installer complains that it is not
> > > a valid root disk even though all tests mention here[1] pass:
> > >
> > >
> > > [1] https://marc.info/?l=openbsd-bugs&m=150170071321416&w=2
> >
> > Strike that last one. Forgot to umount /mnt before going back to the
> > installer, so the "mount test" failed in the installer. Just managed to
> > do the upgrade and it's all back to normal now.
> >
> > Anyway, I took a bit of a scare there. Can anyone shed some light on to
> > what happened? Is a CAVEAT in order? I can try to write something up,
> > but I'd need to understand it first...
>
> Sounds like the BIOC_SCBOOTABLE flag in softraid meta data got cleared
> when the meta data was rewritten by your desktop machine.
>
> If you compile kernels on both machines with 'option SR_DEBUG' and repeat
> the process, you should be able to confirm this. The kernel will now print
> softraid meta data to dmesg while rewriting it. Among several lines there
> will be a line 'ssd_vol_flags 0x...'. The volume is bootable only if flag
> bit 0x80 is set.
>
> The only way to set the 'bootable' bit is via installboot(8). You said you
> were running installboot (how exactly?) but it seems this somehow didn't
> succeed and only the installer eventually succeeded with this when you
> did an upgrade?
On the desktop machine (which incidentally also has FDE, I forgot to
mention that), I attached the HDD (sd2), attached the crypto volume with
bioctl (which became sd3) and ran
# installboot -v sd3
Using / as root
installing bootstrap on /dev/rsd3c
using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
sd3: softraid volume with 1 disk(s)
sd3: installing boot loader on softraid volume
/usr/mdec/boot is 6 blocks x 16384 bytes
sd2a: installing boot blocks on /dev/rsd2c, part offset 144
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 625136336
/usr/mdec/biosboot will be written at sector 64
(hooray for tmux's scrollback)
> So far, I cannot tell if this is a bug or intended behaviour.
>
--
