DietPi Update error occurred during first run update

[gp4311]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=9 G_DIETPI_VERSION_RC=0 G_GITBRANCH='master' G_GITOWNER='MichaIng'
• Distro version | bookworm 0
• Kernel version | Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
• SBC model | RPi 4 Model B (aarch64)
• Power supply used | 5V 3A
• SD card used | KEXIN microSD 32 GB

Additional Information (if applicable)

• Was the software title installed freshly or updated/migrated? freshly installed
• Can this issue be replicated on a fresh installation of DietPi? yes

Steps to reproduce

1. Download the DietPi disk image.
2. Flash the DietPi image.
3. Modify the DietPi image.
   d. Open dietpi.txt and change the following settings:
   AUTO_SETUP_KEYBOARD_LAYOUT=us
   AUTO_SETUP_TIMEZONE=America/Toronto
   AUTO_SETUP_NET_ETHERNET_ENABLED=0
   AUTO_SETUP_NET_WIFI_ENABLED=1
   AUTO_SETUP_NET_WIFI_COUNTRY_CODE=CA
   CONFIG_NTP_MIRROR=gateway
   e. Open dietpi-wifi.txt and change the following settings:
   aWIFI_SSID[0]=''
   aWIFI_KEY[0]=''
   f. Eject the SD card.
4. Insert the SD card into the Pi, connect power and peripherals, and boot.

Expected behaviour

• DietPi-Update should get latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version

Actual behaviour

DietPi-Update
─────────────────────────────────────────────────────
 Phase: Checking for available DietPi update
[  OK  ] DietPi-Update | Checking IPv4 network connectivity
[  OK  ] DietPi-Update | Checking DNS resolver
[ INFO ] DietPi-Update | Getting latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version
curl: (35) Recv failure: Connection reset by peer
[FAILED] DietPi-Update | Unable to get latest version.
[ INFO ] DietPi-Update | Please check the target Git repository and your network connection, then rerun dietpi-update.
[ INFO ] DietPi-Update | If this error persists, please report at: https://github.com/MichaIng/DietPi/issues
[ INFO ] DietPi-Update | APT update, please wait...
Hit:1 https://dietpi.com/apt bookworm InRelease
Hit:2 https://archive.raspberrypi.com/debian bookworm InRelease
Hit:3 https://dietpi.com/apt all InRelease
Hit:4 https://deb.debian.org/debian bookworm InRelease
Hit:5 https://deb.debian.org/debian bookworm-updates InRelease
Hit:6 https://deb.debian.org/debian-security bookworm-security InRelease
Hit:7 https://deb.debian.org/debian bookworm-backports InRelease
Reading package lists...
[  OK  ] DietPi-Update | APT update
[ INFO ] DietPi-Update | Storing number of available APT upgrades to file: /run/dietpi/.apt_updates

Additional Information

• Raspberry Pi has internet access

[Joulinar]

can you check following

curl -I https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version

[gp4311]

After running the command that you specified above:
curl: (35) Recv failure: Connection reset by peer

[Joulinar]

@MichaIng I remember some rare cases where we had similar on curl. Not sure if we found a solution or reason.

[gp4311]

The Pi is connected to a corporate Wi-Fi. Do you think there might be an issue with ISP restrictions, firewall rules, or network blocks?

[gp4311]

Is there a way to disable the process to get the latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/master/.update/version

[Joulinar]

usually not, I mean this will prevent future updates of our scripts

[gp4311]

I understand that, but the cURL request sent to GitHub is blocked by a firewall because I am on a corporate Wi-Fi, which blocks all outbound cURL requests. Do you have any possible workarounds?

[MichaIng]

I am on a corporate Wi-Fi, which blocks all outbound cURL requests

Oh, that explains it. Well, a lot of DietPi scripts, and Linux systems in general, also a lot of software etc strictly depend on cURL or the cURL library. Not sure whether you have any chance to get this nonsense rule removed from this firewall? There is literally zero reason to ever do that, every browser access to anything is naturally more insecure than cURL, as it does not execute JavaScript, CSS or any other web technology, but just prints the raw body content to STDOUT. If not, there is nothing we can do, blocking cURL means breaking basically all network-capable Linux and UNIX systems at their core.

EDIT: Do you know how cURL is blocked in particular? It does not fix library requests, but you could override the HTTP user agent curl uses:

cat << '_EOF_' > /usr/local/bin/curl
#!/bin/dash
exec curl -A 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36' "$@"
_EOF_
chmod +x /usr/local/bin/curl

This is the user agent latest Chrome on Linux currently uses. If this works, it only shows how ridiculous this firewall is. Actually, another problem might be TLS inspection, as this should all be encrypted, and now visible to a firewall, unless it breaks end-to-end security.