Instead of putting the default back, I'd rather fix whatever is preventing it from working on your setup.  I don't know of any specific reason why chroot.img couldn't be located on an external drive.  Can you provide any additional details about how you have your drive set up?

in this particular case, i don't think it's possible [1]

imo, in the scenarios where support is impossible (missing tools, drivers, fs support, etc...), we should only warn (perhaps verbosely), but continue on anyways.  we shouldn't be forcing people to opt out of this manually.

[1] https://groups.google.com/a/google.com/d/topic/chromeos-chatty-eng/x43kfXy0GZM/discussion

It's just an external SSD which I formatted and created one ext4 partition. I mount and unmount it manually.

I don't know of any reason that wouldn't work.  I have chroots all over my system.  In general, from inside your chromiumos checkout, you should be able to do

cros_sdk --chroot /path/to/chroot

to create /path/to/chroot.img, mount it on /path/to/chroot, and enter it. --no-ns-pid and other flags should work normally too.

If you make a symlink from chromiumos/chroot to /path/to/chroot, entering without the --chroot flag should also work once /path/to/chroot is mounted (you'll have to redo that part by passing --chroot once after each reboot).

The initial thread looks like there was a problem with the loopback device.  I've seen some problems where lvmetad caches stale data about loopbacks and then subsequent commands throw out really strange errors.  This might be another manifestation of that.  If it is, this should be fixed after crrev.com/c/1058071 goes in.