looking for a NUC to install SmartOS, is the 10th gen still not compatible? haven't been able to find any new info regarding this since 2020

they should boot now

thank you! is there any config needed on install or it works out of the box?

should just be out of the box.. though some bits like the onboard wireless may not work (wired ethernet should be fine though)

good to know. thanks again

hi there, i am looking to upgrade a smartos server and researching an Intel® Xeon® Silver 4310 setup, but see there are some issues with KVM vms, specifically:

We have a few KVM instances and I was wondering if there is any official documentation on converting these to BHYV or if a rebuild is recommended? My searches didn't turn up much, appreciate any thoughts

Yeah... I wish I had some Ice Lake HW to reproduce & fix this bug.

Could possibly get you access to it if you're interested

I'm imagining I'd need kmdb at the host AND the guest. (Assuming I couldn't find a possible fix via source-diving... in THAT case such a remote-access scenario becomes more plausible.)

I figured you'd need host access. I'll hit you up directly. Thanks

Hi all. I am deep trouble. We are updating Triton from version 20190912T054018Z to the latest version 20220825T001415Z. We have installed the latest platform image on the headnode and restarted the server. Then we updated sdcadm itself, GZ tools and agents tool. Everything went smoothly, but then we hit a roadblock. We are trying to update the manatee but it failed, and we cannot continue the update process.

Manatee primary and sync are ok, but async is in failed state. On async zone we have run “svcadm disable manatee-sitter” and “manatee-adm rebuild” command but without any success.

tealirc: What error are you getting?

Is the async the only issue you have, or are there other things wrong?

bahamat: We do not get any errors, but on the other hand nothing happens(?).

The rebuild process is asynchronous, so maybe it's running already.

I'm not sure. Async zone is still in failed state. We ran the command “manatee-adm rebuild” five hours ago.

check your manatee-sitter log

If the only thing wrong is that your async is failed, then you don't have anything to worry about. The system works fine without an async, you just need to make sure it's fixed before you attempt any upgrades of manatee or other manatee instances fail.

Indeed. The system works fine, but we cannot update the Triton core components and platform images, because the manatee async zone is failed state.

OK, well the first thing is that you'll need to figure out what state the rebuild process is in. To do that, you need to check the sitter log file.

tealirc : what was the result of "manatee-adm rebuild"? did it finish?

neuroserve: No, it is still on "infinite" loop.

I'm just collecting logs.

Logs: pastebin.com/mkcNzqAa

You should definitely not have that nay zfs recv processes running.

I am not sure if this matters, but manatee primary version is 20220825T001415Z, and sync/ async are version 20190912T054018Z.

No, that shouldn't particularly matter.

You'll need to figure out what's going on with zfs there. The sitter is unable to get the status of the recv, so it never sees it as complete.

One possible reason that it can't get the status is because you have so many zfs recv processes running. There should be exactly 1.

If you ran `manatee-adm rebuild` 34 times, that wasn't the best choice.

Could this log point to a problem? pastebin.com/JXDgJq9Y

bahamat: did you find the same issue with piranha? Or perhaps I was on a wrong version?

Smithx10: travisp was working on that.

tealirc: That doesn't provide any additional information.

did a zone stop/start and it seems to automatically begin the zfs receive operation without manatee-admin rebuild. And it seems that it starts new zfs recv's continuously leaving the previous ones still running

there's also a lot of ECONNREFUSED errors all over the log

That's because the zfs dataset hasn't been fully restored, so postgres is not running yet.

It will automatically start a recv if there's no data.

ah

from where is the send supposed to connect?

It will connect to the manatee-backupserver service on the next upstream peer. In this case, that will be the sync.

There's another underlying problem though. In the sitter log it says the progress is null. That should never be the case.

So you've probably got other underlying condition that's breaking zfs.

that might also explain why there's so many zfs recvs running.

Some possible places to look:

* disk full?

* delegated dataset exists?

* dataset is properly delegated to the zone?

should the /data/manatee exist before receive?

the /data is there

Yes, the dataset needs to exist.

ah... there's our problem, I presume

Use zfs list, don't just look for /data/manatee

It's mounted at /manatee/pg, not at /data/manatee

yeah, I see the uuid and uuid/data sets

nothing more

Use zpool history in the global zone to see if you can figure out who deleted it

I see it destroyed -r

I wonder if the upgrade script could've done it?

No, that's not how it works.

I would stop the zone and use sapiadm from the headnode to create a 4th manatee zone, and just Let It Be.

It should come up on its own automatically.

In any case, the sitter should be able to track progress.

If it works, then use sapi to destroy the defunct zone.

If it does not work, then you've got a bigger problem on your hands.

oki... we shall try that

thanks for the help :)