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

I don't have an answer yet, but I need to do that soon and should have a few better ideas.

ok no rush..

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.

that always helps

[illumos-gate] 15304 assert() could provide hints to compilers -- Andy Fiddaman <illumos⊙fn>

Anyone poking around on something like this yet? amazon.com/VisionFive-RISC-V-StarFive-JH7110-Quad-core/dp/B0BGM6STN8

No, But the Arm tools are intended to also cover Risc-v

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

And ACPI/UEFI and other bringups

Does anyone know why SMF services that disable themselves from the start method often start a "sleep 5" in the background before exiting?

We have 7 of them in gate that do that, but they seem to work without, although it could be to avoid a race

example: code.illumos.org/plugins/gitiles/il…usr/src/cmd/hotplugd/svc-hotplug#40

Solaris has $SMF_EXIT_TEMP_DISABLE of course...

Race avoidance might be the reason

had to code sleeps into non shell interactions with SMF a lot

something about the design needs it to not have SMF try restarting it endless

But I never figured out why

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.

Yep svcadm is somehow a bit async

But svcadm enable/disable have an explicit sync flag.

andyf: I forget the details but yes.

rmustacc: I haven't had any luck but that might be me

If I try it synchronously, I get a good error

# svcadm enable -s ipcc

svcadm: Instance "svc:/system/ipcc:default" has been disabled by another entity.

That's from within a method context?

toasterson: Trouble with it from within a method context or outside of it?

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)

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 :)

I just don't like magic like 'sleep 5 &'

From outside. But calling svccfg to fast after svcadm.

svcadm does not wait for the transition to complete

toasterson: OK, then we need to file bugs and get it fixed.

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.

rmustacc: Oh, OK will do was not aware it was a bug

it was not with -s

I mean, if you use svcadm enable -s and then svccfg fails, not sure how that can't be a bug.

Oh.

Well, try -s then.

It's exactly for that purpose.

Now that I know of it I will :)

I didn't find it in the manpages for some reason. Let me check if it's there

I see it there.

It's there. I'll have to check my script then.

It's been a while since I made the cleanup job for the buildserver

all good.

-s worked. Must have overlooked it. Now that script is a bit faster thanks :)

fenix 6245225

OpenSolaris issue 6245225: RFE: SMF_EXIT_DISABLE and SMF_EXIT_DISABLE_TEMPORARY (Accepted)

↳ illumos.org/opensolaris/bugdb/bug.html#!6245225

That bug has some detail on the need for the sleep

Thanks, andyf.

ahh nice...

that reminds me too.. I have a patch somewhere that might be useful with the console-login service

the idea is that if the console is one of the serial devices, it self-disables that instance

but it needs the ioctl that toomas added there to work

so things mostly figure itself out

issue 15320 (fenix)

FEATURE 15320: Add support for SMF_EXIT_TEMP_DISABLE (In Progress)

↳ illumos.org/issues/15320

that would be neat

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

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

I don't think anything has changed in that area though.

The only slightly unusual thing is that the rpool is a two disk stripe - I don't think that's very common

(it's just a test server)

spa_load(rpool, config untrusted): FAILED: couldn't get 'config' value in MOS directory [error=5]

I mean, it could be hardware failure, but the pool's importable and the first few MB of each disk is readable without errors

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.

v. if we pass guids where it will fall back into Josh's code and search

Oh, interesting, so "Cannot mount root on rpool/56407 fstype zfs"

that ID may not exist?

no that's a good one (I think), the bad one is the disk path

let me look

I did do things like forcing a full scan

and checking the retire store, etc.

bootfs, bootpool, bootvdev are good. bootpath is bad.

if you set bootpath zfs will trust it and never fall back to a search

I'm not sure it's the same problem, but where you're failing is where I would fail

because it would try to read the config off the bootpath, and then go down a blind alley

I'll take a look tomorrow (the server is turned off for the night)

but thanks for the pointer

andyf: if it is a stripe, it is not a single vdev pool so the /devices scan won't do anything for you

oof

(it requires enhancement)

(sorry!)

well it worked in as much as it built the same devid cache as before

I didn't think it was the problem, but I was poking all of the buttons

richlowe: I believe with this, your issue during bringup goes away right? illumos.org/issues/15122

→ BUG 15122: vdev_disk_preroot_fini can race against the child vdev open taskq (Closed) | code.illumos.org/c/illumos-gate/+/2498

jclulow: that was my race during boot, separate to bootpath being set and trusted way too much

ah

ok

your "just use this" patch would make that go away (without the full searh)

ah right

that's illumos.org/issues/15137

→ FEATURE 15137: ZFS should allow direct import of a root pool from a /devices path (Closed) | code.illumos.org/c/illumos-gate/+/2498

but I don't think andy can use that, because of the stripe

But also: won't help with a stripe

right

It doesn't look like it's struggling to find the devices

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

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

"children count mismatch" sounds exciting.

also like home alone

"spa_load_verify found 0 metadata errors and 1 data errors" seems to be the issue that makes it all fall down

1 data errors is bad

but yes, that's strange

and yet `zpool import` from a .iso boot works

interesting

feels like finding out what error it is will be valuable

It doesn't seem like your devices have moved around though

Yes, that's where I'll dig tomorrow.

although it might have WoL..

Yes it does :)

paste.ec/paste/N6mTTw-S#vqmJqXCIgxwvooU9y4VCzOa-V+GyJdtZ/t0Vl0lwo4u - not sure it tells me much yet, although error 0x32 is odd

ah, ECKSUM

(I should mention that this pool has been scrubber while imported from the installer shell)

*scrubbed