Hi.
Ich habe auf einer Proxmox-VM, die uns schon lange als Master-Image dient, folgendes gemacht:
do-release-upgrade durchgeführt, um von jammy (22.04) nach noble (24.04) zu gelangen (das lief sauber durch; die Anmeldung per LDAP/AD funktioniert)
eine Sache funktionierte innerhalb der VM seit dem Upgrade leider sehr unzuverlässig und stockend und das war seltsamerweise ausgerechnet X11 . Daher in der Datei /etc/gdm3/custom.conf auf Wayland gewechselt. Damit lief die VM wieder zuverlässig.
eine neue Hardwareklasse noble angelegt (start.conf.noble, .postsync-Script usw sind vorhanden)
einen neuen Eintrag in der devices.csv angelegt, um Clients mit dem neuen Image bestücken zu können
die Proxmox-VM so vorbereitet, dass sie ausgerollt werden kann. Dazu gehörte auch die Konfiguration eines WLANs (später für Laptops) sowie ein Account schueler (später für einen Autologin auf bestimmten Clients)
den Desktop angepasst, getestet und Programme wie firefox, chrome usw. als User schueler alle gestartet, um sicher gehen zu können, dass sie funktionieren (es sind häufig leider snap-Versionen)
das neu erstellte noble-Image per LINBO auf einen Lenovo Yoga-12 Laptop übertragen
Was jetzt seltsam ist:
der Yoga-Laptop reagiert anders als die VM. Dort laufen die o.g. Programme als User nicht. Es gibt stattdessen eine Fehlermeldung wie „snap: permission denied“. Erst eine Neuinstallation des Snap-Dienstes auf dem Laptop hat das Problem gelöst.
die Clients müssen mit X11 laufen, da dort später auch veyon verwendet werden soll. Daher per Postsync den Eintrag von Wayland wieder zurück auf X11 gestellt. Das hat funktioniert.
Hat jemand eine Idee, was das sein kann? LINBO und Postsync machen meines Wissens nichts mit snap. Kann es aber sein, dass die Hostname-Änderung (die ja von LINBO kommt), damit irgendwie zusammenhängt? Oder warum sollte sich snap plötzlich sonst so anstellen?
Hallo nochmal,
ich antworte hier mal kurz selbst … es ist möglich, dass es hieran liegt:
cat /etc/machine-id
(diese ID darf auf dem geklonten Rechner offenbar nicht identisch sein/bleiben?)
Abhilfe:
sudo rm /etc/machine-id
sudo systemd-machine-id-setup
sudo reboot
oder aber auf die harte Tour:
dpkg-reconfigure snapd
Falls dem so ist, müssten aber noch andere von dem Problem betroffen sein bzw eigentlich sogar alle, die irgendein Programm verwenden, das über snap installiert wurde, oder?
Aber dank postsync wäre es ja ziemlich einfach zu fixen, indem man einen entsprechenden Absatz mit in das Postsync-Script aufnimmt.
Daher nochmal die Rückfrage, ob das nicht ein gängiges Problem ist, das auch bei Euch auftritt?
einer der Gründe, warum ich, und anscheinend auch immer mehr andere, von Ubuntu auf dem Client zu debian wechseln, sind die snaps.
Ich war es nach 22.04 Leid, immer mehr snap Programme zu deinstallieren und durch ihre deb Varianten zu ersetzen: vor allem, weil die deb Varianten langsam der Aktualität der snap Programme hinter her hinken.
Dein Problem zeigt mir, dass ich die richtige Entscheidung getroffen habe.
Hallo Holger,
ja, das simmt … snap nervt mich auch. Aber wenn man das Problem dennoch mit so einem einfachen Schritt beheben kann, ist es vielleicht doch einen Versuch wert.
Per postsync eine Datei zu löschen oder eine andere dorthin zu schieben, wo man sie benötigt, ist ja kein Problem. Ich weiß aber noch nicht, ob man auch den mittlereren Befehl per postsync auf dem Client absetzen kann.
Nur, um doch noch eine Lösung beizusteuern: Das hat bei uns so funktioniert!
Als wir die machine-id (z.B. von LINBO und/oder Postsync / onBoot.d-Scripten) neu erstellen ließen bzw den snap-Daemon neu konfigurieren ließen, konnten wir die snap-Apps bei uns auch auf der geklonten Hardware wieder starten.
. Daher in der Datei