[gelöst]amd64-Install. von Ubuntu kein Prob, aber von Debian

[Juglans]

Wenn ich von meinem installierten amd64-Ubuntu-System amd64-Debian per debootstrap installiere und dann Debian boote, bricht der Debian-Kernel beim Booten während der ersten zwei, drei Sekunden ab.
Liegt das an meinem Prozessor (Pentium(R) Dual-Core CPU T4200 @ 2.00GHz)? Oder an der Installation per debootstrap?
Jegliche Hinweise sind willkommen.

Guten Rutsch!

Mike

[gms]

Willkommen im Forum!

Wenn ich von meinem installierten amd64-Ubuntu-System amd64-Debian per debootstrap installiere und dann Debian boote, bricht der Debian-Kernel beim Booten während der ersten zwei, drei Sekunden ab.

"zwei, drei Sekunden" ist eine sehr lange Zeitspanne, was das Booten betrifft, eigentlich sollte/könnte hier schon der init-Prozeß am Werk sein

Liegt das an meinem Prozessor (Pentium(R) Dual-Core CPU T4200 @ 2.00GHz)? Oder an der Installation per debootstrap?

an dem Prozessor liegt es mit sehr großer Wahrscheinlichkeit nicht

Jegliche Hinweise sind willkommen.

hast du vielleicht für uns noch irgendwelche Hinweise ? z.B Fehlermeldungen oder andere Meldungen, die auf dem Bildschirm auftauchen

Gruß
gms

[Juglans]

Es ist etwas schwierig, weil keine log-Datei geschrieben wird. Eine der letzten Meldungen lautet "running scripts/init-bottom". Die letzte Meldung liegt dann vier Zeilen darunter, d.h. es gibt noch drei weitere Meldungen, die ich in der Kürze der Zeit aber nicht entziffern kann.
Bisher war meine /etc/fstab leer, ich habe sie jetzt mit den Angaben für /, proc und swap gefüllt, ohne dass sich da was ändert.
Mir kommt es trotzdem so vor, als ob der Kernel keine Festplatte findet.
Wenn ich jedoch dem Kernel die root-Partition mit "root=/dev/hda1" statt "root=/dev/sda1" angebe, hängt sich der Kernel mit "Begin: Waiting for root file system ..." auf. Also sollte "root=/dev/sda1" im Grub schon richtig sein.

Alles Gute im neuen Jahr,

Mike

[gms]

Mir kommt es trotzdem so vor, als ob der Kernel keine Festplatte findet.

bei init-boottom sollte die root-Partition schon gemountet sein ( siehe "man initramfs-tools" ), eigentlich müßte er danach procfs und sysfs mounten und /sbin/init aufrufen haben. Probiere einmal ob du mittels "init=/bin/bash" Kernel Parameter eine Shell bekommst und welche Devices dort schon gemountet sind, testweise kannst du von dieser Shell auch manuell das init-Kommando absetzen

Gruß
gms

[Juglans]

Ich komme tatsächlich auf eine Shell.
"init 2" gibt aber "/dev/initctl: No such file or directory".
"mkfifo /dev/initctl" behebt das letztgenannte Problem nicht.

Gruß Mike

[gms]

Ich komme tatsächlich auf eine Shell.

ok, dann lauft irgendwas beim System V init schief

"init 2" gibt aber "/dev/initctl: No such file or directory".
"mkfifo /dev/initctl" behebt das letztgenannte Problem nicht.

Damit wollte ich eigentlich nur sehen, ob ein init-Prozeß erstellt werden kann ( alle benötigten Libraries gefunden werden )

( Mit "init 2" startest du nur einen Prozeß der dem init-Hauptprozeß den Wechsel zu Runlevel 2 nahelegen soll. Das geht aber nicht weil der init-Hauptprozeß noch nicht gestartet wurde und daher auch nicht /dev/initctl anlegen konnte. )

ist in "/etc/default/rcS" das "VERBOSE=yes" eingetragen ? Warum kannst du die nachfolgenden Meldungen eigentlich nicht lesen ? Wird nachher gleich rebootet, oder wird der Bildschirm schwarz, oder wird nachträglich so viel Müll rausgeschrieben ?

Gruß
gms

[Juglans]

Der Rechner startet sofort neu.

Gruß Mike

[gms]

probier einmal ob "panic=10" als zusätzlichen Kernel Parameter dir mehr Zeit zum Lesen der Meldungen verschafft

[Juglans]

Mehr Text durch verbose=yes, aber nicht mehr Zeit.
(Ich habe jetzt den Monitor gefilmt)

