Theo, right on point and I agree with the workarounds statement. I would love to send my server in for someone to look at it. I have 3 different machines (2 are similar) all experiencing the same problem with the ghost keyboard at the boot prompt.
What my issue is that the bootloader seems to act differently if the prompt times out or if the "boot" command is given. I would expect the boot command with no arguments to do the same thing as a timeout at the prompt. the boot(8) man page says: "prompt, which means you are in interactive mode and may enter commands. If you do not, boot will proceed to load the kernel with the current parameters after the timeout period has expired." and boot(8) also says: "If device or image are omitted, values from boot variables will be used." (I find a discrepancy between "current parameters" and "boot variables" but I take it to mean the same thing.) sysupgrade(8) says: "The bootloader will automatically choose /bsd.upgrade" I'm either missing something or one of these statements doesn't seem to be entirely true. I feel stuck with no options. -alfred On Fri, Jul 10, 2020 at 3:43 PM Theo de Raadt <dera...@openbsd.org> wrote: > Alfred Morgan <alf...@54.org> wrote: > > > Please, I have had this problem for several versions now and it still > isn't > > working right. > > I have this on all three of my servers: > > echo boot > /etc/boot.conf > > > > I have this boot.conf because openbsd fails to boot (on all three > servers) > > because it hangs on the boot> prompt because of some ghost input (I have > no > > keyboard plugged in). So I was told that putting "boot" in my boot.conf > > would solve the problem and it did the trick. BUT, sysupgrade now fails > > trying to upgrade 6.6 -> 6.7. So what can I put in my boot.conf that will > > ignore the ghost input in the boot> prompt and allow sysupgrade to > succeed? > > > > I feel that it's a bug in sysupgrade that it doesn't behave the same > having > > "boot" in the boot.conf. Any help? > > sysupgrade has nothing to do with this. the bootblocks decide to do > bsd.upgrade > instead, but if you've supplied it commands.... it does that instead. > > everything is working *precisely* as designed. > > As to what makes your keyboard controller do something wrong? That's > the real issue and needs a fix (who knows what), so the workaround is > causing you harm. > > But that's not really news, is it? There is always a cost associated > with workarounds.... >
