This sounds like a partial upgrade to me which is not supported by either Archlinux32 nor
Archlinux.

It sounds, like you tried to upgrade a very old system - is that right?

The supported way of doing so, is by using the archive at archive.archlinux32.org to upgrade in multiple smaller steps. Just upgrading a subset of packages will inevitably lead to trouble - if you choose this path, you must be prepared to fix things the hard way.

It sounds, like you tried to upgrade a very old system - is that right?

Of course.

The supported way of doing so, is by using the archive at archive.archlinux32.org to upgrade in multiple smaller steps.

Ha! Good luck with that! I suppose that we might haggle over what - exactly - those "small steps" might be, especially when a user is left with a paucity of necessary information.

you must be prepared to fix things the hard way.

However you slice it - "this way" or "that way" - they are both "the hard way".

I'm just suggesting a "least change" solution, assuming a "not my problem - won't fix" culture. The alternative is preparing additional "transition" packages, to provide those "small steps", to upgrade to zstd packages. But *that* requires more work, in an uncertain Arch32 culture.

The supported way of doing so, is by using the archive at archive.archlinux32.org to upgrade in multiple smaller steps.

Ha! Good luck with that! I suppose that we might haggle over what - exactly - those "small steps" might be, especially when a user is left with a paucity of necessary information.

Actually, I have already successfully followed this path - it's pretty easy: You try one date (pick one in the middle between "last update" and "now") and if that works, move on - if not, try an earlier date. Usually, two steps are enough: one for pacman (and zstd) and one for the most-recent keyring. However, the keyring update can be circumvented by installing keys manually with pacman-key.

you must be prepared to fix things the hard way.

However you slice it - "this way" or "that way" - they are both "the hard way".

If you're familiar with bisecting, the multiple-steps-from-archive way is not hard.

I'm just suggesting a "least change" solution, assuming a "not my problem - won't fix" culture. The alternative is preparing additional "transition" packages, to provide those "small steps", to upgrade to zstd packages. But *that* requires more work, in an uncertain Arch32 culture.

Actually, those "transition" packages do exist: there is pacman-static, which should be able to install zstd compressed packages on *any* system.

Those simple instructions - "trial and error", pacman-static - added to the home page "Latest News", and particularly, to "Transition from the Official Repositories", would be better than nothing. Still, it seems an abuse of the underlying design of pacman, which specifically provides a "depends" configuration variable to address these kinds of issues.

Alternatively, every zstd compressed package could be made to depend upon whatever "mystery version and later version" of pacman supported that transition to zstd packaging - but that would be silly.

Is it really as simple as saying "first install pacman-static; then run pacman -Syyu as normal"? That would an important bit of advise to share, supposing that pacman-static is not, itself, a zstd compressed package. Unfortunately, a simple search under Packages does *not* show any such pacman-static package, uncompressed or otherwise.

pacman-static is not an official package, it's in the aur. But more importantly, Eli builds binary packages and even provides the extracted binaries (look at the aur page for details).

And yes: with pacman-static (I believe, the command is also called "pacman-static" instead of "pacman"), all that's left, is to get a recent keyring and use pacman-static to do the system update.

