This happens both when I attempt to install mender-client via apt-get and when mender-convert attempts to retrieve the Uboot bootloader via wget. I followed the instructions for configuring APT–both for v3 and v4–to no avail. I tried both the curl and wget commands provided in the Downloads section when logged into hosted.mender.io, which seem to include a cookie, and those don’t work either.
I see there’s another thread from two years ago that suggests a GPG problem preventing APT from working, but that doesn’t explain why plain wget doesn’t work, even when I provide a header with my session cookie.
The official Debian repo has mender-client and mender-connect but not mender-monitor, which is a feature my enterprise plans on using. Besides, I’d rather get the packages directly from Mender to rule out support issues.
For mender-monitor, there is a deb package, but it is not part of the package repository. This is because it’s proprietary licensed and available for download only if you have a plan which has the Add-On enabled. Having said that, the trial period counts technically as Enterprise tier, so you can just follow the documentation at Downloads | Mender documentation with your trial credentials.
Thank you for your reply. APT issues aside, I’m most interested your mender-convertfork since it supports Debian 64-bit, however when it attempts to download the bootloader (URL), it fails due to 403 Forbidden.
The 403 error seems to be a common pattern between APT and the arbitrary wget download for the bootloader, which makes me wonder if there’s a configuration issue with Mender’s download host rather than APT or mender-convert itself.
Thank you again for your help. I love the work you’ve done on mender-convert! The 64-bit support is greatly appreciated.
Edit: apt works on the live system, that part must be an issue with my build system
@duffy ah, my fork being involved is an important bit of information! Please try the Commits · TheYoctoJester/mender-convert · GitHub branch, as that one includes the bootloader binaries. Those are not officially released yet: in order for that to happen, first the patches to our u-boot fork must be merged, then the build scripts extended, then the binaries are actually up for download and the full pipeline is functional. Hence, the rpi_debian_64bit branch is the “sanitized” one for merging upstream, the “rpi64_wip_multiarch” is the one which should be working for local testing. Side effect, it also works on arm64 build hosts.
Side note: I will be away from the Mender Hub for the next two weeks roughly, for personal reasons. So I won’t be able to follow up timely from now on, sorry.
That makes sense! Thank you for explaining. I’m new to the Mender ecosystem so I wasn’t aware of what the state of the art was until now.
Indeed, the WIP branch successfully downloads the 64-bit bootloader. Sadly, Debian 12 64-bit enters an infinite boot loop when run on a CM4 (eMMC). Technically this isn’t about the 403 issue anymore so I’m not sure if I should post this as a separate topic.
In case this is useful, after running the rpi64_wip_multiarch branch against the current 64-bit version of Raspberry Pi OS Lite (Debian 12), this is what the console shows each time before it reboots indefinitely:
Net: eth0: ethernet@7d580000
PCIe BRCM: link down
starting USB...
No working controllers found
Hit any key to stop autoboot: 0
Working FDT set to 2e4e6d00
libfdt fdt_path_offset() return FDT_ERR_BADSTRUCTURE
switch to partitions #0, OK
mmc0(part 0) is current device
25463296 bytes read in 1075ms (22.6 MiB/s)
Moving Image from 0x80000 to 0x200000, end=1b60000