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? So far, I cannot tell if this is a bug or intended behaviour.
