Slow 5+ minute boot; fsck on each boot

  • I am reinstalling/reconfiguring OMV on my Odroid-HC2 and while it previously would boot in about 1 minute, it now takes around 5 minutes.


    I notice large time gaps in dmesg (click here for full log) around hard drive activity:



    I was concerned by the error message print_req_error: I/O error, dev sda, sector 19532873600 so I ran e2fsck -c -c /dev/sda (took over 3 days!) for a non-destructive read-write test checking for bad blocks and it reported no errors. SMART's short self-test also reports OK status. Since the hdd is used for backups, I also ran a consistency check of all the backups contained on it and no problems were found.


    Systemd shows that fsck took ~4 minutes to run, and it runs on each boot. This could perfectly explain the boot time jump from ~1 minute to ~5 minutes.



    Any tips to identify what is going on and bringing the boot time back to normal?

  • It might help if you remove the drive and, using SATA, plug it in to a more powerful Linux computer. Then diagnostics, fsck and format may go faster. Also you can use for instance gparted to check and possibly fix the hdd.


    A full format may be needed. Not a "fast" format. If the drive is bad, it may make it worse. Or fix it.


    Possibly use a temporary Linux computer by booting from a thumbdrive with a live Linux version, like Ubuntu.

    Be smart - be lazy. Clone your rootfs. This help is Grateful™.
    OMV 4: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

  • Thanks, but as mentioned the checks are already done and found no problems. It takes a long time because it's a 10TB drive. I checked it with badblocks when I first got the drive, in a USB3 dock attached to a linux computer, and then too it took 3 days to complete.


    In any case, I still have no clue what the issue is with the long boot time and fsck at each boot.

  • I believe the time used by fsck is proportional to the number of files on the drive. If you recently have unpacked archives or compressed backups, so the number of files have increased a lot, then that may be a cause?

    Be smart - be lazy. Clone your rootfs. This help is Grateful™.
    OMV 4: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

  • Thanks, but as mentioned the checks are already done and found no problems. It takes a long time because it's a 10TB drive. I checked it with badblocks when I first got the drive, in a USB3 dock attached to a linux computer, and then too it took 3 days to complete.


    In any case, I still have no clue what the issue is with the long boot time and fsck at each boot.

    Back in the day I had this sort of thing happen to me twice... I found the problem wasn't "the drive" (at least internally) at all.. On one, one of the wires on from the power supply connector, had worked itself loose and was causing very erratic behavior with the drive. Taped off connector and used a splitter from another drive. Problem solved.


    The other.. and this was a lot more frustrating.. again erratic drive behavior, etc.. Given my previous experiences I double checked the PSU, connectors, etc. What I eventually found, the small "ear" on the data port, had a slight crack, so if no cable was attached, the ear would kind of swing like a door. If a cable was attached, it would still move slightly.. thus causing erratic problems while transferring data, booting, etc. Replaced the drive as it was just out of warranty.

    Air Conditioners are a lot like PC's... They work great until you open Windows.


    Edited once, last by KM0201 ().

  • Adoby No, the number of files has not changed.


    Boot time was ~1 minute before, and now I'm reinstalling due to my OMV installation having gotten messed up with the WebGUI login loop issue and beyond. I don't know why boot time is now consistently 5+ minutes each time.


    KM0201 Oh my... I sure hope it's not a physical problem. In my case I'm using just an Odroid HC2, so there is no SATA or power supply cable to the drive. If there is a physical problem it would be the HC2's SATA connector on the board. Not sure how to check for that, but that would be bad...


    One thought would be to use a different drive and see if the same problem comes up, but since the other drive would probably not get mounted at boot, I'm not sure it would be equivalent.


    The other option that I'm leaning towards right now is to set up OMV5 from scratch, since it was just released as stable, and see if the problem persists.

  • Updating the bridge chip firmware on the Odroid seems to have solved the problem for me: https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update Now there is no more delay, and with OMV5 the boot time is 42 seconds!


    In OMV4 the boot time was long due to fsck taking ~4 minutes to run on each boot. In OMV5, fsck timed out during the boot process after almost 2 minutes resulting in the service failing and the drive not getting mounted at all, and that caused all kinds of other errors in OMV.


    I don't know if somehow original firmware (v173.1.0.1) got corrupted (since it worked fine for months before) or if the issue was something else, but at least it seems fixed now and has been fine over several warm and cold boots. A bonus is that the latest (v173.1.0.2) firmware adds a new feature: hot swap. :)


    One note: after updating the firmware a *cold* boot is required. The wiki mentions it, but I had forgotten and after initial warm reboots the drive was simply not detected. There were a few cold sweats until after a cold boot.


    One great thing about OMV5, aside from the speedy boot time, is that ping responses, SSH, and the webgui are up really quickly, even before the boot process has completed. It quickly lets me know that it is working, which is reassuring for a headless system.

  • grokov

    Added the Label resolved
  • I assume you started with Armbian. On the download page there is a note:


    "This board is stripped Odroid XU4 and we use the same images, however, we provide a specially optimized config (for kernel 4.14.y or higher) which has to be applied manually. This results in shorter boot time and lower consumption. Run armbian-config utility and go to section system -> DTB and select optimized board configuration for Odroid HC1. The same config is valid for HC2 and MC1."


    Might be worth to apply, if you have not done already.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!