Nach dist-upgrade hängt client bei reboot/shutdown


#1

Hallo,

seit dem letzten dist-upgrade habe ich ziemlich viele Probleme. Einige konnte ich, mitunter Dank eurer Hilfe, bereits lösen.
Allerdings nun ein weiteres Problem.
Nach dem Update kann ich den Client neu starten oder runterfahren. Beim 2. Mal bleibt er dann hängen.
Bei Neustart kommt folgendes:

Es geht nicht mehr weiter. Client bleibt hängen.

Beim Runterfahren kommt folgendes:

Und es geht auch hier nicht mehr weiter.

Habe mal recherchiert und bin auf zwei Workarounds gestoßen, die aber in meinem Fall nix veränderten:

  1. Habe in der /etc/default/grub unter GRUB_CMDLINE_LINUX_DEFAULT hinter quiet splash noch acpi=force hinzugefügt. --> grub-update, Neustart (per Powerbutton, da er ja hängt) --> Keine Veränderung

  2. Habe ubuntu-drivers autoinstall ausgeführt. Es wurden keine Fehler gefunden und auch nichts nachinstalliert. --> Keine Veränderung.

Bin mit meinem Latein leider schon wieder am Ende.
Hat/hatte von euch zufällig das gleiche Problem und kann weiter helfen?

Vielen Dank im Voraus und Grüße,

David


#2

Hallo David,

bitte etwas genauer: du hast wo das update gemacht?
Auf dem Client?
Ist das ein 16.04?
Welcher Kernel läuft den? uname -a

Habe mal recherchiert und bin auf zwei Workarounds gestoßen, die aber in
meinem Fall nix veränderten:

Habe in der /etc/default/grub unter GRUB_CMDLINE_LINUX_DEFAULT
hinter quiet splash noch acpi=force hinzugefügt. --> grub-update,
Neustart (per Powerbutton, da er ja hängt) --> Keine Veränderung

… das kann nichts bringen, weil der kernelparameter vom ubuntu grub
übergeben wird, der aber übergangen wird: der grub2 von linbo bootet den
kernel.
Willst du so einen Kernelparameter übergeben, so mußt du ihn in der
start.conf der Gruppe einttragen und dann import_workstations machen,
dann landet er da, wo er wirkt: in der /var/linbo/boot/grub/.cfg
… WENN die Zeile

### managed by linuxmuster

nicht verändert/gelöscht wurde!

Probier mal den Kernelparameter per linbo zu übergeben.
Wenn es nicht hilft, nimm mal einen anderen Kernel.

Gehe ich richtig in der Annahme, dass du lmn 6.2 mit linbo 2.3 hast?

LG

Holger


#3

Hi Holger,
danke für die superschnelle Antwort. Sorry, etwas ungenau.
dist-upgrade auf dem Client mit 16.04.

Kernel müsste 4.4.0-96 sein, wenn ich das noch richtig im Kopf habe, bin gerade nicht an der Schule, erst später wieder.

D.h. die Zeile muss ich in meinem Fall in die /var/linbo/boot/grub/xenial916.cfg auf dem Server schreiben?

Müssen da alle Infos rein, oder nur Kernel Parameter; sprich auch der Eintrag GRUB_DISABLE_LINUX_UUID=true ? Oder bleibt dieser dann in /etc/default/grub auf dem Client?

Und yep, sind auf aktuellem Stand. lmn 6.2 und Linbo 2.3

VG

David


#4

Hallo David,

… das kann nichts bringen, weil der kernelparameter vom ubuntu grub

übergeben wird, der aber übergangen wird: der grub2 von linbo bootet den

kernel.

D.h. die Zeile muss ich in meinem Fall in die
/var/linbo/boot/grub/xenial916.cfg auf dem Server schreiben?

… nein, das macht import_workstations für dich, wenn du die # ###
managed by linuxmuster
noch drin hast.
Wenn du die Datei lieber von Hand editierst, dann kannst du es auch
direkt reinschreiben: ein import ist dann nicht nötig.
Änderst du die Datei (oder ein import), so wird linbo während des
bootens rebooten um die neue config wirksam zu machen.

Müssen da alle Infos rein, oder nur Kernel Parameter; sprich auch der
Eintrag GRUB_DISABLE_LINUX_UUID=true ? Oder bleibt dieser dann in
/etc/default/grub auf dem Client?

das ist ein grub Parameter: der kann auf dem Client bleiben.

LG

Holger


#5

Hi Holger,

