Linbo versucht, den Linux-Kernel (vmlinuz) unter / zu finden, allerdings befindet der sich im Verzeichnis /boot. Das schlägt fehl und deshalb sucht Linbo dann die grub.cfg von der OS-Installation und lässt dann grub das Betriebssystem mit dieser Konfiguration laden.
Weil dort aber noch die Einträge von der Installation drin stehen inkl. der UUID der root-Partition, kann grub damit nichts anfangen und bricht dann mit der Fehlermeldung
das Starten des Betriebssystems ab.
Lösung:
Man muss in der start.conf den Speicherort von vmlinuz und initrd.img korrekt angeben:
WebUI → 20200721_mint20_base (oder eigene start.conf) → Reiter Partitionen → Stiftsymbol in Partition Linux Mint → Reiter OS → Button ERWEITERT
Hallo Jürgen,
vielen Dank für Deine Antwort.
Ich habe dies nun so umgesetzt.
Der Client, der als VM unter Proxmox läuft mit identischer start.conf bootet weiterhin korrekt.
Der „echte“ Client (Laptop x60) startet nach der Synchronisation von Mint 20 leider nicht, sondern friert im Bildschirm ein, aber die bisherige Fehlermeldung habe ich auch nicht mehr.
Ich habe in der VM den Client mal aktualisiert, so dass nun der Kernel 5.4.0.42 installiert ist. Das ändert am Boot-Verhalten des Laptop aber leider bislang auch nichts.
OK, dann kann ich jetzt aber nach einem anderen Fehler suchen
Ich probiere nun mal verschiedene Kernel-Parameter aus.
VG
Chris
Hallo Jürgen,
vorläufiger Zwischenstand bei den Test mit verschiedenen Einstellungen und unterschiedlicher echter Hardware:
a) Ein weiterer Laptop (lenovo sl510) funktionierte sofort, wenn ich die o.g. Anpassungen beim OS in der start.conf eintrage (/boot/vmlinuz & /boot/initrd.img).
b) Ein ThinkCentre M15q mit NVMe und Radon Grafik, hatte mit Mint Probleme. Einstellungen wie unter a) - nach dem Sync versucht Linbo Mint 20 zu starten und landete dann aber immer wieder im Linbo Menü.
c) Ein Fujitsi P758 mit SSD: Hier startete Mint ohne Probleme.
Auf dem funktionierenden Laptop habe ich die Pakete aktualisiert und erhalte bei der Aktualisierung der Quellen folgende Fehlermeldung: GPG-Fehler: https://archive.linuxmuster.net … is in unsupported formate
Ich gehe mal davon aus, dass dies bekannt ist, oder ?
Entspricht das dieser Beobachtung: V7 Repo not signed - dort ist ja auch ein vorübergehender Fix erläutert.
Allerdings steht in Deinem Cloop bereits dieser Fix in der Datei /etc/apt/apt.conf.d/99-linuxmuster - die Fehlermeldung kommt dennoch.
Will ich dann mit linuxmuster-cloop.turnkey der Domäne beitreten, erhalte ich hierbei zusätzlich die Rückfrage für sshd, ob die Version des Systembetreuers … Belasse ich die alte oder ersetze ich diese durch die neue Version erhalte ich in beiden Fällen die Fehlermeldung, dass /var/lib/samba/sysvol/ nicht eingehangen werden kann und die Datei cacert.pem auch nicht gefunden wird.
Ist das ein Rechner mit aktiviertem UEFI-Bios? Wenn ja, könnte es daran liegen, dass das UEFI-Bios den Eintrag für Linux Mint in der EFI-Partition ignoriert. Ein Bios-Update kann in diesem Fall helfen (muss es aber nicht). Wenn das nicht hilft, auf Legacy-Bios umstellen.
Ja, das ist bekannt, der Workaround aus diesem Post steht in der Datei /etc/apt/apt.conf.d/99-linuxmuster. Schau Die Fehlermeldung mal genauer an. Ich meine, davor steht ein gelbes W: für Warning, deshalb bricht apt update auch nicht ab.
Bitte die alte belassen, sonst kann es sein, dass der Remote-Zugriff auf den Client per ssh vom Server aus nicht mehr funktioniert!
Das hört sich ganz danach an, als ob der Postsync nicht durchgelaufen ist.
Prüfe mal, ob auf dem Server im Verzeichnis /srv/linbo für Deine Hardwareklasse das generische Postsync-Skript existiert (HWK.cloop.postsync). Wenn nicht, kopiere entsprechend das Postsync-Skript, das in meinem Cloop Package dabei war (HWK bitte durch den Namen der Hardwareklasse ersetzen):
Hallo Jürgen,
danke für die Hinweise. Der PC mit UEFI und NVME: Hier habe ich zwar UEFI only im BIOS eingestellt. Linbo bootet einwandfrei, es ergeben sich nur nach dem Sync die Startprobleme. Legacy probiere ich mit diesem noch.
Mit dem Fujitsu PC ist es so, dass ich ein postsync für die HWK habe und ich sehe, dass beim Sync das ### postsync ende ### erreicht wird. Dieser wird also angewendet.
Im linbo.log des PC finde ich den Hinweis, dass sda3 und sda4 ein identisches Label aufweisen, was in der start.conf definitiv nicht so ist. Dort findet sich zudem der Hinweis: efibootmgr Boot 0003 same label grub. sda3 ist bei mir der cache.
Der Domänenbeitritt scheitert dennoch. Ich habe dann die Zeiten Server / Client verglichen. Hier gibt es 1 Minute Abweichung - deutlich zu viel Welche Vorgehen hast Du auf dem Client genutzt, um die Zeiten anzugleichen ?
Ich habe mal auf Client und Server timedatectl status geprüft und es ergibt der Unterschied von einer Minute. In der Konfigurationsdatei /etc/systemd/timesyncd.conf ist der Server 10.0.0.1 korrekt angegeben. Allerdings besagt o.g. Status, dass kein Sync der Zeit auf dem Client ausgeführt wurde.
Ich habe dann mit timedatectl set-ntp 0 #deaktivieren
timedatectl set-ntp 1 #aktivieren
Die Zeitsynchronisation initiiert, danach stimmten beide Zeiten.
Allerdings scheitert danach immer noch der Domänenbeitritt
VG
Chris
Welche Vorgehen hast Du auf dem Client genutzt, um die Zeiten anzugleichen ?