[OpenIndiana-discuss] Sun Management Centre

[Toomas Soome]

> On 21. May 2024, at 12:15, Rainer Heilke <rheilke at dragonhearth.com> wrote:
> 
> ------ Original Message ------
> From "Toomas Soome via openindiana-discuss" <openindiana-discuss at openindiana.org <mailto:openindiana-discuss at openindiana.org>>
> To "Discussion list for OpenIndiana" <openindiana-discuss at openindiana.org <mailto:openindiana-discuss at openindiana.org>>
> Cc "Toomas Soome" <tsoome at me.com <mailto:tsoome at me.com>>
> Date 2024-05-21 12:42:46 AM
> Subject Re: [OpenIndiana-discuss] Sun Management Centre
> 
>> 
>> 
>>> On 21. May 2024, at 10:28, Rainer Heilke <rheilke at dragonhearth.com> wrote:
>>> 
>>> Just a quick update:
>>> I'll still try to see if I can find any OpenIndiana.org references to smc (not having found them yet, I suspect they were third party pages), but I don't think I'll get to play with RBAC. It seems my test system likes to lose any USB drives on reboot, and when/if I get them back, all data is gone. zpool is even telling me that one zpool has a property that has never existed on this box:
>>> This pool uses the following feature(s) not supported by this system:
>>>        com.klarasystems:vdev_zaps_v2
>>> cannot import 'Work': unsupported version or feature
>> 
>> We do not support com.klarasystems:vdev_zaps_v2, so you have used OpenZFS based implementation to create this pool. To create pool which is supposed to be shared between different systems, you need to either create it on illumos, or disable feature flags on creation and enable them as needed.
> I previously used one of the two drives on FreeBSD with OpenZFS, but the current pool (a mirror) was created under OpenIndiana/hipster. It seems zpool -a is seeing the old destroyed FreeBSD/OpenZFS, but not the current OI pool. Interesting. Also annoying. :/
>> 

This can happen when you have previous pool little bit “shifted” on disk, so you can read out (some) old pool labels. Typical case with FreeBSD is that pool was created on partitionless disk. Destroyed pool shouldn’t cause much grief, as the fact itself is recorded in pool labels (so you can still recover from accidental destroy), but if the original pool was exported or just left on disk as is, then there is high chance of creating mess. zpool destroy, zpool labelclear and zpool initialize are your friends in such case, but if you do have new data already on disk and want to make sure it is preserved, then more careful approach is needed.

rgds,
toomas

>> There is a work to build arm support, there are even some images to allow to run the current state of the work, but there is still much work ahead about supporting arm.
> That will be interesting. Thanks for the info.
> Rainer