Hat alles nix gebracht. Habe rausgefunden es liegt tatsächlich nur am Kernel. Wenn ich auf 4.4.0-66 downgrade läuft’s wieder ohne irgendeine weitere Anpassung.
Welcher läuft denn auf deinen Clients?

Danke schonmal und Grüße.


#6

Hallo David,

Hat alles nix gebracht. Habe rausgefunden es liegt tatsächlich nur am
Kernel. Wenn ich auf 4.4.0-66 downgrade läuft’s wieder ohne irgendeine
weitere Anpassung.
Welcher läuft denn auf deinen Clients?

auch irgend ein 4.4.0er

LG

Holger


#7

Hallo Holger,

bringt das irgendwelche Nachteile, wenn ich den 4.4.0-66 laufen lasse soweit alles funktioniert?
Und noch eine abschließende Frage.
Vor dem Setzen von GRUB_DISABLE_LINUX_UUID=true blieben meine Clients ja mit dieser UUID Fehlermeldung hängen. Nach dem Setzen auf true kommt die Fehlermeldung immer noch, nach ca. 5 Sekunden oder drücken einer Taste startet Ubuntu nun aber wieder.
Muss man mit der Fehlermeldung leben oder bekommt man die irgendwie weg?

Vielen Dank für deine Unterstützung, in allen Punkten.
Viele Grüße,
David


#8

Hallo David,

bringt das irgendwelche Nachteile, wenn ich den 4.4.0-66 laufen lasse
soweit alles funktioniert?

nein: 4.4 wird noch voll unterstützt.

Und noch eine abschließende Frage.
Vor dem Setzen von GRUB_DISABLE_LINUX_UUID=true blieben meine Clients ja
mit dieser UUID Fehlermeldung hängen. Nach dem Setzen auf true kommt die
Fehlermeldung immer noch, nach ca. 5 Sekunden oder drücken einer Taste
startet Ubuntu nun aber wieder.
Muss man mit der Fehlermeldung leben oder bekommt man die irgendwie weg?

hast du
update-grub
nach Ändern der defaut Datei gemacht?

… eigentlich komisch: der lokale grub sollte doch garnichts mehr mit
dem booten zu tun haben.

Schau halt mal rein in die /boot/grub/grub.cfg
Stehen da in den Kernelzeilen UUIDs oder Devicenamen (sda??)

LG

Holger


#9

Hi Holger,

update-grub hab ich gemacht.
In den Kernelzeilen steht: linux /boot/vmlinuz-4.4.0-66-generic root=/dev/sda1 ro quiet splash $vt_handoff und auch in der Zeile mit --no-floppy kommt ne UUID.
Ich bin mal so frech und poste das Ding. Musste es zum Hochladen in ne txt umwandeln.
grub.txt (8,2 KB)
Grüße,

David


#10

Eins noch, wenn ich update-grub gemacht habe reicht das doch oder? ein grub-mkconfig zuvor ist normal nicht nötig oder doch?

Grüße.


#11

Hallo David,

Eins noch, wenn ich update-grub gemacht habe reicht das doch oder? ein
grub-mkconfig zuvor ist normal nicht nötig oder doch?

ja: ist nicht nötig

LG

Holger


#12

Habe dir oben im vorletzten Beitrag mal noch die grub.cfg angehängt. Vielleicht kannst du bei Gelegenheit mal drüber schauen, ob da der Hund begraben ist :wink:

Danke dir. Viele Grüße,
David


#13

Hallo Holger,

habe nochmals versucht mich dem Problem anzunehmen. Gelöst habe ich es nicht, bin aber einen weiteren Punkt gelangt, an dem ich nicht weiter komme.

Und zwar ändert mein Client nach einem update-grub die UUID in der /boot/grub/grub.cfg nicht nach root=/dev/sda1 (oder so ähnlich), sondern die lange UUID ee33fa… bleibt, obwohl ich in der /etc/default/grub GRUB_DISABLE_LINUX_UUID=true gesetzt habe.

Irgendwie kümmert meine Clients die Änderung dieses Parameters nicht.
Bekomme bei update-grub oder auch bei grub-mkconfig keine Fehlermeldung, weshalb ich nicht weiter komme.
Habe auf meiner anderen Maschine, auf der Linux Mint läuft, das Ganze auch mal getestet und nach setzen von GRUB_DISABLE_LINUX_UUID=true und update-grub nimmt er wie gewünscht die UUIDs raus und ersetzt sie mit den Devicenamen…Nur beim 16.04 Default-Cloop nicht… Hast du oder irgend jemand eine Idee?

Danke vorab und Grüße,

David


#14

Hallo David,

