Nach dem Update von 7.1 auf 7.2 mögen meine Linux-Mint-Clients nicht mehr.
Zunächst war das Problem wie hier:
Beim ersten Boot nach dem Update des Servers starten die Rechner in Linbo 4.0, aber nicht bis in die GUI, sondern starten dann neu und leider nicht ins Linbo 4.2, sondern direkt ins LinuxMint.
Um sie wieder ins Linbo zu bekommen, muss ich die Bootreihenfolge im Bios manuell ändern. Dann startet Linbo 4.2 wie es soll und ein Start ohne Sync funktioniert. Sync+Start läuft zunächst durch, endet dann aber damit, dass das LinuxMint nicht ordnungsgemäß startet und in der BusyBox landet.
Folgendes hab ich schon probiert:
vor dem Sync die Festplatte neu formatiert
apt reinstall linuxmuster-linbo7 brachte keine Besserung.
eine neue Startconf in der WebUI angelegt
Dann habe ich gemerkt, dass im Image aus mir unerklärlichen Gründen plötzlich in fstab bei der Systempartition nicht mehr das Label angegeben ist, sondern der Devicename.
Mit einem noch nicht kaputten Client habe ich das dann behoben und ein neues Image hochgeladen. Das Image funktioniert nun an dem einen Rechner, aber nicht an den anderen. Es scheint irgendwo wieder eine UUID Verwendung zu finden oder Linbo 4.2 macht sonst irgendwas anders als 4.0, aber was?
Jetzt fällt mir auch nichts mehr ein.
Ich hoffe, ihr habt eine Idee. Ich will nicht wieder auf 7.1 zurück müssen, denn das Wiederbeleben der Freeradius war schon so viel Zeit und Arbeit…
Ich hab nun noch probiert nowarmstart aus der start-conf zu entfernen und siehe da, LinuxMint startet. Hier scheint wohl keine UUID eine Rolle zu spielen.
Aber, ein Problem weg, ein neues da:
LinuxMint kann nach dem Warmstart keine Netzwerkverbindung aufbauen - es scheint die Netzwerkkarte nicht richtig zu erkennen…es ist zum Verrücktwerden…
Ich hoffe, es weiß jemand Rat!
Grüße Noah
Hier die Start.conf:
[LINBO]
Server = 10.0.0.1
Group = linux_mint_uefi
Cache = /dev/nvme0n1p2
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
GuiDisabled = no
UseMinimalLayout = no
Locale = de-DE
SystemType = efi64
KernelOptions = quiet splash nomodeset nowarmstart dhcpretry=10
[Partition]
Dev = /dev/nvme0n1p1
Label = efi
Size = 200M
Id = ef
FSType = vfat
Bootable = yes
[Partition]
Dev = /dev/nvme0n1p2
Label = cache
Size = 80G
Id = 83
FSType = ext4
Bootable = no
[Partition]
Dev = /dev/nvme0n1p3
Label = system
Size =
Id = 83
FSType = ext4
Bootable = no
[OS]
Name = Linux Mint
Version = 21.3
Description = Ubuntu 18.04
IconName = mint.svg
BaseImage = linux_mint_uefi.qcow2
Boot = /dev/nvme0n1p3
Root = /dev/nvme0n1p3
Kernel = boot/vmlinuz
Initrd = boot/initrd.img
Append = ro splash
StartEnabled = yes
SyncEnabled = yes
NewEnabled = no
Autostart = no
AutostartTimeout = 5
DefaultAction = start
Hidden = yes
Im Linbo ist noch alles normal mit richtiger IP.
Er startet dann durch, braucht aber schon beim Booten länger mit einer Meldung, dass ein Job für networkmanager ausgeführt wird. das versucht er 2x und bootet dann weiter. Er bekommt aber keine Netzwerkverbindung. In den Einstellungen wird die Kabelverbindung zwar angezeigt mit 10 Mbit/s und MAC, aber er schafft keine Verbindung.
Die WLAN-Schnittstelle scheint nicht betroffen zu sein.
Moin,
das mit der Netzwerkkarte ist ein typischer Fehler, der durch nowarmstart behoben wird – bei manchen Karten hat LInux ein Problem damit, wenn die Netzwerkkarte schon initialisiert ist. Genau das passiert bei der Abfolge Linbo - Warmstart - Mint. In Bezug auf die Netzwerkkarte ist nowarmstart also die Lösung, was natürlich doof für Dein anderes Problem ist…
Ich hab nochmal das Forum durchforstet und hier steht die Lösung:
In der /etc/default/grub folgende Zeile auskommentieren:
GRUB_DISABLE_LINUX_UUID=true
Und dann sudo update-grub nicht vergessen.
Das hatte ich schon mal gemacht, aber vermutlich hat ein LinuxMint Update das mal zurückgestellt und Linbo 4.0 konnte besser damit umgehen?
Vielleicht hätte das den anderen ja auch anstelle eines Warmstarts geholfen?
Nach über 24 Arbeitsstunden seit Updatebeginn 7.1 > 7.2 (die Recherche, die ich zu Hause gemacht habe, ausgeschlossen, scheint jetzt alles wieder zu laufen…gut, dass ich LinuxMusterNet sonst so gerne hab…!
Dann scheint es weiter in den Grub vom Linux zu gehen, wo ja jetzt keine UUIDs, sondern die richtigen Laufwerksbezeichnungen stehen. Die NVME-Clients können jetzt starten.
Jetzt nutze ich das gleiche Image noch mit SATA-Clients mit einer Startconf, in der alle Partitionen mit sdaX angegeben sind. Die SATA-Clients bringen auch obige Fehlermeldung, kommen dann aber selbst mit dem Grub von Linux nicht weiter, weil dort die Laufwerksbezeichnungen nicht sdaX sondern nvme0n1pX sind…
Hallo Noah!
Ich habe auch ein Linux-Image, dass für alle möglichen Clients Verwendung findet (UEFI, BIOS, sda, nvme).
Damit das funktioniert tausche ich die /etc/fstab nach dem Synchronisieren durch linbo durch eine passende Datei aus.
Ich hoffe das hilft dir weiter.
Gruß - Rainer
Danke für den Hinweis, aber das wird nichts bringen, da im Image ja eh schon eine fstab mit Labeln liegt. Wenn, dann müsste ich die Einträge im Grub des Linux von nvme0n1pX zu sdaX ändern. Das würde das eigentliche Problem aber doch wieder nur umgehen.
Das eigentliche Problem ist doch, dass Linbo es nicht schafft, dem Client den Weg zur Systempartition zu weisen. Es steht irgendwo eine UUID, wodurch der Boot von Linbo ins Linux scheitert. Dann versucht der Client (weil als zweites Bootdevice im Setup eingestellt) direkt von der SSD zu starten. Das klappt bei den NVME-Clients, weil im Grub die Laufwerke mit nvme0n1pX angegeben sind. Die SATA-Clients scheitern aber.
Vor dem Upgrade 7.1 > 7.2 mit Linbo 4.0 war noch egal, was im Grub des Linux stand und ich hatte dort nichts angepasst. Also ist irgendwo noch ein Fehler in der Konfiguration von Linbo.
Hallo Noah!
Hast du nur eine start.conf-Datei für nvme- und sata-Clients?
Dann würde ich dort ansetzen.
Ich habe schon immer für nvme-Clients eine andere start.conf wie für sata-Clients, da das Device für die Hardwareklasse ja dort drin steht.
Gruß - Rainer
Ich habe zwei Startconfs eine für SATA und eine für NVME. Deren Inhalt ist bis auf die Laufwerksbezeichnungen sdaX bzw. nvme0n1pX identisch - siehe oben.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p2 during installation
LABEL=system / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
LABEL=efi /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
Und hier noch die Fehlermeldung, die auf allen Clients gleich ist mit identischer UUID:
sieht alles ganz gut aus.
Bitte nochmehr „drumrum“ erzählen.
Du hast das gleiche Image auf zwei Clientarten.
Beide sind UEFI, aber die eine Gruppe hat einen SATA Massenspeicher und die andere eine nvme.
Bei sata klappt alles, aber bei nvme nciht?
Früher hat es genau so bei beiden geklappt?
Wie ist das Start-verhalten Genau?
Die nvme Dinger kommen nicht mal bis in linbo rein?
Oder sie starten nur das mint nicht? (Dann kommt die zweite Meldung mit no video no server …).
Bitte noch dazusagen, welche Hardware die beiden haben z.B.
SATA: sind AMD Prozessoren mit built in GPU
nvme: sind INtel mit built in GPU
(also CPU und GPU benennen: vor allem wenn gesteckte Karten).
Nein, anders herum, weil ich GRUB_DISABLE_LINUX_UUID=true und update-grub an einem der NVME-Clients gemacht habe. Im Grub des Linux stehen also die Partitionen mit nvme0n1pX. Damit kann der SATA-Client nichts anfangen.
nach einer Zeit (egal, ob ich irgendwas drücke) machen sie dann weiter - ich vermute sie nutzen den Grub von LinuxMint, den ich ja im Image für NVME erfolgreich angepasst habe.
der NVME-Client bootet erfolgreich weiter der SATA-Client landet im initramfs - siehe Bild oben.
Es sind beides Intel-Rechner mit integrierter GPU:
Die SATAs sind Lenovo T440p Notebooks - was genau drin ist, müsste ich noch nachschauen.
Die NVMEs sind nagelneue HP-Clients mit folgenden Daten:
hast du die Datei
/srv/linbo/boot/grub/GRUPPE.cfg
von einer der beiden Gruppen schon mal geändert?
Ist die Zeile
managed by linuxmuster.net
noch unverändert?
(kommen also änderungen in der start.confzeile
KernelOptions
nach einem import-devices dort an?)
Beide Hardwareklassen sollten ohne das „nomodeset“ laufen: bitte nimm es raus, mach ein linuxmuster-import-devices und teste, ob linbo noch bootet und dann das BS.
führt das noch nciht zum Erfol, dann bitte ändere den Pfad in der start.conf.GRUPPE-sata für den linuxmint kernel mal von
Kernel = boot/vmlinuz
Initrd = boot/initrd.img
zu:
Kernel = vmlinuz
Initrd = initrd.img
und mach danach ein linuxmuster-import-devices
Dann wieder den Client testen.
Wenn beides nichts hilft, dann schauen wir uns die /etc/default/grub??? vom Client an und ich vergleiche sie mal mit meinen.
Ich verwende seit Jahren ein Image für sata und nvme ohne Probleme: allerdings sind das BIOS Clients, keine UEFIs…
Zwei Dinge mach ich noch anders als du:
bei mir ist immer der cache die letzte Partition
bei mir ist keine Partition „open Ende“: es haben alle Größenangaben.
Hast du mal von linbo aus auf den sata Cleints einfach mal die mintpartition gemountet und reingeschaut? Ist da alles da? ALso mal mit
df -h
schauen, wie voll die ist (nach dem mounten).
Ich hab an der /srv/linbo/boot/grub/GRUPPE.cfg oder irgendeiner anderen Datei nie was verändert und nutze bisher fast nur die WebUI.
nomodeset hab ich rausgenommen und die Änderung kam in der /srv/linbo/boot/grub/GRUPPE.cfg an. Das ändert aber nichts am Verhalten der Clients, außer, dass die Grafikauflösung auf den SATA-Clients nun passt.
Kernel = vmlinuz
Initrd = initrd.img
Ändert auch nichts.
Hier noch /etc/default/grub:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
Ich teste gleich noch, ab eine Größenangabe bei der Systempartition was andert.
Zum Versändnis: Was macht denn Linbo nach einem Start? Schreibt es einen eigenen Grub auf die Partition? Dann wäre doch das Anpassen des Grubs im Image eigentlich unnötig?
Jetzt hab ich noch zweimal neu formatiert und gesynct. Mit Systempartition mit beschränkter Größe am Ende einmal mit
