[SOLVED - Hurrah!] Upgrading from a truly ancient install

levi · 2020-10-21 20:11:44

The question is how you can update a 2017era machine to latest state. You've two problems; your outdated pacman doesn't support zst compression, and it won't have the right keys. You might be able to find deep42thousht's publishing key on a keyserver somewhere which would solve that problem, for example . Download that and import it into the gpg home directory of /etc/pacman.d/gnupg. And you'll need the last version of pacman that came in an xz package but supprorted xst compression hopefully such as this one.

1. Import the key, and download the pacman package.
2. Try '# pacman -U ~/Downloads/pacman-*' to upgrade your pacman that far.
3. Assuming everything's worked to far, update your keyring so that's in a better known state (# pacman -Syu archlinux32-keyring)
4. '# pacman -S pacman' to get pacman up to latest
5. '# pacman -Syu' to get everything else up to date

Hopefully that will get you in a better situation than you are now. It's always possible I've missed some catch that will stop you at some point or another, but that's why I've written this as a forum post and not on a wiki or blog somewhere I guess.

SDRausty · 2020-10-22 16:15:39

levi wrote:

import it into the gpg home directory of /etc/pacman.d/gnupg.

Thank you for sharing the information you shared Levi very much. It appears that this issue is making progress here.

the setup process that i gone through and works fine as intended

Last edited by SDRausty (2020-10-22 16:26:02)

SDRausty · 2020-10-27 12:03:43

levi wrote:

will finally become the only real use for this old project.

Minimum space required to install the installation on device (Android smartphone) can also be a strong motivator here:
1. aarch64 1500MB
2. arm7 1250MB
3. x86_64 800MB

The minimum install size for Arch Linux 32 appears to be around 400 megabytes.

Last edited by SDRausty (2020-10-27 12:04:05)

SDRausty · 2020-10-27 15:22:54

levi wrote:

1. Import the key, and download the pacman package.

[root10:08~]$ gpg --keyserver keyserver.ubuntu.com --recv-keys 0x194e37a47a4c671807bacb37b1117bc1094ea6e9
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key B1117BC1094EA6E9: public key "Erich Eckner <deep42thought@archlinux32.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

levi wrote:

2. Try '# pacman -U ~/Downloads/pacman-*' to upgrade your pacman that far.

[root10:13~]$ pacman -U /var/cache/pacman/pkg/pacman-5.2.2-1.0-i686.pkg.tar.zst
loading packages...
error: could not open file /var/cache/pacman/pkg/pacman-5.2.2-1.0-i686.pkg.tar.zst: Unrecognized archive format
error: '/var/cache/pacman/pkg/pacman-5.2.2-1.0-i686.pkg.tar.zst': cannot open package file

The key is imported successfully, but the pacman package will not install:

Unrecognized archive format

SDRausty · 2020-10-27 15:55:58

SDRausty wrote:

The key is imported successfully

When studying the output of the lastest new customized automated attempt to install Arch Linux an Android smartphones; This is the best result so far with 'setupTermuxArch qemu' option x86:

==> Updating trust database...
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   6  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   6  signed:  62  trust: 0-, 0q, 0n, 6m, 0f, 0u
gpg: depth: 2  valid:  62  signed:   6  trust: 62-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2021-10-23
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key B1117BC1094EA6E9: public key "Erich Eckner <deep42thought@archlinux32.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
resolving dependencies...
looking for conflicting packages...

Packages (2) archlinux32-keyring-20200408-1.0  pacman-5.2.2-1.0

Total Download Size:   0.87 MiB
Total Installed Size:  4.53 MiB
Net Upgrade Size:      0.08 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages...
 archlinux32-keyring...    32.3 KiB  1196K/s 00:00 [####################] 100%
 pacman-5.2.2-1.0-i686    853.5 KiB  19.4M/s 00:00 [####################] 100%
(2/2) checking keys in keyring                     [####################] 100%
downloading required keys...
:: Import PGP key 4096R/5FDCA472AB93292BC678FD59255A76DB9A12601A, "Erich Eckner (just to sign arch packages) <arch@eckner.net>", created: 2018-04-09? [Y/n]
(2/2) checking package integrity                   [####################] 100%
error: archlinux32-keyring: signature from "Erich Eckner (just to sign arch packages) <arch-packages@eckner.net>" is unknown trust
:: File /var/cache/pacman/pkg/archlinux32-keyring-20200408-1.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]

Why is the key imported:

gpg: key B1117BC1094EA6E9: public key "Erich Eckner <deep42thought@archlinux32.org>" imported
gpg

Then promply rejected with an error:

error: archlinux32-keyring: signature from "Erich Eckner (just to sign arch packages) <arch-packages@eckner.net>" is unknown trust

Why is the key imported then promply rejected with an error?

Last edited by SDRausty (2020-10-27 16:01:57)

levi · 2020-10-27 16:10:39

SDRausty wrote:

The key is imported successfully, but the pacman package will not install:
Unrecognized archive format

Yeah, that's cause you didn't do what I said. I told you to download a specific version of pacman that comes in a xz format but ought to support xst packages. You've tried to install an xst package without having a pacman that can cope with that. Luckiy the version you need is still on the packages archive, and I linked to it. Download that and try to install it.

Edit: The key is imported again because you never imported it into pacman's key storre. You imported it into your users key store, as if you were going to send him an email or something. I'm not sure if pacman saying it's done it now has fixed it for you or not though.

Edit2: I've updated the subject of this thread. Each time I forget about it then it pops up again saying 'File is corrupt' I have to remember what it's all about. So I've changed it to something hopefully more reminiscent.

Last edited by levi (2020-10-27 16:17:18)

SDRausty · 2020-10-27 18:49:18

levi wrote:

Download that and try to install it.

[root13:30~]$ pacman -U pacman-5.2.1-1.4-i686.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (2) archlinux32-keyring-20200408-1.0  pacman-5.2.1-1.4

Total Download Size:   0.03 MiB
Total Installed Size:  4.51 MiB
Net Upgrade Size:      0.06 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages...
 archlinux32-keyring-20200408-...    32.3 KiB  1076K/s 00:00 [#################################] 100%
(2/2) checking keys in keyring                               [#################################] 100%
(1/2) checking package integrity                             [#################################] 100%
error: archlinux32-keyring: signature from "Erich Eckner (just to sign arch packages) <arch-packages@eckner.net>" is unknown trust
:: File /var/cache/pacman/pkg/archlinux32-keyring-20200408-1.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

levi wrote:

users key store

All the work being done is in the root user account in PRoot, not a user account. Configuring the user account comes after the root account is configured, which we're working on at present.

There are two abstraction layers that we are dealing with here at this topic:
1. PRoot enables using Linux in a chroot environment,
2. QEMU emulates architectures.

levi wrote:

updated the subject of this thread.

The new title reflects what is happening here at present. If I ever get around to finishing my autumn chores, I will check if there is a working 386 box around to try to make a new root file system. I was hoping that updating the package is easier. Do you have any more suggestions as to what can be updated?

Last edited by SDRausty (2020-10-28 17:43:36)

SDRausty · 2020-10-27 18:58:06

This is currently the code that customizes for Arch Linux 32:

X86INT="whoami ; curl -OL http://archive.archlinux32.org/packages/p/pacman/pacman-5.2.1-1.4-i686.pkg.tar.xz ; pacman -U pacman-5.2.1-1.4-i686.pkg.tar.xz ; rm -f pacman-5.2.1-1.4-i686.pkg.tar.xz ; gpg --keyserver keyserver.ubuntu.com --recv-keys 0x194e37a47a4c671807bacb37b1117bc1094ea6e9 ; whoami"

Last edited by SDRausty (2020-10-27 19:03:13)

levi · 2020-10-27 19:43:15

You'd need to install the key before you try to pacman -U that package I think.

I'm still not convinced you don't need a --homedir /etc/pacman.d/gnupg added to your --recv-keys call. Without that I'd expect gpg to create a key store in /root, which still isn't the right place for pacman to pick it up from. You can either do that once, or use a --gpgdir argument to pacman, but the danger in doing that is you'd need to keep remembering to do that going forward. Better to just import it once into the right place.

SDRausty · 2020-10-27 21:03:42

levi wrote:

You'd need to install the key before you try to pacman -U

I just noticed that too. The 'gpg' command:

gpg --keyserver keyserver.ubuntu.com --recv-keys 0x194e37a47a4c671807bacb37b1117bc1094ea6e9 ;

failed to excecute correctly as:

$ ping keyserver.ubuntu.com
PING keyserver.ubuntu.com (162.213.33.9) 56(84) bytes of data.
^C
--- keyserver.ubuntu.com ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8112ms

Is there an alternate keyserver that you can recommend?

levi wrote:

I'm still not convinced you don't need a --homedir /etc/pacman.d/gnupg added to your --recv-keys call. Without that I'd expect gpg to create a key store in /root, which still isn't the right place for pacman to pick it up from. You can either do that once, or use a --gpgdir argument to pacman, but the danger in doing that is you'd need to keep remembering to do that going forward. Better to just import it once into the right place.

The command 'keys' handles the keyring setup:

grep ^pacman ~/arch/root/bin/keys                                          
pacman-key --init || sudo pacman-key --init || _PRTERROR_
pacman-key --populate || sudo pacman-key --populate || _PRTERROR_                                    
pacman -S "${KEYRINGS[@]}" --noconfirm --color=always || sudo pacman -S "${KEYRINGS[@]}" --noconfirm --color=always || _PRTERROR_                                                                         
pacman-key --populate || sudo pacman-key --populate || _PRTERROR_
pacman -Ss keyring --color=always || sudo pacman -Ss keyring --color=always || _PRTERROR_

Can you elaborate more about this please?

SDRausty · 2020-10-27 21:25:19

gpg: keybox '/root/.gnupg/pubring.kbx' created

levi wrote:

Better to just import it once into the right place.

Where is the right place with --gpgdir?

Edit 1: The option ' --gpgdir' does not exist:

gpg: invalid option "--gpgdir"

Last edited by SDRausty (2020-10-27 22:29:00)

levi · 2020-10-27 22:28:37

--gpgdir is an option to pacman to specify where your non-standard gpg directory is. The more correct option you can supply to gpg is called --homedir.

Edit: To be fair, the log of the automated script you posted at 15:55 today does seem to be using the --gpgdir option to make pacman use the /root gnupg store. But if you're no longer using the automated script and trying to update the working but old system it produced, then doing it the proper way sounds better to me. But to an extent, it depends where you're trying to end up here; if your wanting to update the automatic instructions so that others can follow, then stick with what it's doing already, but if your aim is just to get a working system for yourself that you can continue to use going forward then doing the right thing is best practice.

Last edited by levi (2020-10-27 22:49:22)

SDRausty · 2020-10-27 22:41:09

levi wrote:

--gpgdir is an option to pacman to specify where your non-standard gpg directory is. The more correct option you can supply to gpg is called --homedir.

Done; this is the code:

gpg --homedir /etc/pacman.d/gnupg --keyserver keyserver.ubuntu.com --recv-keys 0x194e37a47a4c671807bacb37b1117bc1094ea6e9

This is the error:

==> Updating trust database...                                                                       
gpg: next trustdb check due at 2020-12-31
Running gpg...
gpg: key B1117BC1094EA6E9: "Erich Eckner <deep42thought@archlinux32.org>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1                                                                       
Running curl...                                                                                        
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  755k  100  755k    0     0  4152k      0 --:--:-- --:--:-- --:--:-- 7127k                       
loading packages...                                                                                  resolving dependencies...
looking for conflicting packages...

Packages (2) archlinux32-keyring-20200408-1.0  pacman-5.2.1-1.4

Total Download Size:   0.03 MiB
Total Installed Size:  4.51 MiB
Net Upgrade Size:      0.06 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages...                                                                             
archlinux32-keyring-20200408-...    32.3 KiB  1076K/s 00:00

[#################################] 100%(2/2) checking keys in keyring                               
[#################################] 100%(1/2) checking package integrity                             
[#################################] 100%

error: archlinux32-keyring: signature from "Erich Eckner (just to sign arch packages) <arch-packages@eckner.net>" is unknown trust                                                                        
:: File /var/cache/pacman/pkg/archlinux32-keyring-20200408-1.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]

error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

The key is imported successfully, but the pacman package will not install

error: archlinux32-keyring: signature from "Erich Eckner (just to sign arch packages) <arch-packages@eckner.net>" is unknown trust

SDRausty · 2020-10-27 22:55:02

Here is my most recent attempt:

gpg: next trustdb check due at 2021-10-23
Running gpg...                                                                                       
gpg: key B1117BC1094EA6E9: public key "Erich Eckner <deep42thought@archlinux32.org>" imported
gpg: Total number processed: 1                                                                       
gpg:               imported: 1

The result is:

:: Import PGP key 4096R/5FDCA472AB93292BC678FD59255A76DB9A12601A, "Erich Eckner (just to sign arch packages) <arch@eckner.net>", created: 2018-04-09? [Y/n]
(1/2) checking package integrity                             
[#################################] 100%
error: archlinux32-keyring: signature from "Erich Eckner (just to sign arch packages) <arch-packages@eckner.net>" is unknown trust
:: File /var/cache/pacman/pkg/archlinux32-keyring-20200408-1.0-any.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Frankly, I'm a little stumped why an imported key is rejected. How about you? Is there another key from Erich Eckner that wants importing too?

levi · 2020-10-27 22:58:14

Yeah, I'm not sure what's up with that trust message. I don't normally make use of the trust features in my own gpg features. Maybe gpg --homedir /etc/pacman.d/gnupg --update-trustdb will help, I'm not sure. But trying that on my own gpg homedir it seems that none of the keys there are actually trusted yet on my machine, including deep42thought's key.

Edit: Actually it's not deep42thought's key that's untrusted. It's an older one probably from before the arch32 split. The update-trustdb ran through all of those old keys but doesn't ask me about his deek42thought key, so presumably that one is already trusted.

Last edited by levi (2020-10-27 23:07:16)

SDRausty · 2020-10-28 00:05:46

After adding:

gpg --homedir /etc/pacman.d/gnupg --update-trustdb

Then tapping

4 = I trust fully

a many times, the error has changed:

Packages (2) archlinux32-keyring-20200408-1.0  pacman-5.2.1-1.4                                                                                                                                           
Total Installed Size:  4.51 MiB                                                                      
Net Upgrade Size:      0.06 MiB                                                                                                                                                                           
:: Proceed with installation? [Y/n]
(2/2) checking keys in keyring                               
[#################################] 100%
(1/2) checking package integrity                             
[#################################] 100%
(1/2) loading package files                                  
[#################################] 100%
error: could not open file /var/cache/pacman/pkg/archlinux32-keyring-20200408-1.0-any.pkg.tar.zst: Unrecognized archive format
error: failed to commit transaction (cannot open package file)
Errors occurred, no packages were upgraded.

The key is now trusted! This is quite a success; thank you for helping levi.

SDRausty · 2020-10-28 02:57:24

It turns out that:

gpg --homedir /etc/pacman.d/gnupg --update-trustdb --yes

Adding --yes did not alleviate the excessive tapping as expected. However moving the gpg import statement before did:

pacman-key --populate

Command order change resolved importing the keys easily. After iterating a couple more versions, after getting pacman installed, this error appears:

(2/2) upgrading pacman                                       
[#################################] 100%
warning: /etc/pacman.conf installed as /etc/pacman.conf.pacnew
New optional dependencies for pacman
    perl-locale-gettext: translation support in makepkg-template
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
pacman-conf: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

This error is blocking further progress.

pacman -Fo libcrypto.so.1.1

It appears at least one more package wants individual updating also; Do you know which package libcrypto.so.1.1 belongs to?

Last edited by SDRausty (2020-10-28 05:42:44)

SDRausty · 2020-10-28 03:35:09

SDRausty wrote:

pacman -Fo libcrypto.so.1.1
It appears at least one more package wants individual updating also; Do you know which package libcrypto.so.1.1 belongs to?

After a little more digging in the Internet I found an answer to this question:

openssl-1.1.1.d-2.0-i686.pkg.tar.xz

SDRausty · 2020-10-28 04:16:19

The answer was NOT the answer:

http://archive.archlinux32.org/packages/o/openssl/openssl-1.1.0.g-1-i686.pkg.tar.xz

Possibly this version which was being tested would have the file that was being sought. The result was negative. This version was just tested:

openssl-1.1.0.d-1-i686.pkg.tar.xz

It looked promising too:

pacman-conf: /usr/lib/libc.so.6: version `GLIBC_2.27' not found (required by pacman-conf)

Unfortunately only the error has morphed. The final result is yet to be achieved.

SDRausty · 2020-10-28 04:40:58

levi wrote:

will finally become the only real use for this old project.

There is also another use case I would like to bring up here for Arch Linux 32 that I have not mentioned yet. Smartphone armv7l architecture is 32-bit. Installing Arch Linux x86_64 in armv7l causes some Arch Linux x86_64 programs to break. This is not the case with aarch64 which is 64-bit architecture.

SDRausty · 2020-10-28 04:47:47

This latest attempt with:

openssl-1.0-1.0.2.k-1-i686.pkg.tar.xz

failed with:

pacman-conf: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

These are the files used in this attempt:

archlinux32-keyring-20191103-1.0-any.pkg.tar.xz pacman-5.2.1-1.4-i686.pkg.tar.xz openssl-1.0-1.0.2.k-1-i686.pkg.tar.xz

SDRausty · 2020-10-28 05:18:26

This latest attempt with:

openssl-1.1.1-1.0-i686.pkg.tar.xz

failed with:

pacman-conf: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

These are the files used in this attempt:

archlinux32-keyring-20191103-1.0-any.pkg.tar.xz pacman-5.2.1-1.4-i686.pkg.tar.xz openssl-1.1.1-1.0-i686.pkg.tar.xz

I must say I am a little befuddled here. It appears that it desires the other version regardless of which one is installed

Last edited by SDRausty (2020-10-28 19:00:47)

levi · 2020-10-28 07:13:42

Now you've got pacman partially upgraded (it only failed in the post-transaction hooks which AFAIK shouldn't result in a roll back), can you not do a '# pacman -Syu'? That's the easiest to get at promised good set of packages we all use.

SDRausty · 2020-10-28 17:40:44

levi wrote:

can you not do a '# pacman -Syu'? That's the easiest to get at promised good set of packages we all use.

Total Download Size:     3.39 MiB
Total Installed Size:  455.17 MiB
Net Upgrade Size:      123.90 MiB

All the keys were rejected; I will try again. Success appears to be linked with finding a matching set for:

archlinux32-keyring
openssl
pacman

How would you match these three ancients?

Last edited by SDRausty (2020-10-28 18:57:44)

SDRausty · 2020-10-28 17:53:07

pacman -Syu                                                                            
pacman: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

This error occurs when these three packages are updated first:

archlinux32-keyring-20191103-1.0-any.pkg.tar.xz
openssl-1.1.1-1.0-i686.pkg.tar.xz
pacman-5.2.1-1.4-i686.pkg.tar.xz

These three packages installed well. The 'libcrypto.so.1.0.0' error is intriguing. Depending on the versions of the packages that were used, sometimes 'libcrypto.so.1.1' would be the one that's missing. What is the best match for these three packages?

Last edited by SDRausty (2020-10-31 00:39:04)

Arch Linux

#26 2020-10-21 20:11:44

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#27 2020-10-22 16:15:39

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#28 2020-10-27 12:03:43

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#29 2020-10-27 15:22:54

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#30 2020-10-27 15:55:58

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#31 2020-10-27 16:10:39

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#32 2020-10-27 18:49:18

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#33 2020-10-27 18:58:06

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#34 2020-10-27 19:43:15

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#35 2020-10-27 21:03:42

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#36 2020-10-27 21:25:19

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#37 2020-10-27 22:28:37

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#38 2020-10-27 22:41:09

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#39 2020-10-27 22:55:02

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#40 2020-10-27 22:58:14

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#41 2020-10-28 00:05:46

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#42 2020-10-28 02:57:24

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#43 2020-10-28 03:35:09

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#44 2020-10-28 04:16:19

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#45 2020-10-28 04:40:58

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#46 2020-10-28 04:47:47

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#47 2020-10-28 05:18:26

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#48 2020-10-28 07:13:42

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#49 2020-10-28 17:40:44

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

#50 2020-10-28 17:53:07

Re: [SOLVED - Hurrah!] Upgrading from a truly ancient install

Board footer