03:53:15 <jbk> rmustacc: i don't suppose you thought any about the topo map stuff? basically an internal NVMe slot w/ a label, and the right 'place' (probably not the right term) to enumerate it
04:55:10 <rmustacc> I don't have an answer yet, but I need to do that soon and should have a few better ideas.
05:02:54 <jbk> ok no rush..
05:04:36 <rmustacc> But I have a board with an internal M.2 slot I have to do that for so hopefully I'll have not just an example but useful topo stuff as well there.
05:05:04 <jbk> that always helps
10:00:17 <gitomat> [illumos-gate] 15304 assert() could provide hints to compilers -- Andy Fiddaman <illumos⊙fn>
16:23:52 <copec> Anyone poking around on something like this yet? https://www.amazon.com/VisionFive-RISC-V-StarFive-JH7110-Quad-core/dp/B0BGM6STN8
16:50:03 <toasterson> No, But the Arm tools are intended to also cover Risc-v
16:50:37 <toasterson> So once we have the loader changes to ARM Risc-V only requires the Headers to be ported and somebody to verify the specs with the headers
16:51:03 <toasterson> And ACPI/UEFI and other bringups
17:11:08 <andyf> Does anyone know why SMF services that disable themselves from the start method  often start a "sleep 5" in the background before exiting?
17:11:38 <andyf> We have 7 of them in gate that do that, but they seem to work without, although it could be to avoid a race
17:11:40 <andyf> example: https://code.illumos.org/plugins/gitiles/illumos-gate/+/refs/heads/master/usr/src/cmd/hotplugd/svc-hotplug#40
17:12:03 <andyf> Solaris has $SMF_EXIT_TEMP_DISABLE of course...
17:12:16 <toasterson> Race avoidance might be the reason
17:12:35 <toasterson> had to code sleeps into non shell interactions with SMF a lot
17:12:59 <toasterson> something about the design needs it to not have SMF try restarting it endless
17:13:10 <toasterson> But I never figured out why
17:13:40 <andyf> http://bnsmb.de/solaris/My_Little_SMF_FAQ.html says it was discussed on an opensolaris list at one time, and that it's fine, but of course the link to the discussion is dead.
17:13:43 <toasterson> Yep svcadm is somehow a bit async
17:14:39 <rmustacc> But svcadm enable/disable have an explicit sync flag.
17:14:46 <jlevon> andyf: I forget the details but yes.
17:15:06 <toasterson> rmustacc: I haven't had any luck but that might be me
17:15:17 <andyf> If I try it synchronously, I get a good error
17:15:18 <andyf> # svcadm enable -s ipcc
17:15:18 <andyf> svcadm: Instance "svc:/system/ipcc:default" has been disabled by another entity.
17:15:31 <rmustacc> That's from within a method context?
17:15:57 <rmustacc> toasterson: Trouble with it from within a method context or outside of it?
17:16:12 <andyf> the start method is running `svcadm disable $SMF_FMRI` - my attempt to enable it from the shell has the -s flag. Without that flag I just get the prompt back (but the service is properly disabled)
17:16:24 <jbk> andyf: at least there's like information there -- i spent a good chunk yesterday afternoon figuring out why a service was (essentially) bricking a system with 'Hardware is invalid' error :)
17:16:26 <andyf> I just don't like magic like 'sleep 5 &'
17:16:31 <toasterson> From outside. But calling svccfg to fast after svcadm.
17:16:45 <toasterson> svcadm does not wait for the transition to complete
17:16:56 <rmustacc> toasterson: OK, then we need to file bugs and get it fixed.
17:17:24 <rmustacc> I have encountered bugs with -s there and we've tried to fix them. If something like svcadm -s isn't working it's important folks report it and we try to fix it.
17:17:28 <toasterson> rmustacc: Oh, OK will do was not aware it was a bug
17:17:48 <toasterson> it was not with -s
17:17:49 <rmustacc> I mean, if you use svcadm enable -s and then svccfg fails, not sure how that can't be a bug.
17:17:52 <rmustacc> Oh.
17:17:57 <rmustacc> Well, try -s then.
17:18:14 <rmustacc> It's exactly for that purpose.
17:18:21 <toasterson> Now that I know of it I will :)
17:19:09 <toasterson> I didn't find it in the manpages for some reason. Let me check if it's there
17:21:18 <rmustacc> I see it there.
17:21:38 <toasterson> It's there. I'll have to check my script then.
17:21:54 <toasterson> It's been a while since I made the cleanup job for the buildserver
17:23:14 <rmustacc> all good.
17:25:00 <toasterson> -s worked. Must have overlooked it. Now that script is a bit faster thanks :)
17:29:01 <andyf> fenix 6245225
17:29:02 <fenix> OpenSolaris issue 6245225: RFE: SMF_EXIT_DISABLE and SMF_EXIT_DISABLE_TEMPORARY (Accepted)
17:29:02 <fenix> ↳ https://illumos.org/opensolaris/bugdb/bug.html#!6245225
17:29:47 <andyf> That bug has some detail on the need for the sleep
17:31:32 <rmustacc> Thanks, andyf.
17:51:44 <jbk> ahh nice...
17:52:08 <jbk> that reminds me too.. I have a patch somewhere that might be useful with the console-login service
17:52:36 <jbk> the idea is that if the console is one of the serial devices, it self-disables that instance
17:52:55 <jbk> but it needs the ioctl that toomas added there to work
17:53:55 <jbk> so things mostly figure itself out
18:58:52 <andyf> issue 15320 (fenix)
18:58:56 <fenix> FEATURE 15320: Add support for SMF_EXIT_TEMP_DISABLE (In Progress)
18:58:56 <fenix> ↳ https://www.illumos.org/issues/15320
20:08:26 <jclulow> that would be neat
21:11:15 <andyf> I'm looking at a weird problem with one of hadfl's servers. It's started to fail to vfs_mountroot with NOTICE: zfs_parse_bootfs: error 5
21:11:54 <andyf> but the loader can see the filesystem and pool fine, and the pool can be imported if you boot from CD to the installer shell
21:12:17 <andyf> I don't think anything has changed in that area though.
21:12:37 <andyf> The only slightly unusual thing is that the rpool is a two disk stripe - I don't think that's very common
21:12:42 <andyf> (it's just a test server)
21:17:15 <andyf> spa_load(rpool, config untrusted): FAILED: couldn't get 'config' value in MOS directory [error=5]
21:17:45 <andyf> I mean, it could be hardware failure, but the pool's importable and the first few MB of each disk is readable without errors
22:30:10 <richlowe> That is the basic problem I hit during bringup, whereby if we pass a bootdev via the loader zfs trusts it _regardless_ of any sense of reality, then fails.
22:30:19 <richlowe> v. if we pass guids where it will fall back into Josh's code and search
22:30:58 <andyf> Oh, interesting, so "Cannot mount root on rpool/56407 fstype zfs"
22:31:03 <andyf> that ID may not exist?
22:31:20 <richlowe> no that's a good one (I think), the bad one is the disk path
22:31:23 <richlowe> let me look
22:31:28 <andyf> I did do things like forcing a full scan
22:31:33 <andyf> and checking the retire store, etc.
22:32:03 <richlowe> bootfs, bootpool, bootvdev are good.  bootpath is bad.
22:32:21 <richlowe> if you set bootpath zfs will trust it and never fall back to a search 
22:33:26 <richlowe> I'm not sure it's the same problem, but where you're failing is where I would fail 
22:33:52 <richlowe> because it would try to read the config off the bootpath, and then go down a blind alley
22:33:59 <andyf> I'll take a look tomorrow (the server is turned off for the night)
22:34:04 <andyf> but thanks for the pointer
22:43:42 <jclulow> andyf: if it is a stripe, it is not a single vdev pool so the /devices scan won't do anything for you
22:43:48 <richlowe> oof
22:43:51 <jclulow> (it requires enhancement)
22:43:54 <jclulow> (sorry!)
22:44:18 <andyf> well it worked in as much as it built the same devid cache as before
22:44:32 <andyf> I didn't think it was the problem, but I was poking all of the buttons
22:46:51 <jclulow> richlowe: I believe with this, your issue during bringup goes away right? https://www.illumos.org/issues/15122
22:46:52 <fenix> → BUG 15122: vdev_disk_preroot_fini can race against the child vdev open taskq (Closed) | https://code.illumos.org/c/illumos-gate/+/2498
22:47:20 <richlowe> jclulow: that was my race during boot, separate to bootpath being set and trusted way too much
22:47:23 <jclulow> ah
22:47:25 <jclulow> ok
22:47:43 <richlowe> your "just use this" patch would make that go away (without the full searh)
22:47:54 <jclulow> ah right
22:48:02 <jclulow> that's https://www.illumos.org/issues/15137
22:48:05 <fenix> → FEATURE 15137: ZFS should allow direct import of a root pool from a /devices path (Closed) | https://code.illumos.org/c/illumos-gate/+/2498
22:48:10 <richlowe> but I don't think andy can use that, because of the stripe
22:48:13 <jclulow> But also: won't help with a stripe
22:48:15 <jclulow> right
22:48:32 <andyf> It doesn't look like it's struggling to find the devices
22:49:02 <jclulow> Broadly speaking, the enhancement we need is mildly architectural: we need to do the early boot scan, which we can do, but then we need to keep it around _and use it_ to locate all of the vdev disks, some of which we open a few times
22:49:30 <andyf> https://paste.ec/paste/kMazd-yB#yQ9NxMLg12oRpk7q5nzgaJPaXL8vXtyZygFPS-JTnNH
22:49:41 <jclulow> to basically open by (pool_guid, vdev guid) when we cannot open by /devices path or devid -- or, worse, if we _can_ open by those paths but the guids are not as we expect
22:50:14 <richlowe> "children count mismatch" sounds exciting.
22:50:19 <richlowe> also like home alone
22:50:24 <andyf> "spa_load_verify found 0 metadata errors and 1 data errors" seems to be the issue that makes it all fall down
22:50:25 <jclulow> 1 data errors is bad
22:50:30 <andyf> but yes, that's strange
22:50:53 <andyf> and yet `zpool import` from a .iso boot works
22:50:59 <jclulow> interesting
22:51:28 <jclulow> feels like finding out what error it is will be valuable
22:51:59 <jclulow> It doesn't seem like your devices have moved around though
22:52:43 <andyf> Yes, that's where I'll dig tomorrow.
22:53:06 <andyf> although it might have WoL..
22:54:08 <andyf> Yes it does :)
23:06:31 <andyf> https://paste.ec/paste/N6mTTw-S#vqmJqXCIgxwvooU9y4VCzOa-V+GyJdtZ/t0Vl0lwo4u - not sure it tells me much yet, although error 0x32 is odd
23:07:41 <andyf> ah, ECKSUM
23:09:34 <andyf> (I should mention that this pool has been scrubber while imported from the installer shell)
23:11:01 <andyf> *scrubbed