Mike, thank you for your multiple responses.
My intent is to use the produced images for CI on OpenBSD. Despite this issue
the images work reasonably well. So I am planning to use them for my intended
purpose and hope that the issue gets resolved in the future.
Bill
On 8/2/18, 7:48 PM, Mike Larkin wrote:
On Thu, Aug 02, 2018 at 05:59:41PM +0000, Bill Zissimopoulos wrote:
> Mike, thank you for your response.
>
> On 8/2/18, 9:07 AM, Mike Larkin wrote:
>
> 1. We've seen this message before (usually on APUs), but only a
single time (eg,
> just one of the signal lines gets displayed). And IIRC it was a
different signal.
>
> The only other instance of this message that I have found online is here:
>
> https://github.com/yellowman/flashrd/issues/30
>
> 2. In your case, the stream of messages seems to stop after some time
and boot
> proceeds normally after that.
>
> You are right. Although I believe that I have seen it print the message
endlessly as well.
>
> 3. When I built the image using your script, on the second boot, I
saw no
> messages.
>
> I'm not sure what's causing the problem, can you try with 6.3
release? (I'm
> assuming you are using -current here? that's what I tested also)
>
> The problem happens for me with the 6.3 release (install63.iso). I have
not tested other releases.
>
> (I believe I tried the 6.2 release at some point, but did not complete my
testing because it needed extensive changes to the expect script.)
>
> 4. in my test the default install location came up as http, so your
script's
> pressing of "enter" for install path hung. I had to change the
default location
> in the script to be cd.
>
> That does not happen for me, perhaps because of the install image I use
(install63.iso).
>
> 5. Your customization step at the end should probably fixup /etc/ttys
or
> you won't be able to log in to the machine via serial (since no getty
will
> be spawned there). I sat there waiting for a while in qemu only to
realize
> the getty was waiting on the vga console, not serial. YMMV.
>
> You are right. I have not managed to fix serial access for OpenBSD yet,
because I focused on resolving the discussed issue first.
>
> My understanding is that the instructions at the following link should
get serial access fully working:
>
> https://www.openbsd.org/faq/faq7.html#SerCon
>
> Bill
>
>
>
Unfortunately, I don't have any other ideas for you as to how to stop the
segvs. It is not seen on real hardware, so I'm at a loss to explain why qemu
exhibits this behaviour.
Perhaps try changing the cpu type with -cpu XXXX ?