Und zwar ändert mein Client nach einem update-grub die UUID in der
/boot/grub/grub.cfg nicht nach root=/dev/sda1 (oder so ähnlich), sondern
die lange UUID ee33fa… bleibt, obwohl ich in der /etc/default/grub
GRUB_DISABLE_LINUX_UUID=true gesetzt habe.

ich hab am Client in der /etc/default/grub
diese Zeile stehen:

#GRUB_DISABLE_LINUX_UUID=true

also auskommentiert.

In der /boot/grub/grub.cfg stehen somit auch UUIDs drin: das stört aber
nicht, weil linbo (bzw. der grub von linbo) diese Datei garnicht abfragt
(normalerweise).

Bitte poste mal deine start.conf

Welche linbo Version hast du?
dpkg -l | grep linbo

Verwendest du postsync?
Poste auch diese Datei bitte mal

LG

Holger


#15

Hi Holger,

danke für die Rückmeldung und erneute Annahme des Problems.

Linbo Version ist 2.3.3-0

start.conf:

# LINBO start.conf, Beispiel fuer Ubuntu
#Ubuntu auf Partition 1

#Swap auf Partition 2
#Cache auf Partition 3

[LINBO] # Start der globalen Konfiguration
SystemType = bios
#SystemType = bios
KernelOptions = quiet splash acpi=force
Cache = /dev/sda3 # lokale Cache Partition
Server = 10.16.1.1
Group = xenial916
RootTimeout = 600 # automatischer Rootlogout nach 600 Sek.
AutoPartition = no # keine automatische Partitionsreparatur beim LINBO-Start
AutoFormat = no # kein automatisches Formatieren aller Partitionen beim LINBO-Start
AutoInitCache = no # kein automatisches Befüllen des Caches beim LINBO-Start
DownloadType = rsync # Image-Download per torrent|multicast|rsync, default ist torrent
BackgroundFontColor = white # Bildschirmschriftfarbe (default: white)
ConsoleFontColorStdout = white # Konsolenschriftfarbe (default: white)
ConsoleFontColorStderr = orange # Konsolenschriftfarbe für Fehler-/Warnmeldungen (default: orange)

[Partition] # Betriebssystem (Ubuntu)
Dev = /dev/sda1 # Device-Name der Partition (sda1 = erste Partition auf erster Platte)
Size = 25G # Partitionsgroesse in kB (Bsp.: ca. 20G)
Id = 83 # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, …)
FSType = ext4 # Dateisystem ext4
Bootable = yes # Bootable-Flag

[Partition] # Swap
Dev = /dev/sda2 # Device-Name der Partition (sda2 = zweite Partition auf erster Platte)
Size = 12G # Partitionsgroesse 8388608 kB (Bsp.: ca. 2,5G)
Id = 82 # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, …)
FSType = swap

[Partition] # Cachepartition
Dev = /dev/sda3 # Device-Name der Partition (sda4 = vierte Partition auf erster Platte)
Size = # Partitionsgroesse in kB (Bsp.: keine Angabe = Rest der Platte)
Id = 83 # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, …)
FSType = ext4 # Dateisystem ext4
Bootable = yes # Bootable-Flag

[OS]
Name = Ubuntu 16.04 LTS # Name des Betriebssystems
Version = # Version (optional)
Description = Ubuntu 16.04 xenial # Beschreibung
IconName = ubuntu.png # Icon fuer die Startseite, muss unter /var/linbo/icons abgelegt sein
#Image = xenial916.rsync # Dateiname des differentiellen Images (Erweiterung .rsync)
#Image = # erst eintragen, wenn es erzeugt werden soll
BaseImage = xenial916.cloop
Boot = /dev/sda1 # Partition, die Kernel & Initrd enthaelt
Root = /dev/sda1 # Rootpartition, in die das BS installiert ist
Kernel = vmlinuz # Relativer Pfad zum Kernel
Initrd = initrd.img # Relativer Pfad zur Initrd
Append = ro splash # Kernel-Append-Parameter, ggf. anpassen
StartEnabled = yes # “Start”-Button anzeigen
SyncEnabled = yes # “Sync+Start”-Button anzeigen
NewEnabled = yes # “Neu+Start”-Button anzeigen
Hidden = yes # verstecke OS-Reiter
Autostart = yes # automatischer synchronisierter Start dieses Betriebssystems: yes|no
DefaultAction = start # DefaultAction bei Autostart: start|sync|new
AutostartTimeout = 5 # Timeout in Sekunden für Benutzerabbruch bei Autostart

postsync

