Yocto build failures due to offline repositories

Technical Support
, ,
1

Lately I’ve seen some sporadic build failures when attempting to build our customized Yocto image where the requisite u-boot repository is offline (either u-boot-toradex, or u-boot.denx.de). This fails despite the local DL_DIR being persisted and having a cached copy of the required commit. Casually browsing git.toradex.com seems to suggest all the repositories are currently offline/unavailable due to a technical issue.

t HOME="/"; git -c gc.autoDetach=false -c core.pager=cat -c safe.bareRepository=all ls-remote https://git.toradex.com/u-boot-toradex.git  failed with exit code 128, output:
fatal: unable to access 'https://git.toradex.com/u-boot-toradex.git/': The requested URL returned error: 502

The variable dependency chain for the failure is: fetcher_hashes_dummyfunc[vardepvalue]

image
image919×289 27.7 KB

Naturally a single point of failure like this is sub-optimal. For official u-boot this can be resolved by adding the github u-boot repo as a mirror; however I’m not aware of any such mirror available for u-boot-toradex - I only see forks belonging to third parties.

Naturally we could maintain our own internal mirrors and manually patch the recipes, but in the interest of a more robust fix that benefits everyone, could I request the Toradex team consider the following?

  • Add mirror(s) to the recipe that relies solely on u-boot.denx.de
  • Consider mirroring u-boot-toradex (and perhaps other repositories) from git.toradex.com to a third-party (github?) and add those mirrors to the relevant recipes?

Thanks!
~BW908

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I understand your frustration with the sporadic build failures when git.toradex.com repositories become unavailable. This is indeed a known issue that affects Yocto builds when the primary repository sources are unreachable, even when local caches exist.

Current Repository Structure

Toradex maintains several BSP layers and repositories that are essential for building custom images (1). The main repositories include:

  • toradex-manifest: Contains all layers used by Torizon OS and Reference Images
  • meta-toradex-bsp-common: BSP layer common to all Toradex modules
  • meta-toradex-nxp: BSP layer for NXP SoC-based modules
  • meta-toradex-ti: BSP layer for Texas Instruments SoC-based modules

Workarounds for Repository Availability Issues

Based on community experiences, here are some approaches to mitigate this issue:

1. Alternative Repository Access Methods

Some users have found success using different protocols when the HTTPS access fails (2). You can try modifying your repository access to use:

git clone git://git.toradex.com/meta-toradex-bsp-common.git

Instead of the HTTPS variant that may be experiencing issues.

2. Local Repository Mirroring

While you mentioned maintaining internal mirrors, this remains one of the most robust solutions for production environments. You can:

  • Clone the essential repositories locally during stable periods
  • Modify your local.conf to point to your internal mirrors
  • Set up automated synchronization during maintenance windows

3. Yocto Build Configuration

Ensure your Yocto build configuration includes proper fallback mechanisms. The Yocto Project documentation suggests configuring multiple source URIs where possible (1).

Repository Status and Alternatives

The issue you’re experiencing appears to be related to temporary server availability problems (3). While there isn’t currently an official GitHub mirror for u-boot-toradex, the community has noted that such infrastructure improvements would benefit all users.

Recommendations

  1. Immediate Solution: Use the git:// protocol instead of HTTPS when accessing Toradex repositories
  2. Medium-term: Implement local mirroring for critical repositories in your build infrastructure
  3. Build Resilience: Configure your build system to retry failed downloads after a delay

Your suggestions for adding repository mirrors and improving the robustness of the build system are valuable feedback that would benefit the entire Toradex community. The current single point of failure does create unnecessary build interruptions for development teams.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Greetings @bw908,

What version of Torizon OS are you building in Yocto?

We do have PREMIRRORS set as seen here: Making sure you're not a bot!

Though in Torizon OS we only configured these starting in 7.X/Scarthgap: torizon: inherit toradex-mirrors class · torizon/meta-toradex-torizon@c52ae54 · GitHub

Looking at our artifacts link provided for the mirrors, there should be artifacts for u-boot-toradex as well.

Best Regards,
Jeremias

4

Hi Jeremias,

this is with 7.4.0. based builds.

The error happens during the parsing recipes step rather than any of the actual “work” steps (setscene/checkout/configure etc), which seems to suggest that stage may not be using the mirrors correctly.

~BW908

5

I see, I didn’t realize this error was still in the parsing stage. In which case then yeah I believe the premirrors don’t get utilized at this stage. A proper mirror would most likely be needed as you said.

I’ll bring this up internally with our team as a discussion point to see how this could be better improved. Thanks for bringing this to our attention.

Best Regards,
Jeremias

1 Like
6

Thanks - Keep us posted!

7

Just a quick update. It seems these instabilities with git.toradex.com, are a fairly recent occurrence and already known to our team. Our team is already working on possible solutions and improvements to the situation.

Best Regards,
Jeremias

1 Like