Tribblix had a new release, so OmniOS CE will soon too, right?

darwin, omnios.org/schedule

thanks

I'm working to complete my migration from Nexenta to Proxmox. I had some underlying disk errors that a consultant helped me with. However, now I cannot login to my Nexenta box as either admin or root (using either my original password or the temp one I made for the consultant). Regular Linux is pretty straightforward for resetting the root

password. What about my Nexenta 3.x install? I know it's a combination of Debian and Solaris, so I'm not sure what my steps would be towards resetting that.

Anyone more plugged into the BHYVE side of things have cycles to see about this?

One of our customers got a bhyve to dump core with a NULL pointer inside umouse_request().

I shared some of what I found there on the FreeBSD ticket, but I'm initially restricted by customer confidentiality.

That someone else in FreeBSD-land might've seen this too is, oddly, a little encouraging.

fenix illumos#16579

BUG 16579: bhyve: xhci tablet device probe fails under recent Linux kernels (Closed)

↳ illumos.org/issues/16579 | code.illumos.org/c/illumos-gate/+/3529

Ahhh f*ck, customer may have been using pre-16579 SmartOS. :-/

I've found root password reset instructions for adding -s to the end of the $multiboot line. I don't have a $multiboot line. In Linux, I'd modify the kernel line. I can and get sent to single user mode, but singleuser mode still requires a root password to login.

I'm not sure if there's any way to avoid sulogin

mounting the disk somewhere else and changing the password is usually easier

I'm not sure where I'd find an elsewhere, though I haven't looked. Is there a free version out there I can push to a USB drive?

you might be able to try booting omnios or such off usb/cd and see of you can import their root volume (I've not used nexenta, but I'm assuming it's probably a zpool)

illumos does not allow passwordless boot, you need to use alternate media to boot from and then fix your system.

there are more complicated things you could try (booting with the debugger and patching the path to /sbin/init jumps to mind), but I'm not sure the result would be usable to do anything unless you could configure the console without being able to see what you're doing.

I'd do what jbk said, and hope there's no pool features or anything in the way