Posts by tmihai20

    If you ever do a test, you should try with a machine that only has UEFI boot, I think this is the issue. I honestly cannot explain why only that version booted on my H2. H2 does not have any other alternative in BIOS, it will always boot UEFI and only that. I hope you can replicate the issue I encountered and find a solution.

    I only wanted to boot GParted to partition a new HDD and it turned out to be a bigger issue than I thought. I will keep on using that working USB stick with SystemRescueCD that is working now (6.0.5, I guess, because this is the latest available one that worked for me). But please try to spend some time on this too. I thought I could use the integrated tools that OMV is offering and I was surprised to find out they are not working. I can help with debugging on my H2 that can only boot UEFI.


    I do not know how many of you are using H2 with OpenMediaVault (OMV), but I am and recently I had some weird issues. OMV has a backup plugin that uses either dd to create a backup image of the installation or fsarchiver. It also has the possibility to boot once into Clonezilla, Gparted or SystemRescueCD to perform a restore or more. I recently had to reinstall OMV because I had a backup that I could not restore anymore. I searched for a proper way to do a backup and I ran across a plugin that uses dd or fsarchiver.

    My main issue is that if I set my H2 to boot once into Clonezilla, Gparted or SystemRescueCD I get a black screen (all done from within OMV). There is no error on screen, I even tried using a monitor instead of the TV (that is conveniently closer to my H2), but it did not work. I then tried to boot Gparted or SystemRescueCD using an USB stick that I made with the recommended tools (RUFUS and some other tools that can write an ISO to a USB stick and make the USB stick bootable). I managed to get SystemRescueCD to boot only with the latest versio or RUFUS (3.8) after about an hour or debugging why my H2 does not boot from a stick that is working on other systems (that do not boot from UEFI only). That bootable USB stick is booting from UEFI on some other systems, only H2 is stubborn enough to not boot.

    Please help, I want to understand what I am doing wrong. I have a multiboot stick with several tools, ISO (Linux, Windows) that does not boot at all (I had to use an old USB stick to make it work). This multiboot UEFI capable USB stick works on other systems (again, booting from UEFI). What can I do to have it booting without so much trouble?

    I think I finally see where you are going but I still don't think it is correct. Just because a user changes their login shell and you specify that user for a cron job doesn't mean it should use their login shell to execute the job. Running them manually must be user an interactive shell (didn't look).

    Running a cron job manually through the GUI to have it finished successfully beats the whole idea of cron jobs. I am just saying that some people may encounter this because there are guides that tell people to change their login shells to bash. I am doing it manually on all the systems I am using. I have just checked and the cron job has been run successfully.

    bash was user for interactive and non-interactive shells before squeeze.

    I know, but it feels like it has been longer than that. Been using Ubuntu for work since 2011 now.

    So OMV should use the interactive shell for non-interactive purposes instead of the non-interactive shell?

    It may be so, but apparently jobs running in the non-interactive shell are not executed successfully because the interactive shell has been changed. Adding a job should work out of the box even if the users change the shell to bash (which a lot of users are doing). Running them manually from the GUI does not yield the error. Do you see my conundrum now?

    and I hate dash

    I cannot say I hate dash, but when a tool is causing more problems than it is useful, then I have a problem with that tool :) (especially if it has been forced by the distro).

    You changed the default interactive shell. The default non-interactive (scripting) shell is whatever /bin/sh is pointing to. It is defined very clearly here - And since OMV uses /bin/sh, how is OMV doing the wrong thing?

    I was expecting that /bin/sh would also be changed to the shell that I chose (different to the default shell). Maybe this is a Debian issue, since Debian did not change what /bin/sh was pointing to after the interactive shell was changed. I think this goes back a lot of releases for Debian/Ubuntu. I will probably change what /bin/sh is pointing to when I will have realized that cron jobs are not running anymore. Anyway, hopefully this will help others with the same issue. I will have confirmation that the issue is fixed only tomorrow.

    I was just thinking that maybe OMV should check what the interactive shell is and not use /bin/sh as a source (as /bin/sh will always point to what the distro wants to use by default and not to what the user is actually using). Debugging was a little difficult because I had to run the generated script myself to actually see what was wrong. On any Debian/Ubuntu system, a regular script using /bin/sh and not running properly would have already thrown those issues immediately. I have encountered the issue myself as I am using Linux and some colleagues had the issue after a fresh install or an upgrade (we are using bash as the go-to shell).

    Uh, the default shell of Debian is dash not sh. This is why sh is symlink'd to dash. So, OMV was doing the correct thing.

    Yes, I have changed the default shell to bash before doing this, I am always doing this. So, OMV is definitely not doing the right thing. I checked, the default shell was being reported as bash. This is what really puzzled me, /bin/sh was pointing to dash although the default shell was changed to bash.

    See above but I hope you changed the symlink the proper way. Otherwise, it will be reverted on upgrades (debian does this not OMV).
    echo "dash dash/sh boolean false" | debconf-set-selections
    dpkg-reconfigure dash

    As for re-configuring or change being reverted, I hope it will not be the case. There is something fishy somewhere. This is a simple thing that should work out of the box and it is not working for a long time now (since 3.x, if I remember correctly).

    I still had the issue with the cron jobs created in the GUI not running. It was puzzling that the jobs would run when manually executed from the GUI, but now when they were expected to run. I tried all the tips, even the ones that I found here. I modified the line to be executed to use absolute path to the binaries and not the name of the binary (/bin/chmod and not chmod), the jobs would still not run. I then had the great idea to run the scripts that OMV is creating in /var/lib/openmediavault/cron.d manually and I found that they were exiting with an error. I then realized that /bin/sh (specified in the scripts generated by OMV) is pointing to dash, even though I have specifically configured bash to be the default shell. This is a tiny, but crucial mishap that should be fixed somehow. OMV should generate those scripts using the default shell, not /bin/sh.

    I changed the symlink /bin/sh to point to bash and I hope that now my cron jobs in the interface will be running when they are scheduled to. This is probably a Debian issue, but OMV should use the default shell when creating any automatically generated scripts.

    Hello guys. I recently switched from an oDroid XU4 (HC1 and HC2 did not exist when I ordered my XU4 a few years ago) to an oDroid H2. I am glad OMV4 is now UEFI bootable. I installed it from an USB stick onto an NVME (H2 has 2 full SATA ports and one M.2 port). I had no issue with installation, I am using OMV since OMV 2.3 probably and I already know how to use it. The only issue that I have is that OMV is not showing the temperature in the dashboard overview. I am pretty pleased with the overall performance, but compared to XU4 (that was booting the kernel from a microSD card and the root filesystem from an 2.5 inches SSD connected via USB) there is not such a big difference, I do not feel like it is so much faster, but I am sure that the hardware power will be sensed when actually using it with Plex, FTP and Samba. H2 should be a lot more future proof than XU4 would be, even though OMV with XU4 should probably be supported for at least a few years (both are running 4.19.x kernels anyway).

    PS: I will upload photos as soon as possible. I am using H2 with a Type 1 case (using one 3.5 inches HDD for the moment) and a separate power button and it looks very, very cool (in a geeky way). The official cases from HardKernel are transparent and a real eye catcher.

    I didn't upgrade Debian. Volker is the OMV author and he did choose to Debian 9 for OMV 4.x but that has nothing to do with why the plugins are not maintained/ported to 4.x.

    I thought some plugins were dropped because of being difficult to maintain them with the new Debian and/or new version of OMV.

    I'm not sure what this statement means.

    When I said "you", I meant "you guys/gals that are in charge of OMV or at least maintaing OMV".

    You make them work although I don't know why you would. Most of the download plugins are just a start/stop. docker is still the best idea.

    If you say it is not worth it, then I will not get involved anymore with the downloader plugins. I can live with installing and configuring Deluge by myself. Deluge plugin was the only one I needed.

    You probably wanted to get rid of some packages because the components that we are discussing about were present there in the previous release of OMV. I know that you upgraded Debian. This situation happened for other when upgrading from OMV 2 to OMV 3. What would it mean to take over the plugins? Is there a github repo where the older plugin is present?

    I am sorry if I offended anyone, but I went from OMV 2 to 2 instances of OMV 3 and then to OMV 4. I has mostly everything in the latest version of OMV3, but my installation got messed up and I wanted to upgrade.

    I may have been also tired when I modified that Python code. I want an error free installation. Is that such a bad thing? I miss the Deluge integration within the GUI. I am not using any other downloaders. I also updated Plex by hand with help from I honestly do not see the benefit of running downloaders in Docker.

    Odd10: thank you for pointing that out. It seems that I did not pay enough attention to what I was doing and I copy pasted it wrong. This never happened on Linux (I was using KiTTY on Windows). My Python knowledge is close to zero :D

    I updated everything there was to be updated, but it seems that OpenMediaVault 4 is a little behind than OpenMediaVault 3 was in regards to fixes and updates. There are also lots of plugins missing in OMV 3, even after this long period of time of being in Beta. It is still in Beta. Enough offtopic about OMV now.

    I came here by looking for a solution to error. I applied the fixes described below, but the web interface would throw a new error on anything I would do with it (for instance, I tried adding a scheduled job):

    Error #0:
    OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; omv-mkconf cron 2>&1' with exit code '1': Failed to import the site module
    Error processing line 1 of /usr/lib/python3/dist-packages/zope.component-4.3.0-nspkg.pth:

    Traceback (most recent call last):
    File "/usr/lib/python3.5/", line 173, in addpackage
    File "<string>", line 1, in <module>
    File "/usr/lib/python3.5/", line 166, in <module>
    import functools as _functools
    File "/usr/lib/python3.5/", line 23, in <module>
    from weakref import WeakKeyDictionary
    File "/usr/lib/python3.5/", line 109
    def remove(wr, selfref=ref(self)), _atomic_removal=_remove_dead_weakref):
    SyntaxError: invalid syntax

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
    File "/usr/lib/python3.5/", line 580, in <module>
    File "/usr/lib/python3.5/", line 567, in main
    known_paths = addsitepackages(known_paths)
    File "/usr/lib/python3.5/", line 344, in addsitepackages
    addsitedir(sitedir, known_paths)
    File "/usr/lib/python3.5/", line 212, in addsitedir
    addpackage(sitedir, name, known_paths)
    File "/usr/lib/python3.5/", line 183, in addpackage
    import traceback
    File "/usr/lib/python3.5/", line 5, in <module>
    import linecache
    File "/usr/lib/python3.5/", line 8, in <module>
    import functools
    File "/usr/lib/python3.5/", line 23, in <module>
    from weakref import WeakKeyDictionary
    File "/usr/lib/python3.5/", line 109
    def remove(wr, selfref=ref(self)), _atomic_removal=_remove_dead_weakref):
    SyntaxError: invalid syntax in /usr/share/php/openmediavault/system/
    Stack trace:
    #0 /usr/share/openmediavault/engined/module/ OMV\System\Process->execute()
    #1 /usr/share/openmediavault/engined/rpc/ OMVModuleCron->applyConfig()
    #2 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
    #3 /usr/share/php/openmediavault/rpc/ call_user_func_array(Array, Array)
    #4 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
    #5 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatus04...', '/tmp/bgoutputV2...')
    #6 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
    #7 /usr/share/openmediavault/engined/rpc/ OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)
    #8 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, Array)
    #9 /usr/share/php/openmediavault/rpc/ call_user_func_array(Array, Array)
    #10 /usr/share/php/openmediavault/rpc/ OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
    #11 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
    #12 {main}

    I reverted changes and now the web interface is working normally again.

    I just upgraded to OMV 4 yesterday. I am in the same situation, I run OMV from an oDroid XU4, updated everything (kernel included). I am using a USB 3 3.5 inches external HDD that had SMART information on OMV 3.

    Really? it has been out for an hour. Obviously, the arm images wont stop. OMV 3.x is eol but the underlying OS is still supported by Debian/armbian. you dont have to upgrade asap.

    I thought OMV 4.x was out for a longer time and that some other OMV4.x arm images would be available. I am not requesting images at all. I am also not very eager to update. I like the fact that it has better mobile interface support. I am using an alternate Android app to do maintenance when I cannot use ssh.