[erledigt] "Sekundäres" Setup nach cdebootstrap-chroot tot

[TomL]

MoinMoin

Im Moment beschäftigt mich ein mir erst mal unerklärliches Problem, welches exakt identisch an 3 verschiedenen Rechnern aufgetreten ist. Ich habe auf 3 Rechnern auf sda1 Debian Jessie via cdebootstrap installiert. Um das zu bewerkstelligen habe ich jeweils vorher auf sda3 (10 GB) ein schnelles LXDE-Netinst-Setup ausschließlich mit Defaults durchgeführt. Von sda3 wurde ordentlich gebootet, ich habe nach sda1 ge'debootstrap't und mich dann auf sda1 gechrootet und dort das richtige Setup durchgeführt. Ganz am Ende ein update-grub und eigentlich sollte es das sein….

….isses aber nicht. sda1 startet perfekt, wie es sein soll… alles bestens. Update-grub hat dafür gesorgt, dass im Grub-Menü beide Systeme anwählbar sind. Aber das System auf sda3 startet ab jetzt nicht mehr. … obwohl es quasi untouched (vorsätzlich von mir) ist.

Sda3 bootet zwar, aber die Bootmeldungen füllen seitenweise rote Fehlermeldungen. Das Netzwerk startet nicht, lightdm startet nicht, systemd und/oder dbus scheinen zu hängen, aber anscheinend startet tty1, nur bleibt der Bildschirm dabei trotzdem schwarz. Aber, so scheint mir, dass es eine grafische Schwärze ist, es ist nicht die „harte“ Terminalschwärze….. also irgendwas von X scheint zu leben…..aber das wars dann auch, mehr geht nicht. Ich konnte mich zwar auf tty2 einloggen, aber das Handling ist mit solcher Auflösung schlicht unzumutbar. Man kann ja nicht mal das Journal vernünftig lesen.

Ich habe lightdm deshalb erst mal deinstalliert und dann bekomme ich einen Login-Screen auf tty1. Ich kann nach der Anmeldung eth0 manuell öffnen, das Netz via /etc/init.d/networking von Hand starten und startx starten….. und siehe da, der Desktop erscheint. Aber automatisch geht beim nächsten Boot dann wieder gar nix. Dem System gelingt es nicht, das Netzwerk automatisch zu öffnen, weder mit networking noch mit systemd-networkd.

Eigentlich denke ich, dass ein debootstrap auf eine andere Partition und dann das abschließende setup via chroot nix im bereits vorhandenen und aktiven System kaputt machen sollte… aber leider ist genau das unabhängig von einander auf 3 unserer PCs passiert. Und nun schließe ich nicht aus, dass ich beim chroot beenden vielleicht doch selber fürs Sterben von sda3 gesorgt habe. Hat jemand vielleicht eine Idee, was da auf 3 Systemen auf sda3 falsch gelaufen sein kann?

[linuxCowboy]

... aber das Handling ist mit solcher Auflösung schlicht unzumutbar.

Versuchs mal mit syslinux.

Ich habe jetzt auch auf meinem Hauptsystem das verfettete grub2 zum Teufel geschickt. Es war ums verrecken nicht mehr als 80x25 in der Console rauszubekommen. Und vga ist ja "deprecated".

Die vermurkste Syntax braucht auch keiner. Viel Aufwand für Nichts. Ich habe meine grub.cfg eh' immer per Hand erstellt.

Oder vielleicht sind's ja zu wenig Module?

[uname]

Also ich mag grub2 auch nicht. Auch weiß ich nicht wo cdebootstrap abschließend die grub2-Konfigurationen ablegt. Aber es könnte schon sein, dass du die alten grub2-Konfigurationen unter /dev/sda3 und die neuen Konfigurationen unter /dev/sda1 hast. Wie unterscheiden die sich denn bzgl. des Eintrags für /dev/sda3?

[TomL]

Es fällt mir erst Mal schwer zu glauben,, dass grub der Verursacher sein soll. Um sicher zu sein, dass Jessie auf sda1 auch wirklich das primäre OS ist, habe ich update-grub eben auf dem gebooteten regulären System auf sda1 ausgeführt. Und wie gesagt, beide Installationen (sda1 und sda3) werden ja erkannt und sind beim nächsten Start wählbar. Die Installation auf sda3 startet ja sogar .... nur eben mit den seitenlangen oben beschriebenen Fehlermeldungen, womit sie es dann nicht bis zum Desktop schafft.

[uname]

Vielleicht wird ja einfach das falsche Dateisystem irgendwie eingehangen. Was sagen denn /etc/fstab (/dev/sda1, /dev/sda3) sowie "mount" nach dem jeweiligen Booten?

[rendegast]

Ich benutze die Möglichkeit von /boot/grub/custom.cfg.
Dort hinterlege ich einen menuentry, welcher nur als Bezeichner dient, um den grub identifizieren zu können.
In der Art

