Issue running 'archinstall'

[gamingmsi]

I've installed ArchLinux using archinstall script at the beginning of the month just fine. This is what I get now in VirtualBox.

What's going on here?

[nixfemby]

Running into the same issue using QEMU.

Updating the keyring package myself errors with a note to use pacman-key --init. Doing so errors as well with an attempt to install the package again afterwards saying its corrupted.

I can provide those errors if needed

[gamingmsi]

Running into the same issue using QEMU.

Updating the keyring package myself errors with a note to use pacman-key --init. Doing so errors as well with an attempt to install the package again afterwards saying its corrupted.

I can provide those errors if needed

Hey, thanks for your response, I'm glad I'm not the only one experiencing this issue. There's no need to post error message as Obema12 has already detailed it even before me, here.

I've sent an email to Christian Hesse about this but still no response, it's his name in the PGP corruption issue after all.

[gamingmsi]

UPDATE: This must be arch-wide problem or something, everyone is playing dumb for some reason, however the issue might be resolved by doing this:

killall gpg-agent
rm -rf /etc/pacman.d/gnupg
pacman-key --init
pacman-key --populate archlinux

I did that and was able to proceed. Hope this helps.

P.S. These PGP keys seem to be a problem these days for some reason. More reasons to stay on Windows I guess.

[vegantom]

UPDATE: This must be arch-wide problem or something, everyone is playing dumb for some reason, however the issue might be resolved by doing this:

killall gpg-agent
rm -rf /etc/pacman.d/gnupg
pacman-key --init
pacman-key --populate archlinux

I did that and was able to proceed. Hope this helps.

P.S. These PGP keys seem to be a problem these days for some reason. More reasons to stay on Windows I guess.

The rm -rf command is not necessary, it doesn't work, but the rest do fix it.
The issue appears to be related to:
/var/cache/pacman/pkg/ is emptied after archinstall has successfully installed an operating system. Going back to archinstall to re-install arch does not work. I've no idea if this only effects VM's, as that's all I've tried it on, but I suspect not.

My only solution was to redownload the iso, and then close down KVM and reopen it, making the new ISO the one it loaded. Your solution is much better, massive thank you for that.

I had tried to make a /backup/pkg in the iso, but when I rebooted it was gone. So I'm not sure why archinstall can seemingly edit the ISO but I can't manually edit it.

I'm not sure if there's more to it than the path I mentioned above, e.g. if other things are being deleted or not.

[nixfemby]

I've no idea if this only effects VM's, as that's all I've tried it on, but I suspect not.

Not sure if I was just lucky but my bare-metal install roughly 24h ago worked perfectly fine except for the connectivity and keyring steps taking a lot longer than usual. It was a fresh, only once used ISO though so I couldn't confirm or deny anything changing after the successful install

[Esmourbad]

Heya! Same issue here.

The fix that worked for me (yes I made an account to say this) was to connect to wifi, there's a tutorial on YouTube on how to do it but that's all. After that, the Archinstall gui(?) Opened

[niluzz]

when will the new archinstall come out?

[noisyBrain]

I have the same issue. Yesterday I got that message, reboot vm and then worked. Today, I'm trying to install again, but it doesn't work

[vegantom]

UPDATE: This must be arch-wide problem or something, everyone is playing dumb for some reason, however the issue might be resolved by doing this:

killall gpg-agent
rm -rf /etc/pacman.d/gnupg
pacman-key --init
pacman-key --populate archlinux

I did that and was able to proceed. Hope this helps.
P.S. These PGP keys seem to be a problem these days for some reason. More reasons to stay on Windows I guess.

The rm -rf command is not necessary, it doesn't work, but the rest do fix it. The issue appears to be related to: /var/cache/pacman/pkg/ is emptied after archinstall has successfully installed an operating system. Going back to archinstall to re-install arch does not work. I've no idea if this only effects VM's, as that's all I've tried it on, but I suspect not.

My only solution was to redownload the iso, and then close down KVM and reopen it, making the new ISO the one it loaded. Your solution is much better, massive thank you for that.

I had tried to make a /backup/pkg in the iso, but when I rebooted it was gone. So I'm not sure why archinstall can seemingly edit the ISO but I can't manually edit it.

