Rickard, thanks for your answer and the provided links. I am aware of the install.conf option, but decided to use the expect method to be inline with how I do things on FreeBSD and NetBSD.
I believe that FreeBSD has its own method of specifying install configuration which is incompatible with OpenBSD. And NetBSD does not have any method as far as I know. So it looked to me that the most straightforward path was to use the same basic technique on all platforms: an expect script. Nevertheless I will check your links and in particular the “GCE Image Import Post Processor” to see how it sets up OpenBSD for the GCE environment (my remaining task in this part of the project). Bill On 8/4/18, 2:17 AM, Rickard von Essen wrote: Kind of a side note, but I use a simpler process to automate the installation of OpenBSD than using expect. The installer can read a config file see 1). The install.conf is described in the man page for autoinstall 2). I use Packer to create Vagrant boxes, currently only for VirtualBox, VMware, and Parallels Desktop, but Packer also support building on QEMU 3). The latest version, 1.2.5 also has a googlecompute-import post-processor 4) which can take the raw disk image create by QEMU and import it into a GCE image (unfortunately the link to this is lost from the documentation so you need to use the direct link provided). // Rickard 1) https://github.com/boxcutter/bsd/blob/master/openbsd.json#L6-L11 2) https://man.openbsd.org/autoinstall 3) https://www.packer.io/docs/builders/qemu.html 4) https://www.packer.io/docs/post-processors/googlecompute-import.html On Fri, 3 Aug 2018 at 09:28, Bill Zissimopoulos <billz...@navimatics.com<mailto:billz...@navimatics.com>> wrote: 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 ?
