Firstrun on PiZero fails #3488

danergo · 2020-04-23T19:21:12Z

Creating a bug report/issue

Details:

Date | Thu 23 Apr 20:16:26 BST 2020
Bug report | ac6383eb-6b72-41dc-a4e1-cb8ef7acb9dc
DietPi version | v6.28.0 (MichaIng/master)
Image creator | DietPi Core Team
Pre-image | Raspbian Lite
SBC device | RPi Zero W (armv6l) (ID=1)
Kernel version | Linux DietPi 4.19.75+ DietPi-System | Quirks noticed by v158 image update #1270 Tue Sep 24 18:38:54 BST 2019 armv6l GNU/Linux
Distro | buster (ID=5)
Command | G_AGUP
Exit code | 100
Software title | DietPi-Software

Steps to reproduce:

Happened during the first run.
I have copied the image onto SD card and inserted into Pi Zero.
I don't have access to external monitor and keyboard so I waited until it got an IP address and SSH-d into it, then this error came during the very first run (after I hit Install).

Expected behaviour:

Installer shall be finished without any error.

Actual behaviour:

Installer stops and not able to continue because:
E: The repository 'https://archive.raspberrypi.org/debian buster Release' does not have a Release file.

Additional logs:

Get:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian buster/non-free armhf Packages [103 kB]
Get:3 http://raspbian.raspberrypi.org/raspbian buster/contrib armhf Packages [58.7 kB]
Get:4 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages [13.0 MB]
Get:5 http://raspbian.raspberrypi.org/raspbian buster/rpi armhf Packages [1,360 B]
Ign:6 https://archive.raspberrypi.org/debian buster InRelease
Err:7 https://archive.raspberrypi.org/debian buster Release
  Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 176.126.240.167 443]
Reading package lists...
E: The repository 'https://archive.raspberrypi.org/debian buster Release' does not have a Release file.

The text was updated successfully, but these errors were encountered:

Joulinar · 2020-04-23T19:27:05Z

Hi,

many thanks for your report. Looks like a temp issue at https://archive.raspberrypi.org/ as you got a Resource temporarily unavailable

Err:7 https://archive.raspberrypi.org/debian buster Release
  Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 176.126.240.167 443]

probably you can try again later.

danergo · 2020-04-23T19:33:32Z

Is there any workaround? :)

danergo · 2020-04-23T19:41:49Z

I can browse https://archive.raspberrypi.org without issues from my PC.
I can even browse https://archive.raspberrypi.org/debian/dists/buster/InRelease

However on the PiZero:

wget https://archive.raspberrypi.org/debian/dists/buster/InRelease
--2020-04-23 20:40:43--  https://archive.raspberrypi.org/debian/dists/buster/InRelease
Resolving archive.raspberrypi.org (archive.raspberrypi.org)... 46.235.231.111, 93.93.135.118, 46.235.231.151, ...
Connecting to archive.raspberrypi.org (archive.raspberrypi.org)|46.235.231.111|:443... connected.

And then it is waiting forever.
Ping works from the Pi too:

root@DietPi:~# ping archive.raspberrypi.org
PING lb.raspberrypi.org (176.126.240.167) 56(84) bytes of data.
64 bytes from 176.126.240.167 (176.126.240.167): icmp_seq=1 ttl=55 time=132 ms
64 bytes from 176.126.240.167 (176.126.240.167): icmp_seq=2 ttl=55 time=133 ms
64 bytes from 176.126.240.167 (176.126.240.167): icmp_seq=3 ttl=55 time=132 ms
64 bytes from 176.126.240.167 (176.126.240.167): icmp_seq=4 ttl=55 time=133 ms

Previous wget if I replace https to plain http succeeds immediately.

