alix1d bootet nicht mehr

[Florian Lohoff]

Hola,

On Sun, Jul 10, 2022 at 06:05:34PM +0200, HaJo wrote:
> Hallo,
> bei mir läuft ein alter alix1d als openvpn Server. Der bootet gerade nicht
> mehr Er bleibt am grub Prompt stehen. In dem Kleinstrechner ist eine AMD
> Geode CPU verbaut. lscpu listet den als i586.
> 
> Nun habe ich bereits versucht, den aus der Grub CLI zu booten.
> 
> set root=(hd0,msdos1)
> linux vmlinuz root=/dev/sdXY ro quiet splash
> 
> Hier kommt dann die Fehlermeldung: attempt to read or write outside of disk
> 'hd0'

Sicher das msdos1 deine root partition ist? Also /dev/sda1? Oder ist das
vielleicht swap?

> in der Root (/) sehe ich das Filesystem des alix, nur ist in /dev tatschlich
> kein blockdevice zu finden. Doof das...

Ist ja auch normal. /dev wird seid ÄONEN durch udev gemanaged (Davor
devfs, davor statisch) - D.h. /dev ist normalerweise ein tmpfs also ein
ram filesystem. Beim booten sind da durch die initrd nur ein ganz paar
device nodes angelegt, den rest übernimmt udev. 

Wenn man das via chroot macht muss man VOR dem chroot einige directorys
in das chroot rein-bind-mounten. 

Also - /target ist dein gemountetes system:

mount -o bind /sys /target/sys
mount -o bind /dev /target/dev
mount -o bind /proc /target/proc
chroot /target

Damit ist im /dev des targets das /dev deines livesystems also durch
das udev im livesystem befüllt.

Es gäbe noch /dev/pts, /dev/shm und /run aber die kann man hier mal
vernachlässigen weil die für den chroot nicht gebraucht werden.

> Na gut, habe ich ir gedacht. Dann also mit BootCD. Ich also in meiner
> Schublade gekramt und einige bootfhige CDs gefunden. Die x64 Versionen
> starten erwartunsgemß nicht. Es waenaber einige wenige 32 bittige dabei.
> Zuerst habe ich mit fsck die Platte geprüft. Die sieht gut aus. Dann wollte
> ich chroot machen und grub neu installieren.  Also:
> 
> mkdir /mnt/backup
> mount /dev/sda1 /mnt/backup
> mount -t proc proc /mnt/backup/proc
> mount -t sysfs sys /mnt/backup/sys
> mount -o bind /dev /mnt/backup/dev
> 
> chroot /mnt/backup /bin/bash
> 
> Dann kommt die Fehlermeldung: FATAL: kernel too old.
> 
> Hier weiss ich nicht weiter. Was ist denn nun zu alt? Die BootCD oder das
> System auf der Platte? Hat jemand einen Tipp?

Der kernel der läuft - Also der deines Rescue systems.

> Ich schreibe gerade die Platte zur Sicherung in ein image. Zur Not
> installiere ich neu und muss dann Stück für Stück alles restaurieren. Das
> ist echt viel Arbeit, die ich mir gern ersparen würde. Das kann ja
> eigentlich auch nur eine Kleinigkeit sein, oder? Ich sehe es aber nicht.
> Liebe Grüße

Das wird nicht notwendig sein. Dein Problem könnte sein das ein ganz
aktuelles Rescue System auch nicht mehr geht weil der Geode Support
irgendwann aus dem userspace geflogen ist IIRC. Ich meine 
das bei Debian die glibc mittlerweile für i686 gebaut wird.

Ubuntu und Redhat haben ein identisches Thema

https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186
https://bugzilla.redhat.com/show_bug.cgi?id=579838

Debian scheint mit Stretch noch funktioniert zu haben:

https://www.debian.org/releases/stretch/i386/release-notes/ch-whats-new.en.html#idm120

	"The 32-bit PC support (known as the Debian architecture i386) now
	no longer covers a plain i586 processor. The new baseline is the i686,
	although some i586 processors (e.g. the “AMD Geode”) will remain
	supported."

Bullseye geht nicht mehr:

https://www.debian.org/releases/stable/i386/ch02s01.en.html#idm186
 "However, Debian GNU/Linux bullseye will not run on 586 (Pentium) or earlier processors."


Ich habe sowas zum spielen - Geräuschlos - SSD, und 64bit CPU.

https://www.lapstore.de/a.php/shop/lapstore/lang/de/a/32723/kw/Fujitsu-Esprimo-Q556/

Flo
-- 
Florian Lohoff                                                     f at zz.de
  Any sufficiently advanced technology is indistinguishable from magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20220712/31408f97/attachment.sig>