Manjaro Xfce 18.0.4 32-bit installation notes

i decided to give installing manjaro xfce a try on my 32-bit machine to see how it’s resource consumption compares to bodhi linux and antiX. i was also interested in working with something that wasn’t ubuntu- or debian-based.

the installation process itself was fairly straightforward, but i ran into a bit of an issue when trying to update. i kept getting some variation of “invalid or corrupted package (PGP signature)” accompanied by “signature from… is marginal (or unknown) trust” which would then end the update procedure with a failure message.

i ran the process a few times to make sure it wasn’t just a fluke. rebooted and ran it again. i was offered a kernel update (nice added feature) and hoped maybe that would change the situation. unfortunately it did not.

finally a few duckduck searches later, i found some very helpful info first in the manjaro wiki. that got me close, but lacked a couple of minor (but imperative for my system) details. i finally found those on the manjaro forum.

the first important difference was that i was installing 32-bit. that meant that i needed to replace “archlinux” with “archlinux32” in the commands given. that seemed to help and get me a bit further down the path, but i was still being asked to accept keys that were considered marginal or unknown trust. that’s where the second additional command came in. i needed to update my package mirrors.

the list of commands i ended up using was:

sudo pacman-mirrors -f0
#to update my package mirrors
sudo rm -fr /etc/pacman.d/gnupg
#to clear the untrusted keys
sudo pacman-key --init
#to reinitialize the key system is my best guess
sudo pacman-key --populate archlinux32 manjaro
#to get a new set of keys. this is where i needed to add the 32 because the 64-bit keys kept getting (understandably) rejected
sudo pacman-key --refresh-keys
#seems pretty self-explanatory
sudo pacman -Sc
#to clear out the packages from the failed install
sudo pacman -Syyu
#to force sync the package database (yy) and install updates (u)

i was going to post parts of this on the manjaro forum and then cross-post here to add to the general knowledge base, but they close threads after 90 days of inactivity so i thought it might be a good idea to share a bit more detailed explanation here just in case someone else wanders into the same system error :slight_smile:

5 Likes

Thanks for sharing.
From my understanding many distros are now moving from 32 bit to 64 bit, but there are many people who can only use 32 bit or use it as preference. The information you have posted here will certainly help them.

2 Likes

Just curious, does your PC only support 32 bit or is this your test system?

1 Like

part of the reason i started trying different distros on my 32-bit computer is that bodhi is based on ubuntu which is dropping 32-bit support as you mentioned. there has been some discussion on the bodhi forum about whether or not there will be a shift to a debian base (perhaps viable until 2038?), but i wanted to look around and see what else was out there. the dropping of 32-bit hadn’t occurred to me when i went looking at manjaro. apparently arch dropped it officially a while back so someone kindly forked it.

@easyt50, that particular laptop is 32-bit (thinkpad T60 with a core two duo and 3 gb of ram). i mostly keep it around to run world community grid results on boinc manager (which also works on old android phones).

a nice recent-ish (the mx present release info is outdated, but otherwise it seems like good info) article on the persistence of 32-bit operating systems. i wasn’t aware that a lot of SoC IoT devices (smart lightbulbs, speakers and doorbells etc) were still using 32-bit.

1 Like

Because for such small appliances this is more than enough. If you need 64-bit you probably don’t have a classic IoT device at hand. :woman_shrugging:

2 Likes

fair point. size and scope are important considerations.

1 Like

On the other hand I remember that there are devices like the Rock64 as well as every Raspberry Pi 3 and higher is technically 64-bit. Yet, for the Rpi 3 or higher there is no official 64-bit support and you need to hack your own kernel and stuff to enable 64-bit and even then the packages aren’t made for this. So in almost all use cases for the Raspberry Pi, it is de facto 32-bit.

Yep - was disappointed after my RPi4 arrived that Raspbian didn’t have a 64 bit version (even RPi3 is 64 bit capable)…

I know some things seem to run better with 32 bit, even if they’re 64 bit capable, but that’s not always the case, and amount of RAM is not necessarily a limiting factor - I’ve supported 64 bit RISC platforms running UNIX on less than 128 MB of RAM, e.g. Digital UNIX/Tru64 on DEC Alpha AXP, IRIX 6 on MIPS (my SGI Indy only has 64 MB RAM - happily runs 64 bit O/S - but I haven’t turned it on for yonks, those SCSI HDD’s are damn noisy!), Solaris 2.7 on UltraSparc ii, iii and iv, - I’d ALWAYS opt for 64 bit over 32 bit on those platforms…

Having said that - I think I’ve mentioned this on here before, I’ve found that running 32 bit Linux on an Intel Atom (fairly old versions) seems “snappier” than a 64 bit Linux… My Gigabyte Brix is some kinda Celeron/Atom thingie, and it’s just fine with 64 bit (was running FreeBSD amd64 on it recently)… maybe things are different in CISC world?

I really do want 64 bit on my RPi4 though…
— edit —
Just noticed the timestamp on the ISO for manjaro i686 - it’s 1st April… hmmm - from :

2 Likes

Same. Managed to compile the kernel myself, but what’s the point if all the software is still in its old ways. Additionally, I didn’t get the correct and working kernel headers for this self-compiled kernel, so I couldn’t even have theoretically compiled every software package from source.