Apollo ISO bug is fixed for most users and also a workaround for those who need it

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 :smile: . That’s all.


the adequate :wink: 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) …

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)

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…


That’s some nice signature!


seems very https://de.wikipedia.org/wiki/08/15_(Redewendung)


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 :wink: ?


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.


This is not a joke! We all know pacman has NO bugs!!! :rofl:
It’s just the luck of a feature, or it is intentional :wink:

The server was down while I was answering… :face_with_head_bandage:

Indeed! Your video made it clearer to how odd it looks…


Even DT had trouble with libinih :scream:


impossible… :nerd_face:

:grimacing: :melting_face:

1 Like

He is human after all :wink: :sweat_smile:

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.


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 :wink:


That sounds like a good idea. :wink:

A post was merged into an existing topic: Apollo neo RC1 ISO testing