EMMC broken on OrangePI PC+

[Da Alchemist]

At first i like to say that this problem is not caused  by Armbian. On my OpiPC+ my EMMC has became unusuable. I got a first hint to this by updating 5.17 Jessie Desktop to 5.20, that failed after downloading 135 MB of Files.

 

I did not thought of an Error and compiled 5.20 myself, put it on SDcard and run nand-sata-install. The Script does it work without any Errors, but after power down, the  Opi did not come up again.

 

Put in the SDcard again and tried to look at the EMMC but it was not mountable. There were some Errors fixed by running fsck  but next time i tried to write on the Emmc i got Errors again, in fact i tried to run nand-sata-install again after i tried to boot from Emmc again, that fails.

 

I run fsck again and wrote a new partiton Table, next fsck-run was without errors, everything looks fine, but  next time mounting  Emmc gives bad Supeblocks Errors etc. again.

 

I have used the OPi a couple of Month as Desktop replacement, that was sufficient for me, according to  Powerconsumption. As Browser i used Chromium, that was stolen from Ubuntu 14.04 armhf (you only need three Files from the Ubunto repos, the Browser itself, chromium-extra-codecs and libgcrypt, but this is not working on 5.20 because of the new opengl feature.)

 

I think writing a lot of Files to EMMC has broken it somehow, so the Opi running from EMMC is not the best for this needs, perhaps running from a Filessystem in Ram would be a better solution.( I have used PuppyLinux and Tinycore on slow x86 Machines and speed was amazing for the old desktops.)

 

Anyway, has  someone any Ideas to get the EMMc back to life?

 

Regards

[tkaiser]

Can you provide the ouput from 'sudo armbianmonitor -u' please?

[Da Alchemist]

Of course here it is: http://sprunge.us/cWPI
 

and this message i got by trying to mount the emmc:

Error mounting /dev/mmcblk1p1 at /media/ek/a6d3948d-7cb3-4110-8034-8ccb4a492abf: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/mmcblk1p1" "/media/ek/a6d3948d-7cb3-4110-8034-8ccb4a492abf"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/mmcblk1p1,
       missing codepage or helper program, or other error

[tkaiser]

Thanks. Hmm... I would collect output of 'cat /proc/partitions' now, then reformat the whole eMMC, mount it somewhere (eg. /mnt/emmc) and then run 'armbianmonitor -c /mnt/emmc' -- might take a long time since it checks the whole device then). And then check 'cat /proc/partitions' again and also output from armbianmonitor -u (or the last relevant lines from dmesg):

cat /proc/partitions
sudo mkfs.ext4 -f /dev/mmcblk1p1
sudo mkdir /mnt/emmc
sudo mount /dev/mmcblk1p1 /mnt/emmc
armbianmonitor -c /mnt/emmc
cat /proc/partitions

[tkaiser]

I think writing a lot of Files to EMMC has broken it somehow, so the Opi running from EMMC is not the best for this needs, perhaps running from a Filessystem in Ram would be a better solution.

 

Armbian's default mount options for the rootfs are these: noatime,nodiratime,commit=600 (minimize writes, write changes to 'disk' only every 10 minutes). It would be interesting how that looks like when Chromium is running (maybe doing all the time syncs to 'disk'). Can you have a look using 'iotop' in another window what happens when you're surfing the web?

[Da Alchemist]

I made a small test with Firefox, because Chromium is not running on 5.20 , while browsing the web, there are  write accesses to disk the whole time (even while writing this)

[tkaiser]

I made a small test with Firefox

 

Well, Firefox is known to be quite 'useful' for disk stress tests. If I would use Firefox on any SBC then not without the necessary tweaks.

[Da Alchemist]

sudo mkfs.ext4 -f /dev/mmcblk1p1

leads to an error

 

 

did you mean

sudo mkfs.ext4 /dev/mmcblk1

instead, that is what i have used before...

[tkaiser]

Well, above you were talking about /dev/mmcblk1p1 all the time so I assumed there's valid partition table on the device. I don't think you can use ext4 directly on a device? Anyway, just realized that we ship with btrfs-tools in legacy H3 images which is ok for this test (or even better). Please try

mkfs.btrfs -O ^extref,^skinny-metadata -f /dev/mmcblk1

And if this succeeds then mount the btrfs fs available as /dev/mmcblk1 to /mnt/emmc and let it then check (btrfs will do checksumming on its own so you might get already huge amounts of errors when testing)

[Da Alchemist]

mkfs.btrfs -O ^extref,^skinny-metadata -f /dev/mmcblk1

works without Errors, mountint to emmc works, armbianmonitor is denied as root or user:

ek@orangepipcplus:~$ armbianmonitor -c /mnt/emmc

WARNING: It seems you're not testing the SD card but instead /dev/mmcblk1 (btrfs)

mktemp: konnte das Verzeichnis nicht mittels Schablone „/mnt/emmc/cardtest.XXXXXX“ erstellen: Keine Berechtigung
/usr/local/bin/armbianmonitor: Zeile 731: /.starttime: Keine Berechtigung
ek@orangepipcplus:~$ sudo armbianmonitor -c /mnt/emmc
Checking disks is not permitted as root or through sudo. Exiting

[tkaiser]

Sorry, I always make the mistake to assume everyone's absolutely familiar with Linux and leave necessary steps out. All that's needed now is a

sudo chown -R ek /mnt/emmc 