`echo "##### POSTSYNC BEGIN #####"
LOG=/mnt/var/log/postsync.log
echo “##### POSTSYNC BEGIN #####” > $LOG
NOW=$(date +%Y%m%d-%H%M)
echo $NOW | tee -a $LOG

#IP-Adresse des Servers
SERVERIP=$(nslookup dummy 2> /dev/null | head -n 1 | awk -F: ‘{print $2}’ | sed “s/\s*//g”)

#Die Hostgruppe des aktuellen Rechners
HOSTGROUP=$(hostgroup)

#Raum feststellen. Dieses Skript geht davon aus
#dass die Rechner Namen der Form
#raumname-hostname haben, also z.B. cr01-pc18
RAUM=${HOSTNAME%%-*}
#wenn der string leer ist, raum auf unknown setzen
if [ “x${RAUM}” == “x” ]; then
RAUM="unknown"
fi

#UVZ für die Patches auf dem Server. Mit dieser Variablen
#kann man verschiedene Patches, z.B. für unterschiedliche
#Linux-Versionen bereitstellen.
#Wenn man hier $HOSTGROUP einträgt, erhält jede Rechnerklasse
#ein eigenes Patchklassenverzeichnis auf dem Server.
#Damit kann man verschiedene Patchklassen mit derselben cloop-Datei
#bedienen, wenn man das benötigt.
PATCHCLASS=“xenial916”

#Das Verzeichnis, in dem die Serverpatches
#im lokalen Clientcache synchronisiert werden.
PATCHCACHE=/linuxmuster-client/serverpatches

echo “” | tee -a $LOG
echo “Hostname: ${HOSTNAME}” | tee -a $LOG
echo “Raum: ${RAUM}” | tee -a $LOG
echo “Patchcache: ${PATCHCACHE}” | tee -a $LOG
echo “Hostgruppe: ${HOSTGROUP}” | tee -a $LOG
echo “Patchclass: ${PATCHCLASS}” | tee -a $LOG
echo “” | tee -a $LOG

#-----------------------------------------
#Patchdateien auf das lokale Image rsyncen
#-----------------------------------------
echo " - getting patchfiles" | tee -a $LOG

#RAUM -> Raumname
#HOSTNAME -> Rechnername
#Verzeichnis anlegen, damit es sicher existiert
mkdir -p /cache/${PATCHCACHE}
rsync --delete --progress -r “${SERVERIP}::linbo/linuxmuster-client/${PATCHCLASS}” “/cache/${PATCHCACHE}” | tee -a $LOG

echo " - patching local files" | tee -a $LOG

#common: Bekommen alle clients der Patchklasse
#files
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/common ]; then
echo " - patching common to /mnt" | tee -a $LOG
cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/common/* /mnt/ | tee -a $LOG
fi

#tarpacks
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/common/tarpacks ]; then
echo " - unpacking tarpacks from common/tarpacks to /mnt" | tee -a $LOG
for pack in /cache/${PATCHCACHE}/${PATCHCLASS}/common/tarpacks/*; do
echo " - unpacking: $pack" | tee -a $LOG
tar xvzf $pack -C /mnt | tee -a $LOG
done
fi

#Raum: Nur die Clients des Raums
#files
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM} ]; then
echo " - patching ${RAUM} to /mnt" | tee -a $LOG
cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM}/* /mnt/ | tee -a $LOG
fi

#tarpacks
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM}/tarpacks ]; then
echo " - unpacking tarpacks from ${RAUM}/tarpacks to /mnt" | tee -a $LOG
for pack in /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM}/tarpacks/*; do
echo " - unpacking: $pack" | tee -a $LOG
tar xvzf $pack -C /mnt | tee -a $LOG
done
fi

#Host: Nur der Rechner
#files
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME} ]; then
echo " - patching ${HOSTNAME} to /mnt" | tee -a $LOG
cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME}/* /mnt/ | tee -a $LOG
fi

#tarpacks
if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME}/tarpacks ]; then
echo " - unpacking tarpacks from ${HOSTNAME}/tarpacks to /mnt" | tee -a $LOG
for pack in /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME}/tarpacks/*; do
echo " - unpacking: $pack" | tee -a $LOG
tar xvzf $pack -C /mnt | tee -a $LOG
done
fi

#Hook, um eigene Skripte auszuführen
if [ -d /mnt/postsync.d ]; then
for SCRIPT in /mnt/postsync.d/*
do
chmod 755 $SCRIPT
echo “Executing: $SCRIPT” | tee -a $LOG
#$SCRIPT > /dev/null 2>&1
$SCRIPT | tee -a $LOG
echo " …done." | tee -a $LOG
done
rm -rf /mnt/postsync.d
fi

#wenn es /mnt/tarpacks gibt - löschen
rm -rf /mnt/tarpacks

#Epoptes Serverkey - Rechte
if [ -e /mnt/etc/epoptes/server.key ];
then chmod 600 /mnt/etc/epoptes/server.key
fi

#Zeitstempel letzter sync hinterlegen
echo $NOW > /mnt/lastsync

#Rechte Dateien Profil-AC
#chown -R 1000:1000 /mnt/home/linuxadmin

echo “##### POSTSYNC END #####” | tee -a $LOG

`:

