Kleinstmögliche Installation um Python laufen zu lassen...

[jedie]

Mich hat der RetroComputing Virus erfasst, nach dem alte Schätze aus dem Keller zum Vorschein gekommen sind.

Nun hab ich mir in den Kopf gesetzt auf einem 486er und einem 386er ein Python ans laufen zu bekommen... Wenn ich es geschafft hab, kann ich mir über den Sinn ja immer noch Gedanken machen

Ziel ist also eine Minimal Debian installation, die nur das absolut notwendige installiert hat, um einen Python Interpreter zu starten... Evtl. auch komplett ohne Netzwerk.

Aktuell hab ich folgende Rechner quasi als Weg hin zum 386:

• Pentium II/III mit 768MB bzw. 1GB RAM
• Pentium 1 133Mhz aktuell nur 32MB RAM
• 486er hab ich aktuell zwei: Maxdata Laptop mit einem Cyrix 5x86 / Fujitsu Stylistic 1000 Tablet jeweils mit 24MB RAM
• 386 mit 8MB RAM

Als ersten Schritt wäre es aber nötig überhaupt ein Linux auf einem alten Rechner zum laufen zu bekommen...

Beim 386er wird es recht schwierig, weil der Linux Kernel den Support für 386er seid v3.8 (Feb.2013) entfernt wurde. Also wenn, dann geht nur noch v3.7.10 ... Aber naja, 468er wäre erstmal ein gutes Zwischenziel


Auf dem Pentium II läuft Linux natürlich ohne Probleme. Aktuell Debian Buster mit XFCE Desktop über eine SATA-SSD mittels PATA Adapter... Aber der "moderne" Rechner dient als erste dazu das CompactFlash Bootmedium als erstes zu Testen...

Mit 32/24/8MB RAM heißt das: Kernel selber bauen... Bin jetzt auch kein Linux Crack und hab das bisher nie gemacht. Aber ich hab "Booting a 486 From Floppy with the Most Up-to-Date Stable Linux Kernel" gefunden und danach einen Kernel gebaut. Wobei mein Ziel keine Floppy ist Nutzte CompactFlash als HDD, hab somit 500MB Platz satt


Ich hab quasi das gemacht:

Code: Alles auswählen

jens@debian386:~/debian_kernel/linux-source-4.19$ make ARCH=x86 tinyconfig
jens@debian386:~/debian_kernel/linux-source-4.19$ make ARCH=x86 nconfig

    General Setup --->
        > Configure standard kernel features (expert users)
            [*]   Enable support for printk
            [*]   Enable PC-Speaker support

        > Initial RAM filesystem and RAM disk (initramfs/initrd) support >
            Support initial ramdisk/ramfs compressed using gzip

    Processor type and features --->
        > Processor family
             <X> 486

    Executable file formats --->
        [*] Kernel support for ELF binaries

    Device Drivers --->
        Character devices --->
            [*] Enable TTY

jens@debian386:~/debian_kernel/linux-source-4.19$ make ARCH=x86 bzImage -j`nproc`
jens@debian386:~/debian_kernel/linux-source-4.19$ ls -la arch/x86/boot/bzImage
-rw-r--r-- 1 jens jens 557376 Aug 19 19:29 arch/x86/boot/bzImage

Dzau gleich mal eine Frage: Kann man die Settings wie CONFIG_M486=y und CONFIG_TTY=y auch direkt setzten, ohne sich durch die ncuses Oberfläche zu hangeln?


Der Kernel ist also gerade mal 557,4KB groß. Das rootfs.cpio.gz aus dem vom Artikel vorgeschlagenen Aboriginal Linux "system-image-486" ist 572,7KB groß. Also zusammen 1,1MB... Aber egal: Floppy ist kein Ziel...


Jedenfalls hab ich mit install-mbr und syslinux eine bootbare CompactFlash mit einer <500MB Partition gemacht. Beim Pentium II System funktioniert das auch so halb. Zumindest startet syslinux den linux Kernel... Dann kommt "Kernel panic ... No working init found." ... Aber immerhin Kernel wird geladen...

