ALERT! /dev/mmcblk0p1 does not exist

[MEMEs]

Hi there,

I have a rockpi 4b running armbian bionic desktop legacy kernel 4.4y on a 128 GB emmc module, I’d like to use this machine as a server.
I was just tinkering around with Plex, .bashrc and crontab while all of a sudden the keyboard mapping over RDP changed (e.g. > became ;, ~ became @ etc) (indication of the problem?).
I tried to fix this by changing the system keyboard layout and running dpkg-reconfigure keyboard-configuration, this all didnt work.
I decided to reboot the machine to see if that would work. After the reboot I could not connect to either RDP or SSH so I decided to connect the machine to a HDMI monitor. This resulted in the following output:

Can anyone help me understand what I am seeing here and how this could have happened ? Is this even Ubuntu ? Or is this GRUB ? Where in the boot process is this ?

My guess is that the whole EMMC is disconnected but this seems very weird since I did not touch the board in any way. (I have no SD installed)

I’m now thinking of solving this problem by attaching the emmc to a sd reader and backing up the etc,home,opt,root,srv,usr and var folder, reflashing the image and putting the folders back. This is however a very destructive process so I hope something less destructive is possible. I also even don’t know if this is going to work since I have no idea how this problem was caused.

Can anyone help me please ?

Thanx in advance!

Thank you in advance

Edited August 24, 2019 by MEMEs
More clear text

[MEMEs]

To clarify, there only an emmc and not an sd card equipped. I've tried to physiclly reinstall the emmc but that did not solve the problem. 

 

When I try to mount the EMMC using an EMMC to SD converter the mounted card cannot be opened because it's read-only. Is this a sign of a failing emmc ?

[MEMEs]

I ended up just reinstalling the system

[qume]

This happened to me too. We have the RockPi 4 embedded in a product so when this randomly happens it bricks it.

 

If anyone has any thoughts as to why it would happen out of the blue that mmcblk0 switches to mmcblk1 out of the blue it would be good to get to the bottom of it

 

Thanks

[tparys]

First, "armbian-monitor -u". Edit your top post and add it at the top.

 

What you're seeing is initial ramfs (or initramfs), but is often written as inital ramdisk (or initrd) for historical reasons. It's singular job is to mount the root filesystem before init / SystemD takes over. It's basically a compressed archive (CPIO) of a bunch of scripts made by initramfs-tools (or dracut on systems like Redhat) that load drivers and pivot to the real filesystem before continuing.

 

In this case, it's attempting to mount the device listed as "/dev/mmcblk0p1", and it can't find it, and eventually gave up. Linux is running, but boot is stuck.

 

If the MMC interface is anything like the Ethernet subsystem, devices get enumerated based on the order they are found. So eth0 is first, eth1 is second and so forth. If two drivers load at the same time, there's a possible race condition and they can flip occasionally, and even change behavior after a software update. This is also the reason for the "persistent" Ethernet device names like "enp3s2" which are crazy looking, but deterministic.

 

I've noticed that many ARM boards get device names from the DTB aliases. But maybe it's not being used for whatever reason? Not sure.

 

In the meantime, if mmcblk0 and mmcblk1 occasionally swap position, it's probably far better to specify your root device via LABEL or even better, by UUID.

 

$ sudo blkid /dev/mmcblk0p1

 

Then change your boot arguments to include "root=UUID=<WHATEVER>". Should be in /etc/armbianEnv.txt. but don't have it in front of me at the moment.

 

Also update your /etc/fstab to point to "UUID=<WHATEVER>", else you won't get much further.

 

More information on initramfs-tools, and boot arguments: https://manpages.debian.org/testing/initramfs-tools-core/initramfs-tools.7.en.html

[qume]

@tparys this is very good advice. It seems the problem was the armbianEnv.txt was becoming corrupt, and losing the UUID (and everything else - the file seems to be clobbered with random content)

 

This corruption problem of armbianEnv.txt used to happen all the time, then after an update it stopped happening on all the devices.

 

This device hasn't been updated or modified in any way in a long time, and it happened again. So I guess the frequency of it happening was reduced greatly but the problem persists.

 

 

 

 

 

[Rodrigo V. Lopes]

I had the same issue and after all I confirm that the problem is exclusively with armbianEnv.txt being corrupted. I spent many hours trying to figure out how to fix it and fortunately it was easy.

 

Steps:

1) burn a SD card with the same Armbian version as installed in your emmc 

2) boot from the SD

3) mount the emmc: 

  mkdir /mnt/emmc
  mount /dev/mmcblk1p1 /mnt/emmc

4) copy the armbianEnv.txt from SD card to Emmc

cp /boot/armbianEnv.txt /mnt/emmc/boot/armbianEnv.txt

 

Important:

* Armbian 21 moved armbianEnv.txt from /etc to /boot

* Armbian 21 is using UUID for rootdev configuration

* blkid is the same for emmc and sd

[FredrikA]

Linux orangepi4 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux

Mine has renamed to 1 and 2

Filesystem     1K-blocks     Used Available Use% Mounted on

pi@orangepi4:~/ext-src/opencv/build$ df | grep mmc
/dev/mmcblk1p1  60651184 22786748  37212048  38% /
/dev/mmcblk2p1  14961544 12154596   2027224  86% /mnt/mmc

Previously the were 0 and 1 using kernel 4.4.213-rk3399