5-Minute Boot

TRR · December 13, 2016 at 2:53 AM

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

**lrusak** · December 13, 2016 at 5:39 AM Official Post

I would run fsck on the disk, seems that it is in disarray

TRR · December 14, 2016 at 2:18 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

**chewitt** · December 14, 2016 at 12:29 PM 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.

TRR · December 15, 2016 at 3:05 AM

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!

TRR · December 30, 2016 at 3:33 AM

Just to follow up:
I got rid of the USB stick and installed to an SSD and now boot time is between 20s and 30s.
Thanks again!

**chewitt** · December 30, 2016 at 7:26 AM Official Post

Nice. Welcome to the 21st century

manicam · January 2, 2017 at 9:42 AM

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.