memstick: set kern.cam.boot_delay

[fichtner]

This is trivial at first sight, but we should make sure this does not transport to the final installation.

Workaround:

1. Escape to loader prompt (3)
2. Type: set kern.cam.boot_delay="10000"
3. Type: boot

Reported by: @lattera on APU2

[mschilt]

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..

[fichtner]

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

[mschilt]

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

[fichtner]

@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.

[fichtner]

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

[mschilt]

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.

[fichtner]

@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. :/

[fichtner]

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. :)

[mschilt]

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

[fichtner]

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

[fichtner]

@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 :)

[fichtner]

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