My thinking as well, hence my posting before.
One might think that it actually should be able to do it but apparently it’s not. Or is it :confused:
1 Like
I’m not saying you aren’t right, but the method described as above worked after Xfce offline was booted up the first time. (And I wasn’t the only one with that result.)
There is no objection the workaround is working fine. I also see the difference of offline, online installation cases, as well when this happens on a running system, as in my case.
I only wanted to propose for the next ISOs to be included in the installation procedure (install keyring first, then pacstrap/install, or something similar), because keyrings are always going to be renewed 
. That’s all.
3 Likes
the adequate 
way will be to install the updated archlinux-keyring explicitly before running the full system update… as it will make sure to update the local keyring.
so running:
sudo pacman -Sy archlinux-keyring
sudo pacman -Syu
But on first system update after installing from Apollo ISO offline XFCE4 version it will work by simply running systemupdate twice… seems in this procedure it install the archlinux-keyring before the package that causes the issue (libinih) …
https://clbin.com/iwAIu
shows the second pacman -Syu on a fresh offline install
[2022-04-27T16:50:55+0200] [ALPM] upgraded archlinux-keyring (20220224-1 -> 20220424-1)
...
[2022-04-27T16:51:05+0200] [ALPM] upgraded libinih (53-2 -> 55-2)
5 Likes
The Arch Ways are indeed impenetrable!
1 Like
already in the HotFix does the same already… but next ISO will do this in the same way:
Seems we do forget to reimplement on some changes.
But the current case is also 2 things at the same time happens… first the outdated keyring and second an issue with one specific key in addition…
7 Likes
That’s some nice signature!
4 Likes
Technically, keyring being installed first, in the same (full) procedure is irrelevant, as the signatures are checked before the new keyring is installed (bringing the new signature in).
Hmm yes so you mean we find a BUG on pacman?
On my test I do remove the package on the first run when pacman asks me if I want that… and on second round it do not bails out on the package but seems it updates the key on first round ?? interesting little issue …
I see that it asks to fetch the key on first round… so seems it updates the key on that but as it was checking for the package before already it fail to install the package on first run but on second it can do it…
this makes it clear I think/hope ?
2 Likes
Looks like the Arch wiki recommendation
sudo pacman -Sy archlinux-keyring
sudo pacman -Su
is generally useful to solve the libinih update issue in all cases that I have tested.
(Note that the double sudo pacman -Syu was my suggestion to Bryan, and at my first tests it seemed to fix it, but actually was not accurate. Sorry about that.)
Note also that the ISO has a separate hotfix.
4 Likes
This is not a joke! We all know pacman has NO bugs!!! 
It’s just the luck of a feature, or it is intentional
The server was down while I was answering…
Indeed! Your video made it clearer to how odd it looks…
2 Likes
Even DT had trouble with libinih 
2 Likes
He is human after all 
I don’t think this is an issue from the Appollo ISO. I have seen this many times happen.
had the same issue by arch linux.
2 Likes
Nah it is not an issue we do produce … for offline install it will simply be a regular update where user needs to do an update of the archlinux-keyring first…
But for online installs we have a little issue on the ISO because we forget that pacstrap is using the keyring from the ISO while installing packages fresh from the repos… so we need to update the archlinux keyring before we start pacstrap
6 Likes
That sounds like a good idea.