I'm not sure if there's more to it than the path I mentioned above, e.g. if other things are being deleted or not.

Did you read the comments noisyBrain?

[noisyBrain]

I did... and did't work.
I just rebooted vm, entered pacman -Syy then archinstall and it worked.
Those commands did't work for me

[Plarpoon]

I actually had this same issue and got it working by entering /etc/pacman.conf and modifying the SigLevel to "Never".
https://wiki.archlinux.org/title/Pacman/Package_signing#Configuring_pacman

This is not a fix, this is a workaround and a really bad one. It worked every single time I tried it as I had an an urgency but be very aware of the risks you are putting yourself at by changing that line.
https://wiki.archlinux.org/title/Pacman/Package_signing#Disabling_signature_checking

[gamingmsi]

Thanks for the responses. I've been tinkering with Linux in VM today after all of my Linux installations went to flames as my browser download speed on ALL distros is capped at meager 200kb/s for some reason.

I've read your responses and 'my' solution doesn't work anymore for me, I've tried @noisyBrain's solution and it didn't work so I ended up using what @Plarpoon said. I've disabled signing as there was no way to proceed with installation in the VirtualBox.

Christian Hesse is still playing dumb on my email and Pierre has said that August ISO is postponed thanks to some kernel bug regarding older CPUs. Seems like Arch Linux is currently an absolute dumpster fire.

I'll probably try to re enable the signing after the installation, the default value was:
SigLevel = Required DatabaseOptional

[Rew20]

I tried out several solutions they only one was with SigLevel=Never but after install and changing to the default I couldn’t install any packages because of the gpg error. Honestly I fad up with Arch I need a GNU which is working after install not for tinker. Installed Fedora36 now and all good.

[Plarpoon]

It's ofcourse your choice if to keep using Fedora or not but you were one step away from solving your issue on Arch.

You just had to restore the keys after restoring the default values from "Never", it's all explained here:

https://wiki.archlinux.org/title/Pacman/Package_signing#Resetting_all_the_keys

Hope this can be useful!

[Rew20]

Thanks, yes that’s really helpful I had never needed this before. I’ll give them a try in my KVM.

[Rew20]

