​NTP and proftpd servers cause Odroid C1+ to crash on boot, then reboot, repeat

  • Questions:
    1. Are services ntp and proftpd needed during boot and/or for OMV in general?
    2. What are pros and cons to disabling and not running them with OMV?
    3. Can starting these services be delayed until OMV is loaded and then start them with a Cron job or something similar?
    4. How to I make the output of these (ntp and proftpd) services VERBOSE during boot so I can troubleshoot the issues described below? Please provide detailed instructions...I'm a novice with Linux.


    Issues:
    I purchased an Odroid C1+ and installed OpenMediaVault onto an SD card (the Flash Memory plugin IS installed and running). The initially compiled versions (i.e. 1.14 or 2.1) seem to work fine, but after installing any updates or upgrading to the latest release (i.e. 1.19 or 2.2.1), both the NTP and proftp servers cause the odroid to crash, then reboot, then repeat. Most of the time, NTP causes the crash, but I've also seen proftpd cause it.


    This boot, crash, reboot cycle will continue without ever reaching the CLI / login prompt. I have reflashed both the 1.14 and 2.1 images ~20 times in an attempt to verify and fix this and the same error always occurs.


    The boot log showing NTP crashing may be seen here (line 1319): http://pastebin.com/9kRKY4Eg


    Finally, I reflashed the image back to the original compiled version (1.14 or 2.1) and used the following commands to remove NTP and proftpd during boot.

    Code
    update-rc.d -f ntp remove
    update-rc.d -f proftpd remove


    This seemed to solve the NTP and proftpd crash on boot problem. Once OMV is loaded, I can access the CLI and manually start the services from there without error. From that point, I can also upgrade to the latest verion or release without issue, but proftp and ntp are not running, unless I manually


    I used both of the images at the links below to for flashing OMV to an SD card for the odroid C1+.
    OMV 1.14: https://sourceforge.net/projects/openmediavault/files/Odroid-C1</a> images/
    OMV 2.1: http://simplenas.com/download/odroid-c1-download/


    One more thing...the ordoid C1+ DOES have a RTC (real time clock) and I DO have a button cell battery attached to it. (I read that might be an issue when using OMV on the raspberry pi. That solved other people's NTP problem, but not mine.)

    • Offizieller Beitrag

    1 - Most people like the time on their server to be correct. That is the only reason to have ntp. If you don't need an ftp server, then you don't need proftpd at all.


    2 - see #1


    3 - They are delayed already. Neither one starts until networking is started. See the init script headers

    Code
    # Provides: ntp
    # Required-Start: $network $remote_fs $syslog
    
    
    # Provides: proftpd
    # Required-Start: $remote_fs $syslog $local_fs $network


    4 - Not needed. They both have their own logs in /var/log/+


    Issues - ntp and proftpd aren't started until after the kernel is booted. There is nothing in your boot log showing those services crashing. I'm not saying they aren't causing a problem but it is after the system is booted. Keep them both disabled if it makes the system work. You can manually set the time or you can use a cron job to update the time.


    OMV 1.x and 2.x are both Debian Wheezy. So, they are basically the same. If one has problems around boot time, the other problem will too.


    Did you really flash the image 20 times? That itself may be causing the problem since it is very hard on the sd card.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • > 4 - Not needed. They both have their own logs in /var/log/+
    When I inspect the logs at the location described above, nothings shows up as being modified recently. I opened each available file and I didn't find any relevant info...only 2~3 lines of information that looks like info from the original image. How do I verify that info is actually being recorded?


    > Did you really flash the image 20 times? That itself may be causing the problem since it is very hard on the sd card?


    Yes, I have 2 cards, 1 was flashed ~15 times and the other ~5 times and both images flashed to the SD card had the same problems. The only reason I flashed the cards so many times was because the Odroid would get into the boot loop described above and I couldn't get it out of that loop without flashing it. It wasn't until recently that I figured out/learned that I could manually delete the links in the rc[runlevel] folders to prevent services from starting up during boot. I now know better way is to remove it using the command update-rc.d, but deleting the links worked in a pinch.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!