BSP 5.1.0 introduced boot.mount taking ages

[ TIME ] Timed out waiting for device /dev/disk/by-label/BOOT.

What is it and how it could be useful? Any other way to make it booting fast except to

systemctl disable boot.mount

P.S. Something odd with code posing from Edge. No new line at the end - code concatenates with comments following. New line - multiple empty code lines…

Greetings @Edward!

Can you please post some details about the image you’re using? Are you using a BSP downloaded directly from the Toradex Easy Installer or are you building this yourself?

Also, does this happen with one particular module or is it reproducible with other modules?

Hi @Edward,

The BSP 5.1.0 should be available in Easy Installer.
If it’s not appearing on the main screen by default, can you check by enabling the Continuuos Integration Server in the Feeds option?

Also, regarding your Yocto Build, could be an issue with it.
We are not using the branch dunfell-5.0.0, so please stay with dunfell-5.x.y.

If you want to get our latest changes, you can try our nightly builds. It uses the integration.xml instead of the default.xml. You can see more details here.

Best regards,
André Curvello

Hi @andrecurvello.tx ,

Thanks! Yes, Integration server works, though takes ages to populate downloads list on TEZI 1.8. And TEZI 2.0b6 is useless without real monitor, doesn’t work via RNDIS, at least with Windows version of VNC viewer.
Regarding boot.mount, it is activated in latest monthly 5.1.0, first monthly 5.1.0 version doesn’t have this issue.

Greetings @Edward!

The CI feeds are known to take a while to load due to the amount of images provided.

Some customers have reported issues accessing the TEZI VNC interface with certain clients. I’ve had success with Remmina on Linux and it seems that you can use TightVNC on Windows while we investigate and fix this.

Also, does a more recent nightly solve your issue? Does it happen with a particular module or with any module you test this with?


We reverted the boot.mount solution in favour of a solution which does not delay the boot if the partition with the boot files does not exist, e.g. on a module with Raw NAND.

Tomorrows nightly should include the fix. Alternatively you could rebuild your image with an update meta-toradex-bsp-common and meta-toradex-demos or, as you already found out by disabling the boot.mount unit.

The feature targets modules with an eMMC were customers were confused that the partition with the files used for boot wasn’t mounted at /boot.


Hi @max.tx

Thank you very much for fix end for explaining purpose of this service


Hi @gustavo.tx

5.1.0 is not available in Toradex Easy Installer. I just did repo sync and bitbake.
Hm, do you think my repo is wrong initially? OK. Copy pasting from here

repo init -u -b dunfell-5.x.y -m tdxref/default.xml

It worked. Changing 5.x.y to 5.0.0

edward@edward-VirtualBox:~/oetrash2$  repo init -u -b dunfell-5.0.0 -m tdxref/default.xml
Downloading Repo source from
remote: Counting objects: 1, done
remote: Finding sources: 100% (19/19)
remote: Total 19 (delta 9), reused 19 (delta 9)
Unpacking objects: 100% (19/19), 11.73 KiB | 235.00 KiB/s, done.
Downloading manifest from
fatal: couldn't find remote ref refs/heads/dunfell-5.0.0
fatal: couldn't find remote ref refs/heads/dunfell-5.0.0

fatal: couldn't find remote ref refs/heads/dunfell-5.0.0
fatal: couldn't find remote ref refs/heads/dunfell-5.0.0

fatal: cannot obtain manifest

So looks like I have only one choice, latest 5.1.0. Isn’t it. It would be to nice to have repo init commands for LTS and monthly releases.

Update. Looks like this is the right way to repo init specific version. Isn’t it?

repo init -u -b refs/tags/5.0.0 -m tdxref/default.xml

Available tags could be found here

Ugh. And if I need to upgrade… new repo init and compile everything from scratch? Another hundred of gigabytes and “only” couple of hours on i7-9700? OK. Thanks.