Bin gespannt auf deine Prognose.
Vielen Dank.

LG

David


#16

Hallo David,

tut mir LEid, ich glaube ich komme langsam bei ein paar Treads
durcheinander, was eigentlich das Problem ist.

Was ist bei dir das Problem?
Ich hab den Tread noch mal von oben an gelesen und … habs vielleicht
überlesen.
Verwendest du noch 4.4.0-66 oder den neueren Kernel?

LG

Holger


#17

Hallo Holger,

kein Ding, kann mir vorstellen, dass du mehr als genug um die Ohren hast.
Problem ist immer noch folgendes:

Zitat:

Vor dem Setzen von GRUB_DISABLE_LINUX_UUID=true blieben meine Clients ja mit dieser UUID Fehlermeldung hängen. Nach dem Setzen auf true kommt die Fehlermeldung immer noch, nach ca. 5 Sekunden oder drücken einer Taste startet Ubuntu nun aber wieder.
Muss man mit der Fehlermeldung leben oder bekommt man die irgendwie weg?

Zitat Ende

Die Fehlermeldung kommt nach wie vor und die Clients booten (sind 10-15 Sekunden) dann auch automatisch oder schneller nach drücken einer Taste.
Von daher ist der Betrieb momentan gewährleistet, ich würde das aber gerne beheben.
Das ist mein momentanes Hauptproblem.

Zudem hatte ich das sekundäre Problem, dass sich die Clients nach Kernelupdate nicht mehr herunterfahren/neustarten ließen und ich bin dann bei 4.4.0-66 geblieben. Gestern habe ich mal einen Testlauf mit dem 4.4.116er Kernel gemacht, da scheint dieses Problem nicht mehr zu existieren aber das Problem mit der UUID Fehlermeldung bleibt.

Ich habe durch einen Test mit Linux Mint mal geschaut, was mit der /boot/grub/grub.cfg passiert, wenn ich in der /etc/default/grub die Zeile von #GRUB_DISABLE_LINUX_UUID=true auf GRUB_DISABLE_LINUX_UUID=true setze und ein update-grub laufen lasse.
In diesem Test mit Linux Mint, und bei Ubuntu muss es sich ja gleich verhalten, taucht nach diesem Vorgang in der /boot/grub/grub.cfg keine UUID mehr auf sondern die Devicenamen.
Bei meinen Clients in der Schule mit dem 16.04 Default Image geschieht nach ändern von
#GRUB_DISABLE_LINUX_UUID=true auf GRUB_DISABLE_LINUX_UUID=true und anschließendem update-grub nix, d.h. in der /boot/grub/grub.cfg ergibt sich keine Änderung, die UUIDs bleiben erhalten, es werden stattdessen keine Devicenamen gesetzt und ich bekomme, meiner Meinung nach, deshalb auch besagte Fehlermeldung.

Ist bisschen kompliziert zu beschreiben, aber ich hoffe du kannst nachvollziehen, was ich meine.

LG

David


#18

Hallo David,

das Herunterfahren Problem (das du ja jetzt vorerst mit dem neuen Kernel
behoben hast) kommt meiner Meinung nach von der OPtion acpi=force in der
start.conf.
Ist aber nicht so wichtig, wenn es eh nicht mehr auftaucht.

zum UUID Problem.

Gehen wir es mal pragmatisch an.

Client syncen, als linuxadmin anmelden, Terminal auf, sudo su
Kontrollieren ob disable UUID =true in /etc/default/grub steht
Kontrollieren, ob in der /etc/fstab statt UUIDs das Device steht /dev/sda?
Dann update-grub
und
grub-install /dev/sda

Danach ein Image schreiben, auf einen anderen Cleint zurückspielen und
testen.

LG

Holger


#19

Hallo Holger,

bis auf grub-install /dev/sda, hatte ich bisher immer ohne “/dev/sda” gemacht, habe ich schon alles durch. /etc /fstab ist UUID-frei. Werde es später mal mit grub-install /dev/sda testen und Bericht erstatten.

Danke dir und Grüße,

David