Beim Pentium I sehe ich allerdings nur "syslinux EDD" und dann nichts mehr.


Meine aktuelle Idee ist das, das ich lieber eine normale Debian installation mache, dann den kernel selber kompiliere, das alles am "modernen" Rechner und damit dann versuche am alten Rechner zu starten.
Allerdings Frage ich mich: Kann grub das system auch auf einem 486 laden? oder sollte man syslinux nehmen? Kann man grub durch syslinux ersetzten?

Dann Frage ich mich, wie viel Speicher ein Python Interpreter überhaupt braucht, also welche Mindest RAM größer man dazu braucht... Wäre Alternative wäre noch MicroPython's unix port: http://docs.micropython.org/en/latest/u ... ckref.html ... Das sollte wesendlich weniger RAM brauchen.


​

[hikaru]

Vom Kernel habe ich wenig Ahnung. Das Einzige was ich dir sagen kann ist, dass Debian seit Stretch eine vollwertige i686-CPU vorausetzt. Das ist bei Intel mindestens ein Pentium Pro, bei AMD ein K6-3.
Bis einschließlich Wheezy gab es ordentlichen i486-Support.
Unter Jessie gab es zwischenzeitlich zwar einen i586-Kernel, aber einige Userland-Pakete haben implizit i686 vorausgesetzt, weil sie i686-Instruktionen verwendeten. Dort kam es dann zu Segfaults. Reproduzieren ließ sich das Ganze auch mit i586-Kernel nur auf i586-Hardware, nicht aber auf i686-Hardware. Jessie auf i586 funktionierte zwar im Prinzip, flog einem aber alle Nase lang mit einzelnen Anwendungen um die Ohren.

Letztes Jahr habe ich auf armhf ein chroot für grundlegende Python-Entwicklung zum Bauen einer Fremdanbieter-Software aufgesetzt. Dieses chroot benötigte run 1,5GB Festspeicher und beim Ausführen des relativ einfachen Fremdprogramms brauchte ich ca. 1GB RAM, wobei aber wahrscheinlich viel auf schlechtes Speichermanagement seitens Python zurückzuführen war. Ich habe den Fremdcode nur überflogen, daher kann ich es nicht mit Sicherheit sagen, aber ich vermute, ein äquivalentes C-Programm wäre mit deutlich unter 100MB RAM ausgekommen.
Ich muss allerdings auch hier sagen, dass ich kein Python-Crack bin und dass ich mich im Wesentlichen nur an die auf x86 ausgerichtete Bauanleitung des Fremdanbieters verlassen habe. Ich habe ein paar Optimierungen am Build-Prozess vorgenommen, die aus meiner Perspektive eines erfahrenen Debianers logisch erschienen, den eigentlichen Python-Code aber kaum verändert. Python-Entwicklung ist auch für den Fremdanbieter nicht das Kerngeschäft, sondern lediglich Mittel zum Zweck, das er kaum besser hinstümpert als ich. Es mag hier also Optimierungspotenzial geben.

Lange Rede, kurzer Sinn:
Ich halte die Kombination langsame CPU + wenig RAM + Python für keine gute Idee.

[Tintom]

Beim 386er wird es recht schwierig, weil der Linux Kernel den Support für 386er seid v3.8 (Feb.2013) entfernt wurde. Also wenn, dann geht nur noch v3.7.10 ... Aber naja, 468er wäre erstmal ein gutes Zwischenziel

Es wird ein Ding der Unmöglichkeit auch nur ein halbwegs aktuelles Debian bei dem wenigen RAM ans Laufen zu kriegen. Teste mal vorab in einer VM wie sich ein System mit so wenig RAM verhält.

[hikaru]

Teste mal vorab in einer VM wie sich ein System mit so wenig RAM verhält.

