sommerfeld: Probably you would do something like what pivy-box does

And keep the symmetric key boxed in a property or whatever so that it can be unboxed via the agent

hi there, im having some "beginner" trouble with openindiana hipster last version. i ve tried it in vm on virtualbox, and after i get root credentials and update with pkg update, the next boot is not possible. i get on reboot illumos menu, i can choose some options but when i hit return , it goes to reboot. what im doing wrong? thx

Please don't DM random people Guest46

? whom i can ask for a "help" ?

Guest46 press esc to get to ok prompt and type: boot -k, or get to options menu and enable kmdb and press enter. are there any messages then?

🙏 ill write back as soon as possible, thank you tsoome

tsoome hi i just "replicated a whole process, fresh install, and than as root pkg update: i got this at the end: "A clone of openindiana exists and has been updated and activated.

On the next boot the Boot Environment openindiana-2026:09:10 will be mounted on '/'.

Reboot when ready to switch to this updated BE." if i reboot now ( im not root )  im i doing something wrong?

no. before reboot you can check beadm list, but no errors means you should be good.

beadm says this :  beadm list

BE                     Active Mountpoint Space  Policy Created

openindiana            N      /          12,21M static 2026-09-10 10:48

openindiana-2026:09:10 R      -          24,41G static 2026-09-10 12:13

yep, new be is present and active for next boot.

ok i ll reboot now :) :) thx

do not forget about -k

now i run into reboots again... and i escaped  in some rescue shell with boot -k  but ...i cannot ssh into now

it says just welcome to kmbd and i see some loaded modules...

enter: ::status

(its kernel debugger)

and ::msgbuf

::status = image uuid : (not set) ; DTrace state: inactive ( last line says stopped on: breakpoint (#bp) trap )

Version 7.2.16 r174877 (Qt6.8.0 on windows) thats my VB version

Virtual Box

sorry this could be pretty complicated, ill stop with this "research" thank you very much

🙏

ah, they not only published the paper on their backdoor analyzer/fuzzer arxiv.org/abs/2607.26719 but also made it usable (within that ROSA tool), github.com/binsec/rosa/tree/lily

Hi, I'm looking for one more +1 for my simple fix: code.illumos.org/c/illumos-gate/+/4968 could somebody take a look please? Also, how can I assign that Issue to me? I'm able to add a comment but probably not update the Assignee...

→ CODE REVIEW 4968: 17965 Want 64bit command touch(1) (NEW) | illumos.org/issues/17965

jsenolt: your account needs to be updated to allow you to edit issue metadata (jclulow can do that)

(and that also needs to happen before anyone can assign a bug to you)

ah, I see. Okay, I will try to find jclulow. And thanks a lot for the review!

(and having the bug assigned to you is not a prerequisite for sending out an RTI..)

great, I will start preparing te RTI then

[illumos-gate] 18341 ahci_mop_commands() corrupts aborted_tags -- Luqman Aden <luqman⊙oc>

Had an odd zfs problem today, system panic unable to mount root

Loader could see the pool and the BEs, and could boot from it, but the booted system couldn't see it

From a live environment, `zfs import` listed it correctly, but the actual import failed saying the device was missing

ok, so loader and the system have different zfs implementations

so at least that aspect makes sense, even if it sucks

ptribble: did you upgrade a format or enable a feature lately?

also loader and kernel have different device driver stacks.

Nothing about the pool or the OS had been touched since initial installation a month or os ago

loader does not depend on recorded device names or devid, but if you boot live environment, you should have carte blanch and import should use devices visible for os....

It gets powered off every day, this afternoon it failed to come back

you can try browsing the pool with zdb, prhaps it will reveal something about it?

Reinstalled as I needed to get work done and it looks OK (scrub clean)

depending on how adventureous you want to be, maybe try booting from alternate media, import the pool, move zpool.cache aside, rebuild boot archive?

The problem is that it's the import that fails; if I could import it at all then it's easy to fix

right, zpool.cache may be contributing factor there.

but there is no zpool cache in live environment....

why i was wondering if maybe that was the difference (and why it could be seen from a live env)...

when I have had this problem on arm, I debugged it through the mountroot etc.

because a lot of context disappears on the way through ZFS

but my problem was also my fault, and completely unrelated to ZFS, devices, etc.

asking loader what and where your disks are, and whether they match your recollection would be good

loader would cope with them moving, the OS wouldn't necessarily

(it would make much more effort than it used to though, so it seems unlikely)

Oh, loader saw the disk just fine. Partitioning etc looked right. What `zpool import` saw was exactly what I expected, it just refused to import the pool.

And what also surprised me was that the reinstall didn't complain about there being an existing pool on the disk either, where normally creating a new pool on an old disk involves some level of wiping labels.

So we have to conclude that it had to be something in uberblock ring or MOS itself.

Or hardware?

for hardware, loader would have been affected too.

what was the pool layout? single disk, no redundancy?

'zpool import' would just browse pool labels, I think.

but actual import would read much more.

Single SSD (it's my desktop, hence the need to get it back).

so metadata should have copies, but no redundancy otherwise.

I'm definitely seriously concerned about this

jbk, rmustacc: you work at places that are ZFS-pokers, you should keep up

*if* it was damaged metadata block and loader was able to go on, it would mean it was able to read a copy, unfortunately it wont report about that fact, it will only complain when reading all copies did fail.

with the pool recreated, I'm not sure how much forensic data is left.. it doesn't resemble anything we've seen

we do have another corruption fix that'll hopefully be going up for review soon...

Thanks, I'll just keep an eye on it

ptribble: scrub the fresh install pool maybe, too?

though it seems the chances of landing on the same cells is about 0

Done that, it comes back clean.

loader initial read of MOS does get 3 populated DVA's and when zio_read() failed with first, it got read done from second one. (just checked with gdb and userboot;)

that test was actually done with 3+1 pool, however.