02:33:45 sommerfeld: Probably you would do something like what pivy-box does 02:34:21 And keep the symmetric key boxed in a property or whatever so that it can be unboxed via the agent 06:31:02 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 07:00:12 Please don't DM random people Guest46 07:01:11 ? whom i can ask for a "help" ? 08:17:46 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? 08:34:05 🙏 ill write back as soon as possible, thank you tsoome 10:33:47 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. 10:33:47 On the next boot the Boot Environment openindiana-2026:09:10 will be mounted on '/'. 10:33:48 Reboot when ready to switch to this updated BE." if i reboot now ( im not root )  im i doing something wrong? 10:35:11 no. before reboot you can check beadm list, but no errors means you should be good. 10:37:32 beadm says this :  beadm list 10:37:32 BE                     Active Mountpoint Space  Policy Created 10:37:33 openindiana            N      /          12,21M static 2026-09-10 10:48 10:37:33 openindiana-2026:09:10 R      -          24,41G static 2026-09-10 12:13 10:38:03 yep, new be is present and active for next boot. 10:38:27 ok i ll reboot now :) :) thx 10:40:38 do not forget about -k 10:45:28 now i run into reboots again... and i escaped  in some rescue shell with boot -k  but ...i cannot ssh into now 10:46:49 it says just welcome to kmbd and i see some loaded modules... 10:49:22 enter: ::status 10:49:34 (its kernel debugger) 10:50:06 and ::msgbuf 10:55:15 ::status = image uuid : (not set) ; DTrace state: inactive ( last line says stopped on: breakpoint (#bp) trap ) 10:58:04 Version 7.2.16 r174877 (Qt6.8.0 on windows) thats my VB version 10:58:20 Virtual Box 10:59:28 sorry this could be pretty complicated, ill stop with this "research" thank you very much 10:59:40 🙏 17:06:22 ah, they not only published the paper on their backdoor analyzer/fuzzer https://arxiv.org/abs/2607.26719 but also made it usable (within that ROSA tool), https://github.com/binsec/rosa/tree/lily 17:20:29 Hi, I'm looking for one more +1 for my simple fix: https://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... 17:20:30 → CODE REVIEW 4968: 17965 Want 64bit command touch(1) (NEW) | https://www.illumos.org/issues/17965 17:32:10 jsenolt: your account needs to be updated to allow you to edit issue metadata (jclulow can do that) 17:34:08 (and that also needs to happen before anyone can assign a bug to you) 17:36:05 ah, I see. Okay, I will try to find jclulow. And thanks a lot for the review! 17:36:49 (and having the bug assigned to you is not a prerequisite for sending out an RTI..) 17:44:15 great, I will start preparing te RTI then 20:06:27 [illumos-gate] 18341 ahci_mop_commands() corrupts aborted_tags -- Luqman Aden 20:08:01 Had an odd zfs problem today, system panic unable to mount root 20:08:37 Loader could see the pool and the BEs, and could boot from it, but the booted system couldn't see it 20:09:30 From a live environment, `zfs import` listed it correctly, but the actual import failed saying the device was missing 20:24:34 ok, so loader and the system have different zfs implementations 20:24:42 so at least that aspect makes sense, even if it sucks 20:25:04 ptribble: did you upgrade a format or enable a feature lately? 20:25:06 also loader and kernel have different device driver stacks. 20:27:19 Nothing about the pool or the OS had been touched since initial installation a month or os ago 20:27:49 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.... 20:28:04 It gets powered off every day, this afternoon it failed to come back 20:28:32 you can try browsing the pool with zdb, prhaps it will reveal something about it? 20:29:17 Reinstalled as I needed to get work done and it looks OK (scrub clean) 20:29:29 depending on how adventureous you want to be, maybe try booting from alternate media, import the pool, move zpool.cache aside, rebuild boot archive? 20:30:09 The problem is that it's the import that fails; if I could import it at all then it's easy to fix 20:30:10 right, zpool.cache may be contributing factor there. 20:30:57 but there is no zpool cache in live environment.... 20:32:31 why i was wondering if maybe that was the difference (and why it could be seen from a live env)... 20:38:25 when I have had this problem on arm, I debugged it through the mountroot etc. 20:38:31 because a lot of context disappears on the way through ZFS 20:38:48 but my problem was also my fault, and completely unrelated to ZFS, devices, etc. 20:40:26 asking loader what and where your disks are, and whether they match your recollection would be good 20:40:41 loader would cope with them moving, the OS wouldn't necessarily 20:40:58 (it would make much more effort than it used to though, so it seems unlikely) 20:42:16 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. 20:43:56 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. 20:44:10 So we have to conclude that it had to be something in uberblock ring or MOS itself. 20:44:24 Or hardware? 20:45:13 for hardware, loader would have been affected too. 20:45:37 what was the pool layout? single disk, no redundancy? 20:46:23 'zpool import' would just browse pool labels, I think. 20:46:53 but actual import would read much more. 20:47:01 Single SSD (it's my desktop, hence the need to get it back). 20:48:05 so metadata should have copies, but no redundancy otherwise. 20:49:14 I'm definitely seriously concerned about this 20:49:39 jbk, rmustacc: you work at places that are ZFS-pokers, you should keep up 20:52:37 *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. 20:52:56 with the pool recreated, I'm not sure how much forensic data is left.. it doesn't resemble anything we've seen 20:58:49 we do have another corruption fix that'll hopefully be going up for review soon... 21:00:16 Thanks, I'll just keep an eye on it 21:18:12 ptribble: scrub the fresh install pool maybe, too? 21:18:28 though it seems the chances of landing on the same cells is about 0 21:18:36 Done that, it comes back clean. 21:26:18 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;) 21:27:50 that test was actually done with 3+1 pool, however.