Jump to content
  • 0

Espressobin: won't boot after upgrade to 5.38


php
 Share

Question

I've been running 5.36 successfully on my espressobin. Saw the upgrade to 5.38, so ran apt-get update and upgrade. Now the boot process shows this log snippet:

[    6.251662] md: autorun ... 
[    6.254188] md: ... autorun DONE. 
[    6.258090] Waiting for root device /dev/mmcblk0p1... 
[    6.267577] mmc1: new high speed SDHC card at address aaaa 
[    6.273478] mmcblk1: mmc1:aaaa SL16G 14.8 GiB 
[    6.279091]  mmcblk1: p1 
[  201.869175] random: crng init done

I've let it sit for a while after this (200 seconds in), but no more log lines. Any other espressobin users successfully running 5.38?

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

  • 0

The device node for the SD card has changed from mmcblk0 to mmcblk1.

You need to edit the file `/boot/armbianEnv.txt`. Either you change  mmcblk0 to mmcblk1 there as well or you modify the  `rootdev` variable to something like:

 

rootdev=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

 

where xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx has to be replaced by the UUID of /dev/mmcblk1p1.


 

sudo blkid

will tell you the right UUID. 

Link to comment
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

Hi @umiddelb, thanks for your suggestion but I'm confused. In my log above, it's trying to boot from mmcblk1p1. My armbianEnv.txt file looks like this, already with the UUID of my microSD card (verified in Ubuntu)

verbosity=1 
emmc_fix=off 
eth1addr=00:50:43:25:fb:84 
eth2addr=00:50:43:84:25:2f 
eth3addr=00:50:43:0d:19:18 
rootdev=UUID=dc2768b6-c4f5-466e-83c1-6cf4aa49a898 
rootfstype=ext4 
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

For kicks I changed it to `rootdev=/dev/mmcblk1p1` but got the same result. Can you provide a reference to the change you mention? I looked at the commit history for boot-espressobin.cmd but it doesn't show recent changes.

Link to comment
Share on other sites

  • 0
25 minutes ago, Igor said:

Is this problem related to specific kernel, 4.4.y / 4.14.y?

I don't know what precipitated the change from mmcblk0 to mmcblk1, but after upgrading to armbian 5.38 I'm running kernel 4.14.14

Link to comment
Share on other sites

  • 0
22 minutes ago, php said:

I don't know what precipitated the change from mmcblk0 to mmcblk1, but after upgrading to armbian 5.38 I'm running kernel 4.14.14


eMMC support was recently added to this kernel and that could trigger this problem. Not sure ATM. When reporting a problem it saves time if people add their full logs, preferably with

armbianmonitor -u

.Sometimes a quick scan can already provide an answer.

Link to comment
Share on other sites

  • 0
10 hours ago, Igor said:


eMMC support was recently added to this kernel and that could trigger this problem. Not sure ATM. When reporting a problem it saves time if people add their full logs, preferably with


armbianmonitor -u

.Sometimes a quick scan can already provide an answer.

Thanks for that tip @Igor Is there any diagnostic value in gathering those logs even after I changed my boot args to get back up and running? I could revert the change to the boot args if helpful.

Link to comment
Share on other sites

  • 0

You should be able to read and modify the stored custom u-boot environment since the -next kernel has built-in support for the M25P80 chip. To gain access, you need to pass some partitioning information to the kernel command line. You may check if the device files /dev/mtd[012] exists. Otherwise you need to add the following parameter to the command line:

 

mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved)

Then, after having rebooted, you need to install the `u-boot-tools´ package and modify `/etc/fw_env.config´ like this

# device name   device offset   env. size   flash sector size  number of sectors
/dev/mtd1       0x0             0x00010000  0x1000             0x10

Now you can make use of `fw_printenv´ and `fw_setenv´ to get userland access the u-boot environment. 

Link to comment
Share on other sites

  • 0
42 minutes ago, umiddelb said:

You should be able to read and modify the stored custom u-boot environment since the -next kernel has built-in support for the M25P80 chip. To gain access, you need to pass some partitioning information to the kernel command line. You may check if the device files /dev/mtd[012] exists. Otherwise you need to add the following parameter to the command line:

 


mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved)

Then, after having rebooted, you need to install the `u-boot-tools´ package and modify `/etc/fw_env.config´ like this


# device name   device offset   env. size   flash sector size  number of sectors
/dev/mtd1       0x0             0x00010000  0x1000             0x10

Now you can make use of `fw_printenv´ and `fw_setenv´ to get userland access the u-boot environment. 

Thanks @umiddelb, that sounds much more elegant than my approach of powering up without the microSD card inserted :-) 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...