First boot - Not able to fetch data with HTTPS/443

It started with first “apt-get update” where the https sources (i.e. did not respond. I tried to send bug report, did not work as the request was on 443.

I passed the ‘update’ part by changing the https://’ in ‘source.list’ to http://

Now I am stuck at “Downloading current dietpi.txt” step, which is hosted in github (https://). No errors, whatsoever.

I have updated system time, tried to update certificates i.e but no luck.

Can anyone provide permanent solution, rather than a work around?

  • DietPi version | v6.32.2 (MichaIng/master)
  • Image creator | DietPi Core Team
  • Pre-image | Raspbian Lite
  • Hardware | RPi 4 Model B (armv7l) (ID=4)
  • Kernel version | Linux DietPi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux
  • Distro | buster (ID=5,RASPBIAN=1)


many thanks for your message. Do you have anything on your network that could block https access to the internet? Like a firewall, a proxy or a router?

No, nothing on router. Pure connection without proxy, vpn or even additional firewall. I am able reach those links from other devices in network.

I have tried both ethernet and wifi on Pi however same result.

Further, I can successfully curl and wget to from the same device

what if you try to curl the file that is hanging?

BTW: try to copy/post the output from your terminal/ssh session instead of doing screen prints. thx

curl gets it.

root@DietPi:~# curl
# - This is intended for advanced users, unless you know what you are doing, do not edit this file. Please use the DietPi programs instead.
# - Do not remove uncommented lines, as the items are scraped by DietPi programs, on demand.

Thanks for the tip and prompt responses. Really appreciated.

and if you use wget. Does this work to download the file? Because that’s what is done on the step your system stuck.

There it is! It hangs at wget

root@DietPi:~# wget
--2021-01-17 12:00:18--
Resolving (
Connecting to (||:443... connected.

I guess one of the following is working?

wget --no-check-certificate

http request redirects to https and hangs in there

root@DietPi:~# wget
--2021-01-17 12:20:12--
Resolving (
Connecting to (||:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: [following]
--2021-01-17 12:20:12--
Connecting to (||:443... connected.

no-check-certificate has no use either

root@DietPi:~# wget --no-check-certificate
--2021-01-17 12:20:33--
Resolving (
Connecting to (||:443... connected.

hmm you could try to reinstall wget as well as ca-certificates

apt update
apt --reinstall install ca-certificates wget

Reinstalled wget and certificates. However unfortunately same state. Hanging.

Any ideas why wget could be hanging on Https request?

Connected to my phone’s hotspot (different network/cellular), incase of MTU or any other packet related issue however it did not work either.

Wget hangs at https requests.


I tried same in raspberry OS setup, it did not go through. Then installed OpenVPN and gave it a go; voila!

I do not know whether it is ISP blocking https wget or the routing table somehow conflicted.

that would be bad if your ISP is blocking such thinks. And you have the same issue on your mobile phone.

Apparently it is not ISP. I have tried it on another hotspot with VPN on, did not work again.

It is most likely a route configuration issue. But why do I have it in two different OS (dietpi 32 and 64bit, raspberry OS)?

So my to-do list:

  • Have a look at wget spec and see if there are hints in there
  • Join wget mailing group and raise a ticket/bug
  • Install a fresh ubuntu release on raspberry and check wget on https
  • Install OpenVPN during DietPi first-boot to bypass this issue

Just to avoid any confusion. DietPi is not an onw OS. It’s a set of scripts installed on a base image. If you are running a Raspberry Pi device, base image used is Raspberry OS. Means, DietPi is a Raspberry OS with reduced amount of packaged installed and some configuration script on top. Therefore it should not make a difference if you are using DietPi or Raspberry OS.

Most probably it’s your geo location, because the SBC did not decide on the routing within the internet. That’s done by the network devices inside the internet. AS well a VPN (which locate you somewhere else on the globe) is overcoming the situation.

Strange case indeed. Would be interesting to try and compare verbose connections details between curl and wget:

wget -v --spider
curl -IL

E.g. our images ship with IPv6 enabled, but IPv4 preferred via wgetrc config. For curl, such is not possible, so curl would connect via IPv6 while wget would do via IPv4 (which can be seen). So would be interesting if the following succeeds:

wget -v --spider -6

Btw, if -I/–spider makes a difference (it’s HEAD requests then), skip it, it just avoids that the whole file content is printed to console :wink:.

good point regarding IPv6. did not consider it as DNS check passt, which usually indicate an issue on IPv6 if it would fail :slight_smile: