12:44:05 Hi! 12:44:47 I wonder if I can define a conflicting service in a service manifest? 12:51:46 In what sense? Two services that are mutually exclusive, so cannot both be running at the same time? 13:04:00 yes 13:04:15 opensmtpd <-> sendmail 13:05:25 Just have one declare an 'exclude_all' dependency on the other. 13:06:27 We use that for chrony, for example, so you don't have it and ntp and vmtools all trying to control the system clock. 13:33:33 thanks, will have a try 13:37:15 seems to work 13:37:29 svc:/network/opensmtpd:default (OpenSMTPD SMTP mail transfer agent) 13:37:29 State: offline since Thu Oct 24 13:36:18 2024 13:37:29 Reason: Service svc:/network/smtp:sendmail is running. 13:41:00 i also wonder if the service should be named smtp:opensmtpd instead of opensmtpd:default? 13:41:01 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 13:50:24 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 ;-) 14:31:08 The manifest: https://github.com/thenktor/smf-manifest-opensmtpd/blob/main/opensmtpd.xml 14:47:49 @ptribble when upgrading Tribblix, bhyve zones should be destroyed beforehand and recreated? 14:51:12 You shouldn't need to, bhyve zones will be preserved across upgrades. 14:59:31 thanks! that missing in the docs, btw: "Any LX, alien, or S10 zones don't need to be touched;" 15:12:20 Sounds like a bug in the docs to me! 19:10:45 [illumos-gate] 16550 vmm: writing 1 byte into a region of size 0 -- Toomas Soome 20:04:00 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? 20:13:45 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 21:33:03 [illumos-gate] 16853 cpuid_pass_basic filling in wrong cpi_extd entry for CPUID_LEAF_EXT_21 -- Luqman Aden 21:33:32 richlowe: My expectation is that pcicfg would leave it alone. 21:36:34 rmustacc: do you happen to know approximately where we'd leave it alone? 21:37:20 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. 21:37:42 (it is about to reprogram it and power it back up again) 21:37:56 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 21:38:34 when I say "power" I mean in the "pcicfg_device_off" way, not necessarily _power_ 21:38:41 I always forget hotplug makes that word important 21:39:32 what I did not, unfortunately, see is any attempt not to get into this path 21:47:28 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. 21:52:13 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 21:52:34 this goes all manner of poorly 21:54:35 I'm in the HP pci configurator via the HP state sync taskq 22:22:09 if anyone is playing along, we're in https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/pciex/hotplug/pciehpc.c#L112 and everything that can go wrong, per the comment, apparently has.