[Bug 210132] hang on boot with locked SSD / regression towards 10.1

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210132

            Bug ID: 210132
           Summary: hang on boot with locked SSD / regression towards 10.1
           Product: Base System
           Version: 10.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: h2+fbsdports at fsfe.org

I have a server with two pools, one unencrypted (boot-pool) and one encrypted
with personal data and services that is brought up manually after the system
has booted. Part of the encrypted pool is a Samsung EVO 850 SSD as ZIL and
L2ARC. This device is locked/unlocked via "camcontrol security".

This has all worked rather well in my previous 10.1 setup. While booting with
the locked device there are a lot of errors when probing the device, but no
real issue. Unlocking works perfectly well and the device is immediately
available.

Now, after upgrading to 10.3 the kernel hangs on detecting the devices. This
was particularly tricky to find out, because on a non-verbose boot you cannot
see it / the boot hangs at different points depending on periphals. But, when
verbose boot is activated it always hangs on
GEOM: ada3
(which is the SSD)

I have also reproduced this with different motherboards. On one of them
selecting "safe boot" actually boots the system with no problems. It is then
possible to unlock the SSD and reboot in regular mode because the lock-state
survives reboots. → this "proves" that it is the locked state that is causing
the problem with 10.3 

Just selecting the old kernel from the boot-loader makes the system boot
normally, which is what I have set it up to do now, but I don't want to stay
with the old kernel too much longer for obvious reasons. I just got lucky, that
the old kernel still works with the new userland.

Thank you for your help!

-- 
You are receiving this mail because:
You are the assignee for the bug.