i486 motivation thread

deep42thought · 2017-12-04 20:14:34

Originating from a probably not that serious comment from Andreas Baumann, I'd like to start a thread to motivate him (and anyone else involved) getting archlinux32 ported to i486.

So this is (part of) my setup.

The bottom left one is my raspberry pi 1 running archlinux arm, the other is my router which currently runs debian. (The devices are mounted beneath my desk.)
It is an ALIX 2d3 doing various net-related tasks:
dhcp, routing, wifi, vpn, dns, nat64, dns64
I also tried running a tor node on it (and combining it with dns resolution of .onion tld), but this was too much for the small cpu.

Anyway: Once archlinux32 will be available for in86 with n<6, I'll give it a shot and try switching to archlinux32 on that box.

andreas_baumann · 2017-12-05 17:59:09

And I thought I'm the only one crazy enough to host his central infrastructure on an Alix and a Raspberry PI. :-)

I have a split horizon DNS, DHCP, firewall on the Alix, it's running OpenBSD (which I will not change even
if I have a i486 build).

The Raspberry PI (a Pi 1) runs the mail, Roundcube webmail, my home page and some other Joomla-based
web content (which I cannot recomment on that limited system because Mysql doesn't play well on it).

Real i486 hardware is darn expensive nowadays, the oldest thing I have is a 150MB RAM Pentium I motherboard
which will serve as a test base for the distro. Also a AMD K6 is on the list as test server.. :-)

andreas_baumann · 2017-12-28 17:12:17

I don't want to spoil Christmas, but we don't need an i486-specific build for the Alix boards.

Just installed on an Alix 1.E with AMD Geode LXD800 a Vanilla Archlinux32 for i686.
The CPU has all necessary commands it seems.

pacstrap onto the CompactFlash, no problem.

The only tricky part was to get past booting:

/etc/mkinitcpio.conf
MODULES=(pata_cs5536)
mkinitcpio -c /etc/mkinitcpio.conf -p linux

noatime in /etc/fstab

etc/sysctl.d/99-writeback.conf
vm.dirty_writeback_centisecs = 1500

I need older hardware to test the i486 on the real thing.

Still, systemd needs some taming (no journal or in memory journal and hell no
coredumps to the Compact Flash!).

Some really useful links:

https://wiki.ubuntuusers.de/Alix/CF-Boo … erstellen/ (German, sorry)
https://www.daniel-boehmer.de/thinkpad-cf/#cf-ide
https://bbs.archlinux.org/viewtopic.php?id=147061
http://buecher.mamawe.net/buecher/headl … -linux.pdf (German again, sorry again)

P.S. Order a 2 GB CF at least or you have a hard time to install even a very basic Archlinux32 :-)

deep42thought · 2017-12-29 11:03:56

hmm, interesting.
I tried to get i686 linux running on my alix once (I'm not 100% sure, I tried archlinux, too) and failed - also debian with i686 kernel didn't work out for me, but debian with i586 kernel did.

andreas_baumann · 2017-12-31 18:28:52

First ISO and cross-compiled packages for i486 are running.

https://mirror.archlinux32.org/i486/
https://archlinux32.andreasbaumann.cc/arch486isos/

Please don't use yet. They are not really Archlinux-y yet (for instance uinit instead of systemd).
And not yet self-hosting, meaning I cannot compile the Archlinux32 i486 on the system itself yet.

A first working machine is one without CMOV:

vendor_id : AuthenticAMD
model name : AMD-K6(tm) 3D processor
flags : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnow k6_mtrr cpuid 3dnowprefetch vmmcall

The build process is a shell script (or text file) with 2'440 lines, not yet suitable for publishing.

But in principle I'm using crosstool-ng for i486, then I use 'asp' to fetch the PKGBUILDs and apply patches
from Archlinux32 and specific i486-cross-compilation patches, finally I build the package, install it into
a 486-chroot (for creating the CD and for chrooting), and into the toolchain sysroot. Seems to work. :-)

andreas_baumann · 2018-04-07 09:56:10

A very first ISO is available: http://archlinux32.andreasbaumann.cc/ar … 7-i486.iso

Currently you can install only base and base-devel packages, the rest you have to build on your own as I
don't have a buildmaster or slave yet set up for continuous i486 package building.

Currently booting the ISO and installing from it needs at least 288 MB of RAM, during installation I recommend
adding a 512MB swap and mount it as very first action before doing a pacstrap or a mkinitcpio.

The memory demands of the standard squashfs-based ISO root file system and the glibc-based RAM disk
make it currently impossible to boot on real vintage computers with as little as a i486 with 32/64 MB of RAM.
That's the next goal to provide non-memory intensive special ramdisks and ISOS. Also installing via PXE/NBD
seems to be a requirement for old vintage machines.

