LibreElec 7.0.0. and 7.0.1 image broken

    Is the problem with rpi-2 booting with 7.0.0-image known about?

    This shows up for me when using a rpi-2 with a HiFiBerry-digi overlay(dtoverlay=hifiberry-digi), in which the hifiberry evice is only seen on the first boot, on the secound boot the overlay directory content has been deleted! Then on the neat reboot the overlay directory itself is gone!!

    If not known about I can post more info, otherwise does anyone have a work arround, I here others may have worked arround by installing an OpenElec image then after configuring it (so rebooting a few times), using the upgrade 7.0.0.tar file to update I have not confirmed this yet.

    regards
    JB

    Edited once, last by javaboyuk (May 19, 2016 at 8:35 PM).

    Not a known issue. I see you've got a thread on the Kodi forum where you've posted more information, looks like fairly significant file system corruption. Configuring LibreELEC doesn't make any changes to the /flash partition which is mounted read-only, so for this partition to become corrupted it's either an OS or hardware issue (power? Incompatible/fake SD card?)

    Quote from milhouse


    Not a known issue. I see you've got a thread on the Kodi forum where you've posted more information, looks like fairly significant file system corruption. Configuring LibreELEC doesn't make any changes to the /flash partition which is mounted read-only, so for this partition to become corrupted it's either an OS or hardware issue (power? Incompatible/fake SD card?)

    As always thank you for your input. The SD card (i hope) is not a fake power supply also good. The card is re-imaged from the download, and if I use the old openelec, or your build for 17, these images are ok. I dont use the 17 test image as I need dvd support.

    So strange that this is completely reproducable, and is always in the same way. I will download a new image, and see what more I can find out.
    Ill report what I can :)

    Again thanks for the support and effort you guys put into this.

    I am not absolutely sure, but after reading this thread it might be possible, that I am experiencing the same problem.

    I am using the gpio-poweroff overlay to cut my Pi from power after shutdown. Yesterday, when testing LE 7.0.0 (fredh install) I was very happy to see, that it was working. Unfortunately, it was only working for the first (and maybe the second) shutdown, nut then stopped working.

    I havent checked, if the overlay folder is corrupted or missing, because I havent really thought of that. I will check this evening and report.


    *******Update*******

    So I checked my sd card after 2 times booting and correctly shutting down the Pi and finally ended up with the same damaged file structure on the fat partition:

    Interestingly, this does not happen with the latest Millhouse builds of LE using the same sd card and somehow even after restarting several more times only the overlay folder is damaged. All other files on the fat partition are still ok, so that LE boots up with no problem.

    Hope, this can be solved ...

    Edited once, last by hollol (May 13, 2016 at 9:10 AM).

    I have now test this with mulitiple cards and multilpe RPi (2 and 3).

    To reproduce:

    1. download 7.0.1 image "unzip it" I used 7-Zip
    2. create sd card, I used Win32DiskImager v 0.9.5 on windows 7 fully patched
    Note I tried 4 and 16 G cards
    3. eject card, wait for it to say ok, (i have even tried re-insert running check disk etc always ok)

    3. insert card in RPI with a usb keyboard added and boot

    4. it auto resizes and starts reboot

    5. during the reboot I see errors flash up in read about can't creat a static device etc in /dev but to quick to read more, but kodi etc seem to star all ok :)

    6. no during the first ful boot say you want ssh, other than that i changed nothing!

    7. now login over ethernet

    8. cd /flash ; ls

    lots of fsck recovery files.

    Obviously as I said before next boot things get worse and you loose the overlay directoy, but things seem to carry on working.... unless you need an overlay of course, so I think this may have been missed in testing.

    Can one of the team confirm you get this, or even confirm following the above does NOT end up in corruption.
    But as you see in this thread its now not just me....

    Those with this issue, can you run the following and paste the output:

    Code
    dmesg | pastebinit
grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null


    [hr]

    Quote from javaboyuk


    Can one of the team confirm you get this, or even confirm following the above does NOT end up in corruption.
    But as you see in this thread its now not just me....

    None of the team get this, it's a rare issue that may be SD card brand/make/model/capacity/controller specific. I can't say that it won't cause catastrophic corruption, chances are that it will eventually.

    It's possible this issue is the same, positing your card details will help.

    Edited once, last by milhouse (May 19, 2016 at 8:54 PM).

    Quote from milhouse


    Those with this issue, can you run the following and paste the output:

    Code
    dmesg | pastebinit
grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null


    [hr]

    None of the team get this, it's a rare issue that may be SD card brand/make/model/capacity/controller specific. I can't say that it won't cause catastrophic corruption, chances are that it will eventually.

    It's possible this issue is the same, positing your card details will help.


    ##############################################
    # LibreELEC #
    # LibreELEC – Just enough OS for KODI #
    ##############################################

    LibreELEC (official) Version: 7.0.1
    LibreELEC:~ # dmesg | pastebinit
    EhPX
    LibreELEC:~ # grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null
    /sys/class/mmc_host/mmc0/mmc0:59b4/cid:744a455553442020024569218d00e7e7
    /sys/class/mmc_host/mmc0/mmc0:59b4/csd:400e00325b59000075cd7f800a4000c1
    /sys/class/mmc_host/mmc0/mmc0:59b4/date:07/2014
    /sys/class/mmc_host/mmc0/mmc0:59b4/erase_size:512
    /sys/class/mmc_host/mmc0/mmc0:59b4/fwrev:0x2
    /sys/class/mmc_host/mmc0/mmc0:59b4/hwrev:0x0
    /sys/class/mmc_host/mmc0/mmc0:59b4/manfid:0x000074
    /sys/class/mmc_host/mmc0/mmc0:59b4/name:USD
    /sys/class/mmc_host/mmc0/mmc0:59b4/oemid:0x4a45
    /sys/class/mmc_host/mmc0/mmc0:59b4/preferred_erase_size:4194304
    /sys/class/mmc_host/mmc0/mmc0:59b4/scr:0235800300000000
    /sys/class/mmc_host/mmc0/mmc0:59b4/serial:0x4569218d
    /sys/class/mmc_host/mmc0/mmc0:59b4/type:SD
    /sys/class/mmc_host/mmc0/mmc0:59b4/uevent:DRIVER=mmcblk
    /sys/class/mmc_host/mmc0/mmc0:59b4/uevent:MMC_TYPE=SD
    /sys/class/mmc_host/mmc0/mmc0:59b4/uevent:MMC_NAME=USD
    /sys/class/mmc_host/mmc0/mmc0:59b4/uevent:MODALIAS=mmc:block
    LibreELEC:~ #

    =======================
    The SD cards are all TRANSCEND
    ========================

    looks like the dmesg has captured some issues such as:
    Failed to start Create Static Device Nodes in /dev.

    I can't see where the fsck happens but quite a few "issues" but they maybe normal:
    [ 3.447470] systemd-journald[217]: Failed to open runtime journal: No such file or directory
    [ 3.454953] systemd[1]: systemd-journald.service: Main process exited, code=exited, status=1/FAILURE
    [ 3.455879] systemd[1]: Failed to start Journal Service.
    [ 3.456255] systemd[1]: Dependency failed for Flush Journal to Persistent Storage.


    ANyway let me know if you need anything else.
    [hr]
    Did a quick grep:
    dmesg | grep failed

    was interesting:
    LibreELEC:~ # dmesg | grep failed
    [ 3.228141] systemd[1]: systemd-tmpfiles-setup-dev.service: Unit entered failed state.
    [ 3.270300] systemd[1]: machine-id.service: Unit entered failed state.
    [ 3.456255] systemd[1]: Dependency failed for Flush Journal to Persistent Storage.
    [ 3.456437] systemd[1]: systemd-journal-flush.service: Job systemd-journal-flush.service/start failed with result 'dependency'.
    [ 3.456505] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 3.514697] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 3.527909] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 3.538684] systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state.
    [ 3.579065] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 3.593833] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 3.610486] systemd[1]: systemd-journald.socket: Unit entered failed state.
    [ 3.610530] systemd[1]: systemd-journald-dev-log.socket: Unit entered failed state.
    [ 4.386776] systemd-udevd[250]: Process '/sbin/hdparm -E8 /dev/sr' failed with exit code 2.
    [ 4.388436] systemd-udevd[246]: Process '/sbin/hdparm -E8 /dev/sr_mod' failed with exit code 2.
    [ 4.695552] systemd-udevd[253]: Process '/bin/sh -c 'echo enabled >/sys/class/net/eth0/device/power/wakeup' ' failed with exit code 1.
    [ 934.215891] systemd[1]: systemd-tmpfiles-clean.service: Unit entered failed state.

    Edited once, last by javaboyuk (May 19, 2016 at 11:43 PM).

    Try a different card reader/writer or a completely different PC for writing the image to the SD card. Also make sure the power supply for the PI is strong enough and provides a stable voltage.

    The images are perfectly fine and work without an issue on PI2 and PI3.

    It is really important to have a good power supply. Many people having problems just use underpowered supplies or an USB output from a device that does not deliver enough amps.

    I can confirm, one question: in last few days before that happen, didnt you seen rainbow square? Watch out USB A -> USB micro cables, they can ruin a fair voltage from power adapter also..

    Recently I have experience with newly purchased Rpi2 and LE7.0 -> 7.1. I use USB A cable connected to universal power source, and rainbows shows almost always (4A, also 3.5A source). On the other Pi2's which I have I use 2A, 2.5A without problem. Rainbow dissappears after using power adapter without USB A connector, just AC --> micro USB. But my point is, even when LE 7 make it start after check/fix, I cant update (no SYSTEM and Kernel in tar!).

    Solution in my case was simple, filesystemcheck&repair doesnt work permanently. So I copy Storage, format partition and copy back. Then Update and LE start without problems. Just hoping that this was the case of power undervoltage, and nothing else (other 2 Pi's updated without problem).

    Edited once, last by JimmySmith (May 21, 2016 at 4:56 PM).

    I have had no power issues, I am using an "official" power supply that directly connect to the PI, works great on even RPi-3 with and external hard drive (2.5") thats powered from the PI, so I can't see that being the isse (no not seen power issues, well I did ages ago with a cheap poer supply and even cheaper lead, they went to the bin!) hence buying new supplies which are not "general USB" units.

    Let me try some other things, I find it interesting that you guys confirm that if you follow the instructions to reproduce it does not have my issues (thats an assumption, could one of you guys confirm :-)). So If must be me! I really want to work out what it is, and Ill post what (however embarrasing that might be LOL).

    thank you for the feed back.

    Hello,

    I have just encountered this issue with a clean install of "LibreELEC-RPi2.arm-7.0.1.img" written with Win32 Disk Imager 0.95.

    This is repeatable as I reimaged the card and ran it again with the same result.

    I have previously upgraded from OpenELEC to the LibreELEC Milhouse "Krypton" builds, without issue.

    Raspberry Pi2, with official Pi2 power supply and Samsung Evo 32GB.

    It boots, resizes and then I briefly see Imgur: The most awesome images on the Internet on screen before the LibreELEC setup wizard starts.

    Full paste of dmesg JcSN

    # dmesg | grep failed
    LibreELEC:~ # dmesg | grep failed
    [ 4.349695] systemd[1]: machine-id.service: Unit entered failed state.
    [ 4.353110] systemd[1]: systemd-tmpfiles-setup-dev.service: Unit entered failed state.
    [ 4.634376] systemd[1]: Dependency failed for Flush Journal to Persistent Storage.
    [ 4.634900] systemd[1]: systemd-journal-flush.service: Job systemd-journal-flush.service/start failed with result 'dependency'.
    [ 4.635055] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 4.779673] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 4.815890] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 4.818871] systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state.
    [ 4.921115] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 4.977968] systemd[1]: systemd-journald.service: Unit entered failed state.
    [ 4.999568] systemd[1]: systemd-journald.socket: Unit entered failed state.
    [ 4.999981] systemd[1]: systemd-journald-dev-log.socket: Unit entered failed state.
    [ 6.318550] systemd-udevd[255]: Process '/sbin/hdparm -E8 /dev/sr' failed with exit code 2.
    [ 6.321506] systemd-udevd[244]: Process '/sbin/hdparm -E8 /dev/sr_mod' failed with exit code 2.
    [ 6.426106] systemd-udevd[257]: Process '/bin/sh -c 'echo enabled >/sys/class/net/eth0/device/power/wakeup' ' failed with exit code 1.
    [ 948.709883] systemd[1]: systemd-tmpfiles-clean.service: Unit entered failed state.

    # grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null
    /sys/class/mmc_host/mmc0/mmc0:0001/cid:1b534d303030303010d29d55e200fa0f
    /sys/class/mmc_host/mmc0/mmc0:0001/csd:400e00325b590000ee7f7f800a404055
    /sys/class/mmc_host/mmc0/mmc0:0001/date:10/2015
    /sys/class/mmc_host/mmc0/mmc0:0001/erase_size:512
    /sys/class/mmc_host/mmc0/mmc0:0001/fwrev:0x0
    /sys/class/mmc_host/mmc0/mmc0:0001/hwrev:0x1
    /sys/class/mmc_host/mmc0/mmc0:0001/manfid:0x00001b
    /sys/class/mmc_host/mmc0/mmc0:0001/name:00000
    /sys/class/mmc_host/mmc0/mmc0:0001/oemid:0x534d
    /sys/class/mmc_host/mmc0/mmc0:0001/preferred_erase_size:4194304
    /sys/class/mmc_host/mmc0/mmc0:0001/scr:02b5800200000000
    /sys/class/mmc_host/mmc0/mmc0:0001/serial:0xd29d55e2
    /sys/class/mmc_host/mmc0/mmc0:0001/type:SD
    /sys/class/mmc_host/mmc0/mmc0:0001/ueventRIVER=mmcblk
    /sys/class/mmc_host/mmc0/mmc0:0001/uevent:MMC_TYPE=SD
    /sys/class/mmc_host/mmc0/mmc0:0001/uevent:MMC_NAME=00000
    /sys/class/mmc_host/mmc0/mmc0:0001/uevent:MODALIAS=mmc:block

    # ls -l /flash
    total 126640
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0000.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0001.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0002.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0003.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0004.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0005.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0006.REC
    -rwxr-xr-x 1 root root 49152 Jan 1 1980 FSCK0007.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0008.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0009.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0010.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0011.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0012.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0013.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0014.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0015.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0016.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0017.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0018.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0019.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0020.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0021.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0022.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0023.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0024.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0025.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0026.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0027.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0028.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0029.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0030.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0031.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0032.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0033.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0034.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0035.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0036.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0037.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0038.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0039.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0040.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0041.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0042.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0043.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0044.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0045.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0046.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0047.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0048.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0049.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0050.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0051.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0052.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0053.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0054.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0055.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0056.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0057.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0058.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0059.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0060.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0061.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0062.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0063.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0064.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0065.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0066.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0067.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0068.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0069.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0070.REC
    -rwxr-xr-x 1 root root 8192 Jan 1 1980 FSCK0071.REC
    -rwxr-xr-x 1 root root 119328768 May 17 09:53 SYSTEM
    -rwxr-xr-x 1 root root 48 May 17 09:53 SYSTEM.md5
    -rwxr-xr-x 1 root root 12728 May 17 09:53 bcm2709-rpi-2-b.dtb
    -rwxr-xr-x 1 root root 13398 May 17 09:53 bcm2710-rpi-3-b.dtb
    -rwxr-xr-x 1 root root 17924 May 17 09:53 bootcode.bin
    -rwxr-xr-x 1 root root 57 May 29 19:25 cmdline.txt
    -rwxr-xr-x 1 root root 4785 May 17 09:53 config.txt
    -rwxr-xr-x 1 root root 9729 May 17 09:53 fixup.dat
    -rwxr-xr-x 1 root root 5758632 May 17 09:53 kernel.img
    -rwxr-xr-x 1 root root 48 May 17 09:53 kernel.img.md5
    drwxr-xr-x 0 root root 0 May 17 09:53 overlays
    -rwxr-xr-x 1 root root 3844392 May 17 09:53 start.elf

    # ls -l /flash/overlays/
    total 0

    Edited once, last by amediauser (May 30, 2016 at 2:01 PM).

    Had the same problem on an img install on a Pi1. I fixed it by downloading the tar, and copying over the overlays directory, then ssh'ed in and did "rm /flash/*.REC"

    Thanks popcornmix. Just re-downloading the refreshed 7.0.1 file (tar or img.gz) and re-applying as an update (copy the tar/img.gz to the Update folder, reboot) should fix the issue and clear up the fsck files.

    Thanks everyone for notifying us about the issue, and apologies that this slipped through testing - unfortunately it was a semi-random problem (1-in-4 maybe 1-in-3 chance of it happening), and installing images isn't something you tend to repeat if you can help it, particularly when it worked previously and hasn't changed...