freebsd bhyve instance does not show kernel messages after boot screen

[tech-lists]

Hello list,

context is freebsd-12 r317212 host and freebsd-11-stable r333924 guest

I run this freebsd instance in screen. I start it like this:

vmrun.sh -c 4 -m 8192M -t tap3 -d fbsd-guest.img fbsd-guest

It starts, I get the daemon screen, then this:

/boot/kernel/kernel text=0x70572d data=0xa5648+0x340ac0
syms=[0x8+0xc0c78+0x8+0xde421]
/boot/entropy size=0x1000
Booting...
Unhandled ps2 mouse command 0xe1

and that's it. The guest loads, is functional, I can ssh into it, etc.

Other freebsd-11 VMs started in the exact same way on the same server
give the expected messages scrolling up when the VM starts. Why is this
VM different and how can I fix? There was a time when the messages were
displayed, then one day they didn't.

I've built/installed a new world/kernel on this VM to no effect.

thanks,
--
J.
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[David P. Discher]

Try in /boot/loader.conf of the VM :

console=userboot

or after beastie drop to loader OK promot and try :

set console=userboot

I think 11.x should fall back to userboot in bhyve if vidconsole of comconsole were set.

(This is assuming non-EFI booting - using bhyveloader ).

--
David P. Discher
https://davidpdischer.com/
408.368.3725 • d...@dpdtech.com

[tech-lists]

On 14/06/2018 23:26, David P. Discher wrote:
> Try in /boot/loader.conf of the VM :
>
> console=userboot
>
> or after beastie drop to loader OK promot  and try :
>
> set console=userboot
>
> I think 11.x should fall back to userboot in bhyve if vidconsole of
> comconsole were set.
>
> (This is assuming non-EFI booting - using bhyveloader ).

Hi,

Thanks for trying to help. I tried it both ways - in loader.conf and
from the loader prompt but unfortunately it didn't work. For
clarification, here's the exact way I start the VM:

1. $ screen -S fbsd11-vm
2. $ sudo su -
3. # (cd to where vm is)
4. sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 8192M -t tap3 -d
fbsd-guest.img fbsd-guest

If I transfer the VM to a freebsd-11 host (r333874) it also happens. So
the behaviour is a property of the VM. Unless of course the issue is
with bhyve itself on both -stable and -current.

A possible clue (but I'm really out of my depth here) is ISTR something
like this happening if say the VM is called say fbsd-guest and is then
subsequently launched with some other name like fbsd11guest.

Any ideas?

[Rodney W. Grimes]

> On 14/06/2018 23:26, David P. Discher wrote:
> > Try in /boot/loader.conf of the VM :
> >
> > console=userboot
> >

> > or after beastie drop to loader OK promot ?and try :
> >
> > set console=userboot
> >
> > I think 11.x should fall back to userboot in?bhyve if vidconsole of

> > comconsole were set.
> >
> > (This is assuming non-EFI booting - using bhyveloader ).
>
> Hi,
>
> Thanks for trying to help. I tried it both ways - in loader.conf and
> from the loader prompt but unfortunately it didn't work. For
> clarification, here's the exact way I start the VM:
>
> 1. $ screen -S fbsd11-vm
> 2. $ sudo su -
> 3. # (cd to where vm is)
> 4. sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 8192M -t tap3 -d
> fbsd-guest.img fbsd-guest
>
> If I transfer the VM to a freebsd-11 host (r333874) it also happens. So
> the behaviour is a property of the VM. Unless of course the issue is
> with bhyve itself on both -stable and -current.
>
> A possible clue (but I'm really out of my depth here) is ISTR something
> like this happening if say the VM is called say fbsd-guest and is then
> subsequently launched with some other name like fbsd11guest.
>
> Any ideas?

With the VM shutdown look in /dev/vmm for the same name as the VM,
if you see it there, make sure you do not have a running instnace
of it, then do:
bhyvectl --destroy --name=fbsd11-vm

You may have remanants of a prior/crashed VM hanging around
causing you issues.


--
Rod Grimes rgr...@freebsd.org

[tech-lists]

On 15/06/2018 15:02, Rodney W. Grimes wrote:
> With the VM shutdown look in /dev/vmm for the same name as the VM,
> if you see it there, make sure you do not have a running instnace
> of it, then do:
> bhyvectl --destroy --name=fbsd11-vm
>
> You may have remanants of a prior/crashed VM hanging around
> causing you issues.

Unfortunately this made no difference either.

If someone can tell me what to do to debug [1] this, I'll make a problem
report?

[1] unfortunately debugging this particular thing is outside of my realm
of expertise. I know how to start/stop bhyve but not much else outside
of that.

thanks,
--
J.