TBH: My feelings towards proper dependencies is very similar to yours (e.g. zst-compressed packages should depend on a recent-enough pacman; etc.), however, this is not, how (upstream) arch considers things. (Or at least, that's my impression of how they do). BUT: The more we deviate from upstream archlinux, the more work our four hands have to do to keep up. That's the reason, why we try to stay as close as possible to archlinux.

Can you check, if updating via 2020/01/01 repositories is really a two-step process? If so, it would be nice, if you could document it in some forum thread, then I would link that on the front page

Can you check, if updating via 2020/01/01 repositories is really a two-step process?

Hmm - I might poke through the junk pile for another 32bit laptop. I'd be more inclined to try the pacman-static solution, since that promises to be simpler.

zstd-1.3.6-1.0-i686.pkg.tar.xz has files dated 2018-10-18.

libarchive-3.3.3-1.0-i686.pkg.tar.xz has files dated 2018-09-07.

pacman-5.1.2-2.0-i686.pkg.tar.xz has files dated 2019-01-10.

From what you suggest, that version might work.

pacman-5.2.1-1.4-i686.pkg.tar.xz is the last xz version of pacman, and has files dated 2019-11-21.

So no, 2020/01/01 seems too late. However, what you suggest also requires a user hand-pick similarly dated packages for libarchive, zstd, pacman, and acl, to be first downloaded from the *archive*, and manually installed together, with `pacman -U`, and without other packages, before trying `pacman -Syyu`. This is presupposing that the user actually has the information needed to understand the purpose for doing all that - the dependency information. And though it may work, it seems a silly amount of ritual.

Admittedly, the only advantage to keeping properly versioned dependencies in the pacman package - other than that it is the "right thing to do" - is to *prevent* someone simply bypassing the zstd compression problem - in an oversimplified and failed attempt - to get a working pacman, to handle upgrading to the current zstd compressed packages - which is what I did, not knowing where the decompression mechanism was hidden, at the time. Again, of course, note - a *current* zstd compressed pacman package - and particularly, all of its dependencies - cannot be installed with a version of pacman that cannot install zstd compressed packages. When following the rules, pacman is pretty fool-proof and "does the right thing". Otherwise, pacman becomes fragile.

The pacman-static approach seems much more straightforward. I suggest a whacking-big arrow on the Arch32 home page, to using pacman-static as the *first* recourse, before someone manages to break their existing pacman tools, trying to find some kind of resolution to failed upgrade messages, at least with respect to changing package formats. Effectively, pacman-static would handle the pacman dependencies, acting as a work-around for the shortcomings in pacman itself, which does not always gracefully handle those package format changes.

That is, assuming that pacman-static in the AUR will build on an old 32bit linux box. A better solution would be for Arch32 to build and host its own pacman-static, which need be no more than building the AUR package, as is.

Using the archive should be as simple as putting

Server = https://archive.archlinux32.org/repos/2020/01/01/$arch/$repo

into the mirrorlist. Though, I just notice, we're missing the symlinks needed to make that approach work fully. So one has to download the packages manually, currently - I'll try to fix that (or at least open a bug about it ).

I was wrong, the archive works as described above: There is a rewrite rule in the webserver in place. I was only looking at the filesystem, before …

Hmm - help me understand this. Looking through core.files.tar.gz from the 2020/01/01 repos, I see pacman-5.2.1-1.4 *and* its dependencies. That part should work.

So then, the user has to point their /etc/pacman.conf *exclusively* at this archive repository, which can be done most simply by substituting a modified mirrorlist containing *exlusively* that archive server repo, rather than having to rewrite their pacman.conf.

Next, perform an upgrade, and, after that upgrade, replace mirrorlist with the standard mirrorlist and upgrade again. Did I get that right?

Just for the sake of argument, do we know that a direct upgrade with pacman-static, as an alternative, would *not* also work? There are issues with encryption keys? Will there also be key issues with the archive repo upgrade?

Hmm - it still seems to me that adding a 32bit-built pacman-static from the AUR to the Arch32 repository would be prudent.

As built, the pacman-static is xz compressed. The first stable xz release has files dated 2010-10-23, so pacman-static should cover Arch upgrades back 10 years or so, and it is easy enough for someone to install an uncompressed pacman-static, if that was needed. Arch Linux was first released 2002 March 11, and the i486 predates that. I suspect that uncompressed pacman-static could work back to the beginning of Arch.

Hmm - coming-up on the Arch 20 year anniversary. Nice!

Hmm - help me understand this. Looking through core.files.tar.gz from the 2020/01/01 repos, I see pacman-5.2.1-1.4 *and* its dependencies. That part should work.

So then, the user has to point their /etc/pacman.conf *exclusively* at this archive repository, which can be done most simply by substituting a modified mirrorlist containing *exlusively* that archive server repo, rather than having to rewrite their pacman.conf.

Next, perform an upgrade, and, after that upgrade, replace mirrorlist with the standard mirrorlist and upgrade again. Did I get that right?

Yes, that's, how it should work. I also added this information to https://archlinux32.org/download which is linked on the main page for how to transition from archlinux.

Just for the sake of argument, do we know that a direct upgrade with pacman-static, as an alternative, would *not* also work? There are issues with encryption keys? Will there also be key issues with the archive repo upgrade?

I think, it will work similarily good. In both cases, you might need to install a intermediate keyring, update signing keys manually or ignore the signatures (I would not recommend the latter officially).

Hmm - it still seems to me that adding a 32bit-built pacman-static from the AUR to the Arch32 repository would be prudent.

Eli has all that (not in our repository, though. otoh a *packaged* pacman-static is of little use anyways) - look at his repo (which I linked earlier): pacman-static package for i686 and x86_64 as well as the extracted pacman-static binary for i686 and x86_64 (the i686 one works well on pentium4, too).

As built, the pacman-static is xz compressed. The first stable xz release has files dated 2010-10-23, so pacman-static should cover Arch upgrades back 10 years or so, and it is easy enough for someone to install an uncompressed pacman-static, if that was needed. Arch Linux was first released 2002 March 11, and the i486 predates that. I suspect that uncompressed pacman-static could work back to the beginning of Arch.

uncompressed pacman-static might even work on any system running a linux kernel

Yes, that's, how it should work. I also added this information to https://archlinux32.org/download which is linked on the main page for how to transition from archlinux.

Well, I looked at your addition to the page, but that is not enough. The user has to understand the necessity for an *exclusive* mirrorlist and the ritual of mirrorlist swapping.

I suggest moving the last sentence "If you're upgrading an old installation which struggles to install zstd compressed packages, you need to install packages from e.g. 2020/01/01 which include a[n] xz compressed pacman which is able to install zstd compressed packages." from under the "Package Archive" heading, and into the section directly below, "Transition from the Official Repositories", as the *first* instruction.

That first instruction must also be qualified, followed with something to the effect of "You must first create a mirrorlist file which includes *ONLY* the archive repository, and then you must execute `pacman -Syyu` to force a refresh of all package databases." The subsequent instructions should then work, though I don't know if there also will be keyring issues with the archive upgrade.

But, I point out that, using the pacman-static approach instead, completely avoids the mucking-about with mirrorlist files, or explaining why or how to do that.

BTW, that section header, "Transition *from* the Official Repositories", really should be "Transition *to* the Arch32 Repositories", since the Arch32 Repositories *are* "Official Repositories". They're just 32bit instead of 64bit. Don't sell it short. There is nothing "not official" about Arch32 or Arch Linux 32 or "archlinux32", whatever the proper name is. "Arch32" seems the better nickname.

a *packaged* pacman-static is of little use anyways

Why do you say that? That is not at all evident.

Eli has all that … look at his repo (which I linked earlier)

Uhm - this is very much "presuming the conclusion". Yes, if the user already knows the answer, knows what to do, then you may conclude that the user already knows what to do. But the user does *not* already know what to do. You have to "spell it out" on the Arch32 web page.

I looked again at the AUR page. Reading in the Pinned Comments:

Direct links to the extracted binary.
If your computer is broken, you can download this, verify the signature with the repo keyring using pacman-key -v, and transfer via USB to your broken system:

x86_64 uncompressed (GPG) compressed (GPG)

i686 uncompressed (GPG) compressed (GPG)

The only parts of interest here are "i686 uncompressed" and "GPG":
https://pkgbuild.com/~eschwartz/repo/i686-extracted/pacman-static https://pkgbuild.com/~eschwartz/repo/i686-extracted/pacman-static.sig

There is no reason to send users "looking for a needle in a haystack". I suggest simply that an additional bullet point be added to the bottom of the "Transition" section, to the effect of "As an alternative to intermediate upgrades or swapping custom mirrorlist files, or if your pacman program is broken, you can download and install a pre-built 32bit static uncompressed *pacman-static* binary and signature from here:", followed by the two links above.

uncompressed pacman-static might even work on any system running a linux kernel

I consider that to be a *very* interesting observation, maybe even intriguing. And I highly recommend that you add it also, as is, as a final bullet point in the "Transition" section.

Well, I looked at your addition to the page, but that is not enough. The user has to understand the necessity for an *exclusive* mirrorlist and the ritual of mirrorlist swapping.

This is all pretty well documented in the archwiki. I replaced the duplication by a comment and link to the respective wiki page.

I suggest moving the last sentence "If you're upgrading an old installation which struggles to install zstd compressed packages, you need to install packages from e.g. 2020/01/01 which include a[n] xz compressed pacman which is able to install zstd compressed packages." from under the "Package Archive" heading, and into the section directly below, "Transition from the Official Repositories", as the *first* instruction.

That first instruction must also be qualified, followed with something to the effect of "You must first create a mirrorlist file which includes *ONLY* the archive repository, and then you must execute `pacman -Syyu` to force a refresh of all package databases." The subsequent instructions should then work, though I don't know if there also will be keyring issues with the archive upgrade.

Yes, good idea - the transition instructions were out-of-date. I tried to clarify them.

But, I point out that, using the pacman-static approach instead, completely avoids the mucking-about with mirrorlist files, or explaining why or how to do that.

I think, we should add a pacman-static hint somewhere else and only link that on the transition notes. pacman-static is also a great tool to recover a severely-broken system without the need to boot a live medium. But from my feeling, the "proper" path of updating an old system is not by using the unbreakable stand-alone tool pacman-static, but rather by doing, what would have happened if updates had been performed more regularly (e.g. use the archive to do updates in multiple steps).

BTW, that section header, "Transition *from* the Official Repositories", really should be "Transition *to* the Arch32 Repositories", since the Arch32 Repositories *are* "Official Repositories". They're just 32bit instead of 64bit. Don't sell it short. There is nothing "not official" about Arch32 or Arch Linux 32 or "archlinux32", whatever the proper name is. "Arch32" seems the better nickname.

I tried to improve it - do you think, it's better?

a *packaged* pacman-static is of little use anyways

Why do you say that? That is not at all evident.

How do you install (a packaged) pacman-static if pacman is broken? What do you need pacman-static for if pacman is not broken?

Eli has all that … look at his repo (which I linked earlier)

Uhm - this is very much "presuming the conclusion". Yes, if the user already knows the answer, knows what to do, then you may conclude that the user already knows what to do. But the user does *not* already know what to do. You have to "spell it out" on the Arch32 web page.

Yes, we should add something about pacman-static, but I'm not sure, where it fits. "download" is probably the wrong place, though - it rather belongs to "troubleshooting".

I looked again at the AUR page. Reading in the Pinned Comments:

—-
> Direct links to the extracted binary.
> If your computer is broken, you can download this, verify the signature with the repo keyring using pacman-key -v, and transfer via USB to your broken system:

x86_64 uncompressed (GPG) compressed (GPG)

i686 uncompressed (GPG) compressed (GPG)
> —-

The only parts of interest here are "i686 uncompressed" and "GPG":
> https://pkgbuild.com/~eschwartz/repo/i686-extracted/pacman-static
https://pkgbuild.com/~eschwartz/repo/i686-extracted/pacman-static.sig

There is no reason to send users "looking for a needle in a haystack". I suggest simply that an additional bullet point be added to the bottom of the "Transition" section, to the effect of "As an alternative to intermediate upgrades or swapping custom mirrorlist files, or if your pacman program is broken, you can download and install a pre-built 32bit static uncompressed *pacman-static* binary and signature from here:", followed by the two links above.

Yes, but as said above, I think, we should not put this into the download section - or at least, it deserves its own section.

uncompressed pacman-static might even work on any system running a linux kernel

I consider that to be a *very* interesting observation, maybe even intriguing. And I highly recommend that you add it also, as is, as a final bullet point in the "Transition" section.

My statement is rather bold: pacman-static will happily install all kinds of packages, but it will also not interoperate with any package manager that installed stuff before (except for pacman, obviously): So if you run pacman-static on debian to switch to archlinux, it might work, but will leave you with lots of file conflicts (just use '–overwrite *' to solve these) and then with lots of files unknown to pacman, because they were installed/tracked by apt-get.

This is all pretty well documented in the archwiki. I replaced the duplication by a comment and link to the respective wiki page.

Again, "presuming the conclusion". The ArchWiki reference under the prior "Package Archive" section does not inform the user *why* they should go there, and then search 3/4 of the way down the page, under "How to restore all packages to a specific date", for the part - in small print - that begins "or by replacing your /etc/pacman.d/mirrorlist with the following content: …". Seriously - you cannot expect people to just "intuit" that action when they are probably in "overwhelm" mode. You have to "spell it out". Like, literally, add the qualifier, "read at the bottom of the page under 'replacing your /etc/pacman.d/mirrorlist'.", following the ArchWiki link.

Yes, good idea - the transition instructions were out-of-date. I tried to clarify them.

Yes, that looks good. Much better! I think that that addresses the underlying issue here, dealing with package format breakage.

I think, we should add a pacman-static hint somewhere else and only link that on the transition notes. pacman-static is also a great tool to recover a severely-broken system without the need to boot a live medium.

Ok, but somewhere prominent, so that a new user will know that pacman-static is an option in their "toolbox". I've been running linux for 25 years, and Arch for maybe 10 or more, and I've never know about pacman-static. Admittedly, I've never really had reason to know about it, but it is a good thing know it is there, and why. Arch32, because it implies old hardware, is a place where pacman-static might be handy, more so than with main-stream Arch.

I suggest on the home page itself, in the blue box at the top, there could be a link to a page that discusses pacman-static, where to get it, how to use it, and why.

But from my feeling, the "proper" path of updating an old system is not by using the unbreakable stand-alone tool pacman-static, but rather by doing, what would have happened if updates had been performed more regularly (e.g. use the archive to do updates in multiple steps).

Ok, on reflection, I agree - likely to be "safer", more conservative, and less risky. This use case - a very old Arch system, upgrade to an unknown future Arch system - is not traditional Arch. A "rolling release" system is normally never very "old".

I tried to improve it - do you think, it's better?

Yes, totally. That works!

How do you install (a packaged) pacman-static if pacman is broken? What do you need pacman-static for if pacman is not broken?

Last question first, as I mentioned, "As an alternative to intermediate upgrades or swapping custom mirrorlist files, or if your pacman program is broken, you can download and install a pre-built 32bit static uncompressed *pacman-static* binary and signature from here:", followed by the two links above.

To the first question - glad you asked, because I've had to deal with this. And yes, it's nice if you are already a super-geek, and never take a wrong turn - but sometimes there's a learning curve - and bad things happen. So, in desperation, you download the current ISO, "dd" it to a flash drive, mount the flash drive and copy 'pacman-static' there. Unmount the flash drive and use it to boot to a working linux. Remember, we *do not* want to "blow away" the perfectly good, otherwise working, linux system on the hard drive. We just want to fix pacman - because, you know, something bad happened. Mount the hard drive, and copy 'pacman-static' from the flash drive to the existing system on the hard drive. Reboot from the hard drive, and run shiny new pacman-static.

Then, make a mental note, to *always* install a gratuitous linux-lts and pacman-static - just in case. Or, at the least, keep the binary pacman-static itself in some safe directory.

Yes, we should add something about pacman-static, but I'm not sure, where it fits. "download" is probably the wrong place, though - it rather belongs to "troubleshooting".

As above, starting with a link from the home page. But not so much "troubleshooting", simply because a user should think about this *before* they have reason to be searching under "troubleshooting". pacman-static is like insurance. It's something to have *before* you need it.

Yes, but as said above, I think, we should not put this into the download section - or at least, it deserves its own section.

Yes, somewhere. You can reference Eli's AUR page, but some Arch32 specific context and discussion is warranted. I don't know that it has to be a lot of information, but something to amplify the value and perspective of pacman-static.

I did finally install the packman-static package from the AUR. The binary does in fact get renamed "pacman-static", so it can be installed next to stock "pacman", as I think you mentioned. But there is also an entire /usr/lib/pacman/ directory that has other purpose, which you may or may not want to discuss.

My statement is rather bold: pacman-static will happily install all kinds of packages, but … with lots of files unknown to pacman …

It just sparks the imagination!

I think a little playing-around with diff, find {/usr,/var}, cat /var/lib/pacman/local/*/files|sed 's=.*=/&=', and mv or rm, could clean-up the debris. This might be entertaining on a system where booting the ISO is impractical or impossible.

How do you install (a packaged) pacman-static if pacman is broken?

Sorry - don't know what I was thinking there - mixing a couple of different projects, and not answering the question you actually asked.

Yes, if pacman is broken, a pacman-static *package* cannot be installed, after the fact. Instead, the idea would be to preemptively install a pre-built pacman-static package, as insurance against some future potential breakage.

Other alternatives presuppose that our hypothetical user also has access to another, working, linux box. In that case, the 32bit pacman-static binary could be extracted from an Arch32 pacman-static package, to be somehow copied into the machine with the broken pacman.

Still, as you point out, that 32bit binary can already be found in Eli's repository, linked from the pacman-static AUR page. And, the package could just as well be built by the user themselves, directly from the AUR. An Arch32 hosted pacman-static package would just be a courtesy to the user.

To make a correction to my earlier example, if a system is bootable or already running, pacman-static can be copied using, for instance, a USB drive, as Eli points-out on the AUR page. If ssh and the network are working, scp could be even easier.

If pacman gets broken and the system is not bootable, then the Arch32 ISO becomes useful. But - the iso9660 filesystem is not writable - and there is no pacman-static there. Copying a pacman-static to the same flash drive requires adding a second partition and filesystem.

But then, if the machine is running the ISO from the flash drive, the ISO *has* a working pacman, and there is no need for pacman-static. On reflection, I must concede your point. And an Arch32 packaged pacman-static would be no more than a courtesy.

can you have a look at the download page again, if I changed it to your liking?

Yes, that works. A few comments:

In the "Transition from Archlinux to Archlinux32" section, some emphasis could be put on the idea of "as sole mirror", something like "as the *only* mirror", where "only" is in italic or bold or some such.

Also, the archive instruction could be introduced with the qualifier, "If the last system update was prior to 2019, first update pacman to provide zstd support."

The last sentence does not need to be in parenthesis. I was taught "If you need to say something, just say it," but the "it" should be made explicit, 'Alternatively, use a recent pacman-static to provide zstd support. See "Fixing broken pacman" below for details on how to obtain pacman-static.'

In the "Fixing broken pacman" section, `arch-chroot /mnt` could also be mentioned, as an alternative, "… and use `pacman –sysroot /mnt …`, or just `arch-chroot /mnt`, to …".

You might also capitalize the words in the section titles, as in "Fixing Broken Pacman".

BTW, if you find a place for this, since I went to the trouble, here are simple instructions for adding a writable partition to the standard ISO install media, using the defaults.

$ sudo dd if=archlinux32-2021.03.02-i686.iso of=/dev/sdX
$ sudo sh -c 'echo ,,,|sfdisk -N 2 /dev/sdX'
$ mkfs -v /dev/sdX2

That grabs the remainder of the install media for the second partition and creates an ext2 filesystem there. Someone could add packages there, for instance, to install a basic - or even complete - system without going out to the Internet, or to install custom configuration files in /etc/ or /var/lib/, or to copy-in a preconfigured home directory. It might be useful sometime, to install Arch without a network connection.

In the "Transition from Archlinux to Archlinux32" section, some emphasis could be put on the idea of "as sole mirror", something like "as the *only* mirror", where "only" is in italic or bold or some such.

done.

Also, the archive instruction could be introduced with the qualifier, "If the last system update was prior to 2019, first update pacman to provide zstd support."

Hmm, I don't see, where that would fit: The archive instructions are only given for the transition from arch to arch32 - which is always pre-2019.

The last sentence does not need to be in parenthesis. I was taught "If you need to say something, just say it," but the "it" should be made explicit, 'Alternatively, use a recent pacman-static to provide zstd support. See "Fixing broken pacman" below for details on how to obtain pacman-static.'

done.

In the "Fixing broken pacman" section, `arch-chroot /mnt` could also be mentioned, as an alternative, "… and use `pacman –sysroot /mnt …`, or just `arch-chroot /mnt`, to …".

This will not work: arch-chroot would chroot and then use the pacman from the installed system - which is presumably broken.

You might also capitalize the words in the section titles, as in "Fixing Broken Pacman".

done. It's hard for non-native English writers to get these things right. Usually, I would capitalize a lot more words

BTW, if you find a place for this, since I went to the trouble, here are simple instructions for adding a writable partition to the standard ISO install media, using the defaults.
>
> $ sudo dd if=archlinux32-2021.03.02-i686.iso of=/dev/sdX
> $ sudo sh -c 'echo ,,,|sfdisk -N 2 /dev/sdX'
> $ mkfs -v /dev/sdX2
>
> That grabs the remainder of the install media for the second partition and creates an ext2 filesystem there. Someone could add packages there, for instance, to install a basic - or even complete - system without going out to the Internet, or to install custom configuration files in /etc/ or /var/lib/, or to copy-in a preconfigured home directory. It might be useful sometime, to install Arch without a network connection.

That sounds like something, that would fit into the upstream installation guide. Why don't you add it there?

Hmm, I don't see, where that would fit: The archive instructions are only given for the transition from arch to arch32 - which is always pre-2019.

ArchLinux32.org started in 2017, and before that, Arch Linux supported i686 directly. Anyone updating Arch32 during and since 2019 will have gained zstd support. Anyone who has - as you are pointing-out - an Arch system that has not been touched since before 2017 *is* transitioning from Arch to Arch32. But also, anyone who had updated their system between 2017 and 2019, using Arch32, *will also - very likely - be reading these instructions*, despite the section title "Transition from Archlinux to Archlinux32". Those people will appreciate being warned - and will need to be warned - about the zstd transition. Very likely, in 2021, whether their Arch Linux machine was last upgraded before 2017 or after 2017 but before 2019, is going to be a somewhat academic distinction, because the zstd transition will *still* be an issue, either way. And, all they will be caring about is *how* to make the upgrade work.

Maybe you would expand the section title, "Transition from Archlinux to Archlinux32 and Transition to zstd Compression"?

This will not work: arch-chroot would chroot and then use the pacman from the installed system - which is presumably broken.

Hmm - yes, point taken - pacman *has* to be from the recent ISO installer in that case. Thanks. You could even add that as a warning, "arch-chroot will not work in this case, where the native pacman is not usable." arch-chroot will be familiar to a user from a first Arch install, and `pacman - -sysroot …` maybe not so much.

It's hard for non-native English writers to get these things right. Usually, I would capitalize a lot more words.

Ha! I like Capitals. And even for native English speakers, there are style preferences and differences of opinion, depending on where they grow-up. My biggest pet-peeve with writing style, though, is with German-English, and the use of infinitives - "to set" - in place of gerunds - "setting". "This requires you to set the default." is acceptable. "This requires setting the default." is typical English. "This requires to set the default." is like "fingernails scratching chalkboard". There is no simple rule for gerunds and infinitives, and the difference in meaning - in cases where they can be interchanged - can be subtle. Lots of Linux documentation is written by native German speakers.

That sounds like something, that would fit into the upstream installation guide. Why don't you add it there?

Hmm - I actually have an answer for that question. I once began contributing to the Arch Wiki. And then a rather juvenile and inexperienced, but ambitious and self-appointed "editor" began reverting every edit I made, even on pages where I was the original author. It's a bit of time and work, providing proper context, and getting everything to make sense to some reader who may be new to Arch and not have the same level of experience. I don't care to fight with people about policy differences, when they believe "their way" is "the only way". "Once burned, twice shy." I don't want to waste my time.