Hi!

I wonder if I can define a conflicting service in a service manifest?

In what sense? Two services that are mutually exclusive, so cannot both be running at the same time?

yes

opensmtpd <-> sendmail

Just have one declare an 'exclude_all' dependency on the other.

We use that for chrony, for example, so you don't have it and ntp and vmtools all trying to control the system clock.

thanks, will have a try

seems to work

svc:/network/opensmtpd:default (OpenSMTPD SMTP mail transfer agent)

State: offline since Thu Oct 24 13:36:18 2024

Reason: Service svc:/network/smtp:sendmail is running.

i also wonder if the service should be named smtp:opensmtpd instead of opensmtpd:default?

The mail service case is a bit more interesting, because you really want to make sure that the wrong service *never* runs, because that might lose mail

that's true, but I don't think I can do anything else. opensmtpd cannot start now until sendmail is disabled. hopefully it will never start again then ;-)

The manifest: github.com/thenktor/smf-manifest-opensmtpd/blob/main/opensmtpd.xml

@ptribble when upgrading Tribblix, bhyve zones should be destroyed beforehand and recreated?

You shouldn't need to, bhyve zones will be preserved across upgrades.

thanks! that missing in the docs, btw: "Any LX, alien, or S10 zones don't need to be touched;"

Sounds like a bug in the docs to me!

[illumos-gate] 16550 vmm: writing 1 byte into a region of size 0 -- Toomas Soome <tsoome⊙mc>

if I have a device which was discovered at boot (in the manner of pci_autoconfig), should I expect pcicfg, when it appears in the system, to leave it alone?

I don't think the big theory goes into it (though thanks rm), and the per-function comments describing "a potentially turbulent start up sequence" is, well, or at least seems in my brain, more accurate than I'd hoped

[illumos-gate] 16853 cpuid_pass_basic filling in wrong cpi_extd entry for CPUID_LEAF_EXT_21 -- Luqman Aden <luqman⊙oc>

richlowe: My expectation is that pcicfg would leave it alone.

rmustacc: do you happen to know approximately where we'd leave it alone?

I have just reached the point in my debugging where pcicfg has created a new dip from whole cloth (and named it "pseudo", to my chagrin), thenpowered down the device that pci_autoconfig had already created a dip for.

(it is about to reprogram it and power it back up again)

which is, in a sense, kind of the dream of what I was going for. I'd just rather it wasn't happening now, and by surprise

when I say "power" I mean in the "pcicfg_device_off" way, not necessarily _power_

I always forget hotplug makes that word important

what I did not, unfortunately, see is any attempt not to get into this path

Hmm. Normally on x86 my memory here is that the way this works is that the bridge ends up indicating it's hp capable and then on bridge events trigger pcicfg_configure which does the rest.

yeah, it appears that with an HP bridge with a device under it, right now, I throw the device away (it is attached, potentially, at this point!), and pcicfg a new one

this goes all manner of poorly

I'm in the HP pci configurator via the HP state sync taskq

if anyone is playing along, we're in github.com/illumos/illumos-gate/blo…mon/io/pciex/hotplug/pciehpc.c#L112 and everything that can go wrong, per the comment, apparently has.