does propolis had bhyve-api and crucible upstairs build in? I mean when compiled propolis, does them be compiled and packaged within ?

tozhu: Yes, when you build a Rust binary, generally all of the library crates that it uses are built into a single executable.

So the crucible client library (known also as "the upstairs") is compiled into "propolis-server" and so on.

jclulow, Thank you very much

I have one machine wit ha minor loader issue after updating to today's bits.

I updated 2 machines without any problem, so I don't think the build is fundamentally broken.

But the third no longer boots automatically - I don't see the 3..2..1 countdown, just a flashing cursor (ish) bottom left.

Hit return and it boots up just fine - fortunately this isn't a headless machine.

Do you have a sense of what it went from and to? I'm not going to be around much but I think helping figure out what's on the scene will help.

Not sure if we're looking at things that say landed in the last few months or years.

The old working build was March 27th (b45434de9824c9c75b495234de67668cbaabddab aka 16323 to be precise)

ptribble is it bios or uefi loader?

flashing cursor is bios, ofc silly me

without countdown and loader still responsive, the only plausible explanation is that it got spurious keypress event.

ptribble: You know, I feel like I've had that happen on a machine too

I ended up putting autoboot_delay="0" in a conf.d file to make it boot automatically

It's definitely EFI

It ends up stuck with a "/" character, like the spinner has stopped spinning

bios, I presume based on its age

I get the normal loader menu, and can interact with it normally, it's just the autoboot that seems awry

It's been updated for every Tribblix release since I got it, so it's possible there's some debris lurking, but the other machines are even older

Interesting.

So what jclulow said, setting the boot delay to 0 seems to work, in that it automatically boots.

Having it set to 3, or unset, seemed to fail.

I still say its about those "phantom" keypresses, but the question would be, is it just startup issue or entirely random.

ptribble if you have time to check, we actually do have loop in vidc_init() to clean random keypresses, but the loop is limited up to 10 iterations, can you remove the condition i < 10 and see if it will get better? its usr/src/boot/i386/libi386/vidconsole.c line 1107

Could be slightly tricky (the system affected is my primary development machine so is in constant use) but I'll see if I can take a look

ah. btw, does it have serial ports?

ok, bios version should drain random data on port setup in comconsole.c, so that should not be the case.

That's the other thing I just thought of - my SPARC box is connected to the serial port, but is powered off (if it's powered on, especially if it's booting, that causes absolute havoc)

because sparc does diag output on serial port:)

on ttya, if my memory serves:)

we had a customer system that had an rj45 serial port... they had mistakenly hooked up an ethernet port to it (despite the documentation)... for the longest time it'd stop the countdown timer in loader and we couldn't figure out why until someone went onsite

we started to wonder if maybe their site was built over an old burial ground :)

:D

'that's not supposed to be in there'... unplug it and the problem went away

I have done this, or similar, with two systems set up to be eachother's console, flipped the cables

I also remember when spanning-tree was new to consumer stuff, and end-users plugging cables could end the world.