You are not logged in.
Hello
I am installing Arch Linux 32 on an Intel Atom desktop.
Everything goes smoothly using official installation instructions for regular Arch Linux at https://wiki.archlinux.org/title/installation_guide, however once I enter the chroot and attempt to install additional software like nano, I get a prompt to import a key, and then it reporting back that it is "Unknown trust". I believed this had something to do with the -K option to pacstrap, however going through the same process again, this time without -K yields the same error. I have tried running pacman-key --refresh-keys, but it was taking a very long time so I have gave up on that. I am currently stuck on step 3.4 in the installation instructions regarding generating locales. Could setting up a locale help? This is the specific error I received https://imgur.com/a/ReKcCA9
Thanks in advance
Last edited by circl (2022-12-16 15:28:29)
Offline
As i read it you absolutely need to invoke pacstrap with the -K option the first time you run it, but not so much if you feel the need to rerun it. I can't say I've ever needed to rerun it though because it's always worked for me. There does seem to have been an uptick in key signing and rotation ih the past year sr so, so I guess you want to be using the most recent iso you possibly conveniently can. I'm not sure setting a locale will help at all really provided you can understand the messages it prints. Other than that I've no suggestions other than maybe investigating pacman-key (if that's in the iso, I've not checked) and it's -lsign-keu and -updatedb options.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Sometimes keys expire, you can try to use pacman-key refresh on the ISO or in the chroot, also check if the archlinux32-keyring is up to date (the newest I can see is
20220927-1.0), though that one should be on the ISO. As last resort you can also just disable the key checks in pacman.conf (SigLevel = Never).
Offline
I have unfortunately not tried installing since, but my issue was reproduced in this video: https://youtu.be/F_JOpTSvBlY?t=900
Offline
Yeah, this is (as mentioned) a henn-and-egg problem. The trick is not to let keys expire. :-)
Instead of SigLevel=Never you should download the keys manually and add them to the pacman
GPG keyring (as described in https://bugs.archlinux32.org/index.php? … s%5B0%5D=).
As not all keyservers and gpg confiugrations give you valid keys we have to point people to a project
key server which they have to trust ultimately again.
I considered adding this as an announment but there is a tradoff when documenting something
which should never happen and can confuse the normal user.. so I opted not to make an
announment.
The other issue is with ISOS, they cannot really be updated once in the wild. So actually people
have to use the newest one. Sadly the point in time when you want to build an ISO falls
together with Python not rebuilding and archinstall32 being broken, so you skip an ISO or so,
leaving the problem unfixed for longer than it should be. What I would propose is to move
ISOs more agressively to the archive, especially if we think, they are no longer working.
Also, the archlinux-keyring is there only for convenience, everything you install as 32-bit
packages is signed with keys from archlinux32-keyring. The archlinux-keyring is there
for convenience if you want to install something signed with it (like an 'any' package).
The problem currently is that sequoia-sq needs Rust and this has the potential to break
the archlinux-keyring package. Given our troubles with Rust it's not wise to start to depend
on such tools..
Offline
Just for the next time:
curl -Ss https://archlinux32.org/keys.php?k=5FDC … DB9A12601A | gpg --homedir /etc/pacman.d/gnupg/ --import
curl -Ss https://archlinux32.org/keys.php?k=1619 … A0AF9BA7E7 | gpg --homedir /etc/pacman.d/gnupg/ --import
pacman -S archlinux32-keyring
Offline
The video is nice, it shows many things which can go wrong and solutions for that. :-)
I'm somewhat sorry for the author, because he hit the possibly worst time of expired keys and stuff..
Offline