I prefer the first approach, but sometimes if you feel overwhelmed with all these missing keys, the second approach is definitely more convenient at the risk of introducing malware, but if your repo is simply debian I would place a high-level of confidence there is no malware. The other convenience is that iirc there would be an updated developer keys package that updates the public keyring with the newer developer public keys on your behalf. Similar stuff like this occurs on Fedora as well.
gpg --keyserver keyring.debian.org --recv-key E852514F5DF312F6
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
Please remember to take that stuff out once it’s all settled. BIG SECURITY HOLE.
The package signature expired end of January. If you contact the package maintainer ftpmaster@ports-master.debian.org for the entire snapshot repo in question perhaps they could renew their key and re-submit the packages with the newer key and provide you with that new key to import.
Thank you for isolating the issue. It is definitely the entire snapshot repo with all its packages that need to have their keys renewed since they all [expired: 2023-01-31]. At least we now know who to report the issue to.
We need to email
ftpmaster@ports-master.debian.org
and request them to renew their key since it expired 2 days ago and re-package all the packages with the new key.
The 2023 package is in the updated package list. If not able to update with the mentioned args, try wget/curl the package directly and install with dpkg -i debian-ports-archive-keyring_2023.02.01_all.deb
Good news: aptitude and emacs-nox work. The full unstable repo snapshot is available to install which is impressive. Java was already installed. I installed Rust nightly with no issues via the standard https://rustup.rs way. Rust likes to have a cc around so I installed build-essential,clang-15-tools, lld-15, llvm 15 as well with no issues.
There is a much simpler solution:
1- download the debian-ports-archive-keyring_2023.02.01_all.deb package from https://deb.debian.org/debian-ports/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2023.02.01_all.deb with wget or curl,
install with dpkg -i debian-ports-archive-keyring_2023.02.01_all.deb
2-Use the regular unstable ports directory in /etc/apt/sources.list: deb http://ftp.ports.debian.org/debian-ports/ unstable main
instead of (or comment out) #deb https://snapshot.debian.org/archive/debian-ports/20220616T194833Z unstable main
Thanks @johanhenselmans; 1. by itself didn’t fix anything for me (maybe it wasn’t supposed to), but 1. and 2. seems to work (and boy, it’s working itself through 895 updates now).
I also like a CLI only image version. Many I suspect use as 24/7/365. Therefore only need a CLI version that ssh to when need access.
A method to easily enable SSH from base image would be most helpful so do not need to connect HDMI and keyboard to download/enable SSH. For example with RaspberryOS all one needs to do to enable ssh on image is to touch /boot/ssh. When RaspberyPiOS boots it enables ssh and deletes the /boot/ssh file.
(“Can’t boot” is a particularly useless bug report - you need to share how fair it gets at the very least)
It worked for me, but I saw one scary potential failure: the apt upgrade proposed a change to /etc/defaults/u-boot which would probably break boot if accepted:
You’re right, I should’ve been much more specific.
After a bit of analysis, my machine actually boots up, but the HDMI isn’t working. And when I try the SSH connection(I had to connect my sd card to another machine to change ssh conf), this works fine. Is there any logs I should provide to troubleshoot this?
Plus, The apt suggested two configuration changes, one is mime.conf and another one is uboot. I used previous configuration for uboot, and I changed mime conf file to new one. Like you said this debian image has unique uboot configuration, so it shouldn’t be changed.
Well HDMI has never worked for me (see other threads). @Michael.Zhu has proposed workaround which should give 1920x1080 on my 2560x1440 monitor. I haven’t tested it as I mostly use it remotely anyway. I’ve seen plenty of other people with HDMI issues, so I assume it’s a know issue being worked.