Posts by Wek

    @qwertz123 first of all thanks for sharing your experience, I was considering to throw away the unit :°D.


    But I'm definitely love the same points you mentioned in your post, so I hope to have it work good indeed.


    I will try to install stretch and see if with the backport kernel will solve the nasty problem of haning login prompt at startup as you said (indeed it's only "cosmetic" as the server startup anyway and I can access through ssh and webgui as you said), indeed is what I'm experiencing right now that want me to throw the unit out of the window.


    Funny thing is with basic debian jessie with stock kernel (no backports) it works well, out of the box, the problem of the sp5100_tco (that I blacklisted to solve) and the hanging at boot screen happens only if I use the backport from jessie or the stock kernel on stretch, so maybe is a bug they fixed with the new kernels, so I'm going to try your way stretch+backport kernel.


    From your post I didn't understood one thing though, if you go stretch+backport kernel+non-free-firmware+omv4 on top of it will get you the fix of complete boot with vga attached to the server? I mean can you finally get it until the login prompt with a monitor atteched to the server doing this?
    otherwise is just the same I've got with the situation right now (I'm trying to fix the prompt stuck before asking for login on boot)


    Lastly about the settings I didn't know how I missed them, now I found them thanks,...about the registration to download bios firmware is beyond stupid o.O..I created the account registered my server all is good, but still can't download the firmware it asks also to connect your account with some non more specific certificate or contract (!?!?!?!?) but the page keeps refreshing itself no download...this is F*****G annoying an really stupid, so much that I would probably need to contact the support just for this stupid thing that's really....wasting time.



    Anyway one last thing qwertz did you try to issue the command dmesg --level=err ?



    I didn't notice any error in my omv logs, but when I issued that command I found all of this caos with it:


    As you can see even a warning about the ssd where the os is installed screaming about corruption...could you check it aswell and see if you get some nasty stuff too?

    I have a quick question, I'm plagging to move my actual omv onto another system.


    I was wondering instead of reinstalling everything from scratch, can I directly move the SO ssd and the data disks to another rig even if the architecture is completly different from amd to intel, without the need to reinstall everything and just turn it on?
    Will this create any problem in the long run?


    In other words when Omv gets installed, does it install with generic kernel drivers or is it tailored to the components it's installed on first time?

    I would like to build a server\nas from scratch it doesn't need to be ultra powerful, actually I'm looking for the best bang for the buck, the server will be used mainly as backup server and nas to distribute files on a small office (5-6 employees)


    I was thinking about going the ryzen 3 way quad core, really cheap, I like the new amd line also I would like to support them, but I read that it's supported only from kernel 4.10 up is it right? so I guess it's not feasible because omv3 installs with 3.9.0 kernel and the backported one is 4.9.0, so do I need to assume a ryzen build with omv3\omv4 could go terribly wrong? does anyone have some ryzen config right now working fine?


    So with this out of the way, I assume, what would be a right choice for my needs to go with?


    Considering that going intel new gen is also out of the way...so I guess I have to go back in time, but I don't know what intel\amd model (and complimentary mobo to go with) could be a great config for my needs and my wallet right now.


    Any suggestion would be really helpful!!


    Other goals I would achive:


    • I would like to find a mobo that has more than 4 sata ports (or supports m2 ssd so I don't have to occupy a sata slot and leave them for all the data disks) I would like to have 4 or more sata ports for data disks
    • I would achieve the build with a small footprint so, anything on the range matx, even itx if it's possible (but I guess the second chance is a bit troublesome with my first point about sata numbers?!)
    • I would like a case with easy access to hard disks, without the need to disassemble the whole pc, just to change data hard disks, with hot swap could be awesome, I didn't find many of those to be honest, especially at a reasonable price

    I had lot of issues trying to install omv3 on my HPE proliant microserver gen10.



    After dozen of tries the only method that worked to have omv3 installed
    on the ssd on the internal sata was to make a debian jessie bootable usb
    and once installed the base system add the omv3 repo by hand and
    install omv3 on it..



    Now..to be honest I'm not very happy with this microserver so far, so I
    hope the experience from now on will be better, or i'll think about to
    get a refund for this server unfortunately.



    Anyway I have two major issues right now I hope that @Spy Alelo or someone else that had same issues can help me out.



    • I'm getting this issue on boot: sp5100_tco: I\O address 0x0cd6 already in use, it only happens with omv3 backported kernel 4.9.0 (doesn't seem to happen with 3.9.0 kernel)
    • I noticed there is a bios firmare upgrade for gen10 on the hpe site, but unfortunately download something simple like a firmware bios seems to require some sort of magic first the site asked for register after that doesn't let you still download it, seems like you have to pay for some sort of license for it?!? (if it's not is not really clear how to get those). So what is the right way to update the firmware on the microserver
    • I looked at the uefi\bios settings doesn't seem to be present a function to power on on power failure, nor a wake on alarm setting..I tried anyway to plug off the cord from the server and "make" a power failure and then plug back in, it seems it auto start up again, so I guess this function is autoimplemented even if there is no setting in the bios am I right?
    • Also what about ACHI support setting in the bios for the ssd instead of RAID (that I don't use anyway) in the bios? I don't see it either

    Little Edit:


    I found out that this happen because of power race, the ups didn't finish his battery before the ac get back in, so the server will retain his previous state that is shutdown because of the clean shutdown issued by the ups through usb.


    So I found out through nut documentation that is suggested a shutdown script as a workaround:



    So I went ahead and copy\pasted the script from line 7. on, onto a script created into /usr/local/bin/powerace and gave the file +x flag to execute it


    then I created this service for systemd to recall the shutdown script:



    Installed the service through systemctl command and rebooted, then I tested the script out unplugging the power to the ups and put back in after the server shutdown and before the ups loses the whole battery....


    UNFORTUNATELY didn't happen anything the script doesn't seem to work either, so I'm out of ideas.


    Does anyone had same issue and resolved it?

    Almost sure is a stupid question and I'm overlooking something here, but I'm playing around with my omv3 and ups with nut plugin and I'm encountering an issue without find a solution.


    • I set up my omv3 mobo to wake up after power loss\back on (it works if I plug off the cord and back on it starts up as it should so is not the mobo)
    • Then I installed nut-plugin and set the driver correctly for the Ups Eaton 5E650va and connected through usb to the server (lsusb recognize the ups connected correctly through usb)
    • Configured the plugin per nut documentation with the driver configuration suggestion with: [eaton 5e] driver = usbhid-ups port = auto and have it to turn off the server after 30 sec
    • Tested it plugging off the current from the ups, the ups battery kick in wait for 30 sec and then correctly shutdown the server (I can see it through the server cmdline aswell)
    • Here come the problem when I put the cable back on the ups everything went back to normal with the ac, but the server remain powered off...it should turn on at least that's what I'm trying to achive.

    Has anybody encounter the same problem with or without the same ups and found a way to fix it? Am I missing something here?



    Some more useful information:


    • psu atx be quit! system power 7 300 watt
    • ups eaton5e 650i va


    • motherboard asrock itx with function power on on ac back turned on (tested out with pluggin off on the cord it works)


    lsusb:


    Code
    root@omv:~# lsusb
    Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 008 Device 002: ID 0463:ffff MGE UPS Systems UPS
    Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    upsc command:


    @Huberer what you want to achive is feasible, the problem is you are doing it totally the wrong way, you NEVER download package like that from another distro (doesn't matter if it's unsable testing or stable vs oldstable) what you will achive is breaking packages updates\upgrades and possibly your whole system :D.


    In debian almost all packages depends on others packages, called dependencies, so basically you are installing something without dependencies and hope that works. (actually is more complex than that, but you got what I meant I think).


    To achive what you want you should understand how to backport packages from testing\unstable to stable the proper way, search on google "debian backport packages the correct way" you'll find tons of information.


    If I remember correctly it should be also present how to do it properly in the handbook I just linked to you.


    If you want some help with it maybe open another thread and me and other users will be willing to help you out with your issue (actually I don't know if you should open a thread here or on the proper debian forum for this).


    Anyway the way you are doing is basically wrong and will put you in trouble with your system :) with the right way you could achieve what you are looking for without problems and without the need of the latest\bleeding edge os :) .
    Keep in mind though that apt pinning is not really sponsored\suggested from debian and you could fall into trouble none the less, maybe I would consider the backporting way it's easier and less risky if you know what you are doing of course, the choice is yours, the only thing I would suggest you is basically never download packages and install them like you did :°D is not windows :D .


    I'm glad that helped you out, have a good read pal! :)



    Little EDIT:


    More over before all of this...have you tried to look into stretch-backports repos? I mean you are looking for a vga driver this kind of packages are almost always backported already, so you basically don't need to do anything of what we were discussing and just install it through apt like any other package

    @Huberer is never a good idea to mix match stable\unstable repos especially without proper configuration, it will lead to problems during updates like you are experiencing, most of them are mitigated by correct apt pinning configuration, may I ask you how did you add unstable repo and installed your package through omv, more over are you using apt pinning at all?


    May I suggest you to read this official debian document on the matter:


    Apt Preferences


    I'm pretty sure will solve all your problems, and maybe install the repo\package through omv-extras repos and omv apt-tool (the last suggestion is not really necessary if you know how to properly handle the terminal, but I don't know your level of knowledge in general, so I just thought to put that as well if you needed, I guess you don't anyway)



    Also because we are on the matter, I will suggest to download and read (also support if you can) this "official" debian ebook, to you if you are curious about debian administration in general and all the others that don't really know how to properly handle this awesome os:


    The Debian Administrator's Handbook



    Actually I think moderators should stick that book link on the homepage :D, so newcomers that install omv and don't really know what is happening under the hood and would like to or want to troubleshoot problems and get dirty hands could read\learn how to do things the proper way

    @tkaiser sorry I just forgot to answer your question it's a type A usb, the hardware on that server is not really ultimate generation :D so type c unfortunately is excluded.


    I'm taking it seriously by the way don't worry I'm looking up what you posted


    Little edit:


    I think I found out what's going on, the external usb hard drive is one with an external power aswell, I noticed that if I FIRST plug the usb in and then Turn the switch on it works, it doesn't if I first turn it on and then insert the usb into the port...does it make any sense?


    I didn't thought about that because all my external hard drives are self powered through usb port but this one.
    But shouldn't it be the same when to plug in the usb?

    @subzero79 and @tkaiser


    Now it's even more strange..I was playing around with the other usb ports...after I plugged it to the usb2.0 automount worked out...so I thought maybe was the 3.0 usb damaged so I plugged it back to the 3.0 and now lsusb shows it aswell on the same 3.0 even so does usbbackup plugin ?(


    Hi @subzero79


    I tried to reboot omv and replug the external 1tb hard drive onto the usb 3.0 port formatted with ext4 once booted up.


    here's my lsusb and dmesg grep, strange enough lsusb shows as everything is empty


    As the title say, I'm trying to understand the correct way to auto mount a couple of hard disks mounted as ntfs and ext4 to a server already running, without the need to reboot (so I guess no fstab).


    I'm thinking to install usbmount package:

    Code
    usbmount/oldstable 0.0.22 all
      automatically mount and unmount USB mass storage devices


    I'm looking to be able to automount external hard disk of 1tb and up through usb2.0\3.0 to use in conjunction with usbbackup plugin and standalone to transfer files between omv and the hard disk.



    But it seems to not support ntfs out of the box (maybe achievable through the conf file)


    Am I missing some other way to correctly do it? I thought omv would automount by itself, for using it with usbbackup plugin, but it does not, it doesn't see my external hard disk at all if plugged through usb3.0.
    Any help on the matter would be very appreciated.

    @molnart why do you need all that bleeding edge for a server?! It doesn't make much sense, I mean it's far better be with rock solid debian than arch and the bleeding edge side..but maybe you are using your server in a weird situation don't know, I would definitely pick debian oldstable\stable 10 times better than any single distro out there bleeding edge.


    I think @ryecoaaron explained it better some posts before if you need some particular bleeding edge package just use docker for it and that's it


    Heck I even use debian stable on my everyday desktop without any need for any more bleeding edge :) but I guess that's just preference (and software needed of course), also it's worth noting that debian backports already get a lot of "new" packages.

    Yep. Let's have a look at AFP and SMB services OMV provides for example.
    SMB is provided by Debian's Samba packages (so all security fixes come from upstream Debian team/repo) while AFP is OMV (so once Ralph provides a Netatalk security fix, Volker will update the openmediavault-netatalk package). I don't see the point once upstream Debian Jessie support stops and therefore many of essential packages don't receive any more updates to further provide support for OMV's 'own' packages since at least I would consider such a situation simply highly confusing. But maybe that's just me.


    But that's why I would consider upstream Debian release life cycles currently somewhat related to OMV release lifecycle policy (especially since votdev obviously got tired answering the same questions over and over again -- same with 'When is OMV $n+1 ready' :) )


    Maybe It's too much late here..:°D and I don't follow you properly...but...If I'm correctly understanding you...you are seeing the problem at the opposite direction..


    I mean...I'm concerned about the opposite not debian jessie be terminated before omv3 (of which I don't see the point either to mantain omv after jessie eol), but omv3 been not supported for the whole jessie cycle


    that was my point O.o


    I hope I understood you and I'm not mistaken your words..I do agree omv project shouldn't give support after debian dropped support for the same base os, I couldn't see a reason in doing so..


    Then again, I wasn't asking for when omv4 will be out :°D I was asking for a suggestion about other users experience on the same matter as @molnart stated, AND if there were some more precise eol info about omv3, that maybe I missed out THAT'S IT.


    I hope you understood me now, why are you bring this whole thing up is beyond me...I stated in my first message "I KNOW the philosophy about it's ready when it's done" and I'm totally fine with this too O.o...again I'm not understanding your point...


    I'm sorry if it seems I came up a bit rude, it's not my intention, but it seems you are putting words on my mouth that I didn't say, or to make me appear like I make pressure to votdev or anyone of the team asking about an exact date or be disrespectful of votdev and others work which I'm not, or probably I completely misunderstood you, because my brain is totally f*cked up at this time :°D so in that case I apologize, it's a bit late here.

    OMV 3.x is in maintenance mode now (feature freeze). It's running on Debian Jessie (so called 'oldstable' release). So everything known or at least searchable as soon as you start to fill the three characters 'EOL' with life. Since there are no new features to be expected you could define 'EOL' as the period of time the underlying Debian release is provided with updates (especially security related ones). Or are other definitions possible too?

    If the result of such an upgrade is important to you investing some time/efforts into fail-safe upgrade strategies might be a better alternative to 'hope' :)

    I guess that's not entirely correct, I mean, that is true for the underline debian os (I'm not worried about that, I trust debian security and I know its life cycle), at the same time, that's not true about the web interface or plugins of omv, the fact that is in freeze doesn't mean it will not get any update fix for security, as stated in the same link you posted, actually it's quite the opposite, as you can see freeze will get fix and sec updates and No new features...that's the point..


    I think votdev and all the others who works to the project are not tied to debian lifecycle indeed, they can decide when terminate the life cycle of it despite the fact oldstable will still be there next day, therefore "debian oldstable sec\eol" is not equal to "omv3 sec\eol"...unless I'm missing something here.


    AAAAAAAAAAAAAAAAnyway...as I said I didn't want to create a problem, I was just wondering about before go one route or the other :)


    about the upgrade importance, that's for sure thanks :D, actually I'm proactive, this discussion is the first step to investing time\effort to that goal :D



    @molnart yep I guess I will try both and if omv4 will be pretty stable already I guess I will go that route indeed I'll test it out tomorrow, thanks:)

    That's what I suspected, was worth a try, I was hoping for some more "clear" life cycle of the distro, but that's ok, I guess I have no other alternatives then to go like you said, omv3 to omv4, hoping everything will be good with the upgrade furhter in the line :)


    Thank you @hoppel118

    Still didn't understand what you suggest would be the right path ...but thanks anyway :) and thanks for this awesome distro
    Could somebody tell me at least for how long omv3 will be supported? I mean what is its EOL? I can't find any info on this, that would be very helpful thanks.

    I have a question in this regard,


    I need to build a small office server in few weeks, so I was wondering how much time roughly will require to omv 4 to be stable? (I know it's ready when it's ready philosophy :D) I mean are we talking about month\s maybe or are we talking a year?


    I'm asking this because I don't want to go omv3 route and have to start from scratch to install for om4 after some weeks or a month.
    Especially because I will not have easy physical access to the office after have deployed it.


    At the same time in the past I already had some issues going from omv3 beta to omv3 in one of my box ( though probably was a plugin issue, I don't remember exactly).
    So I'm looking for the best thing to do in this moment to have as much support in a long run, going omv3 route or omv4 beta now -> omv4 stable when it will be out.


    Keep in mind that the server will need just omv core and I guess rsnapshot plugin, for backup, that's it (that I saw is already into omv-extras repos for omv4).
    I guess omv4 is pretty secure right now because of the debian stretch base am I wrong?


    In case you think the best way is still go with omv3, for how long will omv3 be supported? has it same life cycle of oldstable debian jessie for support (roughly another year at least from now if I'm not mistaken, am I right)?


    Thank you in advance for your help\suggestion

    That's really interesting, I'm wondering though, why didn't the samba share disconnected as soon as the rules were built instead of wait for reboot? I mean if I was blocking it with the destination ip, why does it kept working anyway until next reboot?! just out of curiosity.



    In the meanwhile, you were right everything worked well after removed the destination ip and now I'm playing around with iptables LOG rules to see the messages that's fun to do :) despite the fact sometimes iptables gives me headaches, by the way thank you for the heads up man :)