Nach SuSE-Update: "ERROR: no hit for procs_bla"

[guru meditation]

Ich habe meinen Webserver mit SuSe 9.1 "einfach" auf'ne lokale Kiste gezogen (gleiche HDD), dann per SuSe 9.3 CD ein Update gemacht. Nach der Auswahl im Lilo Bootloader kommt nur noch abwechselnd die Meldung:


ERROR: no hit for procs_running
ERROR: no hit for procs_blocked

Was's das denn?

Ein Grund für diese Prozedur ist die: Ich kann beim vorhandenen 9.1 kein Kernel-Update machen, weil anschließend die Kiste nicht mehr hochfährt. Lokale Images fahren auf dem Webserver gar nicht erst hoch (kein Eintrag in /var/log).

[mceric]

Hi, ich habe das gleiche Problem: Beim Boot immer
"ERROR: no hit for procs_running" nach einem ftp-Update
von SuSE 9.0 auf 9.3. Es scheint zu helfen, Alt-Druck-s
1-2mal zu drücken. Vermutlich besserer Workaround ist:

/etc/sysconfig/boot editieren (interessant, dort kann man
auch "jeden Schritt vom User bestätigen lassen" und
"Flow Control mit Ctrl-S/Ctrl-Q" einschalten) und dort

RUN_PARALLEL="no"

setzen.

Beim Update gingen einige weitere Sachen schief, evtl.
weil ich mangels CD-Brenner nicht wie empfohlen erst
von der 60 MB Installations-CD von 9.3 gebootet hatte.
Ich musste zum Beispiel von Hand mkinitrd 1.2 installieren
(ich glaube sogar von rpmfind.net). Mein AMD K6-2 kriegt
von SuSE 9.0 normal einen nicht funktionierenden Athlon
Kernel verpasst, also von Hand den Defaultkernel wählen.
Bei der Kernel-Installation wird mit Grafiktreibermodulen
gespielt, also nochmal das RPM refreshen / installieren
sobald das Grafiksystem aktualisiert ist. Hinterher ggf. Lilo
laufenlassen nicht vergessen...

Der Umstieg auf xorg-x11 statt XFree86 ging auch nicht
so glatt: Ich habe von Hand die xorg-Pakete selektiert und
die XFree86-Pakete deselektiert. Hat einige "Diskussionen"
mit YaST gekostet, und der automatische Abhängigkeits-Test
dauert auf meinem PC doch ziemlich lange.

Sicherheitshalber wollte ich den k_deflt (2.4er Kernel) behalten.
Also vmlinuz und initrd in /boot kopiert. Leider habe ich das
Backup von /lib/modules/2.4... vergessen und musste hinterher
den 2.4er Kernel nochmal installieren (habe ich gleich drauf
gelassen dann). Der kernel-default (2.6er Kernel) mag mich
immernoch nicht. Zuerst hatte ich oft "Waiting for /dev/root
to appear" und dann einen Timeout und kein / gemountet. Woran
es zur Zeit liegt, weiss ich nicht. Bin gerade mit 2.4er Kernel und
einiger Handarbeit online:

Den 2.4er Kernel gestartet, mit Alt-Druck-e Dinge Abgebrochen
bis ich einloggen konnte, von Hand mount -a / swapon -a /
modprobe 8139too / ifconfig eth0 up / ifconfig eth0 192.168.1.99 /
route add default gw 192.168.1.1 / mit telinit zwischen S, 2, 3 und
5 hin und her gewechselt bis alle Services gut genug liefen / das
sbl (suse-blinux) Paket deinstalliert (rpm -e sbl) da es meine Maus
als Braille-Display behandeln wollte), und so weiter.

