memstick: set kern.cam.boot_delay about tools HOT 12 CLOSED

Also run into that.. Installation was not possible without setting boot_delay to 10'000.
Would be great to have it permanently fixed or written somewhere.

I also sent a mail to pcengines to make sure they add this to the howto collection:
http://pcengines.ch/howto.htm#OS_installation

notetoself: buy @lattera a beer..

from tools.

@mschilt this is only needed for the USB devices, right?

from tools.

yes.
I am using a Zalman USB Disk that emulates an USB CDROM from .iso files on the disk. Very helpful and no pain in creating a bootable USB stick.

Initially the boot works but at some point it tries to locate the usb device and there it stuck.
Can do that again this evening and get you some logs if you want.

Looks like a known issue:
http://unix.stackexchange.com/questions/19561/installing-freebsd-from-usb-stick-boots-but-later-cant-find-the-usb-stick
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160192

from tools.

@mschilt I was afraid of that, needing it everywhere, even the ISO and later not being able to strip it.

Thinking about adding it permanently now, but will need feedback from the other devs.

from tools.

After much discussion, this will be very visibly documented, not added in code.

from tools.

hmm.. so users will run into that issue until they find the hint.. (because nobody reads the docs beforehand ;-) ) On the other side it would delay the install process by 10sec. for all users. So despite having a different opinion I can understand your decision.

from tools.

@mschilt I completely understand. I am not so sure it's only about the install media. The problem is that:

Without further code, the flag will transport to the installed system until the first boot. If the first boot goes fine, the flag is stripped and the second boot on the hardware still requires the delay the box will be defunct again.

I guess we could also strip it during the install process, which may or may not present the first problem on reboot.

So we don't know whether this option is required and don't want to enforce arbitrary boot delays on installed systems.

It looks like the route here is to do something in the installer, but then again the same problem would exist for nano images which don't have an installer and may not boot without the boot delay. :/

from tools.

A bit of loader.conf magic went into core.git, which gives us leverage against a persistent setting of loader.conf, where we could potentially strip kern.cam.boot_delay on first boot. I expect the code to stabilise with 16.7.5 so that 17.1 will likely have this fixed in the sanest way possible. :)

from tools.

Ok, great. If you create an ISO that contains the fix I can test this on sunday.

from tools.

@mschilt Thanks! I don't think it'll be done this Sunday, let me ping you again for a custom ISO early next week :)

from tools.

@mschilt this was a lot more complicated than I thought, but here is an all development image (that works): https://pkg.opnsense.org/snapshots/OPNsense-17.1.a-LibreSSL-cdrom-amd64.iso.bz2

The install media boot is delayed, so is the first boot of the real install. Afterwards the delay is stripped. If it's still needed there will be an "os-boot-delay" plugin to enable that permanently :)

from tools.

Worked from my end in numerous tests. If we need to do more, please let me know.

from tools.