5-Minute Boot

1st Official Post

    Long-time OE user here (since before 1.0.0), just converted to LE about a month ago.

    I'm on 7.90.009, but this problem has been occurring for a while (even with OE stable). I just never bothered to address it, because most of the time, the system is just on.

    I need a little help as to why boot is taking so long. Here's a clip of the spot in dmesg where things appear to take forever, but I have no idea why. Notice the 15 second and then 3.5 minute delay. Anyone have a thought? I've seen these messages in other dmesg files on the internet, but there is never a long time period between them. Here are the relevant lines (at least, I assume these are relevant). Where can I find a log of what's going on during the wait time?

    Any help is appreciated!

    [ 10.352038] EXT4-fs (sdb2): couldn't mount as ext3 due to feature incompatibilities
    [ 10.359016] EXT4-fs (sdb2): couldn't mount as ext2 due to feature incompatibilities
    [ 12.214025] random: crng init done
    [ 27.018256] EXT4-fs (sdb2): recovery complete
    [ 27.025022] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
    [ 243.127747] ### BIG FAT WARNING
    [ 243.127787] ### sdb2 is removable. suspend/resume may not work
    [ 243.129962] ### BIG FAT WARNING
    [ 243.130027] ### sdb1 is removable. suspend/resume may not work


    EDIT: additional poking around and I found the following in journalctl with a large delay. Is the slewing process taking that long to adjust the time? If so, how the heck do I fix it?

    Dec 12 20:55:53 Office kernel: snd_hda_intel 0000:03:00.1: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
    Dec 12 20:55:54 Office kodi.sh[651]: libEGL warning: DRI2: failed to authenticate
    Dec 12 20:55:54 Office kodi.sh[651]: libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/dri)
    Dec 12 20:55:57 Office connmand[328]: ntp: time slew +0.001855 s
    Dec 12 20:58:10 Office kodi.sh[651]: no talloc stackframe around, leaking memory
    Dec 12 20:59:10 Office kernel: r8169 0000:01:00.0: invalid short VPD tag 00 at offset 1

    Edited once, last by TRR (December 13, 2016 at 3:14 AM).

    fsck -fy on both sdb1 and sdb2 show a clean system (I assume...I'm not well versed in fsck usage):

    :~$ sudo fsck -f -y /dev/sdb2
    fsck from util-linux 2.20.1
    e2fsck 1.42.9 (4-Feb-2014)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    Storage: 4522/212160 files (0.5% non-contiguous), 140116/847232 blocks
    :~$ sudo fsck -f -y /dev/sdb1
    fsck from util-linux 2.20.1
    e2fsck 1.42.9 (4-Feb-2014)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    System: 16/32768 files (6.3% non-contiguous), 64142/131072 blocks

    • Official Post

    Clock slew has no impact on startup other than the clock being slightly wrong. The journal on a Raspberry Pi (with no RTC) will show you a system that starts happily on 1st Jan 1970 until the network comes up and NTP drags the clock forwards 36 years.

    The first delay of 15 seconds occurs because /dev/random is locked due to a lack of entropy. This usually stems from using simple HTPC hardware with no external peripherals or mechanical media which are the OS's main sources of entropy. LE7.0+ does some workarounds for storing and then recovering entropy on next boot that normally reduce the delay, but there's not much to do about that.

    The second much larger delay looks to be related to /dev/sdb. I'd make an educated guess that this is a larger capacity (and/or slow speed) USB stick and the OS + hardware shutdown process is leaving the stick into an unclean state which triggers fsck on restart; the scan takes time to complete so you see a boot delay and because you already fsck'd the partitions a manual check after boot shows nothing as the issues caused were already resolved.

    Install to a proper HDD/SSD and the longer delay issue probably goes away.

    Thank you good sir! Good call on the HTPC. It's a Zotac Zbox with nothing in it except RAM. And, yep, I'm using a 4 GB usb stick. It used to work fine, but started having this issue a year or so ago. I'll buy an SSD and throw it in there. Thanks for taking the time to respond! Excellent work over the years, by the way. I really appreciate it!

    Help! Help! Help!

    Dear Sir,

    I am using LibreELEC 7.0.2 on a Raspberry pi 2.
    I plan to add a PiFi DAC 2.0 soundcard to the Raspberry pi.

    One enthusiast suggested editing the following to enable the PiFi DAC to work on LibreELEC :

    mount /flash -o remount,rw
    nano /storage/.config/modules-load.d/hifiberry.conf
    snd_soc_bcm2708_i2s
    bcm2708_dmaengine
    snd_soc_wm8804
    snd_soc_hifiberry_dacplus
    nano /storage/.config/modprobe.d/disable-lirc.conf
    blacklist lirc_rpi
    nano /flash/config.txt
    dtoverlay=hifiberry-dacplus
    dtdebug=1
    sync
    reboot

    Your advice is kindly sought if this would work for the Raspberry pi 2/LibreELEC 7.0.2/PiFi DAC 2.0 setup.
    Thank you.