Ich hatte das mal getestet. Ich meine das war als Wheezy stable war.
Mit 32MB RAM kam das System sauber hoch. Mit 24MB kam zwar noch der Kernel, aber irgendwas im Userland sponn. Mit 20 oder 16MB kam dann nicht mal mehr der Kernel hoch.

[Tintom]

Ich war neugierig und habe mal geschaut welches Debian-Release noch mit dem 386er lauffähig wäre.
Debian 2.1 ("Slink") braucht mind. 4 MB RAM [1], der Nachfolger Potato braucht schon mind. 12 MB RAM [2]. Debian Slink kommt mit Kernel 2.0 aber immerhin schon mit apt

[1] https://www.debian.org/releases/slink/i ... .html#s2.3
[2] https://www.debian.org/releases/potato/ ... .html#s2.3

[jedie]

Lange Rede, kurzer Sinn:
Ich halte die Kombination langsame CPU + wenig RAM + Python für keine gute Idee.

Sinn ergibt das so oder so nicht Ist eh nur der Spaß um zu sehen ob es funktionieren könnte...

Ich hatte das mal getestet. Ich meine das war als Wheezy stable war.
Mit 32MB RAM kam das System sauber hoch. Mit 24MB kam zwar noch der Kernel, aber irgendwas im Userland sponn. Mit 20 oder 16MB kam dann nicht mal mehr der Kernel hoch.

Aber hast du den Kernel auch selbst gebaut, mit dem absoluten minimal Umfang?

Ich war neugierig und habe mal geschaut welches Debian-Release noch mit dem 386er lauffähig wäre.
Debian 2.1 ("Slink") braucht mind. 4 MB RAM [1], der Nachfolger Potato braucht schon mind. 12 MB RAM [2]. Debian Slink kommt mit Kernel 2.0 aber immerhin schon mit apt

Anhand welcher Daten hast du das nachgesehen? Geht es um den "default" Kernel oder um die min.RAM Angabe in der Anleitung?

Nach meinen Info's, die ich im Eingangspost schon schrieb wurde der 386er support aus dem Kernel 3.8 gelöscht. Somit geht nur der 3.7er zweig... Debian wheezy hat 3.2.x und jessie 2.16.x ... Von daher sollte ein wheezy theoretisch funktionieren, wenn man alle "abschaltet" was nicht "nötig" ist...

[hikaru]

Aber hast du den Kernel auch selbst gebaut, mit dem absoluten minimal Umfang?

Nein, das war de Standardkernel.

[jedie]

So... Hab mal ein neues Experiment gemacht:

Auf einer 1GB CompactFlash Karte eine 500MB Partition gemacht (Weil bei 504MB alte BIOS Versionen Probleme haben)
Als Dateisystem XFS (Ist die Frage ob ext2 oder was andere weniger RAM verbrauchen würde... Keine Ahnung)

Dann mit debootstrap ein "minbase" installiert und grub-pc nachinstalliert, ungefähr so:

Code: Alles auswählen

~# mount /dev/sdd1 /mnt
~# debootstrap --arch=i386 --variant=minbase buster /mnt http://ftp.de.debian.org/debian/
...
I: Unpacking the base system...
I: Base system installed successfully.
~# df -h | grep sdd
/dev/sdd1                                 473M    225M  249M   48% /mnt
~# for dir in /dev /dev/pts /proc /sys /run; do sudo mount --bind $dir /mnt$dir; done
~# sudo cp /proc/mounts /mnt/etc/mtab
~# sudo mount -o bind /etc/resolv.conf /mnt/etc/resolv.conf
/# apt install grub-pc

Grub startet auf meinem alten Pentium II System... Auf dem 468 kommt allerdings nur, nach einiger Ladezeit die Meldung "Read Error"
Laut https://gnu.huihoo.org/grub-0.90/html_c ... ub_13.html ist es ein "Stage 1" Fehler:

Read Error
A disk read error happened while trying to read the stage2 or stage1.5.

Schade... Ideen?

[Tintom]