Ich habe von der 9.0 Boot-CD noch die /bin/*mod* und /sbin/*mod*
Kernelmodul-Tools als dateiname.old auf mein System kopiert, da
sonst der 2.4er Kernel nicht mit Modulen arbeiten kann (die modutils
vom 2.6er Kernel sind nur für 2.6er, rufen aber ggf. automatisch
dateiname.old auf). Praktisch ist auch cat /proc/modules ...

Beim 2.6er Kernel hatte ich teilweise ein leeres /proc/partitions
glaube ich (mit cat und echo statt ls kommt man nicht so weit...).
Ausserdem verwendet 2.6 ein /sys Dateisystem, was ich bei 2.4
nicht habe, wodurch wohl die SuSE initrd Erzeugung nicht hinhaut?
Ich habe das alte mkinitrd aufbewahrt, aber das neue mkinitrd
klappt halbwegs für 2.4er Kernel nach Boot von der 9.0 CD2 als
rescue system (mounten von / und /var und /usr unter /mnt/...)
und zwar: mkinitrd -k vmlinuz-2.4.21-99-default
-i /mnt/root/tmp/my-initrd -d /dev/hda2 -t /mnt/root/tmp /mnt/
wobei ich ein /root/tmp auf meiner Linux-Partition hda2 habe...
Leider erzeugt mkinitrd manchmal keine initrd aber zeigt auch
keine entsprechende Fehlermeldung: Also immer schauen, ob die
Datei wirklich aktualisiert wurde. Hinterher wieder Lilo starten...

Was mich als DOS user an SuSE 9 ärgert: Man kann zwar FAT16
Partitionen erzeugen bei der Installation, aber diese sind mit
fdisk als FAT32 markiert! Nur das mkdosfs Argument wird von SuSE
korrekt auf FAT16 gesetzt. Also wieder von Hand nacharbeiten.
FreeDOS kann zwar auch FAT32, aber fdisk-Daten und Dateisystem
sollten schon zusammenpassen.

[mceric]

Hi, der vorige Beitrag beschreibt meine Tricks, um mit
Kernel 2.4 ins System zu kommen. Natürlich hätte ich
gerne Kernel 2.6 genommen, aber ich bekomme immer
Fehlermeldungen wie "Waiting for /dev/root to appear"
(gibt ziemlich schnell auf, und dann sitze ich in der initrd
und kann keinerlei Partitionen mounten, /proc ist da sehr
pessimistisch)... Woran kann das liegen? Fehlen Module
in der Initrd? Wie kriege ich das von 2.4 aus hin? Kann
nämlich nicht von 2.6 booten (sag bloss!) aber die SuSE
2.6er Kernel-Installationsskripte (laufen bei der rpm-
Installation) wollen auf /sys zugreifen, was nur in 2.6
Systemen vorhanden ist. Argh!

Ich kann mir auch keine 9.3er Boot-CD brennen mangels
Brenner. Dabei sind sogar alle ISOs online:
http://www.linux-schulserver.de/Article137.phtml
Mein Update lief per FTP mit YaST2, ca. 3.2 GB Daten...
man muss bei der Serverangabe kein / am Anfang des
Verzeichnisnamens haben. Also nimmt man z.B.:

ftp
134.76.11.100
pub/linux/suse/ftp.suse.com/suse/i386/9.3/

Sonst bekommt man einen Fehler über das "Medium".
Ausserdem muss mindestens eins der Quellmedien
echt eine CD oder gemountetes CD-Image sein, wegen
der .sel Dateien ("proposals"). Habe mit der 9.0 CD
angefangen und später das 60MB 9.3 boot ISO dazu
gemountet... A propos, warum ist bei 9.0 nur die 2.CD
richtig bootbar? Die 1.CD hängt bevor Lilo startet schon.

Hoffentlich helfen meine Erfahrungen ein paar Usern...

Eric

[mceric]

Endlich...!
Mein System lebt jetzt mit X.org (ging direkt aber emiclock
von SuSE 6.4 geht nicht mehr, andere Cursor-Interfaces?)
und mit 2.6er Kernel :-) ... Der 2.4er Kernel war ja keine
so tolle Kombination mit SuSE 9.3, aber erst mal der 1zige
Kernel, den ich nach dem Update von 9.0 überhaupt in
Gang gekriegt habe.

Hier also einige Erfahrungen von meinen Versuchen:
Komischerweise waren irgendwann einige /dev/hda*
weg. Die habe ich dann mit mknod -m 660 hdaX b 3 X
wieder erzeugt, wobei X die "fehlende Zahl" ist.

Der TRICK mit den 2.6 Kerneln ist, dass man in
/etc/sysconfig/kernel in INITRD_MODULES neuerdings
sogar Module für IDE Controller laden muss. Auf meinem
System habe ich nach längerem Überlegen folgenden
Eintrag, alles auf 1 Zeile in der obengenannten Datei:
INITRD_MODULES="ide-core ide-generic via82cxxx cdrom
ide-disk ide-cd reiserfs fat vfat msdos jbd ext3 nls_cp437
nls_iso8859-1 nvram msr cpuid edd 8139too mii parport
parport_pc lp"

Also IDE, dazu der UDMA Treiber für meinen via82cxxx
Chipsatz, diverse allgemeine Laufwerks- und Dateisystem-
treiber (sonst geht das Mounten beim Boot schief... jbd
wird für ext3 benötigt, und fat/vfat/msdos/nls* hängen
auch zusammen), dazu Druckerport und Realtek 8139
(und mii) standard Netzwerktreiber.

Da ich eine klassische serielle Maus habe, hatte ich mit
SuSE Blinux Probleme (wollte in der Maus ein Braille-
display suchen). Also mit rpm -e sbl Blinux deinstalliert.

Hotplug wollte nicht mehr starten. Mit "strace -ff -eexecve
rchotplug start" bin ich dann auf die Idee gekommen, die
Schuld bei fstab zu finden: Was bei 2.4 noch usbdevfs war
heisst bei 2.6 offenbar usbfs. Ausserdem hat 2.6 ein sysfs,
was von manchen Skripten verwendet wird. Also 1 Zeile
in fstab aktualisiert und 1 Zeile zugefügt. Damit habe ich
an virtuellen Dateisystemen:


/dev/hda11 swap swap pri=42 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
proc /proc proc defaults 0 0
sysfs-foo /sys sysfs defaults 0 0
usbdevfs-foo /proc/bus/usb usbfs noauto 0 0


Natürlich musste ich nach der Korrektur der INITRD
MODULES Variable nochmal mkinitrd und dann nochmal
lilo starten. Ich glaube bei Grub statt Lilo als Bootlader
braucht man nur nochmal mkinitrd laufen lassen und
braucht Grub nicht nochmal zu starten.

Mit gemountetem /sys /proc /proc/bus/usb gingen dann
auch wieder der network und der hotplug Dienst. APM
geht nicht, hat der Kernel scheinbar nicht. ACPI Throttle
geht auch nicht, da das BIOS behauptet, es ginge nicht
(also cpuspeed / powersaved skipped). Mit FDAPM in DOS
geht Throttle aber (Nachteil: Wenn das BIOS wegen zu
hoher Temperatur gedrosselt hat, kann FDAPM wieder auf
vollen Takt schalten...). Vielleicht kann ich irgendwann
mit der DSDT / FADT Override Funktion (in /etc/sysconfig/
kernel...) Linux überzeugen, zu throttlen... ;-).

In der Zwischenzeit verwende ich mein böses throttle.c
mit hardcoded ACPI I/O Port. Geht also so nur auf meinem
VP3/MVP3 Mainboard und nur in der aktuellen PCI Config!

Bisher sieht SuSE 9.3 gut aus. Loggt mich auch hoffentlich
nicht mehr so oft spontan aus wie SuSE 9.0 mit XFree86 4.3
das getan hat... :-D

Eric

[mceric]

So. Hier übrigens das Throttle Programm. Use at your
own risk and know what you are doing...

Irgendwo in /proc/acpi/fadt kann man den Port finden.
Oder man fragt hwinfo --pci, dort steht bei mir dann:

SysFS BusID: 0000:00:07.3
Hardware Class: bridge
Model: "VIA VT82C586B ACPI"

In /proc/ioport finde ich ausserdem:
5000-50ff : 0000:00:07.3
5000-5003 : PM1a_EVT_BLK
5004-5005 : PM1a_CNT_BLK
5008-500b : PM_TMR
5020-5023 : GPE0_BLK
5040-5045 : via-i2c

Leider kenne ich keine Anwendung von via-i2c, aber
hwinfo empfiehlt den Treiber... Vermutlich kann man
damit dann die Lüfterdrehzahl lesen oder so?
Was aber funktioniert:

acpitbl /proc/acpi/dsdt /proc/acpi/fadt

PM1a_EVT_BLK: 0x00005000
-- also ist die ACPI Basisadresse 0x5000.
DUTY_OFFSET: 1
DUTY_WIDTH: 3
-- also sollte duty width control (throttling) gehen.
Trotzdem zeigt
cat /proc/acpi/processor/CPU0/throttling
nur "not supported" an. Seltsam.
modprobe acpi und modprobe powernow-k6 sind
auch nicht erfolgreich.

Also selbermachen, mit dem angehängten Tool :-)
... Die Zeile

movw $0x5010,%%dx ; // processor control port for my PC

muss ggf. von 0x5010 auf EURE_ACPI_BASISADRESSE_PLUS_0x10
geändert werden, ausserdem sind die DUTY_... Werte fest
eingestellt. Zum Glück sind aber die Werte 1 und 3 sehr weit
verbreitet...

Anwendung ist denkbar minimalistisch:

"throttle 8" setzt das System auf Normalgeschwindigkeit,
"throttle 4" auf 4/8 also 50% der Normalgeschwindigkeit.
Langsamste Einstellung ist "throttle 1". Maximum ist 8.

Viel Spass beim Pfuschen :-D ... Das Tool funktioniert mit
allen Kerneln der 2.2, 2.4 und 2.6 Familie, da es direkt ohne
grosse Hilfe vom Kernel am Chipsatz rummacht :cool: (dafür
kann es natürlich auch im Prinzip Chaos erzeugen, wenn
andere Linux Funktionen gleichzeitig auch die Geschwindigkeit
regeln wollen :rolleyes: - kommt aber praktisch nie vor :) ).

Eric