cat /boot/dietpi/.versionG_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=30
G_DIETPI_VERSION_RC=0
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
echo $G_DISTRO_NAME or cat /etc/debian_versionbuster
uname -aLinux dietpi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
echo $G_HW_MODEL_NAME or (EG: RPi3)RPi 3 Model B+ (armv7l)
5V / 2.0A
SanDisk Extreme (64GB)
sudo apt updateIt should sync as it does when changing
deb https://archive.raspberrypi.org/debian/ buster main
in /etc/apt/sources.list.d/raspi.list to
deb http://archive.raspberrypi.org/debian/ buster main
"https://archive.raspberrypi.org/debian buster Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 93.93.135.117 443]"
The aforementioned error shows up on all my local devices (1x RPi 3 / 2x Zero W) - all running dietpi. Which is the expected result, because it's an external error. But one that affects dietpi in general, since it relies on that specific repo (via ssl).
Hi,
many thanks for your message. The domain raspbian.raspberrypi.org is outside DietPi support and we would need to wait until Raspbian has fixed the SSL certificate.
As a temp workaround you could change from secure SSL/HTTPS to a non-secure HTTP connection.
Creating a bug report/issue
Required Information
* DietPi version | `cat /boot/dietpi/.version`G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=30
G_DIETPI_VERSION_RC=0
G_GITBRANCH='master'
G_GITOWNER='MichaIng'* Distro version | `echo $G_DISTRO_NAME` or `cat /etc/debian_version`buster
* Kernel version | `uname -a`Linux dietpi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
* SBC model | `echo $G_HW_MODEL_NAME` or (EG: RPi3)RPi 3 Model B+ (armv7l)
* Power supply used | (EG: 5V 1A RAVpower)5V / 2.0A
* SDcard used | (EG: SanDisk ultra)SanDisk Extreme (64GB)
Steps to reproduce
1. `sudo apt update`Expected behaviour
It should sync as it does when changing
deb https://archive.raspberrypi.org/debian/ buster mainin /etc/apt/sources.list.d/raspi.list to
deb http://archive.raspberrypi.org/debian/ buster mainActual behaviour
"https://archive.raspberrypi.org/debian buster Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 93.93.135.117 443]"
Extra details
The aforementioned error shows up on all my local devices (1x RPi 3 / 2x Zero W) - all running dietpi. Which is the expected result, because it's an external error. But one that affects dietpi in general, since it relies on that specific repo (via ssl).
I'm experiencing the same thing.
How do you change it to a unsecure SSL
you can do nano /etc/apt/sources.list.d/raspi.list and change from https to http
unsecure SSL
SSL is secure by default. Un-secure means, without SSL and encryption.
As written above:
Change
deb https://archive.raspberrypi.org/debian/ buster main
in /etc/apt/sources.list.d/raspi.list to
deb http://archive.raspberrypi.org/debian/ buster main
I knew it's an external error from the beginning, but one that affects a lot of people.
so in one of the files on the SD card before installing it? I'm trying to install it on my pi4
or in the command
sorry I'm so new to this. I was hoping to run my raspberry pi4 with an OS that uses FireFox as the browser vs chromium trying to not support google that much these days
this is an external error that occurs today but we can't fix it from DietPi side. Once you hit by this, exit the setup, change the file and reboot. Or you have a system that can read ext4 file system. If yes you can add your SD card and mount the DietPi ext4 partition to change the file
great thanks so much
Looks like it's fixed, since at least my browser does not complain about the https://archive.raspberrypi.org/ certificate. Otherwise probably rerun time sync, probably your system time is in the future, leading to cert being recognised as outdated falsely:
/boot/dietpi/func/run_ntpd 1
Hmm though a bid strange, the earliest expiry of the cert chain is in 15.07.2020, and the earliest has been created in 15.07.2019 (both archive.raspberrypi.org itself)... however lets see 馃.
Verified:
2020-05-30 15:57:49 root@micha:/tmp# APT
Ign:1 https://archive.raspberrypi.org/debian buster InRelease
Get:2 https://mirror.netcologne.de/raspbian/raspbian bullseye InRelease [15.0 kB]
Err:3 https://archive.raspberrypi.org/debian buster Release
Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 176.126.240.167 443]
Get:4 https://mirror.netcologne.de/raspbian/raspbian bullseye/main armhf Packages [12.8 MB]
Reading package lists... Done
E: The repository 'https://archive.raspberrypi.org/debian buster Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
Strange that my Opera browser has no issues, showing all the certs of the chain being valid with expiry at earliest in 15.07.2020.
Changed https to http received below error
`Err:8 http://archive.raspberrypi.org/debian buster/main armhf Packages
Hash Sum mismatch
Hashes of expected file:
Tried performing
apt-get clean
rm -rf /var/lib/apt/lists/*
apt-get clean
apt-get update
apt-get upgrade
Same issue. Can lockdown get worse than this? :-(
I guess there are changes or issues at raspberry.org side. So we would need to wait for them to fix
@MichaIng
I found the same. On browser ist working fine while apt is going to fail.
I am unable to install Dietpi due to this, is the a file I can edit on the SD card in windows?
Once you hit by this, exit the setup, change the file and reboot.
Reboot is not even required, the following will continue first boot setup: /DietPi/dietpi/login
Filed the issue:
Let's hope they will fix it soon
Should be sorted now.
ok I will mark this topic as closed as the issue seems to be fixed at archive.raspberrypi.org side
Most helpful comment
Filed the issue:
https://github.com/RPi-Distro/repo/issues/175