Posts by FredK

  • Configuring Home Assistant as a appliance with openmediavault-kvm plugin

    ryecoaaron

    Quote

    If you look at the openmediavault-kvm plugin, it has an Appliances menu and one of the options is to create a Home Assistant VM.

    I found your recent advice to use Services → KVM → VMs → Appliances → Install Home Assistant OS to integrate Home Assistant into OMV8.

    Two questions arose (up to now):

    1. Which Storage Pool has to be used, isos of volumes?
    2. What's the recommended network type? The default or the br0 bridge? Or the 2nd physical network interface of my Odroid H4+?

    Thank you in advance

  • Raid5 spontaneous resync?

    Is this truly a new MD scrub (indicated by a lower completion percentage), or is it simply the continuation of a original process that was suspended (high completion value)? The MD check will be suspended on high CPU usage and continued later. That's my understanding of the timers in /etc/systemd/system/mdmonitor.service.wants.


    Have a look at "Diagnostics -> Performance Statistics -> Load Average"

  • Raid5 spontaneous resync?

    nasuser_omv

    Please have a look at /etc/systemd/system/mdmonitor.service.wants/mdcheck_start.timer

    Once a month, to be more specific, at the first Sunday, a "MD array scrubbing" will be performed.


    You can observe the process using

    Code
    # cat /proc/mdstat

    My RAID5 is at 66,6% now.

  • Issues after migration of a RAID5

    Final remark:

    Since I was unable to identify the cause of the problems described, I decided to set up the system including restore of the existing backups from scratch. OMV is up and running again now.

  • Issues after migration of a RAID5

    Last try before creating a new MD.


    After the recovery of the degraded array I inspected the system via dmesg.


    Entries regarding md:

    Finding: sdb not operational as raid disk


    Entries regarding disks:

    Finding at [ 3.709424] sdb: sdb1
    /dev/sdb has a partition /dev/sdb1, consequence: the RAID magic is overwritten.

  • Issues after migration of a RAID5

    BernH

    Quote

    I never had to copy a mdadm config, as omv/mdadm will automatically see/assemble the raid based on the metadata stored on the drives

    My first approach was in deed not to copy the mdadm.conf -> Same result.


    Quote

    If I were you, after running through this issue several times now, I would cut my losses, make sure you have a current backup of the array, rebuild it via the omv multiple device plugin, and restore the backup.

    That's also my idea. One shot or at most two, then I'll build my arrray from scratch.

  • Issues after migration of a RAID5

    I run a omv-salt deploy run mdadm:

    Looked good IMHO.

    But after a reboot we see the same situation. One of the four disks had a wrong MBR magic (the RAID magic was overwritten. The 19 hour RAID recovery started.


    Something else I can't evaluate:

    Quote

    root@OMV:~# mdadm --examine --scan

    ARRAY /dev/md/Store5 metadata=1.2 UUID=092183f5:bd256db2:e0e9ce3e:765b1b34

    root@OMV:~# mdadm --detail --scan

    ARRAY /dev/md127 metadata=1.2 spares=1 UUID=092183f5:bd256db2:e0e9ce3e:765b1b34

    There is neither a /dev/md/Store nor a /dev/md.

  • Issues after migration of a RAID5

    The RAID5 has been recovered and the two actions described above have been performed.

    But I'm reluctant at this stage to reboot the system avoiding the next degraded array.

    Is there anything I can do? What about a omv-salt deploy run mdadm?


    cat /proc/mdstat

    Code
    Personalities : [raid0] [raid1] [raid4] [raid5] [raid6] [raid10]
md127 : active raid5 sda[4] sdb[0] sdd[2] sdc[1]
      23441685504 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 15/59 pages [60KB], 65536KB chunk

unused devices: <none>


    blkid


    cat /etc/mdadm/mdadm.conf


    mdadm --detail --scan --verbose

    Code
    ARRAY /dev/md127 level=raid5 num-devices=4 metadata=1.2 UUID=092183f5:bd256db2:e0e9ce3e:765b1b34
   devices=/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd


    mdadm --detail /dev/md127

  • Issues after migration of a RAID5

    I used for many years a Helios4 (32bit) with a RAID5 built on 4 8TB HDDs. Now Helios4 is no more under active maintenance, neither the OS-base (Armbian) nor OMV. So it was time to switch to another hardware. I chose Odroid H4+, containing 4 SATA ports as the Helios4. My plan was to migrate the RAID to the new platform avoiding to build the RAID from the backups.


    What I did was to copy the mdadm.conf ARRAY entry from the old NAS (Helios4) to the new one (ODROID H4+).The entry looked like

    ARRAY /dev/md/Store5 metadata=1.2 name=helios4:Store5 UUID=092183f5:<bla>:<bla>:765b1b34

    After some "mdadm --detail", "mdadm --examine" and "mdadm --assemble" the MD reappeared but the RAID magic of one disk was overwritten. Consequence: The MD had been flagged "degraded" (3 of 4 disks) and recovery took place. It was a game of about 15 hours and the MD was "clean", all data available and correct sub-entries in the OMV storage section.


    Sound good, but after a reboot the MD was "inactive". I was capable to assemble the MD using three of the four disks, but again one disk (not the same as before) lost the RAID magic. New recovery is in progress, expected finalized tomorrow (Wednesday ) 8:00 UTC+1.


    My question: What have I to do avoid a recovery for the third time?

    I learned from the forum two actions:

    1. Exchanging the ARRAY-entry in mdadm.conf with the output of "mdadm --detail --scan" which I expect to look like
      ARRAY /dev/md127 metadata=1.2 UUID=092183f5:<bla>:<bla>:765b1b34
    2. omv-salt deploy run initramfs

    Anything else?

  • Do you have an old version of 32-bit arm OVM?

    crashtest

    32bit support for my Helios4 is not a matter generally today, Armbian and OMV support the platform as long as only the NAS functionality is concerned. Another point of view is docker support for 32bit. That's the background of my plan

    > And I'll start developing a migration path to 64-bit, perhaps leaving the Helios4 for a while as a pure NAS, i.e. no docker support at all.

    As a pure NAS the system is unavailable from the internet by a specific VPN connection only.

    btw No 1: After nextcloud 26.0.2 was running finally, the system was upgraded successfully twice to 26.0.3 and 27.0.


    btw No 2: I worked in IT security for almost 20 years, most of that time at a large telco. If I'll experience the slightest indication of a security vulnerability the system will go offline if the vulnerability can't be mitigated. Regular security scans, e.g. https://scan.nextcloud.com/ will be performed. Today's rating: A.


    OTOH: In general I support your suggestion.

  • Do you have an old version of 32-bit arm OVM?

    Quote from FredK

    Thank you. I'll give it a try at next opportunity. I'll report.

    "Next opportunity" was today. My experiences:

    • Generation of nextcloud and swag were quite straightforward.
    • Generation of nextclouddb (mariadb) required much manual work, detected later at initalization of my new nextcloud.
      • I got "Error while trying to create admin user: Failed to connect to the database" with "Connection refused".
        First idea was to use the addional environment parameters MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD as described in https://docs.linuxserver.io/images/docker-mariadb and RE: Nextcloud with Letsencrypt using OMV and docker-compose - Q&A:
        No success.
      • I had a look into the nextclouddb log and found at the beginning:
        [Setting Up Initial Databases
        chown: cannot access '/auth_pam_tool_dir/auth_pam_tool': No such file or directory
        Couldn't set an owner to '/auth_pam_tool_dir/auth_pam_tool'.
        It must be root, the PAM authentication plugin doesn't work otherwise..

        chown: cannot access '/auth_pam_tool_dir': No such file or directory

        Cannot change ownership of the '/auth_pam_tool_dir' directory to the 'abc' user.

        Check that you have the necessary permissions and try again.


        Installing MariaDB/MySQL system tables in '/config/databases' ...
        2023-07-13 11:36:36 0 [ERROR] mariadbd: File '/config/log/mysql/mariadb-bin.index' not found (Errcode: 13 "Permission denied") 2023-07-13 11:36:36 0 [ERROR] Aborting

        To remedy the situation I created a symbolic link
        /auth_pam_tool_dir -> /usr/lib/mariadb/plugin/auth_pam_tool_dir
        and changed ownership and permissions appropriate für user abc.
        Result: Looking better but not good.
      • At the end of the nextclouddb log I found:
        2023-07-13 11:36:36 0 [Note] Starting MariaDB 10.6.13-MariaDB-log source revision a24f2bb50ba4a0dd4127455f7fcdfed584937f36 as process 166
        2023-07-13 11:36:36 0 [ERROR] mariadbd: File '/config/log/mysql/mariadb-bin.index' not found (Errcode: 13 "Permission denied") 2023-07-13 11:36:36 0 [ERROR] Aborting
        I created the mariadb-bin.index with ownership abc:abc
        Result: Initalization of my new nextcloud successful.

    I know my actions look as severe hacks and I'm not happy with them. And I can't anticipate possible nasty adverse effects. I'm open to repeat the mariadb part of the nextcloud armhf installation.


    And I'll start developing a migration path to 64-bit, perhaps leaving the Helios4 for a while as a pure NAS, i.e. no docker support at all. Parallely building a 64-bit OMV with nextcloud first, moving the RAID5 at a later time.

  • Do you have an old version of 32-bit arm OVM?

    Thank you. I'll give it a try at next opportunity. I'll report.

  • Do you have an old version of 32-bit arm OVM?

    Quote from Soma

    The time to move to arm64 is NOW (in this case). And I can see this happening to a huge amount of users that run armhf systems with Linuxserver images.


    For Nextcloud transition from armhf to arm64, I don't know if it will be just a matter of recreating the container on a new arm64 system.

    Maybe something to ask on their GitHub.

    I really like my Helios4 so I try to postpone switching to a new hardware until it gets completely unavoidable. Helios4 is a supported Armbian platform.


    I just found rather new "arm32v7-latest" packages on https://github.com/linuxserver/docker-nextcloud, https://github.com/linuxserver/docker-mariadb, https://github.com/linuxserver/docker-swag. Perhaps macom (author of the corresponding How-To) can comment. I could live with a fresh install of nextcloud because I'm the sole user.

  • docker not working since omv-upgrade

    Works for me. Simple but effective solution on my armbian (32-bit) Helios4.

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    I'm back in business after going back to "image: webhippie/mariadb:latest-arm32v6" and a restore of the last but one backup.

    I had to go this way because I didn't succeed with the latest mariadb image from webhippie which is release 10.6. I found several links where an incompatibility between nextcloud and mariadb 10.6 are described, e.g. https://github.com/nextcloud/docker/issues/1492


    I'll stay for a while with mariadb:latest-arm32v6 until the incompatibility will be resolved, instead of to try the workaround mentioned in the line above.


    EDIT:

    linuxserver/mariadb is at 10.5 → No incompatibility

  • Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

    Quote from Morlan

    Googling brings up this: https://til.codes/how-to-fix-e…ed-storage-engine-innodb/


    Be sure to take backups before changing anything

    Last night I found a similar link. But I had no success (I better should have mention this detail).

    The log says now:

    The nextcloud login screen appears now but after the logon I see the "Internal Server Error" again.