Imagebuilder - Error in the pull function in ./scripts/feeds update -a process

For Developers
1

I dragged out an unused Mint 19 laptop to dedicate to building OpenWrt images from Snapshot, and set to following Quick Image Building Guide.

All went well until I got to the Update and install feeds process - ./scripts/feeds update -a

When it got to Updating feed 'luci', it errors out with failed: Error in the pull function.

Same for feed 'routing', feed 'telephony' is OK, feed 'freifunk' seems OK, but then in Collecting package info: feeds/freifunk it all goes bad from there.

Checking the dump.txt logs as directed, they all seem to refer back to the original error with same content in each dump.txt file:

cat dump.txt
../../freifunk.mk:12: *** did not find luci.mk in any feed.  Stop.

Can anyone please shed some light on what I might be missing?

3

Sorry, I knew the buildbots were having an issue, but when @hnyman posted

“Packages for mvebu routers have been rebuilt a few hours ago...”

I figured I was good to go for my platform. I’ll just sit tight a few days.

4

It is likely not related to the buildbot problems.

I guess that your problems are more related to some build tools missing from Linux mint.

You can also disable the freifunk feed (in feed config file)

5

Hmmmm. Used this for the build prerequisites:

sudo apt-get update
sudo apt-get install subversion g++ zlib1g-dev build-essential git python python3 python3-distutils libncurses5-dev gawk gettext unzip file libssl-dev wget libelf-dev ecj fastjar java-propose-classpath

No faults through that.

Seems strange that Cloning into './feeds/packages'...,
Cloning into './feeds/telephony'..., and
Cloning into './feeds/freifunk'... were successful, but
Cloning into './feeds/luci'... and Cloning into './feeds/routing'...
both returned:
fatal: unable to access 'https://git.openwrt.org/project/luci.git/': gnutls_handshake() failed: Error in the pull function.

Doesn't seem to point to missing build tools.

6

You have SSL (tls) problems for some reason. No SSL download capabilities?

7

User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Protocol Support

TLS 1.3 :heavy_check_mark: Enabled
TLS 1.2 :heavy_check_mark: Enabled
TLS 1.1 × Disabled (Good)
TLS 1.0 × Disabled (Good)

Mixed Content Handling Test

Images :heavy_check_mark: Upgraded to HTTPS
Audio :heavy_check_mark: Upgraded to HTTPS
Video :heavy_check_mark: Upgraded to HTTPS
CSS :heavy_check_mark: Blocked
Scripts :heavy_check_mark: Blocked
Frames :heavy_check_mark: Blocked

Handshake

TLS Protocol TLS 1.3 [HTTP/2.0]
Cipher Suite 0x1302 TLS_AES_256_GCM_SHA384 Good

????????????????????

8

Your browser has no role in the download.
As you ssee from the error message, the "GnuTLS" library is used for the download byu the download tool.

No idea what is wrong, but likely something related to your environment (cache, antivirus, whatever), as there been no general error flood about downloads.

9

Yea. I felt more than a little dense when I thought about it. :roll_eyes: :grimacing:

FWIW, I have a suspicion it may have had something to do with my VPN and/or PBR. I can't be definitive of that, but with two contrasting fails and success only when VPN and VPN-PBR are taken out of the equation, well . . . I dunno.

rm -r openwrt
and started over -
Updating feed 'luci' was sucessful this time, but conversely, Updating feed 'telephony' failed this time around. Hmmm - contrasting outcome.

Grasping at straws, I stopped PBR and took down the VPN and repeated the process. Voila! Success.

10

+1

Yeah... (What the heck is PBR?)

Likely your software caused the SSL handshake to fail due a "man-in-the-middle" attack suspicion, or something like that. Having any middlemen in HTTPS traffic is a no-go for secure libraries.

11

Policy Based Routing