Files under mount point "/lib/init/rw" will be hidden ... (warning).
Starting the hotplug events dispatcher: udevd udev: start
on 149
.
Synthesizing the initial hotplug events ... done.
Waiting for /dev to be fully populated ... _

[gms]

hier sind wir also im /etc/rcS.d/S03udev Script, wenn du dort nach "udevd --daemon" suchst und die beiden Optionen "--debug-trace --debug" hinzufügst, solltest du weitere Meldungen sehen

[Juglans]

Really great!

Ich habe im /etc/rcS.d/S02udev nicht nur die angegebenen Optionen eingefügt, sondern auch ein "exit 1" nach jeder Änderung. Und siehe da, der Rechner bootet weiter. Der Fehler scheint also in der Umgebung dieses Scripts zu liegen.
Ein Lichtstrahl am Horizont.
Die jetzt vorhandenen Fehlermeldungen kommen in Kürze!

Gruß Mike

[gms]

Die jetzt vorhandenen Fehlermeldungen kommen in Kürze!

nachdem Bootlog erst nach dem Udev gestartet wird, könnte ein derartiges Konstrukt helfen die Meldungen vom Udev mitzuloggen:

Code: Alles auswählen

    if udevd --daemon --debug-trace --debug 2>&1 | tee /boot/S03udev.log; then

[Juglans]

Vielen Dank.

if udevd --daemon --debug-trace --debug 2>&1 | tee /boot/S03udev.log; then

Wo soll die Zeile hin?

Ich habe jetzt mit meiner Exit-Strategie das Problem etwas eingegrenzt:

log_daemon_msg "Starting the hotplug events dispatcher" "udevd"
if udevd --daemon; then
log_end_msg $?
else
log_end_msg $?
fi

mkdir -p /dev/.udev/queue/ /dev/.udev/rules.d/
create_dev_root_rule /dev/.udev/

hier ein "exit 1", und der Rechner bootet

log_action_begin_msg "Synthesizing the initial hotplug events"
if udevadm trigger; then
log_action_end_msg $?
else
log_action_end_msg $?
fi
hier ein "exit 1", und das Rechner bricht das Booten ab.
Es scheint am "udevadm trigger" zu liegen, was immer das auch ist.

[Juglans]

#log_action_begin_msg "Synthesizing the initial hotplug events"
#if udevadm trigger; then
#log_action_end_msg $?
#else
#log_action_end_msg $?
#fi

Auch, wenn ich "udevadm trigger" auskommentiere, statt das Script abzubrechen, bootet der Rechner.

Gruß Mike

[Juglans]

Wenn ich nur /lib/udev/rules.d/80-drivers.rules verschiebe, ohne /etc/rcS.d/S02udev zu verändern, bootet der Rechner auch.

[gms]

Interessant wäre es zu wissen, was der Udevd gerade anstellt, wenn der Crash ( bzw Reboot ) ausgelöst wird.
Daher wäre die Ausgabe vom Udevd mit diesen zusätzlichen Optionen interessant:

--debug-trace
Run all events completely serialized. This may be useful if udev triggers actions or loads kernel
modules which cause problems and a slow but continuous operation is needed, where no events are
processed in parallel.

--debug
Print debug messages to stderr.

Die Optionen "--debug" und "--daemon" widersprechen sich aber eigentlich, und das Verhalten vom Udevd, wenn beide Optionen angegeben werden ist nicht dokumentiert. Daher schlage ich folgende Änderung vor:

Code: Alles auswählen

if udevd --daemon; then
log_end_msg $?
else
log_end_msg $?
fi

ersetzen durch

Code: Alles auswählen

nohup udevd --debug --debug-trace 2>/boot/S03udev.log &

( kommt mehrmals in dem Script vor )

[Juglans]

Welche Treiber werden denn hier von 80-drivers.rules geladen?

Code: Alles auswählen

ENV{MODALIAS}=="?*",                   RUN+="/sbin/modprobe -b $env{MODALIAS}"

Wenn ich diese Zeile auskommentiere, kann ich booten.

[Juglans]

Ich habe /etc/rcS.d/S02udev wie vorgeschlagen geändert.
Dadurch bootet der Rechner. Ich nehme an, weil "udevd --daemon" verschwunden ist.
Wenn ich es richtig verstehe, soll in /boot eine Datei mit den Fehlermeldungen sein (/boot/S03udev.log). Eine solche Datei gibt es aber nicht.

