You are not logged in.
Pages: 1
Pacstrap ist failing for me with "error: keyring is not writable" (see log below for more details). This is in archiso using an automated script. Sometimes the installation fails with that error, most of the time it works. If I run pacstrap again in the same shell, it works fine. I did not change anything about the VM in between installation runs.
Installation script (run via script=)
#!/usr/bin/sh -ex
loadkeys de
parted -s /dev/sda mklabel gpt mkpart "EFI_system_partition" fat32 1MiB 501MiB set 1 esp on mkpart "root" ext4 501MiB 100%
mkfs.fat -F 32 /dev/sda1
mkfs.ext4 /dev/sda2
mount /dev/sda2 /mnt
mount --mkdir /dev/sda1 /mnt/boot
pacstrap -K /mnt base linux linux-firmware openssh nano
Log:
+ mount /dev/sda2 /mnt
+ mount --mkdir /dev/sda1 /mnt/boot
+ pacstrap -K /mnt base linux linux-firmware openssh nano
==> Creating install root at /mnt
gpg: /mnt/etc/pacman.d/gnupg/trustdb.gpg: trustdb created
gpg: no ultimately trusted keys found
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/mnt/etc/pacman.d/gnupg/secring.gpg' to gpg-agent
gpg: migration succeeded
==> Generating pacman master key. This may take some time.
gpg: Generating pacman keyring master key...
gpg: directory '/mnt/etc/pacman.d/gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/mnt/etc/pacman.d/gnupg/openpgp-revocs.d/B0BF58B34AC4154FB1F3ED50FE024B71BC78F08F.rev'
gpg: Done
==> Updating trust database...
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
==> Installing packages to /mnt
:: Synchronizing package databases...
core 152.1 KiB 1383 KiB/s 00:00 [########################################################] 100%
extra 1744.5 KiB 24.3 MiB/s 00:00 [########################################################] 100%
community 7.2 MiB 31.3 MiB/s 00:00 [########################################################] 100%
resolving dependencies...
:: There are 3 providers available for initramfs:
:: Repository core
1) mkinitcpio
:: Repository extra
2) booster 3) dracut
Enter a number (default=1):
looking for conflicting packages...
Packages (126) acl-2.3.1-2 archlinux-keyring-20221220-1 argon2-20190702-4 attr-2.5.1-2 audit-3.0.9-1 bash-5.1.016-1 binutils-2.40-2 brotli-1.0.9-9
bzip2-1.0.8-5 ca-certificates-20220905-1 ca-certificates-mozilla-3.87-1 ca-certificates-utils-20220905-1 coreutils-9.1-3 cryptsetup-2.6.0-1
curl-7.87.0-3 dbus-1.14.4-1 device-mapper-2.03.18-4 diffutils-3.8-1 dnssec-anchors-20190629-3 e2fsprogs-1.46.5-4 expat-2.5.0-1
file-5.44-1 filesystem-2022.10.18-1 findutils-4.9.0-1 gawk-5.2.1-1 gcc-libs-12.2.1-1 gdbm-1.23-1 gettext-0.21.1-2 glib2-2.74.5-1
glibc-2.36-7 gmp-6.2.1-2 gnupg-2.2.40-1 gnutls-3.7.8-4 gpgme-1.18.0-2 grep-3.8-2 gzip-1.12-1 hwdata-0.366-1 iana-etc-20221215-1
icu-72.1-2 iproute2-6.1.0-3 iptables-1:1.8.8-2 iputils-20221126-1 jansson-2.14-2 json-c-0.16-1 kbd-2.5.1-1 keyutils-1.6.3-1 kmod-30-3
krb5-1.20.1-1 ldns-1.8.3-2 less-1:608-1 libarchive-3.6.2-2 libassuan-2.5.5-1 libbpf-1.0.1-1 libcap-2.66-1 libcap-ng-0.8.3-1
libedit-20210910_3.1-2 libelf-0.188-2 libevent-2.1.12-4 libffi-3.4.4-1 libgcrypt-1.10.1-2 libgpg-error-1.46-2 libidn2-2.3.4-3
libksba-1.6.3-1 libldap-2.6.3-2 libmnl-1.0.5-1 libnetfilter_conntrack-1.0.9-1 libnfnetlink-1.0.2-1 libnftnl-1.2.4-1 libnghttp2-1.51.0-1
libnl-3.7.0-1 libp11-kit-0.24.1-1 libpcap-1.10.3-1 libpsl-0.21.2-1 libsasl-2.1.28-3 libseccomp-2.5.4-1 libsecret-0.20.5-2
libssh2-1.10.0-3 libsysprof-capture-3.46.0-3 libtasn1-4.19.0-1 libtirpc-1.3.3-2 libunistring-1.1-2 libverto-0.3.2-4 libxcrypt-4.4.33-1
libxml2-2.10.3-2 licenses-20220125-1 linux-api-headers-5.18.15-1 linux-firmware-whence-20230117.7e4f0ed-1 lz4-1:1.9.4-1 mkinitcpio-34-2
mkinitcpio-busybox-1.35.0-1 mpfr-4.2.0-2 ncurses-6.4-1 nettle-3.8.1-1 npth-1.6-3 openssl-3.0.7-4 p11-kit-0.24.1-1 pacman-6.0.2-5
pacman-mirrorlist-20221204-1 pam-1.5.2-1 pambase-20221020-1 pciutils-3.9.0-2 pcre2-10.40-3 pinentry-1.2.1-1 popt-1.19-1
procps-ng-3.3.17-1 psmisc-23.6-1 readline-8.2.001-1 sed-4.9-1 shadow-4.13-2 sqlite-3.40.1-1 systemd-252.4-2 systemd-libs-252.4-2
systemd-sysvcompat-252.4-2 tar-1.34-1 tpm2-tss-3.2.0-3 tzdata-2022g-1 util-linux-2.38.1-1 util-linux-libs-2.38.1-1 xz-5.4.1-1
zlib-1:1.2.13-2 zstd-1.5.2-7 base-3-1 linux-6.1.8.arch1-1 linux-firmware-20230117.7e4f0ed-1 nano-7.2-1 openssh-9.1p1-3
Total Download Size: 467.04 MiB
Total Installed Size: 887.97 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
linux-firmware-20230117.7e4f0ed-1-any 170.2 MiB 21.2 MiB/s 00:08 [########################################################] 100%
linux-6.1.8.arch1-1-x86_64 164.1 MiB 12.2 MiB/s 00:13 [########################################################] 100%
gcc-libs-12.2.1-1-x86_64 33.9 MiB 14.4 MiB/s 00:02 [########################################################] 100%
(... removed, see paste ...)
base-3-1-any 2.2 KiB 319 KiB/s 00:00 [########################################################] 100%
ca-certificates-20220905-1-any 2.0 KiB 289 KiB/s 00:00 [########################################################] 100%
Total (126/126) 467.0 MiB 15.3 MiB/s 00:31 [########################################################] 100%
(126/126) checking keys in keyring [########################################################] 100%
warning: Public keyring not found; have you run 'pacman-key --init'?
downloading required keys...
error: keyring is not writable
error: keyring is not writable
(... repeates removed, see paste ...)
error: keyring is not writable
error: keyring is not writable
error: required key missing from keyring
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.
==> ERROR: Failed to install packages to new root
The disk is writable and working fine. Pacstrap was able to create various files on it.
(full log: https://bpa.st/6UIOY)
For comparison, a log of a working installation within the same VM: https://bpa.st/WFD7G
Any hints on how to debug this further?
Offline
I was mistaken, pacstrap _always_ fails at the first attempt, but _always_ succeeds at the 2nd attempt within the same installation run. In between pacstrap runs the disk is formatted, though, so it can't build on its earlier progress. If I delay the 1st rund for a minute before running pacstrap, it also works fine. So we're working with some kind of timing issue here?
Offline
Yes, there's a timer archlinux-keyring-wkd-sync.{service,timer} that will update the keyring to the latest version if/once you have a network connection. If you run before that has elapsed/ran then chances are your keyring is outdated. You should be able to explicitly invoke that as part of your script which I'm assuming would fix the issue... though since the point of the -K option is to explicitly create a new keyring that does sound somewhat weird.
Last edited by V1del (2023-01-26 11:45:24)
Online
Figured it out. Pacstrap doesn't work properly until pacman-init.service in the live system is done. This may be after the interactive shell started. To get a working fully automated installation, add something like the following before running any pacman-related commands.
echo waiting for pacman keyring init to be done
while ! systemctl show pacman-init.service | grep SubState=exited; do
systemctl --no-pager status -n0 pacman-init.service || true
sleep 1
done
There is probably a way to integrate this into the systemd dependencies so the shell doesn't start before pacman actually works. There is also probably a smarter way to script it. Just running the init commands in the script / shell probably also works, although I don't know if they like running twice at the same time.
archlinux-keyring-wkd-sync.service is linked to this, but takes >10 minutes to run, so I would rather not wait for that.
Case closed, for me at least
Offline
@luto Woah, nice, this is really helpful as I had frequent struggles deploying VMs with archiso / pacstrap, too. I tried every possible solution similar to this approach: https://bbs.archlinux.org/viewtopic.php?id=267364. But pacstrap running when not properly initialized didn't come in my mind. Let me express my gratitude translating your approach into an expect script fragment
expect_before "*SubState=exited*" {
expect $prompt
send -- "pacstrap -K /mnt base linux linux-firmware {{ further packages }}\r"
}
expect $prompt {
sleep 3
send -- "systemctl show pacman-init.service | grep SubState | cat\r"
exp_continue
}
Greetings
Offline
The installer image got broken some time ago because of this. It started when the ISO image was switched to loading itself in to RAM before running. In the installation guide step "1.8 Update the system clock" it is CRITICALLY important, which is not mentioned. I mean if that's not working then you MUST stop and get it working before continuing.
If it fails to activate NTP then pacman-init will never run. There is no message or hint that something is wrong but any attempt to use pacman will get weird signature, keyring, etc errors. Those aren't the real problem. The real problem is that NTP hasn't initialized (and in turn pacman-init). There really should be messages that describe the problem.
This can also be a problem on machines that have network access but not Internet access. The system gets confused.
Also, it's really difficult to work while in the install image because there is no space to install more packages in the installer environment.
All of this used to work. The old system was better.
Offline
Same problem here since a month ago or so. Temporary switched to manjaro, but that's not the same.
Is there a working boot image of arch anywhere?
Offline
The installer image got broken some time ago because of this. It started when the ISO image was switched to loading itself in to RAM before running. In the installation guide step "1.8 Update the system clock" it is CRITICALLY important, which is not mentioned. I mean if that's not working then you MUST stop and get it working before continuing.
If it fails to activate NTP then pacman-init will never run. There is no message or hint that something is wrong but any attempt to use pacman will get weird signature, keyring, etc errors. Those aren't the real problem. The real problem is that NTP hasn't initialized (and in turn pacman-init). There really should be messages that describe the problem.
This can also be a problem on machines that have network access but not Internet access. The system gets confused.
Also, it's really difficult to work while in the install image because there is no space to install more packages in the installer environment.
All of this used to work. The old system was better.
Thanks!
I just had pacstrap to fail during the installation of Arch Linux through a recently downloaded, fresh ISO and ended up in this thread.
After reading the reply above, I ran
$ timedatectl
and got "System clock synchronized: no". This raised a red flag. Then I ran
$ systemctl status pacman-init.service
and it was dead. This raised another red flag.
I started looking up for services related to time synchronization, and found "systemd-timesyncd.service". I ran
$ systemctl status systemd-timesyncd.service
and the output showed that it was timing out while trying to connect to some kind of public NTP server. It turns out that there is a file "/etc/systemd/timesyncd.conf" where this can be configured. I edited it and saved it like this:
[Time]
NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
FallbackNTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
Basically, I just copied what was into FallbackNTP= to NTP= and uncommented those lines (other lines left commented).
After that, I restarted the service:
$ systemctl restart systemd-timesyncd.service
Finally, running
$ timedatectl
gave me "System clock synchronized: yes"; and running
$ systemctl status pacman-init.service
told me the service was active.
And now pacstrap worked.
Offline
This can also be a problem on machines that have network access but not Internet access.
I am facing exactly this issue. I had to install Arch Linux in an isolated network behind a http(s)-only proxy.
While simply starting pacman-init.service via
$ systemctl start pacman-init.service
was not possible (I have no idea about pacman-init.service at all), I just issued the following commands:
$ pacman-key --init
$ pacman-key --populate
and that did the trick for me
Offline
Yesterday I faced this problem when attempting to set up a new guest system in a QEMU/KVM virtual machine, running a newly downloaded Arch Linux ISO.
It turned out to be my own installed firewall UFW on the host Arch system which was blocking things. Temporarlly disabling it immediately fixed all problems for the VM.
Though I have yet figure out how to configure that properly in the firewall.
Last edited by jongeduard (2023-04-23 10:25:13)
Offline
Pages: 1