Ich war neugierig und habe mal geschaut welches Debian-Release noch mit dem 386er lauffähig wäre.
Debian 2.1 ("Slink") braucht mind. 4 MB RAM [1], der Nachfolger Potato braucht schon mind. 12 MB RAM [2]. Debian Slink kommt mit Kernel 2.0 aber immerhin schon mit apt

Anhand welcher Daten hast du das nachgesehen? Geht es um den "default" Kernel oder um die min.RAM Angabe in der Anleitung?

Nach meinen Info's, die ich im Eingangspost schon schrieb wurde der 386er support aus dem Kernel 3.8 gelöscht. Somit geht nur der 3.7er zweig... Debian wheezy hat 3.2.x und jessie 2.16.x ... Von daher sollte ein wheezy theoretisch funktionieren, wenn man alle "abschaltet" was nicht "nötig" ist...

Meine Überlegung war, dass Wheezy das letzte Debian mit Support für i386 war. Darauf hat hikaru seine Erfahrungen gepostet, was bedeutet, dass dein 3/486-System in der derzeitigen Konfiguration nicht laufen würde. Um deine beiden ältesten Maschinen stabil ans Laufen zu bekommen, müsstest du daher noch weiter in den Releases zurück gehen. Die Angaben von Debian sind zu verstehen als "Minimalangaben, unter denen das System stabil läuft". Bedenke auch System != Kernel, weil du immer noch einen Haufen an Hintergrundprogrammen am Laufen hast, die ihrerseits noch etwas vom RAM-Kuchen abhaben wollen.

[Tintom]

Schade... Ideen?

Hast du den Post von hikaru gelesen und verstanden?

[jedie]

Grub startet auf meinem alten Pentium II System... Auf dem 468 kommt allerdings nur, nach einiger Ladezeit die Meldung "Read Error"
Laut https://gnu.huihoo.org/grub-0.90/html_c ... ub_13.html ist es ein "Stage 1" Fehler:

Read Error
A disk read error happened while trying to read the stage2 or stage1.5.

​Ah! Die selbe CompactFlash startet auf meinem 368er! Da sehe ich das grub menu. So wie es sein soll... Dauer zwar ein wenig, aber immerhin... Sehr cool.

Da Frage ich mich doch, was beim 486er falsch läuft... In dem Fall war es ein "Fujitsu Stylistic 1000"...

Wobei: Beim 368er nutzte ich "XTIDE Universal BIOS" -> http://www.xtideuniversalbios.org/ das könnte der Grund sein...


Zur älteren debian Version: Ja, das wäre natürlich auch eine Variante... Und ja: ein Kernel ist kein Linux. Schon klar. Aber zumindest auf einem 486er bekommt man einen aktuellen Kernel definitiv ans laufen, das zeigt https://www.insentricity.com/a.cl/283 Laut seinen Angaben war es der v5.8-rc2-1-g625d3449788f (Mir ist klar, das beim 386er definitiv nur 3.7.x geht.)

Aber: Ist es so, das ein modernes Linux mehr RAM braucht? Warum? Weil einfach nur mehr Zeugs gestartet wird? (Wobei da die Frage ist, was kann man alles abstellen?!? Und halt, wenn man wirklich alles bis auf die shell (busybox?) abgestellt hat, wie viel RAM braucht das prompt?) ... und eine weitere Frage: Wieviel RAM braucht der Python Interpreter um irgendein Mucks von dich zu geben?

[jedie]

Hab nun mal versucht potato per debootstrap einzurichten... Vergeblich.

Der eigentliche debootstrap funktioniert zumindest, wenn man die richtige URL zusammen hat:

debootstrap --arch=i386 potato /mnt http://archive.debian.org/debian-archive/debian/

Aber nach dem chroot weiß ich nicht mehr so ganz weiter...

Die Anleitung hab ich auch noch gefunden: https://www.debian.org/releases/potato/ ... ll.de.html

Offenbar wurde damals noch LILO genutzt. Aber damit kenne ich mich nicht mehr aus.