Afterwards the check should be running. If not create as root 'mkdir -m777 /mnt/emmc/test' and point armbianmonitor to this directory instead.

[Da Alchemist]

sudo chown -R ek /mnt/emmc 

does the trick

 

armbianmonitor reports

Health summary: OK

and cat /proc/partitions gives

ek@orangepipcplus:~$ cat /proc/partitions
major minor  #blocks  name

 179        0   31260672 mmcblk0
 179        1   30947040 mmcblk0p1
 179       16    7634944 mmcblk1
 179       48       4096 mmcblk1boot1
 179       32       4096 mmcblk1boot0

Is it possible to use nand-sata-install again or do  ihave to change the filessytem to ext4 somehow before ?

[tkaiser]

IIRC you need to create a single partition before that will then be formatted as ext4 if not already done. You could now also do some magic stuff and use flashbench to get optimal ext4 parameters (just do a web search for 'flashbench ext4 stride' or something like this) but i would keep it simple.

 

BTW: device size 7634944 looks ok. Please get back to us anyway how stuff proceeds.

[Da Alchemist]

No matter what i try here; whenever it comes to ext4, i can not mount the emmc. I have used gparted, i wrote zeros on it with dd ....what is puzzling me is the output of fsck, that is the allways the same, there is one big file and two directories on a new formatted partition

ek@orangepipcplus:~$ sudo fsck.ext4 -v -f -y -c /dev/mmcblk1
e2fsck 1.43.3 (04-Sep-2016)
Es wird nach defekten Blöcken gsucht (Nur-Lesen-Modus):  0.00% erledigt, 0:00 verledigt                                             
/dev/mmcblk1: Updating bad block inode.
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft

/dev/mmcblk1: ***** DATEISYSTEM WURDE VERÄNDERT *****

          11 Inodes sind in Benutzung (0.00% von 477664)
           0 nicht zusammenhängende Dateien (0.0%)
           0 nicht zusammenhängende Verzeichnisse (0.0%)
             # von Inodes mit ind/dind/tind Blöcken: 0/0/0
             Histogramm der Tiefe von Erweiterungen: 3
       54759 Blöcke werden benutzt (2.87% von 1908736)
           0 defekte Blöcke
           1 große Datei

           0 reguläre Dateien
           2 Verzeichnisse
           0 zeichenorientierte Gerätedateien
           0 Blockgerätedateien
           0 Fifos
           0 Verknüpfungen
           0 symbolische Verknüpfungen (0 schnelle symbolische Verknüpfungen)
           0 Sockets

[tkaiser]

Hmm... I would try to keep it simple and stop accessing /dev/mmcblk1 with ext4 and better create /dev/mmcblk1p1 instead. Using something like this

parted -s /dev/mmcblk1 mklabel mbr
SectorCount=$(parted -s /dev/mmcblk1 unit s print | awk -F": " '/^Disk \/dev\/mmcblk1/ {print $2}' | tr -d 's')
LastUsableSector=$(( ${SectorCount} / 2048 ))
parted -s /dev/mmcblk1 --align optimal unit s mkpart primary ext4 2048 $(( ${LastUsableSector} * 2048 ))
mkfs.ext4 -b 4096 /dev/mmcblk1p1

[Da Alchemist]

parted -s /dev/mmcblk1 mklabel mbr

gives an error at once:

ek@orangepipcplus:~$ sudo parted -s /dev/mmcblk1 mklabel mbr
[sudo] password for ek: 
parted: invalid token: mbr
Error: Expecting a disk label type.

[tkaiser]

No idea, I usually use gpt instead, just thought most Linux user love stuff from last century and maybe u-boot might not be able to deal with GPT. There are tutorials available how to create partitions on a device in Linux, simply use them please

[Da Alchemist]

Thanks for your patience. I will stop trying to get the EMMC back, a 20$ Machine is not worth spending so many time on it, in the end it is only another broken SD-Card . (Now I know that i can still use it with btrfs )

A Samsungs Evo is dong its job in the Slot and Firefox is running smoothly with Cache in Ram and the new Opengl  feature.

 

Regards

[Da Alchemist]

It is finally up again with some"dirty" trick.

 

To make things clear, no matter what i have tried it was impossible to mount the emmc when there was a ext4 Partition on it (even if there was a device /dev/mmcblk1p1). Using Gpt instead of msdos Label did not make any difference.

 

The fact, that is was possible to use the Emmc with btrfs leads me to try ext3 insead of ext4, so after creating an ext3 Partition I was able to mount Emmc again.  There was a Directory "Lost and Found" 193MB on it, but I could mount it.

 

Next step was simple, I forced nand-sata-install to use ext3 instead of ext4 and Armbian is up and running again.

 

Regards

[wildcat_paris]

@Da Alchemist

 

be careful, don't put any sensitive data (or at least, do regular backup) because the eMMC may get worse and fail completely.

[tkaiser]

As Browser i used Chromium ... I think writing a lot of Files to EMMC has broken it somehow

 

Related read (about Firefox but applies to Chromium too): https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/

[arox]

Related read (about Firefox but applies to Chromium too): https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/

And that is for IO. If you use ff on a badly cooled card with bad throttling protection, always have a "cpu meter" on your desk if you dont want ff to burn your board. There are a lot of pages with looping, experience enhancing, sniffing javascript. And no protection or easy way to kill these scripts or hinder periodic recall of the script.