Rockstor on Suse console messages

jmangan · January 6, 2021, 8:58am

I don’t know if this is the right place for this or if the issue has already been recognised but just in case it is useful…

I built a Leap 15.2 x86_64 installer as per the instructions on a Suse Leap 15.2 VM (Hyper-V host).

I ran that to create another VM in the same environment with three disks. I’ve installed to one and created a RAID 1 pool with the others.

Web interface works and seems to be fully functional but I’ve noticed a constant stream of messages on the console. I don’t know if I’ve messed something up, this is a known issue or I’ve found something you need to know about.

Screenshot%202021-01-06%20085740

phillxnet · January 6, 2021, 11:41am

@jmangan Hello again and thanks for the report. And well done on getting the Rockstor 4 installer built and installed.

So this to me looks unrelated to Rockstor code as such and likely something to do with how the kernel’s storage drivers are interacting with your Hyper-V host environment. I would look further afield for similar reports.

Also is there any more pointers earlier in the log as they may help with finding the context for this series of looping errors.
The main pointer so far is the:

[storvsc] Add. Sense: invalid command operation code

You could take a look in the main journal via:

journalctl

to see if there are any more pointers to help your search. But it’s definitely something not happy there somewhere. Let us know how your explorations go on this but my guess is that it’s kernel/hyper-visor related, i.e. an incompatibility or failure somewhere along the line. Sorry I can’t be of more help here. But there is likely more info in the main journal than what you are seeing on the terminal.

Our kernel for the Rockstor 4 release is exactly that of a fully updated Leap 15.2 currently:

github.com

rockstor/rockstor-installer/blob/master/rockstor.kiwi#L368


<package name="grub2"/>
<package name="grub2-arm64-efi" arch="aarch64"/>
<package name="grub2-branding-upstream"/>
<package name="grub2-i386-pc" arch="x86_64"/>
<package name="grub2-snapper-plugin"/>
<package name="grub2-x86_64-efi" arch="x86_64"/>
<package name="htop"/>
<package name="iproute2"/>
<package name="iputils"/>
<package name="jeos-firstboot"/>
<package name="kernel-default"/>
<package name="keyutils"/>
<package name="less"/>
<package name="lsof"/>  <!--for zypper ps-->
<package name="nano"/>
<package name="NetworkManager"/>
<package name="NetworkManager-branding-upstream"/>  <!--or branding-openSUSE-->
<package name="nfs-client"/>
<package name="open-iscsi"/>
<package name="openssh"/>
<package name="parted"/>

Hope that helps.

jmangan · January 6, 2021, 12:10pm

Much appreciated. I’ve just starting using Hyper-V so it could well be something I’ve missed.

I’ll keep playing with my VM in the meantime.

Thanks again.

jmangan · January 8, 2021, 8:28am

Well I’ve tried rebuilding and a couple of tweaks but I’ve still got the same error. The Leap 15.2 VM I built to build the installer doesn’t have the issue so it must be something I did.

On the ‘Change this’ line for RPM version I wasn’t sure what to put so left it as 4.0.4 - is this correct?

Thanks.

phillxnet · January 8, 2021, 9:12am

Or still something we do but is not default in Leap15.2. An example might be our smart info probe.

github.com

rockstor/rockstor-core/blob/master/src/rockstor/storageadmin/views/disk.py#L454-L463


    # try to establish smart availability and status and update db
    try:
        # for non ata/sata drives
        do.smart_available, do.smart_enabled = smart.available(
            do.name, do.smart_options
        )
    except Exception as e:
        logger.exception(e)
        do.smart_available = do.smart_enabled = False
else:  # We have offline / detached Disk db entries.

this in turn calls:

github.com

rockstor/rockstor-core/blob/052ad79639311110ea68b48bbcc8313607a8c6b9/src/rockstor/system/smart.py#L328-L335


def available(device, custom_options="", test_mode=TESTMODE):
    """
    Returns boolean pair: true if SMART support is available on the device and
    true if SMART support is enabled.
    Used by update_disk_state in views/disk.py to assess smart status
    :param device:
    :return: available (boolean), enabled (boolean)
    """

Which ends up running:

/usr/sbin/smartctl --info dev-name-here

Although the above dev-name and any custom options are handled by:

github.com

rockstor/rockstor-core/blob/052ad79639311110ea68b48bbcc8313607a8c6b9/src/rockstor/system/smart.py#L422-L434


def get_dev_options(dev_byid, custom_options=""):
    """Returns device specific options for all smartctl commands.  Note that in
    most cases this requires looking up the base device via get_base_device but
    in some instances this is not required as in the case of devices behind
    some raid controllers. If custom_options contains known raid controller
    smartctl targets then these will be substituted for device name.


    :param dev_byid:  device name as per db entry, ie by-id type without a path
    :param custom_options: string of user entered custom smart options.
    :return: dev_options: list containing the device specific smart options and
    the appropriate smart device target with full path.


    """

But from memory if no custom options have been specified, see:

http://rockstor.com/docs/smart/smart.html#disk-custom-s-m-a-r-t-options

then it should be just what we call internally the base device (no partitions) which is retrieved via:

github.com

rockstor/rockstor-core/blob/052ad79639311110ea68b48bbcc8313607a8c6b9/src/rockstor/system/osi.py#L1407-L1419


def get_base_device_byid(dev_byid, test_mode=False):
    """A by-id type name parser which simply removes any trailing partition
    indicators in a given dev_byid name. The remaining name will represent the
    base device ie:-
    dev_byid = ata-QEMU_HARDDISK_QM00005-part3
    base_dev_byid = ata-QEMU_HARDDISK_QM00005
    Given the structure of by-id type names this should always follow.
    At time of last update this function is used exclusively to derive the base
    name of a device for SMART interrogation purposes, ie currently called only
    by smart.py/dev_options which is a portal for pre-processing smart commands
    which have been found to be more reliable when acting on the base device ie
    not called on a partition but on the base device. Hence this functions part
    in dev_options pre-processing.

and a path is added and you have your device name.

Likely just the by-id name (with path) of the base device.

It’s worth executing the resulting command, as above, to see if this triggers the same error as then at least we have a very likely candidate. But it may be completely unrelated to this call. It’s just the only thing that springs to mind given your report of it not having been seen in the generic Leap 15.2 which, as far as I know, doesn’t by default do this smart capability/availability probe.

There is another probe we do using hdparm but that can be another post once we have check this smart probe’s potential side effect.

Yes that will do. If you subscribe to testing you will then be offered our 4.0.5 testing rpm but as that has a few too many changes it’s still only in testing and not in our Stable channel which currently only has a place holder of 4.0.4 as release candidate 5.

Hope that helps.

jmangan · January 11, 2021, 3:02pm

In the web console the SMART status of the drives is ‘Not Supported’ which makes some sense.

I’ve got the following devices:

And they all return the same information from the smartctl command:

I’m surprised they are shown as ‘thin provisioned’ because I allocated them fully at setup.

Does that help?