[gelöst] 2. Installer zerschrotet 1. Installation

[TomL]

Moin @ all

Ich wollte`heute abend auf einer kleinen Partition der Festplatte (sdb) ein zusätzliches LXDE installieren. Auf der SSD (sda) ist mein normales Stretch installiert. Die Installation lief problemlos durch, den Punkt "Bootloader installieren" habe ich übersprungen. Ich hatte vor, nach der Installation vom primären Stretch auf sda ein grup-update zu machen. Nun ja, der aktuelle Stand ist, die zweite Installation ist fehlerhaft, und die erste Installation wurde angepackt und bootet nicht mehr sauber. Wie kann das sein, was treibt der Installer mit bestehen Installationen? Ich habe mir mal das Bootlog des Systems von sda angeehen, das hängt 45 Sekunden beim Kernel, erst dann wird als nächstes systemd gestartet, zwischenzeitlich meldet sich der Monitor ohne Signal ab.

Ich hab ja mittlerweile ungezählte Male installiert, und ich bin sicher, dass ich mich nirgends vertan habe. Es scheint so, als würde der Installer irgendwas machen, was er nicht darf, da er ganz offensichtlich sda angepackt hat, obwohl ich nur auf sdb installiert habe.

Hat jemand ne Idee, was das sein kann?

[smutbert]

Klingt möglicherweise so, als ob der Installer swap formatiert und das daher eine neue UUID erhalten hätte. Testweise kannst du mit der Kerneloption noresume booten und wenn da die Wartezeit entfällt die uuid in fstab und /etc/initramfs/conf.d/* prüfen und »update-initramfs -u« ausführen, damit die initrd von der richtigen uuid erfährt.

Was allerdings nicht dazu passt ist der dunkle Monitor.

[schwedenmann]

Hallo

ein zusätzliches LXDE installieren.

Wir sind zwar hier im DF, aber es kann ja trotzdem sein, das du kein Debian installiert hast ?


Wenn dem so ist, kann es manchmal Probleme mit der Option (ohne Bootloader) geben.

mfg
schwedenmann

[TomL]

Moin @ all

Wir sind zwar hier im DF, aber es kann ja trotzdem sein, das du kein Debian installiert hast ?

Doch, es war Debian 9. Andere Distris finden bei mir nur den Weg in eine VM.

Klingt möglicherweise so, als ob der Installer swap formatiert und das daher eine neue UUID erhalten hätte. Testweise kannst du mit der Kerneloption noresume booten und wenn da die Wartezeit entfällt die uuid in fstab und /etc/initramfs/conf.d/* prüfen und »update-initramfs -u« ausführen, damit die initrd von der richtigen uuid erfährt.
Was allerdings nicht dazu passt ist der dunkle Monitor.

Das war die Ursache und gestern abend ein ziemlich unerfreuliches Erlebnis. Die Falschdeutung der Symptome enstand dadurch, weil ich durch die SSD eigentlich gewohnt bin, dass alles blitzschnell reagiert. Ich habe den Rechner neu gestartet, und nicht nur das nach Grub nix mehr passierte, der Monitor hat sich mangels Signal auch noch abgeschaltet. Ich habe das dann als "einfrieren" interpretiert, deswegen neu gestartet und versucht über das Grub-Menu anders vorzugehen. Nach etlichen erfolglosen Versuchen hab ich irgendwann einfach nur ratlos auf den Monitor gestiert und wusste nicht mehr weiter.... und plötzlich wird die Monitor-LED blau und das Anmeldebild ist da. Der hat also einfach seinen Timeout bezgl. seines Swap abgewickelt, ich hätte zuvor also einfach nur warten müssen. Aber wie gesagt, ich hatte das fälschlicherweise als totales einfrieren gedeutet.

Weil das Grub-Menu durch die 3 Setup-Fehlversuche (dazu ein neuer Thread) mittlerweile strubbelig war, habe ich es von meinem primären D9 versucht es zu reparieren:

Code: Alles auswählen

grub-install /dev/sda
grub-install --recheck /dev/sda 
update-grub 

Ob das jetzt in dieser Form so notwendig war, weiss ich nicht, aber es war erfolgreich - danach waren jedenfalls nur noch die zwei tatsächlich vorhandenen Installationen im Grubmnü enthalten. Ist dieses Vorgehen so ok?

Allerdings verstehe ich nicht, was ich mit »update-initramfs -u« gemacht habe, bzw. was das bewirkt. Ich hatte zuvor einfach in der Datei /etc/initramfs-tools/conf.d/resume die neue UUID der Swap-Partition von Hand eingetragen. War das richtig oder wäre das durch den Update-Befehl sowieso passiert?

Und wieso überhaupt initramfs? Ich habe versucht, die Zusammenhänge über die Manpage und diverse Websites zu verstehen. Dabei habe ich gelesen, dass initramfs der Nachfolger von initrd ist.... ok, soweit so gut... aber auf meinem Stretch scheint unverändert initrd zu leben.

Code: Alles auswählen

ls /init*
lrwxrwxrwx 1 root root 29 2017-10-09 09:47 /initrd.img -> boot/initrd.img-4.9.0-4-amd64
lrwxrwxrwx 1 root root 29 2017-10-09 09:47 /initrd.img.old -> boot/initrd.img-4.9.0-3-amd64

Wieso also initramfs, wenn doch immer noch initrd "aktiv" ist. Im Moment fehlen mir einfach die Zusammenhänge, um das zu verstehen, um vielleicht später bei einer neuen Baustelle zielgerichtet selber die Probleme lösen können. Ich hatte mich wegen dem für mich ziemlich mysteriösen Bootvorgang bisher auch noch nie so richtig damit befasst - und allein mit lesen komme dabei selber nicht weiter. Kann man das mit einfachen Worten und relativ kurz in 2,3 oder 5 Sätzen erklären?

[smutbert]

initramfs-tools sind die Werkzeuge, die automatisch eine initrd für installierte Kernel bauen, damit der Kernel von Hardware und Dateisystemen starten kann, deren Treiber nur als Module und nicht in den Kernel einkompiliert zur Verfügung stehen, was der Normalfall ist.

Bis der Kernel genügend Treiber für die echte Hardware und die Dateisysteme zur Verfügung hat fungiert die initrd also als /-Dateisystem samt eigenem init, das noch vor dem init-System der eigentlichen /-Partition gestartet wird.
Zusätzlich erkennt die initrd, wenn ein Suspend2disk durchgeführt und der ehemalige Speicherinhalt auf der swap-Parition geschrieben wurde. In dem Fall startet die initrd das Wiederherstellen der letzten Sitzung. Damit das funktioniert wird die UUID der swap-Partition in die initrd geschrieben und wenn die swap-Partition (oder die /-Partition oder etwas anderes wichtiges) fehlt, dann wartet die initrd eben bis zu einem Timeout ob das Dateisystem nicht doch noch im System auftaucht.

Dass es obendrein eine Konfigurationsdatei mit der uuid der swap-Partition in »/etc/initramfs-tools/conf.d/« gibt ist eigentlich nicht notwendig – update-initramfs schreibt auch ohne diese Konfigurationsdatei die UUID der ersten swap-Partition in die initrd, was es auch kund tut:

Code: Alles auswählen

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.13.0-0.bpo.1-amd64
I: The initramfs will attempt to resume from /dev/sdb2
I: (UUID=xxxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxx)
I: Set the RESUME variable to override this.

du kannst die Datei also auch löschen, dann hätte es genügt, lediglich die initrd neu zu schreiben.
(Auch ein fstab-Eintrag für swap ist nicht nötig, weil systemd swap-Partitionen automatisch aktiviert, zumindest meistens.)

afaik kann man im Installer auch festlegen, dass swap-Partitionen nicht neu formatiert werden sollen.
An der ganzen Geschichte würde mich an deiner Stelle am meisten stören, dass du offensichtlich die Meldungen von der initrd nicht zu sehen bekommst, weil der Monitor dunkel bleibt. Was hast du denn für eine Grafikkarte?

[TomL]

Danke, das waren jetzt einige Infos, mit denen mir vieles klarer geworden ist. Ich hatte mich zuvor noch nie damit befasst und hatte keine brauchbare Vorstellung über die Abläufe beim Boot.... was ja für mich als normaler User meistens auch nicht so wichtig ist... na ja, solange es halt keine Probleme gibt.

afaik kann man im Installer auch festlegen, dass swap-Partitionen nicht neu formatiert werden sollen.

Beim ersten Fehlversuch hatte ich natürlich "mit" ausgewählt und schlichtweg nicht dran gedacht, dass das auch Auswirkungen auf mein normales D9 haben wird. Beim zweiten Versuch habe ich im Installer-Partitionsmenü bewusst die Auswahl der Swap-Partition dem Installer überlassen. Er hat die korrekte ausgewählt, aber ich vermute, Formatierung gehört dann zum Default-Verfahren. Ich müsste jetzt noch mal ne dritte Variante starten, mit manueller Vorgabe der Swap-Partition, aber "nein" zur Formatierung. *hmmmm*... aber nach dem Heckmeck von gestern trau ich mich nicht, mir wieder das Grub-Menü kaputt zu machen.

An der ganzen Geschichte würde mich an deiner Stelle am meisten stören, dass du offensichtlich die Meldungen von der initrd nicht zu sehen bekommst, weil der Monitor dunkel bleibt. Was hast du denn für eine Grafikkarte?

Keine externe. Da es bei mir nur ein Office-PC ist und auch sein soll, nutze ich nur die OnBoard-Grafik, was wirklich für alle meine Bedürfnisse bisher ausreichend war: ASRock B150M-HDVD3. Aber ich kriege auch sonst im Gegensatz zu früher kaum noch Bootmeldungen. Das Grub-Menü schließt sich, dann ein kurzer schwarzer Bildschirm, dann ist das Anmelde-GUI da.... alles in wenigen Sekunden.

[smutbert]

Ja, dass man normalerweise nicht viel von den Meldungen mitbekommt kenne ich auch, aber doch nicht bei einem 45sekündigen Timeout...

Etwas was ich auf PCs mit integrierter Intel-Grafik gewohnheitsmäßig mache, auch wenn es zur Darstellung der Meldungen eigentlich nicht notwendig sein sollte, aber immerhin sorgt es bereits früher im Bootvorgang für die richtige (hohe) Auflösung, ist das Hinzufügen des Kernelmoduls i195 zur initrd:
Eine Zeile mit

Code: Alles auswählen

i915

an die »/etc/initramfs-tools/modules« hängen und hinterher die initrd wieder neu bauen lassen

Code: Alles auswählen

# update-initramfs -u

[TomL]

Führt das Vorgehen über die initramfs zu einem anderen Ergebnis, als ich damals im Februar beim Setup gemacht habe?

Code: Alles auswählen

apt install intel-microcode

Und aktuell:

Code: Alles auswählen

lsmod | grep i915
i915                 1232896  3
drm_kms_helper        155648  1 i915
drm                   360448  4 i915,drm_kms_helper
video                  40960  1 i915
i2c_algo_bit           16384  1 i915
button                 16384  1 i915

Ich verstehe das jetzt so, dass das Kernelmodul bereits geladen ist.

[smutbert]

Die Microcodeupdates haben erst einmal nichts mit den Kernelmodulen zu tun.

Dass der Treiber so oder so geladen wird, steht außer Frage, aber er kann natürlich erst geladen werden, wenn der Kernel das Dateisystem lesen kann auf dem das Kernelmodul liegt.
Mein Gedanke ist, dass wenn das Modul bereits auf der initrd verfügbar ist und geladen wird und deswegen die Grafik bereits während dem Abarbeiten der initrd in die höhere Auflösung geschaltet wird, dir solche Meldungen über eine nicht gefundene swap-Partition nicht mehr entgehen können. Es eliminiert oder verkürzt also hoffentlich die Lücke mit fehlender Grafikausgabe, die auftritt nachdem grub an den Linuxkernel übergeben, aber Linux noch keinen Grafiktreiber geladen hat.

Ein Nebeneffekt ist, dass das Geflacker vom Umschalten des Grafikmodus dann meist so früh nach grub kommt, dass man auch auf Systemen, deren Grafikausgabe während der initrd funktioniert, nichts davon bemerkt.
Auch bei Splashscreens wie plymouth hilft diese Maßnahme den Bootvorgang etwas schöner zu gestalten.

[TomL]

Die Microcodeupdates haben erst einmal nichts mit den Kernelmodulen zu tun.

Da hätte ich auch wirklich selber drauf kommen können ... vor allem, weil sich der der Zusammenhang ja zwangsläufig wie von selber ergibt, wenn man Deine Erklärung aus dem Posting davor (zu initramfs) in die Betrachtung einbezieht.

Aber was mir jetzt nicht klar ist, setzt die geänderte initrd nicht auch voraus, dass das System (welches auch immer gerade während des Boots aktiv ist) den richtigen Monitor zur Ausgabe auswählt? Mir ist nämlich auch aufgefallen, dass ich seit längerem keinen ASRock-Splash-Screen mehr sehe.... erst heute, als ich beim Testen zufällig nehmen dem Monitor auch den TV (HDMI-1) an hatte. ... und siehe da, der ASRock-Splashscreen war auf dem TV. Vielleicht teilt das Bios dem System Mist mit, soll heissen, die Meldungen werden beim Booten zwar erzeugt, aber sie gehen auf den falschen Monitor. Kann das vielleicht sein?

[smutbert]

Ja, das kann gut sein.
Normalerweise lässt sich der primäre Anschluss im BIOS-Setup einstellen. Manchmal verschluckt sich die Konfiguration aber hartnäckig oder es gibt Bugs, die dazu führen, dass die Ausgabe trotzdem nicht dort landet wo man sie will.

[TomL]

Moin

Heute morgen habe ich mal drauf geachtet, wie der Boot bei mir abläuft:
1 Schwarzer Bildschirm, orange LED, kein Signal
2. Schwarzer Bildschirm, blaue LED, Signal vorhanden, Grub-Menü mit 2 Sekunden Time-Out bis zum Default-Start
3. Schwarzer Bildschirm, Login-Screen

Das ganze beansprucht etwa 10 Sekunden - 5 Sek. bis Grub, 5 Sek. bis zum Login-GUI. Da kommt nicht eine einzige Meldung..... und solange ich das jetzt nutze, ich habe das noch nie vermisst oder das Fehlen der Meldungen als falsch empfunden. Im Gegenteil, das läuft so problemlos und sauber, wie man sich das nur wünschen kann.

Einigermaßen unschlüssig verbleibend, geradezu in einem "wie-geh-ich-jetzt-damit-um-Dilemma" habe ich diesen Thread erstmal auf gelöst gesetzt. Das Problem der fehlenden Meldungen ist ja hier kein Standard-Problem, sondern eher ein Nebenschauplatz, quasi zufällig bewusst geworden durch die Probleme nach dem Setup in der 2. Partition. Mein Problem wird sein, dass ich mich in einem Jahr kaum noch an die Umstände erinnern werde, warum es ggf. notwendig sein kann, auf einer Maschine ein spezielles Kernelmodul in die initrd einzubauen - plus der Folgefrage, welches Kernelmodul es nun hier an der aktuellen Maschine sein soll. An der initrd rumzubauen, obwohl alle unsere PC mit dem Standard perfekt laufen, kommt mir vor, wie Spielen am Motorsteuergerät meines Autos .... und davon habe ich auch keine Ahnung *lol*

Eine Frage ist da nur noch offen: Sind diese betroffenen Meldungen eigentlich andere als die, die anschließend im Journal stehen? Geht es hier um initrd-Meldungen, die nicht im Journal stehen, weil systemd-journald noch nicht gestartet wurde?

[smutbert]

Da bin ich unsicher - bis zum Mounten des /-Dateisystems habe ich nur Kernelmeldungen im Log, aber das kann auch daran liegen, dass es vorher schlicht keine anderen Meldungen gibt (am Monitor sichtbare sowieso nicht).
Andere Meldungen fangen bei mir erst mit dem Start von systemd nach dem Mounten des /-Dateisystems an, aber wenn ich raten müsste, würde ich vermuten, dass so eine Timeoutmeldung aus der Zeit der initrd nicht im Log landet.


Das Hinzufügen von i915 zur initrd kannst du zwar gefahrlos ausprobieren - geladen wird das Modul sowieso, in der initrd nur etwas früher, aber ich habe den Verdacht, dass es dann bei dir doch nichts bringt, weil trotzdem noch der falsche Grafikanschluss der primäre sein wird.
ich nehme an über Kernelparameter ließe sich auch der primäre Grafikanschluss festlegen (eleganter wäre wohl das BIOS-Setup - schließlich wird man auch BIOS-Einstellungen nicht unbedingt über den Fernseher ändern wollen), aber ich weiß nur wie man bei einzelnen Anschlüsse die Auflösung festlegt oder sie komplett deaktiviert und weiß nicht wie man dem Kernel sagt welcher Anschluss nun der erste sein soll. Deaktivieren solltest du einen Anschluss jedenfalls mit

Code: Alles auswählen

video=HDMI-1:d

können (X/Wayland können den dann natürlich dann wieder aktivieren, so wie sie es jetzt mit deinem eigentlichen Monitor machen), aber ich weiß nicht ob das den gewünschten Effekt hat.