FYI
It`s working again with no issue for this time. I just downloaded the Arch release 08.05. and try it works fine.

[vegantom]

This. I installed with archinstall and then went back into the ISO to try and run archinstall just to test it, and it seemed to start the script up okay.

[gamingmsi]

Yeah, it's working now for me too with the new ISO. Got bored of tinkering and pgp key problems that I ended up with Linux Mint in the end. :)

Should probably close this then, or leave it open in case it happens again.

[svartkanin]

Would you mind closing the issue if you feel it's resolved (I don't have permissions:) )

[rursache]

the issue is still happening on the latest archlinux-2022.08.05-x86_64.iso
had to run

pacman-key --init
pacman-key --populate archlinux

before being able to execute archinstall successfully

[Rew20]

I suspect that depends on the keyrings which on Aug.31. were changed again. I think with Sep.ISO it works again without input. I'm tired of Arch after the insane Grub disaster I switched to Fedora.

[rursache]

if the script breaks bi-weekly maybe it should include the pacman-key commands... otherwise it's useless

[Torxed]

if the script breaks bi-weekly maybe it should include the pacman-key commands... otherwise it's useless

We do, but it's a bit of a nasty fix for someone that really is another areas responsibility to keep reliable.
It's a very well known issue tho, and they're working on it. But a huge issue is the human factor in the way the keys can be rotated at any given time.

So until then, we actually attempt to do this:

archinstall/examples/guided.py

Lines 286 to 298 in ee64276

	if not archinstall.arguments.get('offline'):
	latest_version_archlinux_keyring = max([k.pkg_version for k in archinstall.find_package('archlinux-keyring')])
	# If we want to check for keyring updates
	# and the installed package version is lower than the upstream version
	if archinstall.arguments.get('skip-keyring-update', False) is False and \
	archinstall.installed_package('archlinux-keyring').version < latest_version_archlinux_keyring:
	# Then we update the keyring in the ISO environment
	if not archinstall.update_keyring():
	log_file = os.path.join(archinstall.storage.get('LOG_PATH', None), archinstall.storage.get('LOG_FILE', None))
	archinstall.log(f"Failed to update the keyring. Please check your internet connection and the log file '{log_file}'.", level=logging.INFO, fg="red")
	exit(1)

Line 295 being the one that does the actual update.

[rursache]

@Torxed I'm not following very closely who should do what but honestly, as an user, why should I care? OOB it's not working.
This issue keeps happening and until a proper fix is applied (god dammit, just run those two commands automatically as the shell is available or something) I don't see why this ticket it's closed. It should be open with critical priority.

[Torxed]

@rursache I get that this is frustrating, but you be would forced to fix this manually either way as it's a function of how arch is designed. So the workaround is globally within the arch ecosphere and somethin everyone is either expected to understand or at least ask support staff which can explain the workaround - as it's a temperary issue. Again, archinstall is a program, just like ls, pacman or chrome. We rely on the keyring just like everyone else and share your frustration. We have tried to program in a workaround but because the upstream issue has evolved/change, which means we need to adapt. And as a user of Arch you are expected to care, at least a bit. And making this comment is enough to show that you care i guess :)

I'll get on with trying to again, fix the workaround for upstream :)

[svartkanin]

@Torxed as a suggestion here, we could at least capture this error and then print a help output of where to go to fix it and also mention that this isn't related to archinstall. The error will be very cryptic to most people and new issues will be raised for it in the future :)

[Torxed]

To quote https://bbs.archlinux.org/viewtopic.php?pid=2055012#p2055012:

"""
That's the aforementioned archiso#191 issue.
The solution is to wait until pacman-init.service finishes before running pacman, pacstrap or archinstall.

You can follow it with journalctl:

journalctl -u pacman-init.service -f

You can proceed once you see:

Finished Initializes Pacman keyring

"""

@svartkanin I agree that the error message could be more clear and I'll get right on it and squeeze it in to v2.5.1.
<ventilation>
Just a bit annoying that this topic/related issues have been hitting us a bit differently each time, and we always play catch-up trying to bodge a better error message and handling when the issue should be fixed elsewhere ^^
</ventilation>

[J1Man]

This issue started happening again today. Archinstall tries to update the archlinux-keyring and gives the exact same error message that @gamingmsi posted. The exact same issue was also posted by @hard-tek in a separate bug ticket that I linked below.
#1448

The good news is that I found a very simple solution that works in Virtualbox. I hope it will work in other virtual machines. It seems like setting the time zone before running archinstall prevents this archlinux-keyring update error. After booting your virtual machine using the official Arch Iso that was released on November 1st 2022, just set the time zone using the command below and run archinstall afterwards.

timedatectl set-timezone America/Los_Angeles
archinstall

The example I gave above is for Los Angeles, but you should use your own local time zone.

What is weird is that, even if you set your time zone to an incorrect time zone (such as US/Alaska), it still prevents the archlinux-keyring update error message.

When the official arch iso boots, the time zone is set to UTC by default. You can confirm this by using the command "timedatectl status". Setting the time zone (that is already in UTC) to UTC also prevents the keyring error. Just try the command "timedatectl set-timezone UTC" before running archinstall. It works!!

Changing the time zone after you see the keyring error message does not work. If you already ran archinstall and got the keyring error message, please restart your virtual machine before you try my solution. Changing the time zone should be the first command that you run when the official Arch Iso boots up.

I would appreciate if users of native machines (no virtualization) and users of other virtual machines (QEMU, Vmware, etc) can test this solution and let me know if it worked for them.

@Torxed I agree that this is an upstream bug, but it might be possible to implement a band-aid solution in archinstall based on my findings above. If keyring has to be updated, archinstall can just read the system time zone and set it one more time to the same timezone by executing "timedatectl set-timezone Zone/SubZone" command. You won't be changing the time zone. You will just be setting it one more time to whatever it already is. As I explained above, for whatever weird reason, even resetting the already UTC time zone to UTC prevents this error. Do you think that there might be any side-effects to this solution?

[marvhus]

the issue is still happening on the latest archlinux-2022.08.05-x86_64.iso had to run

pacman-key --init
pacman-key --populate archlinux

before being able to execute archinstall successfully

Happening on archlinux-2022.12.01-x86_64.iso too.
Though those commands seams to have fixed it
(though I had to do killall gpg-agent first)

Edit:
I deleted the QEMU/KVM vm and started setting up a new one... and now it magically works without having to do it... WTF!
Edit 2:
It is now the 3rd time... it did it again. WHY?

[planet36]

the issue is still happening on the latest archlinux-2022.08.05-x86_64.iso had to run

pacman-key --init
pacman-key --populate archlinux

before being able to execute archinstall successfully

Happening on archlinux-2022.12.01-x86_64.iso too. Though those commands seams to have fixed it (though I had to do killall gpg-agent first)

Edit: I deleted the QEMU/KVM vm and started setting up a new one... and now it magically works without having to do it... WTF! Edit 2: It is now the 3rd time... it did it again. WHY?

It's explained here #1389 (comment)

When pacman-init.service successfully finishes, its substate will be "exited".
systemctl show pacman-init.service | grep SubState

[planet36]

This issue started happening again today. Archinstall tries to update the archlinux-keyring and gives the exact same error message that @gamingmsi posted. The exact same issue was also posted by @hard-tek in a separate bug ticket that I linked below. #1448

The good news is that I found a very simple solution that works in Virtualbox. I hope it will work in other virtual machines. It seems like setting the time zone before running archinstall prevents this archlinux-keyring update error. After booting your virtual machine using the official Arch Iso that was released on November 1st 2022, just set the time zone using the command below and run archinstall afterwards.

timedatectl set-timezone America/Los_Angeles archinstall

The example I gave above is for Los Angeles, but you should use your own local time zone.

What is weird is that, even if you set your time zone to an incorrect time zone (such as US/Alaska), it still prevents the archlinux-keyring update error message.

I suspect you had success because after entering the commands for setting the timezone, enough time had elapsed that pacman-init.service finished.

On my machine, pacman-init took about 35 seconds from the moment the prompt appeared to when it finished.

date
while ! systemctl show pacman-init.service | grep -q 'SubState=exited' ; do sleep 1s ; done ; date

[planet36]

Not sure if this is related to issues mentioned earlier here...

I ran the 2022.12.01 Live CD on a machine in a different location (with a strict firewall, I presume), and I had an issue where pacman-init.service was waiting to start because (I guess) a dependency never finished. This was after an uptime of 10+ minutes.

systemd-analyze critical-chain pacman-init.service

Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs

The output of systemctl list-jobs showed these 8 jobs waiting.

• time-sync.target
• timers.target
• pacman-init.service
• multi-user.target
• shadow.timer
• archlinux-keyring-wkd-sync.timer
• man-db.timer
• graphical.target

In journalctl --boot there were many of the following lines:

archiso systemd-timesyncd[353]: Timed out waiting for reply from (IP addresses)

I know this isn't an archinstall problem, but it does prevent it from running.

[binarydepth]

UPDATE: This must be arch-wide problem or something, everyone is playing dumb for some reason, however the issue might be resolved by doing this:

killall gpg-agent
rm -rf /etc/pacman.d/gnupg
pacman-key --init
pacman-key --populate archlinux

I did that and was able to proceed. Hope this helps.

P.S. These PGP keys seem to be a problem these days for some reason. More reasons to stay on Windows I guess.

The agent wasn't running but the next steps fixed the issue for me. Running Arch successfully!

[javierspn]

UPDATE: This must be arch-wide problem or something, everyone is playing dumb for some reason, however the issue might be resolved by doing this:

killall gpg-agent
rm -rf /etc/pacman.d/gnupg
pacman-key --init
pacman-key --populate archlinux

I did that and was able to proceed. Hope this helps.

P.S. These PGP keys seem to be a problem these days for some reason. More reasons to stay on Windows I guess.

This worked for me, except that I didn't need killall gpg-agent:

rm -rf /etc/pacman.d/gnupg
pacman-key --init
pacman-key --populate archlinux

I was banging my head thinking it was my corporate LAN blocking non authorized DNS servers somehow or maybe the networking stack of virtualbox itself...nah, simpler than that.

Surprised to see that this issue has been ongoing for a long time.

Thanks!

[Torxed]

@Torxed I agree that this is an upstream bug, but it might be possible to implement a band-aid solution in archinstall

Yepp, I'm 100% agreeing with you and it will be more solid in the next release!