[Eisfair] E1-32bit bonding, lilo - und der ganze rest...

Kay Martinen usenet at martinen.de
Mi Mär 22 22:55:29 CET 2023


Hallo

Ich habe jetzt mal meinen alten Homeserver raus gekramt der mit einem 
Atom N270, einem embedded board und einer 4 GB CF + HDD läuft und den 
aktualisiert. Wollte ich eigentlich nicht, nur das bonding-paket laden 
aber weil er es erst nicht fand mußte ich updaten. Und danach hat am 
bonding-paket über 100 MB an updates dran geklebt. :-/

Also hat das lahme Ding jetzt halt systemD. :) Teste ich halt...

Nachdem alle updates plus ein paar Reboots liefen jetzt die Probleme/Fragen:

Das Bonding-paket nimmt die IP der ersten NIC. Okay. Es scheint aber als 
ob deren IP dann immer noch an der ersten NIC klebt - und der bond die 
nur mit übernimmt. Ich würde die IP gern NUR auf dem bond0 haben. Also 
trage ich die in der bond Konfig ein und lösche sie in der base, in der 
ich die 2. NIC nicht eintrug. Funktioniert dennoch, aber die base-konfig 
meckert wegen der nicht vorhandenen IP bei der 1. NIC. Ich kann das dann 
übergehen und nicht noch mal editieren und es läuft auch nach reboot. 
Nur finde ich das unschön oder ggf. wacklig.

Eigentlich sehe ich keinen großen unterschied zwischen einem bond und 
einer bridge und bei der bridge würde ich wenn IP diese dann auf der 
Bridge haben wollen - und nicht auf einem slave-device.

Ist das update-fest so wie das mom. eingestellt ist oder zerreißt es das 
nächste Update weil in der base keine IP steckt?

Zweite Punkt. Der Atom N270 ist lt. lscpu nicht von den fehlern 
betroffen also wollte ich schauen ob und welche mitigations evtl. aktiv 
sind und sie dann mit 'mititations=off im Kernel aus schalten.

Nur... in /etc liegt nur eine lilo.conf-OLD. ??? WTF ist die lilo.conf 
denn jetzt geblieben? In /boot finde ich sie auch nicht.

Nebenbei würde ich gern ab boot einen anderen videomode setzen, so 
132+50 z.b. Auf die wird es nach dem booten schon gesetzt was die 
meldungen übersichtlicher macht (kein umbruch) aber bis dahin sieht's 
mist aus.

In dem Zusammenhang. In /boot liegen die initrd, die kernel 5.15.102 und 
5.15.64 sowie boot.0xxx und eine 'map' aber die system-map* dateien 
liegen im Wurzelverzeichnis. Kann man/ich die einfach nach /boot rüber 
schieben? Ich finde die gehören dort hin und nicht nach /

Zum Schluß. Kann man die ganzen Meldungen von systemd unterdrücken in 
denen er meckert das er keine unit fand und mittels sysv-generator 
on-the-fly eine zusammen gekloppt hat? So was interessiert mich beim 
booten eigentlich nur ein mal summarisch, danach sollte so was im log 
stehen. Finde ich.


Bye/
    /Kay

-- 
"Kann ein Wurstbrot die Welt retten?" :-)


Mehr Informationen über die Mailingliste Eisfair