[Apfelmann]

Schau Dir mal bunsenlabs (hydrogen) an, ist ein installierbares Debian-Live-System (jessie - i386)

https://kelaino.bunsenlabs.org/ddl/Archive/

LG

[hikaru]

(jessie - i386)

Bei Angaben wie "i386" sollte man immer skeptisch sein, denn das bezeichnet oft nicht den minimalen Befehlssatz, sondern ist als Sammelbezeichnung für x86_32 zu verstehen. Der minimale Befehlssatz ist dann meist irgendwas von i486 bis i686.
Wie gesagt, Jessie unterstütze längst kein tatsächliches i386 mehr, sondern eingeschränkt noch i586. Und eine Distribution die darauf aufbaut kann das nicht sinnvoll ändern, sonst müsste sie nämlich das gesamte Repo recompilieren.

Ich hätte in meinem ersten Beitrag fast zu BSD geraten, aber zur Sicherheit hatte ich bei Free-, Open- und Net-BSD nochmal nachgeschaut, und auch die unterstützen heute keinen i386-Befehlssatz mehr.

[MSfree]

...und auch die unterstützen heute keinen i386-Befehlssatz mehr.

Zumindest sollte aber eine Distribution, die auf einem 80486 läuft, auch auf einem 80386 laufen, sofern dieser über einen 80387 Coprozessor verfügt.

Eine 80486-Distri wird wegen des fehlenden Coprozessors auch nicht auf einem 80486SX laufen.

Das Problem ist, daß der 80387 damals sehr teuer war und entsprechend selten auf den alten Mainboards vorhanden ist (der Sockel dafür ist in der Regel leer). Wer damals (zumindest ab 1989) einen Coprozessor brauchte, hat eigentlich gleich einen 80486DX gekauft, der war nicht teurer als ein 80386/80387-Gespann, aber deutlich schneller.

[hikaru]

Zumindest sollte aber eine Distribution, die auf einem 80486 läuft, auch auf einem 80386 laufen, sofern dieser über einen 80387 Coprozessor verfügt.

Ich bin zu jung um hier eigene Erfahrungen beisteuern zu können, aber rein von der Papierform her halte ich das für fragwürdig. Das würde nämlich bedeuten, dass i486-Software (Kernel+Userland) keine der zusätzlichen i486-Instruktionen [1] verwendet.
Bei den Übergängen i486-i586 und i586-i686 waren die Unterschiede in den Befehlssätzes durchaus relevant. Beim Ersten erinnere ich mich an CMPXCHG und beim Zweiten an CMOV und FCOMI.

[1] https://en.wikipedia.org/wiki/X86_instr ... with_80486

[jedie]

Dem schließe ich mich an. Aber davon mal ab: Mein 386er System hat einen 80387 Coprozessor drauf

Ich bin ein Stückchen weiter und hab nun ein bootfähiges system per debootstrap...

Hab nun das gemacht:

Code: Alles auswählen

...
debootstrap --arch=i386 --variant=minbase buster /mnt http://ftp.de.debian.org/debian/
...chroot...
apt install linux-image-686 sysvinit-core ...
...blkid >> /etc/fstab + anpassen...

Folgende Pakete hab ich dazu installiert:

Code: Alles auswählen

    grub-pc
    linux-image-686
    sysvinit-core

    console-common
    keyboard-configuration
    sudo

    memtest86+
    htop
    mc

Wenn es gebootet ist, zeigt htop 35MB Ram Auslastung an:



Also mit einem Rechner der 48MB hätte wäre das ja schon was... z.Z. hab ich aber nur ein 486er mit 24MB RAM... Einer kann vermutlich bis 64MB aufgerüstet werden...

Aber ich vermute mal, das kann man noch ein wenig kleiner machen: Ist die Frage ob man auf "systemd-udevd" verzichten kann?
Man kann sicherlich auch weniger TTY starten (Wo einstellen?)
Und bash durch was kleineres ersetzten?

