Posts by viewmo

    I rolled back to a backup I had made before the botched update. And I re-ran the update today. Again via OMV's web GUI.

    This time there was no big scary error message.

    Halfway through the update being installed, there was an error of a different kind. It's a bit cryptic:


    Setting up libldap-2.4-2:arm64 (2.4.47+dfsg-3+deb10u6) ...
    Setting up php7.3-cli (7.3.27-1~deb10u1) ...
    Setting up libisccfg163:arm64 (1:9.11.5.P4+dfsg-5.1+deb10u3) ...
    Setting up php7.3-cgi (7.3.27-1~deb10u1) ...
    Setting up php7.3-fpm (7.3.27-1~deb10u1) ...
    Installing new version of config file /etc/php/7.3/fpm/pool.d/www.conf ...

    >>> *************** Error ***************

    <<< *************************************
    Setting up openmediavault (5.6.0-1) ...
    Installing new version of config file /etc/udev/rules.d/61-openmediavault-dev-disk-by-id.rules ...
    Creating configuration database ...
    Migrating configuration database ...


    I'm hoping it's nothing major. Just a config being updated on the fly or something. It doesn't give any hint of what went wrong.

    I checked for updates using OMV web GUI. I got a verbose error message.Distilling down to what seems like the main points:

    W: Conflicting distribution: buster-backports InRelease (expected buster-backports but got buster-updates)
    E: Repository ' buster-backports InRelease' changed its 'Origin' value from 'Debian Backports' to 'Debian'
    E: Repository ' buster-backports InRelease' changed its 'Label' value from 'Debian Backports' to 'Debian'
    E: Repository ' buster-backports InRelease' changed its 'Suite' value from 'buster-backports' to 'stable-updates'
    E: Repository ' buster-backports InRelease' changed its 'Codename' value from 'buster-backports' to 'buster-updates'
    E: Repository ' buster-backports InRelease' changed its default priority for apt_preferences(5) from 100 to 500. in /usr/share/openmediavault/engined/rpc/
    Stack trace:
    #0 /usr/share/php/openmediavault/rpc/ Engined\Rpc\Apt->Engined\Rpc\{closure}('/tmp/bgstatusJW...', '/tmp/bgoutputTW...')
    #1 /usr/share/openmediavault/engined/rpc/ OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
    #2 [internal function]: Engined\Rpc\Apt->update(NULL, Array)
    #3 /usr/share/php/openmediavault/rpc/ call_user_func_array(Array, Array)
    #4 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->callMethod('update', NULL, Array)
    #5 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('Apt', 'update', NULL, Array, 1)
    #6 {main}

    Anyone any ideas?

    Armbian 21.02.1 Buster

    Linux 5.10.12-meson64

    OMV 5.5.23-1

    Its not a home network, but home networks. ;)
    They are two separate networks.
    One is entirely offline. The other isn't.
    It's not that strange, no more than having two computers is strange.

    Maybe I'm using over-complicated language. The internet "network" is just a router that accesses the internet. No other resources.

    There is no WiFi connection on router 1 (router A above).
    Both routers have IPs outside the scope of each other.
    The NAS has static IPs.

    It is definitely possible. I'm using it that way for years on Ubuntu. I was having similar issues until the magic tick-box solved the issue.

    Why have you got it set up like this

    Why not?:P

    I want one network offline.

    I want internet access too, so I have a second router for that.

    Just to finish this post for anyone who comes across it in the future.
    I forgot to add that demsg listed no related error messages.
    And I'm running:
    openmediavault-luksencryption 5.0.2
    OMV 5.5.23-1

    Ok, after some digging around I found this 2017 forum post and if I understand it correctly, it seems to say there are no config files for the Encryption plugin and that once there is no instance of an Encrypted device listed on the plugin's page then you should be good to go.

    So I wiped the drive (Storage>File System>Wipe>Quick wipe) in question, then I created a new Encrypted device on the HDD and it all seems to be working fine.

    I've no idea what the error message was complaining about.

    I'd just created a LUKS container on a single entire HDD.
    I hadn't yet created a filesystem on it.

    I decided to redo the LUKS container so I deleted it via the Encryption plugin page.

    I locked the container first. Then the plugin's "Delete" option became activated.
    I hit delete and then this error appeared:

    Unable to remove encrypted device: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; dd if=/dev/urandom of='/dev/sdb' bs=512 count='' 2>&1' with exit code '1': dd: invalid number: ‘’

    The LUKS container instance was deleted from the plugin's page.

    I rebooted the system

    Any ideas where I should check that no traces have been left on the system?
    Or anyone understand what the error means (...maybe there are no traces?)

    There's nothing at all listed in /etc/crypttab
    (even though I have a second LUKS disk that is encrypted and working!)

    And the drive in question isn't in /ect/fstab either.
    (The working HDD is)

    Any help appreciated. Thanks

    Hi Macrom.
    Thanks for the reply.

    I commented the fstab line.
    No more mentions of the failed share in dmesg.:)

    Looking at /etc/openmediavault/config.xml
    There is only one set of remote mount plugin tags and they are empty

    I guess they correspond to the Remote Mount web interface page, which is also clear of any shares.

    That seems like job done to me.
    Unless plugins have their own configs?

    I was trying remote mount plugin for the first time.
    I set up the share but it failed to mount & it listed errors.
    The option to 'apply' or 'revert' was displayed so I hit 'revert'.

    Again an error was displayed but the failed share was deleted from the plugin's page.

    I rebooted.
    But traces of the failed remote mount attempt still remain.

    In dmesg I can see

    [ 9.802572] CIFS: Attempting to mount //
    [ 9.832640] CIFS: VFS: cifs_mount failed w/return code = -112

    Looking at /etc/fstab I can see the failed remote mount line still listed.

    To fix it do I manually delete the fstab line or is there a remote-mount plugin or OMV config file too?

    OMV 5.5.23-1

    remote-mount 5.0.3

    Thought I'd update this for anyone interested. The little DS3231 module works fine on the HC4.
    Unfortunately you can't just place it directly on the GPIO pins-- the case just about catches on it when you try to close it up again. So I got some GPIO cables on Ali Express and they allow it to fit neatly down the side.
    Tested on Armbian and Debian.

    You see, CMOS can be damaged, but it doesn't always fail completely.

    So the result a user might see might see would be unusual hardware behavior but without ever knowing what the cause was? Damn.

    It doesn't matter where you are or how reliable your local power is.

    I honestly thought it was dues to crappy US electrical utility companies with crappy standards (rolling black outs in California, Enron etc.) I need to research power surge protection some more.

    I have whole house surge suppression, mounted in my power panel

    I was hoping this was standard practice. I guess not.:(

    some major Linux distributions (openSUSE and Fedora) use it as their primary filesystem.

    Wow, didn't know that. That's quite encouraging, progress is being made. I still think I'll be leaving it to mature for a while longer.

    I myself use it on all my systems and did not have a problem yet (for what that counts...).

    Always good to hear real world experiences. Thanks.

    Sorry for late response.

    No need to apologize, you're under no obligation. I'm sure you're plenty busy. Thanks for your Debian netboot project. It got me out of a jam.

    This might be a bit cheeky (feel free to ignore) but I don't suppose you publish the source code for your project?

    ... hit by electricity spikes, lightening, his house could burn down, ...get a virus or be zapped by malware ...get hit by bus.

    Or, maybe COVID mutates and attacks Armbian! (gasp!....)

    Only need a plague of locusts and I'll have my own personal apocalypse.^^