Beiträge von mauromol

    Systemd unit file. systemctl is-enabled openmediavault-engined.service

    Thanks, I'll try!




    You still make it sound like it should be simple. I still don't know how other NASes do it. What if a drive is missing or has a different UUID or something else hardware related has changed? Maybe they don't have the hierarchy in the database like OMV where if a filesystem is gone, it screws up sharedfolders which would break plugins. Either way, it won't be me creating it and I think it will be a pain in the ass. I would rather just use lvm or btrfs snapshots to revert to a prior state on the OS drive.


    I think OMV could just skip those preferences that can't be restored. Which is, I'm pretty sure, what other NASes do... A nice to have feature could be a final report that says which settings could not be restored, but as a first step simply skipping what can't be restored would be enough. I still believe that in a "normal" situation (a system upgrade by reinstall, for instance, or a boot drive failure with no backup at hand) this would help a lot.

    The init script is not needed. The openmediavault-engined unit file takes its place. I would make sure that unit file is enabled and try omv-mkconf monit

    What do you mean exactly by "unit file" and how can I check if it's in place / enabled?



    Actually it was in OMV 0.2. Just didn't work well. How do you restore your Windows config?? I work with many things that don't have a config restore. VMware is a huge one. Plenty of appliances have restores but most OSes don't. FreeNAS does but it is a commercially supported product. OMV is targeted at home users who usually don't have a complicated config and really just need a backup.

    I personally see OMV more like an appliance rather than an OS. Or, at least, I miss the feature to save settings I can change through the web UI. Saving and restoring the whole OS configuration is obviously a different story, but if we assume the basic OMV configuration can be done entirely through the UI, having the ability to export and restore all the settings the user can change from the UI would be a big plus. Exactly what all the other "embedded" NAS systems do.
    Of course, if I customise the system by changing the underlying Debian configuration, I should then take care or restoring all my customisation if I reinstall the system: I don't expect OMV to make it for me with an export/restore configuration operation.

    Returning back on topic, I disabled and removed all the services and scripts regarding openmediavault in /etc/init.d, but now when I start the system monit alerts that:


    [pre]
    Does not exist Service omv-engined


    Date: Wed, 31 Jul 2019 21:47:18
    Action: restart
    Host: openmediavault.local.lan
    Description: process is not running


    Your faithful employee,
    Monit
    [/pre]


    And then monit restarts this service (I guess by running the omv-engined command directly, since the script in /etc/init.d was removed...):


    [pre]
    Exists Service omv-engined


    Date: Wed, 31 Jul 2019 21:47:51
    Action: alert
    Host: openmediavault.local.lan
    Description: process is running with pid 1440


    Your faithful employee,
    Monit
    [/pre]


    Before removing omv-engined I saw that it was indeed running. So the question now is: is it needed (and hence I should restore it) or it's just some configuration of monit that needs to be changed (to avoid it to restarting omv-engined)?


    P.S.: how the hell can I insert a piece of preformatted text without formatting it as "source code" in this forum? X/

    While it sounds like a basic thing, it is very difficult to implement. With the upcoming features in OMV 5.x, it will be easier to implement but I don't know if it is on the 5.x radar. Probably a 6.x feature.Yes. Personally,

    Basic feature does not necessarily mean "easy to implement", but it's indeed a basic feature that all network devices (routers, NASes, SANs, etc.) have and has had for years, ranging from home and SOHO products up to professional products. So I still believe it's a major lack in OMV, especially if we consider we're at version 4.x already...



    Yes. Personally, I think this is good for people for go through this process so they don't forget how to do the setup. Helpful for disaster recovery.

    Well, this is certainly an optimistic point of view! :D

    As I side note: I decided to try the update from 2.x to 3.x even though it was suggested to perform a new installation because I didn't want to reconfigure all from scratch. In particular I was wondering whether OMV is still missing a "save/restore" configuration feature, which is a basic thing IMHO.
    It it's still missing, what is the recommended way to perform a "clean upgrade" by reinstall? Just reconfigure all the system from scratch by hand?

    Just a note that Init scripts still work on systemd but OMV 3.x did move to using unit files for its services. Just delete them. We did recommend fresh installs over upgrades from 2.x to 3.x. And not to kick a dead horse since I know you don't want to upgrade to 4.x but you are asking for support on an unsupported version.

    Yes, I know, but please note that those orphaned scripts would still be a problem if I upgrade from 3.x to 4.x, unless the 4.x upgrade process is smart enough to remove them ;)


    Thanks for your hint: I know those init scripts still work, in fact I get the "double beep" problem at boot/shutdown. And, exactly for this reason, I didn't know whether the other openmediavault scripts in there could still be required in some way. Now that you confirm that they are not needed any more (because they were all migrated to systemd), I can remove them. Thank you for your help! :thumbup:

    Why do you want to stay on OMV 3.x?

    Upgrading from 3.x to 4.x means another major upgrade of the underlying Debian system... I read OMV 4 release notes and I don't see any major new feature that justifies the effort right now (at least for my usage scenario). I just upgraded from 2.x to 3.x just not to stay too much behind and because Wheezy got EOLed, beyond the LTS period.

    Upgrading from OMV 2 to 3 brings the underlying Debian 7 to 8 upgrade and the switch from sysvinit to systemd.


    After performing a successful upgrade from OMV 2 to 3 (I just have to fix some glitches, solved by searching on this precious forum), I however noticed that the beep sound on system startup and shutdown were generated twice. I then suspected that there were some duplicated scripts in /etc/init.d and in the new systemd configuration. In fact, I both find:


    Code
    /lib/systemd/system/openmediavault-beep-down.service
    /lib/systemd/system/openmediavault-beep-up.service

    AND

    Code
    /etc/init.d/openmediavault-beep

    Indeed, in /etc/init.d I find:

    Code
    /etc/init.d/openmediavault
    /etc/init.d/openmediavault-beep
    /etc/init.d/openmediavault-configimport
    /etc/init.d/openmediavault-engined

    I suspect al those scripts shouldn't be in there any more. Can you confirm? What is the right way to remove them?



    Thanks in advance,



    Mauro

    My statement assumed you were using a supported version of OMV. OMV 3.x has been EOL'd for quite a while

    Yes, of course, I just wanted to add a clarification for whoever, like me, prefers to stay on OMV 3.x by now.



    omv-extras for OMV 4.x has had a UI option to enable/disable the backports kernel for a long time.


    Good, to know, thank you! Unfortunately it doesn't seem to be available for OMV 3.


    Finally, you still get security updates since most security updates aren't kernel updates AND the backports kernel is maintained/receives security updates.


    Just a clarification, if any one gets here now like me.
    It's not entirely true that backported kernels receive security updates, at least they don't with the same LTS policy of standard kernels. The clue is this problem with the jessie-backports repositories being removed from the mirror infrastructure and moved to the archive.debian.org site only (see also this and also this for proper fix, because right now just changing the repository URL is not enough to make apt-get happy again).



    Right now, if one wants to stay with OMV 3.x and benefit from Jessie LTS security updates until the final Debian EOL deadline, he/she should stay with the standard 3.16 kernel if possible.



    So, providing a UI option to enable and disable backport kernels should be desirable, IMHO, in any case.

    Why seeing BTRFS as a replacement for traditional filesystems+MADM+LVM? Couldn't OMV support it as an alternative?
    I mean, to simplify things OMV may let you use a physical device in one configuration OR (exclusive) the other.


    Wheezy indeed still uses an old 3.2 kernel version and I don't know what's the state of btrfs there. The experiments I did with a 3.11 kernel based Linux Mint were very satisfactory for RAID-1 (mirror) configurations.

    Well, however it's quite unusual that you are using a so specific netbook processor for a NAS box ;)
    I think the great majority of home users today (including most of those with an Atom) do have a 64-bit processor, although often running a 32-bit OS.


    Anyway, I do agree that having the possibility to have a 32-bit version of OMV in some (not too cumbersome) way would be nice, since I'm using it on an old Pentium III, as you can read before.

    It it were only a 64-bit ISO, but a good wiki page that guides you to install OMV on top of a 32-bit Debian wheezy, that would be perfectly fine for me.


    However, I do not think it's just to install OMV packages on top of plain Debian, because I guess some changes on the default Debian configuration might be needed to suit OMV needs.

    I do not think that the new release will necessarily declare the old one as EOL.
    0.3 was declared EOL after quite some time that 0.4 was released as "non-BETA".


    Regarding the squeeze EOL, that's yet another story.


    I think Volker's feedback is needed here...