Ist jetzt auch der standard kernel. Ich weiß nicht, wie viel RAM ein selbstgebauter einsparen würde?!?

[hikaru]

Wenn es gebootet ist, zeigt htop 35MB Ram Auslastung an:
[..]
Also mit einem Rechner der 48MB hätte wäre das ja schon was...

Da läuft aber noch kein Python-Programm. Wenn du das anschmeißt werden dir die Ohren schlackern - zumindest, wenn du um einzelne MB im RAM feilschen musst!

Und bash durch was kleineres ersetzten?

dash oder busybox.

[jedie]

Im dosreloaded.de Forum herrscht die Meinung das ein Debian auf einem 468er nicht laufen wird, weil die Programme auf i686 compiliert wurden und somit abstürzen werden... Somit reicht der bau eines Kernels nicht, wenn man keinerlei Programme starten kann...

Aber stimmt die Aussage?

Vermutlich kann man auf https://tests.reproducible-builds.org/d ... cible.html nachsehen, wie gebaut wurde, oder? Bin da kein Experte... Aber ich hab mal dpkg für i386 (buster) rausgesucht: https://tests.reproducible-builds.org/d ... /dpkg.html
Da sieht man u.a.: --build=i686-linux-gnu

Grundsätzlich gibt oder gab es --build=i386-linux-gnu

Dann stimmt die Annahme also? 486er ist raus, nicht nur wegen dem Kernel?

Also geht nur ein entsprechend altes Debian zu nehmen, was? Weiß jemand ab wann das umgestellt wurde?

EDIT: NetBSD und FreeBSD unterstützen 486, zumindest steht das hier:

https://wiki.netbsd.org/ports/i386/
https://www.freebsd.org/platforms/i386.html

Heißt doch aber auch, das sie langsamer sind, auf modernen Prozessoren die noch kein 64-Bit Modus haben, oder?

[DeletedUserReAsG]

Im dosreloaded.de Forum herrscht die Meinung das ein Debian auf einem 468er nicht laufen wird, weil die Programme auf i686 compiliert wurden und somit abstürzen werden. […] Aber stimmt die Aussage?

Für ein aktuelles Debian: Ja, wie du auch einfach selbst auf debian.org nachlesen könntest. Es würde allerdings nichts abstürzen, sondern es würde gar nicht erst booten – der Kernel ist genauso für i686 gebaut worden.

[hikaru]

@jedie:
Liest du meine Beiträge? Unter welchem Debian-Release welcher x86_32-Befehlssatz funktioniert, habe ich in meinem ersten Beitrag geschrieben - rudimentär auch mit Unterscheidung nach Kernel und Userland.

[Tintom]

Heißt doch aber auch, das sie langsamer sind, auf modernen Prozessoren die noch kein 64-Bit Modus haben, oder?

Halt, jetzt würfelst du ein paar Dinge durcheinander.
Keine der in diesem Thread genannten Architekturen hat einen 64-Bit Modus. Wir unterhalten uns hier ausschließlich über 32 Bit bzw. allgemein über die Architektur x86_32.
Und ganz allgemein gesprochen: Praktisch alle x86-Prozessoren, die in den letzten 15 Jahren gebaut wurden, verstehen 64 Bit. Für diese Prozessoren nimmt man aber bevorzugt keine Software, die für x86_32 gebaut wurde, sondern nimmt gleich Software für x86_64 (z.B. "amd64").

[hikaru]

Praktisch alle x86-Prozessoren, die in den letzten 15 Jahren gebaut wurden, verstehen 64 Bit. Für diese Prozessoren nimmt man aber bevorzugt keine Software, die für x86_32 gebaut wurde, sondern nimmt gleich Software für x86_64 (z.B. "amd64").

Wobei man das "Praktisch" aber als Relativierung hervorheben sollte. Intel hat mit den frühen Atoms noch vor 12 Jahren reine x86_32-CPUs hergestellt. Ich glaube, VIA hat das sogar noch länger getan.