The standard ISO is for machine with enough RAM but not having a "modern" CPU like AMD K5/K6, real Penitum I and II,
and i486 and clones.

BTW: Using the official NBD mounting with archiso_nbd_srv and archiso_nbd_name with the ISO is an option if you have at
least 768MB of RAM as the ISO is slurped into a ram disk with an overlay filesystem.

andreas_baumann · 2018-04-10 20:23:41

A good way to install to low-memory machines seems to be to use PXE/TFTP to load the
kernel and the RAM disk. The RAM disk itself should have the mkinitcpio-nfs-utils mkinitcpio-nbd
hooks installed as follows:

MODULES=(8139too e100 nbd isofs)
BINARIES=(/usr/bin/mount.nfs4 /usr/bin/nbd-client)
HOOKS=(base udev autodetect modconf block filesystems keyboard net nbd)

This has to be built on a i486 installation (I'm using a virtual image for this).

Then I set up a tftp-hpa (atftp always runs into timeout issues, no clue why?)
with a structure like this:

/srv/tftp/*.c32 (from syslinux)
/srv/tftp/*.bin (from syslinux)
/srv/tftp/pxelinux.cfg/default
/srv/tftp/initramfs-linux.img
/srv/tftp/vmlinuz-linux

The kernel can be taken from the linux pacman package (the one installed on the VM).

/srv/tftp/pxelinux.cfg/default contains the necessary configuration to load the kernel and
the ramdisk via TFTP:

say Archlinux32 i486 NBD based install
default linux
prompt 1
timeout 100
label linux
com32 cmd.c32
initrd initramfs-linux.img
linux vmlinuz-linux
append rw nomodeset ip=:::::eth0:dhcp nbd_host=<IP of NBD server> nbd_name=arch486install debug root=/dev/nbd0

cmd.32 and nomodeset are important as some old machines really don't like VGA mode switching and KMS fiddling
(neither does my old Olivetti CRT monitor, 30 years old and still working!).

You have to configure your DHCP server to hop to 'next-server <IP of TFTP server>'.

Now the NBD server has to serve the airootfs.sfs as unpacked file system:

truncate -s 2G /data/nbd/arch486install.img
mkfs.ext4 -O ^64bit /data/nbd/arch486install.img
mount -o loop arch486install.img /mnt
mount -o loop archlinux-2018.04.07-i486.iso /media/cdrom
cd /mnt
unsquashfs /media/cdrom/arch/i486/airootfs.sfs
mv squashfs-root/* .
rmdir squashfs-root
# add the unofficial i486 mirror
sed -i 's/Server/#Server/g' /mnt/etc/pacman.d/mirrorlist
echo 'Server = http://archlinux32.andreasbaumann.cc/$arch/$repo' >> /mnt/etc/pacman.d/mirrorlist

In /etc/nbd-server/config:

[arch486install]
exportname = /data/nbd/arch486install.img
copyonwrite = true

So now, 64 MB is sufficient to boot an old 486 and install from the mounted NBD root as usual.

Just make sure to add a swap partition or swap file before doing anything memory consuming. :-)

Another caveat: Use mkfs.ext4 -O ^64bit for 32 bit systems..

Caveat 2: If I say PXE, I mean, use iPXE, I had some weird issues with some network firmware claiming
to support PXE. iPXE has a i486 bug, so has syslinux, use versions from around 2011 which are still running
(I used iPXE aaf7a35207f4fa88c6d3e1b1e26d1950c19a8169 and syslinux 4.07).

And a side note: using the default ISO with archiso_nbd_srv=<IP of NBD server>
archiso_nbd_name=arch486iso and archiso.img is an option if you have more than 768 MB RAM.

deep42thought · 2018-09-11 05:37:12

abaumann: How much manual work does building i486 packages involve currently (besides adding necessary patches to our modifications repository)?
Do you simply run "makepkg" on a i486 vm. now that the bootstrapping is done?
The way to integrate i486 with our build system is, to add a script (or expand build-packages) which retrieves i486 build assignments from the build master and executes whatever you do manually (?) now.
I would really like to see this running to load some work off you.

regards,
deep42thought

andreas_baumann · 2018-09-11 06:30:59

I have a slighly forked version of the 'builder' (branch i486), and one new script:
- rebuild-core-i486: builds everything linearly
- build-package-i486: slightly adapted copy from test-build-package

There are diffs in a i486 branch in 'packages' which contain a if $CARCH=i486
section. There I'm mainly breaking cycles (which still exist for base and base-devel).

For the adaptions, the --disable-cet was one of the nastier one lately, usually there
is not much to do. What worries me, is that without testing on real hardware Qemu
cannot always guarantee to act as an early alert system for illegal opcodes.

deep42thought · 2018-09-11 07:08:56

can you push this branch to gitea, please?

andreas_baumann · 2018-09-11 08:44:22

huh? I thought I did..

andreas_baumann · 2018-09-11 08:46:22

https://git.archlinux32.org/archlinux32 … ranch/i486
https://git.archlinux32.org/abaumann/bu … ranch/i486

the second one is a fork.

deep42thought · 2018-09-11 12:02:02

ah, I read "branch" instead of "forked"

hmm, I see some (solvable) problems integrating your i686 builder with our build tools. We need:

switchable repositories (e.g. use [build-support] or not)
separation from the system - e.g. we should use a chroot
build-assignment management and package upload should be done by/via the build-master

My proposal to solve these issues would be to:

use the magic from build-packages to talk to the buildmaster
use the magic from devtools (e.g. staging-i686-build and staging-with-build-support-i686-build) to manage the chroots

This basically boils down to two changes which make the i686 build-packages able to build for i486:

we need to request i486 build-assignments from the buildmaster if we're running on i486
we need to apply i486 modifications if we're running on i486

what do you think, abaumann?

andreas_baumann · 2018-09-11 18:26:11

Sounds good. :-)

deep42thought · 2018-09-12 08:34:08

ok, the buildmaster now manages i486 packages, too (except unexpected bugs - and it does not know about any already built packages yet)
Also, build-packages requests i486 or i686 packages depending on $(uname -m).

I think my last point "we need to apply i486 modifications if we're running on i486" is not cleanly applyable:
There might be an "any" package handed out to an i686 or i486 build slave, but it should not build different sources.
Maybe it's better to merge all i486 modification into the master branch with something like

depends_i486=()
if [ $ARCH = i486 ]; then
...
elif [ $ARCH = i686 ]; then
...
fi

objections?

andreas_baumann · 2018-09-12 17:55:51

mmh. Why $ARCH and not $CARCH?

I actually don't usually add 486-specific packages, removing is actually common
like:

makedepends=(${makedepends[@]//docbook-sgml/})

deep42thought · 2018-09-12 17:59:50

andreas_baumann wrote:

mmh. Why $ARCH and not $CARCH?

my mistake, of course "$CARCH"

andreas_baumann wrote:

I actually don't usually add 486-specific packages, removing is actually common

well, then just do
makedepends_i686=(docbook-sgml)
makedepends=(${makedepends[@]//docbook-sgml/})

schmorp · 2018-11-19 19:55:56

is not much to do. What worries me, is that without testing on real hardware Qemu
cannot always guarantee to act as an early alert system for illegal opcodes.

Sorry to barge in - while this is true, qemu does a very good job at emulating those old cpus, it's just that most people run it with kvm, which of course only "emulates" your real cpu.

I found that using something like:

qemu-system-i386 -M pc,accel=tcg -cpu 486,check

Gives a pretty accurate CPU emulation, by trapping illegal opcodes. i386 is harder (qemu only does i486+), but given that the linux kernel requires a 486+ nowadays, this is not going to be a problem for a new distribution.

tkteun · 2019-05-10 17:41:28

I (still) have stack of these that I just can't throw out... I remember having set them up once on PXE but was already facing issues with Debian Squeeze and was forced to install Lenny. (Did do a three way LACP with 280Mbps LTSP/NBD/remote X)

Now I've found this thread, but I'm not quite sure how to set this up. Should I use the 2018.04.07 iso or compile packages in a vm?

Anyhow, does anyone maybe have an archive of their PXE folder? And send it to me?

Thanks!

andreas_baumann · 2019-05-10 18:25:34

Oh, nice boxes! :-)

I hope they have at least 64 MB RAM, otherwise you'll have a hard time to install
Archlinux32 on them.

I opened up my TFTP directory with a PXE setup:

https://archlinux32.andreasbaumann.cc/tftp/

Quite messy, but you may get some inspiration there.

You will have to use PXE or iPXE (I used to have trouble with some PXE BIOSes and
iPXE didn't work after a certain version for old i486-like CPUs), see ipxe-i486.dsk.

You have to set up a DHCP to redirect to the next-server PXE (sorry, I have OpenBSD on the

router and for the DNS server):

dhcp.conf

  allow booting;
  allow bootp;
  next-server 192.168.1.12;

    host euroalix {
      hardware ethernet 00:0D:B9:0F:62:78;
      fixed-address 192.168.1.25;
      filename "pxelinux.0";
    }

The ramdisks are quite special as they have to fit to your hardware, I didn't make generic
ones, because I had memory limitations on my machines.

Also note I went via NBD for the root device:

[arch486iso]
        exportname = /data/nbd/archlinux-2018.04.07-i486.iso
        readonly = true

There I'm just exposing the last i486 ISO.

You'll find some other small snippets of information here and there in the forum secion about
old machine and i486 motivation thread.

And don't hesitate to ask.. :-)

levi · 2019-05-10 19:37:45

According to the sticker on the RAM part installed there, it looks like a 256MB DIMM. And yes, that is a sexy box.

tkteun · 2019-05-13 19:13:34

Hi, thanks for your reply

Yeah, I got them with busted PSU caps which I replaced (ones without mark). Good thing I've scabbenged all the SDRAM I could find, mostly 256 and 128. (does 512 even exist?) I've always had problems with storage in these, the one DoM I have (in the IDE) also only does PIO4, no UDMA.

Thanks for posting your setup, I've set up my DHCP/TFTP/NBD services, but I'm having some issues with the pxelinux.cfg options.

Been trying quite a bunch of options, but keep running into issues leaving me without a root filesystem.

append ro nomodeset ip=:::::eth0:dhcp archiso_nbd_srv=10.42.0.190 archiso_nbd_name=arch486iso

This line was based on the third append you have commented out, but should work?
I don't know what your arch486install share contains, or why I get the message about a nbd name/host not being present. (the eth0 message doesn't appear on the machine)

Thanks!

Last edited by tkteun (2019-05-13 19:14:49)

levi · 2019-05-13 22:18:20

tkteun wrote:

Hi, thanks for your reply
Yeah, I got them with busted PSU caps which I replaced (ones without mark). Good thing I've scabbenged all the SDRAM I could find, mostly 256 and 128. (does 512 even exist?) I've always had problems with storage in these, the one DoM I have (in the IDE) also only does PIO4, no UDMA.

I bought a 512MB SDRAM DIMM to upgrade my last server, a Pentium3 733MHz board. I paid under 4 quid for it at the time, but it seems scarcity pricing is now in full effect as that seller now wants many times that for another one should I want it.

I'm afraid I'm all out of idea when it comes to your booting woes however, sadly.

andreas_baumann · 2019-05-14 21:07:53

Yeah. I think you miss drivers in the ramdisk. You need at least nbd, a network and a disk driver.
The ramdisk has to be generated on another machine using i486 as architecture.
I usually install a chroot with pacstrap for the i486 architecture, edit mkinitcpio.conf accordingly
in the chroot and the generate a special ramdisk for that machine (mkinitcpio -P).
The kernel then uses all modules from the ramdisk when booting and is fairly generic.

An alternative approach is to compile a custom kernel without most modules and compiling
in the essential network, disk, NBD drivers directly into the kernel. This avoids the trouble
to generate a ramdisk (and frees up quite some memory).

tkteun · 2019-05-15 09:40:33

Ah, okay... I thought you had created an image with NBD enabled so I could cheat out of cross compiling...

The 8139too driver works great on the actual machine, the vm was just for a screen shot of the NBD hook error messages...

Arch Linux

#1 2017-12-04 20:14:34

i486 motivation thread

#2 2017-12-05 17:59:09

Re: i486 motivation thread

#3 2017-12-28 17:12:17

Re: i486 motivation thread

#4 2017-12-29 11:03:56

Re: i486 motivation thread

#5 2017-12-31 18:28:52

Re: i486 motivation thread

#6 2018-04-07 09:56:10

Re: i486 motivation thread

#7 2018-04-10 20:23:41

Re: i486 motivation thread

#8 2018-09-11 05:37:12

Re: i486 motivation thread

#9 2018-09-11 06:30:59

Re: i486 motivation thread

#10 2018-09-11 07:08:56

Re: i486 motivation thread

#11 2018-09-11 08:44:22

Re: i486 motivation thread

#12 2018-09-11 08:46:22

Re: i486 motivation thread

#13 2018-09-11 12:02:02

Re: i486 motivation thread

#14 2018-09-11 18:26:11

Re: i486 motivation thread

#15 2018-09-12 08:34:08

Re: i486 motivation thread

#16 2018-09-12 17:55:51

Re: i486 motivation thread

#17 2018-09-12 17:59:50

Re: i486 motivation thread

#18 2018-11-19 19:55:56

Re: i486 motivation thread

#19 2019-05-10 17:41:28

Re: i486 motivation thread

#20 2019-05-10 18:25:34

Re: i486 motivation thread

#21 2019-05-10 19:37:45

Re: i486 motivation thread

#22 2019-05-13 19:13:34

Re: i486 motivation thread

#23 2019-05-13 22:18:20

Re: i486 motivation thread

#24 2019-05-14 21:07:53

Re: i486 motivation thread

#25 2019-05-15 09:40:33

Re: i486 motivation thread

Board footer