Re: r352368 can't boot

> On 17 Sep 2019, at 14:21, Warner Losh <imp_at_bsdimp.com> wrote:
> 
> 
> 
> On Tue, Sep 17, 2019, 11:24 AM Toomas Soome <tsoome_at_me.com <mailto:tsoome_at_me.com>> wrote:
> 
> 
>> On 17 Sep 2019, at 13:09, Warner Losh <imp_at_bsdimp.com <mailto:imp_at_bsdimp.com>> wrote:
>> 
>> 
>> 
>> On Tue, Sep 17, 2019, 6:47 AM Toomas Soome <tsoome_at_me.com <mailto:tsoome_at_me.com>> wrote:
>> 
>> 
>> > On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko <kiri_at_truefc.org <mailto:kiri_at_truefc.org>> wrote:
>> > 
>> > Hi,all
>> > 
>> > Yesterday I've updated latest head (r352368) and rebuild
>> > 13.0-CURRENT. All went fine, but when I boot, it's stopped
>> > at boot stage. Then I typed `boot', booted normally and put
>> > login prompt and login go ahead. But `shutdown -r now',
>> > stopped at loader prompt same as login case. What happened?
>> > All I've done is whithin bhyve VM.
>> > 
>> > 
>> 
>> 
>> > Consoles: userboot  
>> > 
>> > FreeBSD/amd64 User boot, Revision 1.1
>> > (Mon Jun 18 16:11:55 UTC 2018 root_at_releng3.nyi.freebsd.org <mailto:root_at_releng3.nyi.freebsd.org>)
>> > Loading /boot/defaults/loader.conf
>> > xemit not found
>> > Error while including /boot/frames.4th, in the line:
>> >                h_el _at_ xemit
>> > 
>> > can't load 'kernel'
>> > 
>> > Type '?' for a list of commands, 'help' for more detailed help.
>> > OK 
>> > 
>> 
>> This is unfortunate case where the guest image has more recent boot scripts than hosts /boot/userboot.so has. I did push the fix for that issue to stable/11 and stable/12. The patch does introduce xemit word.
>> 
>> Such situation is unfortunate, but accident waiting to happen with this method where we are attempting to use bootloader (userboot.so) from older system to load  guest vm. 
>> 
>> Can we provide a fallback to xemit builtin for old systems without it? I believe we did this for other things as a transition. Forth has a way to do this, though we need to make sure we properly constrain what we pass to emit...
>> 
>> Warner
>> 
>> P.s. I'm at legoland this week, so I can't look at it for a bit.
>> 
> 
> Well, the only way to avoid such issue is to make sure the guest environment is providing all the needed bits, but since we do have interpreter inside the userboot.so and userboot.so is in host, this does set rather unfortunate limits what we can do.
> 
> Yes. I understand that we are limited in our scripts to somehow testing if xemit is a forth word and if not providing a fallback implementation of it in forth using emit.
> 
> 

done:)

rgds,
toomas