Code: Alles auswählen

menuentry '--------- BEZEICHNER blafoo -----------------' {
echo
}

Problematisch ist es, daß dem Hex-Code von stage1 / stage2 auf der Platte nicht anzusehen ist,
auf welche boot-Partition er zielt.
Vielleicht über eine grub-Variable, sodaß ein entsprechender String im stage1 / stage2 auftaucht?
Erkennbar ist da bisher nur
"GRUB Geom Hard Disk Read Error" (stage1, ~ grubs boot.img)
"loading Geom Read Error" (stage2, ~ grubs core.img).
Checksummenvergleich mit core.img klappt nicht, da grub-install wohl noch irgendeinen Zeitstempel oder sonstwas schreibt
(naja, hier irgendwas im Bereich 0x1f0 bis 0x220 des core.img).

[TomL]

Vielleicht wird ja einfach das falsche Dateisystem irgendwie eingehangen. Was sagen denn /etc/fstab (/dev/sda1, /dev/sda3) sowie "mount" nach dem jeweiligen Booten?

Das wäre zu schön gewesen.... wenn das die Ursache wäre... aber leider ist es das nicht. Aber ich habe neue Vermutungen, unerklärlich zwar, aber irgendwie scheint es sich zu bestätigen. Es scheint sich bei der LXDE auf sda3 um Berechtigungsprobleme zu handeln.... völlig unerklärlich, aber es scheint so zu sein.

Im Log sehe ich, dass für diese Daten die Berechtigungen fehlen.... mit dem Effekt, dass sich dbus.service nicht starten lässt... weder manuell noch beim Start:

Code: Alles auswählen

/etc/dbus-1/system.conf

Ich kontrolliere das und sehe root:root als Besitzer. Ok, denke ich mir, das ist doch alles richtig. Aber trotzdem, ich ändere das mal, direkt hintereinander weg, einmal rein und sofort wieder raus, famit ich die vollzogene Änderung auch wirklich sehe:

Code: Alles auswählen

chown thomas:thomas /etc/dbus-1/*
chown root:root /etc/dbus-1/*

Und jetzt kommts.... dbus.service lässt sich starten wieso ist denn jetzt mein root:root nun ein anderer, als der vorherige root:root

Den nächsten Fehler konnte ich mit rpcbind und nfs-common in Verbindung bringen. Ein "apt-get --reinstall install" für diese beiden Pakete wurde wieder mit fehlenden Permissions abgelehnt. Anscheinend gehörten irgendwelche Config-Files in /etc wieder nicht root:root, selbst dann nicht, wenn "root:root" dort steht. Und da ich nicht genau weiss, was da alles dranhängt, habe ich sie kurzerhand einmal gepurged und dann neu installiert. Nun passend für diese zwei Dienste als erzwungenenermaßaen wieder die Rechte.

Aktueller Stand ist, dass das Netzwerk jetzt wieder startet, aber es hängt immer noch am lightdm.... da bleibt der schwarze Bildschirm. Dabei ist wiederum interessant, dass ich via tty1 problemlos startx ausführen kann.... der Desktop kommt sofort.... was fehlt ist das Login-GUI. Allerdings denke ich jetzt auch, dass das vielleicht auch nur mit verschrobenen Permissions zusammenhängt.

Aber die Kernfrage bleibt, wie kann es nur sein, dass sich die Rechte so zerschießen, nur weil ich von diesem (sda3) System auf sda1 zum Jessie-Setup gechrootet habe? Ne andere Ursache fällt mir echt nicht mehr ein. Ich würde ja einfach /etc komplett root:root "schenken", weiss aber nicht, was ich da wieder hinsichtlich der abweichenden Default-Einstellungen kaputt mache.

[TomL]

Also ich mag grub2 auch nicht. Auch weiß ich nicht wo cdebootstrap abschließend die grub2-Konfigurationen ablegt. Aber es könnte schon sein, dass du die alten grub2-Konfigurationen unter /dev/sda3 und die neuen Konfigurationen unter /dev/sda1 hast.

Offensichtlich wars doch Grub. An irgendeinem Punkt habe ich meine Bemühungen sda3 noch mal sauber ans Booten zu bringen eingestellt und es kurzerhand mit "mkfs.ext4 /dev/sda3" platt gebügelt. Und das faszinierende Ergebnis war, dass nun auch das reguläre System auf sda1 nicht mehr bootet.... er bleibt im "grub rescue" stehen.... na toll. Ich bin deswegen immer noch irritiert, wieso grub überhaupt auf der Partition sda3 installiert war, wo ich doch Meinung war, ich hätte beim Setup nicht eine Partition ausgewählt, sondern das Device.

Mit der Live-CD ein "grub-install /dev/sda" hats erst mal wieder gerichtet..... soweit ist das also erledigt.