Seems an issue with https links. None of them seems working on the Pi Zero W with DietPi :(

lucasburlingham · 2020-04-23T19:57:03Z

I think I got this error the first time I ran DietPi on a Pi Zero W (yesterday). I had forgotten to plug in my keyboard, so I simply unplugged the Pi and this seemed to fix the problem.

Joulinar · 2020-04-23T20:12:20Z

for me this is working fine

root@DietPiVM1:~# wget https://archive.raspberrypi.org/debian/dists/buster/InRelease
--2020-04-23 21:55:10--  https://archive.raspberrypi.org/debian/dists/buster/InRelease
Resolving archive.raspberrypi.org (archive.raspberrypi.org)... 46.235.227.39, 46.235.230.122, 46.235.231.111, ...
Connecting to archive.raspberrypi.org (archive.raspberrypi.org)|46.235.227.39|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25112 (25K)
Saving to: ‘InRelease’

InRelease                             100%[=========================================================================>]  24.52K  --.-KB/s    in 0.003s

2020-04-23 21:55:10 (7.04 MB/s) - ‘InRelease’ saved [25112/25112]

root@DietPiVM1:~#

So theoretically it should be working

can you do following

wget --spider https://archive.raspberrypi.org/debian/dists/buster/InRelease

danergo · 2020-04-24T06:24:39Z

Hi, yes:

# wget --spider https://archive.raspberrypi.org/debian/dists/buster/InRelease
Spider mode enabled. Check if remote file exists.
--2020-04-24 07:23:45--  https://archive.raspberrypi.org/debian/dists/buster/InRelease
Resolving archive.raspberrypi.org (archive.raspberrypi.org)... 46.235.227.39, 176.126.240.167, 46.235.231.111, ...
Connecting to archive.raspberrypi.org (archive.raspberrypi.org)|46.235.227.39|:443... connected.

It hangs forever until Ctrl+c.

danergo · 2020-04-24T06:27:28Z

This might also be interesting:

# wget -d https://archive.raspberrypi.org/debian/dists/buster/InRelease
DEBUG output created by Wget 1.20.1 on linux-gnueabihf.

Reading HSTS entries from /root/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'InRelease' (UTF-8) -> 'InRelease' (UTF-8)
--2020-04-24 07:26:34--  https://archive.raspberrypi.org/debian/dists/buster/InRelease
Certificates loaded: 128
Resolving archive.raspberrypi.org (archive.raspberrypi.org)... 46.235.231.145, 46.235.231.151, 93.93.135.117, ...
Caching archive.raspberrypi.org => 46.235.231.145 46.235.231.151 93.93.135.117 176.126.240.84 93.93.135.118 176.126.240.86 46.235.230.122 46.235.231.111 176.126.240.167 46.235.227.39 2a00:1098:84:1e0::3 2a00:1098:80:56::1:1 2a00:1098:84:1e0::1 2a00:1098:82:47::1:1 2a00:1098:80:56::2:1 2a00:1098:82:47::1 2a00:1098:84:1e0::2 2a00:1098:88:26::2:1 2a00:1098:88:26::1:1 2a00:1098:88:26::1
Connecting to archive.raspberrypi.org (archive.raspberrypi.org)|46.235.231.145|:443... connected.
Created socket 3.
Releasing 0x0038c8d0 (new refcount 1).
GnuTLS: Error in the pull function.
Closed fd 3
Unable to establish SSL connection.

danergo · 2020-04-24T07:18:39Z

Also very interesting and might give some light:

Curl works without issues, however I have no idea how to tell apt to use curl instead of wget.

Joulinar · 2020-04-24T07:38:58Z

strange seems you are unable to establish SSL connection using wget

There could be some reason for this.

try using TLSv1.0: wget --secure-protocol=TLSv1
try wget with a different web site like https://www.google.com/
ensure time/date are updated correctly
do you use a Proxy to connect to the internet?

danergo · 2020-04-24T07:42:38Z

try using TLSv1.0: wget --secure-protocol=TLSv1
Same results.
try wget with a different web site like https://www.google.com/
this works with wget.
ensure time/date are updated correctly
Datetime is good I have checked.
do you use a Proxy to connect to the internet?
No, it's a home internet (at least I'm not aware of anything like this).
The external IP of my router is a public one.

Joulinar · 2020-04-24T07:45:28Z

hmm than it's not a general issue with wget and https. probably dedicated to raspberrypi.org. Maybe you can check using --no-check-certificate using wegt.

danergo · 2020-04-24T07:46:16Z

--no-check-certificate does not solve it, I have tried.

danergo · 2020-04-24T07:47:02Z

It can not be dedicated to raspberrypi.org, because curl works fine on this device.
And on other devices wget works fine too.

danergo · 2020-04-24T07:48:00Z

Is there a way to instruct apt to use curl for its downloads?

Joulinar · 2020-04-24T07:48:02Z

Did you post some issue on this board??

https://raspberrypi.stackexchange.com/questions/111687/raspberry-pi-https-fails

danergo · 2020-04-24T07:48:49Z

Yes. I don't know which direction will the solution come from.

danergo · 2020-04-24T07:53:06Z

Will post the solution here if we don't find it here.
This is major, DietPi is not able to finish it's first run due to this.

Joulinar · 2020-04-24T08:00:06Z