Habe ich es außerdem richtig verstanden, dass udev über die Datei 80-drivers.rules notwendige Gerätetreiber in den Kernel lädt und bei mir einer der Treiber nicht mit meiner Hardware kompatibel ist?

[gms]

Dadurch bootet der Rechner. Ich nehme an, weil "udevd --daemon" verschwunden ist.

hm, die Option "--daemon" und die Kombination "nohup ... &" sollten so ziemlich das Gleiche bewirken. Der Prozeß wird "detached" und in den Hintergrund geschickt
die neue Option "--debug-trace" bewirkt eine Serialisierung aller Events und hat wahrscheinlich einen größeren Einfluß.
Wenn der Rechner mit diesen Optionen reproduzierbar bootet, dann probiers einmal ohne "--debug-trace"

Wenn ich es richtig verstehe, soll in /boot eine Datei mit den Fehlermeldungen sein (/boot/S03udev.log). Eine solche Datei gibt es aber nicht.

Dieses Verhalten kann ich mir überhaupt nicht erklären, die Datei sollte eigentlich schon angelegt werden, bevor der Udevd überhaupt gestartet wird und wenn dieser nichts rausschreibt, sollte diese Datei leer bzw die Startmeldung von "nohup" geschrieben worden sein ( "nohup: ignoring input and appending output to `nohup.out'" )
Kannst du deine Änderungen bitte nochmals überprüfen, bzw wenn /boot eine eigenständige Partition ist, dann verwende bitte ein anderes Verzeichnis ( das Homeverzeichnis von root )

Habe ich es außerdem richtig verstanden, dass udev über die Datei 80-drivers.rules notwendige Gerätetreiber in den Kernel lädt und bei mir einer der Treiber nicht mit meiner Hardware kompatibel ist?

da bin ich mir noch nicht ganz sicher, es deutet aber sicherlich einiges darauf hin. Allerdings bekommst du anscheinend auch keine "kontrollierte" Kernel Panic, sonnst hätte der Kernel Parameter "panic=10" etwas bewirkt

[Juglans]

Code: Alles auswählen

nohup udevd --debug --debug-trace 2>/boot/S03udev.log &

legt in einer Shell (unter Ubuntu) klaglos die gewünschte Datei an und schreibt die entsprechende Meldung in die Datei, nicht aber beim Booten von Debian.
Auch ohne "--debug-trace" bootet Debian übrigens mit der geänderten /etc/rcS.d/S02udev.
Der Debian-boot-Ordner liegt nicht auf einer anderen Partition.

[Juglans]

Wenn ich auf das Grundsystem xorg installiere, ändert sich das Verhalten nicht. Sobald jedoch gdm und gnome-core dazu kommen, stürzt der Rechner wie gehabt ab, und zwar reproduzierbar, egal ob mit originaler oder veränderter Datei /etc/rcS.d/S02udev.

Gruß Mike

[Juglans]

Wie kann ich am besten kontrollieren, welche Treiber während des Bootvorgangs geladen werden?

Gruß Mike

[gms]

Wenn ich auf das Grundsystem xorg installiere, ändert sich das Verhalten nicht. Sobald jedoch gdm und gnome-core dazu kommen, stürzt der Rechner wie gehabt ab

beim Starten vom GDM ?
Was hast du eigentlich für eine Grafikkarte ? Welcher Treiber wird dafür in Ubuntu verwendet ? Vielleicht sollten wir den Kernel Upgraden

[Juglans]

KDE kann ich installieren und komme beim Booten bis zum kdm, dann friert der Rechner ein.
kdm.log sagt

Code: Alles auswählen

X.Org X Server 1.6.5
Release Date: 2009-10-11
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.30-2-amd64 x86_64 Debian
Current Operating System: Linux mike 2.6.30-2-amd64 #1 SMP Fri Sep 25 22:16:56 UTC 2009 x86_64
Build Date: 13 October 2009  09:39:10AM
xorg-server 2:1.6.5-1 (jcristau@debian.org) 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan  3 11:26:46 2010
(==) Using default built-in configuration (30 lines)
(EE) open /dev/fb0: No such file or directory
SELinux: Disabled on system, not enabling in X server

Als Kernel habe ich für die Versuche der letzten beiden Tage 2.6.30-2-amd64 verwendet, vorher den 2.6.32-trunk.
Meine Grafik: GeForce 9300M GS

[Juglans]

Wenn ich gdm und gnome installiere, stürzt der Rechner nicht beim Starten von gdm ab, sondern an der üblichen Stelle, also vorher.