you could give it a try to reinstall wget

apt --reinstall install wget

danergo · 2020-04-24T08:03:24Z

Yes, tried, same results unfortunately.

danergo · 2020-04-24T08:07:36Z

Only way to escape from "boot-loop" is to modify

/etc/apt/sources.list.d/raspi.list and change https to http.

Is it possible to do this before first run after flushing the image onto SD card?

Joulinar · 2020-04-24T08:09:31Z

you would need to connect your SD card to a system that is able to read/write ext4 file systems. Than you could try to edit the file before hand. Another option is to exit the first run once it give the error, edit the file and reboot. This should restart the first run.

MichaIng · 2020-04-25T18:00:50Z

GnuTLS: Error in the pull function.

I remember seeing this error once a while ago and same issue that noone was able to reproduce on different system or with different tool 🤔.

Can you try to reinstall the underlying GnuTLS library and the ca-certificates package:

apt install --reinstall libgnutls30 ca-certificates

Found one, where it was indeed a proxy issue: #2601
Found the one I had in mind, @Joulinar you remember? #3306 (comment)

Issue was resolved by switching to WiFi... that doesn't lower confusion 😄

Joulinar · 2020-04-25T18:54:41Z

ah indeed was quite a strange topic as well. Unfortunately we didn't find out why it was failing on eth0 while WiFi was working fine

danergo · 2020-04-26T06:10:50Z

Wow, this shall be lying deep down in some kernel stuff maybe. I currently don't have an option to change the network (Pi0W does not have eth0, and I don't have usb2eth now).
So the only option is with wifi, but currently the workaround was to just have the https changed to http so at least the apt update goes through.

danergo · 2020-04-26T06:14:05Z

I close this issue as we have a workaround for moving on the first run.

MichaIng · 2020-04-26T10:06:08Z

@danergo
Okay, if this is the only combination (raspberrypi.org + HTTPS with APT/wget), then you should be fine with this. Yeah one can adjust /etc/apt/sources.list entries before first boot via dietpi.txt but not the /etc/apt/sources.list.d/ content (firmware repos). This needs to be done manually then. Let us know if you face the same or similar issue with other HTTPS resources at a later time, and also after some APT update/upgrade periodes probably have raspberrypi.org again reachable via HTTPS. Probably it is also something related to local network, router or ISP, or some issue with DS lite (compare to duel stack IPv6 + IPv4) or the router firewall.

Joulinar added the Investigating 🤔 label Apr 23, 2020

danergo closed this as completed Apr 26, 2020

MichaIng added Workaround available 🆗 Workaround is available/has been implemented, but a definite solution should be found when possible. and removed Investigating 🤔 labels Apr 26, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Firstrun on PiZero fails #3488

Firstrun on PiZero fails #3488

danergo commented Apr 23, 2020

Joulinar commented Apr 23, 2020

danergo commented Apr 23, 2020 •

edited

Loading

danergo commented Apr 23, 2020 •

edited

Loading

lucasburlingham commented Apr 23, 2020

Joulinar commented Apr 23, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020 •

edited

Loading

danergo commented Apr 24, 2020 •

edited

Loading

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

MichaIng commented Apr 25, 2020

Joulinar commented Apr 25, 2020

danergo commented Apr 26, 2020

danergo commented Apr 26, 2020

MichaIng commented Apr 26, 2020

Firstrun on PiZero fails #3488

Firstrun on PiZero fails #3488

Comments

danergo commented Apr 23, 2020

Creating a bug report/issue

Details:

Steps to reproduce:

Expected behaviour:

Actual behaviour:

Additional logs:

Joulinar commented Apr 23, 2020

danergo commented Apr 23, 2020 • edited Loading

danergo commented Apr 23, 2020 • edited Loading

lucasburlingham commented Apr 23, 2020

Joulinar commented Apr 23, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020 • edited Loading

danergo commented Apr 24, 2020 • edited Loading

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

danergo commented Apr 24, 2020

danergo commented Apr 24, 2020

Joulinar commented Apr 24, 2020

MichaIng commented Apr 25, 2020

Joulinar commented Apr 25, 2020

danergo commented Apr 26, 2020

danergo commented Apr 26, 2020

MichaIng commented Apr 26, 2020

danergo commented Apr 23, 2020 •

edited

Loading

danergo commented Apr 23, 2020 •

edited

Loading

danergo commented Apr 24, 2020 •

edited

Loading

danergo commented Apr 24, 2020 •

edited

Loading