Startseite » eisfair » spline.eisfair.dev » Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar
| Re: Eiskernel-64-virt 5.4.0 hc3a4nger bei compress backup.tar [Beitrag #83183 ist eine Antwort auf Beitrag #83181] |
Thu, 07 January 2021 10:06   |
Heinz-Peter Faasen
Beiträge: 1196
Registriert: July 2010
|
Senior Member |
|
|
Hallo Holger,
>> Allerdings stimme ich Tom zu, dass das ein Würgaround ist, aber keine
>> Lösung.
>
> Ich sehe das nicht als Wuergaround, wenn ich etwas von einem Globalen
> update|upgrade ausschliesse, dass hier jetzt nur der Kernel aufscheint,
> ist der Demonstration geschuldet wie man --exklude=, ohne jedesmal erst
> darueber nachdenken zu muessen was man ausschliessen will, benutzen kann.
>
> Da ich Kernel Grundsaetzlich nur installiere wenn ich es will, da ich
> auch auf meinen dev Maschinen immer einen bestimmten Stand habe, ist das
> fuer mich ein Weg das update von Pakete zu steuern.
>
> Hinzukommt hier auch, dass ich bei einem Kernelupdate, auch wissen will
> was passiert ohne dass das in einem grossen rauschen untergeht.
diese Aspekte sind aber primär für Entwickler und Experten relevant.
Anwender, denen es vornehmlich um das "easy" geht, ist vor allem aber
ein simpler und sicher Aktualisierungsvorgang wichtig.
> Nunja, es kann ja auch jeder halten wie er will.
Kann ich nur 100%-ig zustimmen!
Deshalb habe ich es jetzt erst mal so eingebaut und werde sehen, wie das
in Zukunft läuft.
Vielen Dank!
Heinz-Peter
|
|
|
|
|
|
| Re: Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar [Beitrag #83185 ist eine Antwort auf Beitrag #83184] |
Thu, 07 January 2021 10:28 |
Marcus Roeckrath
Beiträge: 15197
Registriert: August 2010
|
Senior Member |
|
|
Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>> Ok, mal sehen, ob ich mit meinem eis auf einem USB-Stick mal ein paar
>> Test mache, den Kernel parallel zu anderen Paketen zu installieren.
>>
>> Offenbar trat das aber nur auf virtualisierten Systemen auf.
>
> es fällt mir schwer, das zu glauben. Denn das sind doch auch nur
> Zugriffe auf das Dateisystem und die funktionieren ansonsten klaglos.
Ja, aber bislang waren es nur virtualisierte Systeme, von denen ein Problem
berichtet wurde.
Oder sollten alle Nutzer echter Hardware immer Kernelupdates von anderen
Updates separieren.
Wäre schon ein seltener Zufall.
--
Gruß Marcus
[eisfair-Team]
Gruß Marcus
|
|
|
|
| Re: Eiskernel-64-virt 5.4.0 hc3a4nger bei compress backup.tar [Beitrag #83186 ist eine Antwort auf Beitrag #83183] |
Thu, 07 January 2021 10:26 |
Marcus Roeckrath
Beiträge: 15197
Registriert: August 2010
|
Senior Member |
|
|
Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>> Da ich Kernel Grundsaetzlich nur installiere wenn ich es will, da ich
>> auch auf meinen dev Maschinen immer einen bestimmten Stand habe, ist das
>> fuer mich ein Weg das update von Pakete zu steuern.
>>
>> Hinzukommt hier auch, dass ich bei einem Kernelupdate, auch wissen will
>> was passiert ohne dass das in einem grossen rauschen untergeht.
>
> diese Aspekte sind aber primär für Entwickler und Experten relevant.
> Anwender, denen es vornehmlich um das "easy" geht, ist vor allem aber
> ein simpler und sicher Aktualisierungsvorgang wichtig.
Auch auf reinen Produktivkisten ist ein Kernelupdate etwas, waa besonders
beobachtet werden will. Wenn Paket x nach einem Update ein Problem macht,
ist das behebbar, wenn aber nach dem Kernelupdate der Reboot schief geht,
weil eine gravierende Meldung übersehen wurde und man vorschnell rebootet,
ist dann durchaus fatal.
Bitte alle, die Probleme beim Kernelupdate haben, bitte im Moment des
"Hängens" in einer zweiten Konsole auch die Ausgabe von
df -h
--
Gruß Marcus
[eisfair-Team]
Gruß Marcus
|
|
|
|
| Re: Probleme bei eisman upgrade mit Upgrade von eisman (war: Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar) [Beitrag #83187 ist eine Antwort auf Beitrag #83182] |
Thu, 07 January 2021 10:33 |
Marcus Roeckrath
Beiträge: 15197
Registriert: August 2010
|
Senior Member |
|
|
Hallo Ansgar,
Ansgar Püster wrote:
>> nein, das ist nicht ein fortlaufendes Problem
>
> Sorry, aber das _ist_ ein weiter bestehendes Problem.
>
> isotest # eisman upgrade
>
> The following packages will be installed:
>
> version status name source
> ---------------------------------------------------------------------
> 3.0.2 stable eisman https://www.pack-eis.de
> 1.12.0 stable bpytop https://www.pack-eis.de
>
> "hängt" bei
>
> Installation of: bpytop (1.12.0) ...
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
> COMMAND
> 6965 root 30 10 13440 3328 2488 R 1.656 0.162 0:05.52 gawk
>
> gawk nutzt als einziger Prozess CPU Zeit!
>
> Meines Erachtens ist es übel ein Paket (eisman) mit vielen Unterskripten
> via update zu ersetzten, wenn gerade Skripte mit "Stapelbetrieb" laufen.
>
> Ich vermute, dass das geänderte Locking von eisman hier eine Rolle
> spielt. Ggf. kann Daniel hier ja Näheres beitragen.
Ich hätte da einen anderen Verdacht.
Ein laufendes Skript wird durch ein neues ersetzt während es läuft und setzt
dann an falscher Stelle wieder auf.
Ich habe schonmal, während ein Bash-Skript lief, dieses geändert und
abgespeichert, was das ursprünglich laufende ganz schön aus dem Tritt
gebracht hat.
Vielleicht kommen da auch (g)awk-Skripte aus dem Tritt.
--
Gruß Marcus
[eisfair-Team]
Gruß Marcus
|
|
|
|
| Re: Eiskernel-64-virt 5.4.0 hc3a4nger bei compress backup.tar [Beitrag #83188 ist eine Antwort auf Beitrag #83159] |
Thu, 07 January 2021 10:38 |
Marcus Roeckrath
Beiträge: 15197
Registriert: August 2010
|
Senior Member |
|
|
Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
> Ich habe den Prozess per ssh angestoßen. Auffällig ist, dass auf der
> Maschinenkonsole dabei folgende Ausgabe erschien:
>
> udevd[1292]: specified group 'plugdev' unknown
Hat definitiv nicht mit dem Kernelupdate-Problem zu tun.
Die Group plugdev gibt es als "Spezialität" nur auf Debian/Ubuntu.
SuSE schneidet die Group inzwischen wieder aus der Rules-Datei raus und das
wird dann mit dem nächsten Release der fido2-Pakete auch bei uns der Fall
sein, womit dann die Fehlermeldung auch verschwindet.
--
Gruß Marcus
[eisfair-Team]
Gruß Marcus
|
|
|
|
|
|
|
|
|
|
| Re: Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar [Beitrag #83193 ist eine Antwort auf Beitrag #83191] |
Thu, 07 January 2021 11:33 |
Marcus Roeckrath
Beiträge: 15197
Registriert: August 2010
|
Senior Member |
|
|
Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
>> Ja, aber bislang waren es nur virtualisierte Systeme, von denen ein
>> Problem berichtet wurde.
>>
>> Oder sollten alle Nutzer echter Hardware immer Kernelupdates von anderen
>> Updates separieren.
>>
>> Wäre schon ein seltener Zufall.
>
> aus meiner Sicht ist BEIDES äußerst obskur.
Genau das; laut Wahrscheinlichkeit wäre jeder (auch noch zu seltene) Zustand
möglich, aber eben auch möglicherweise extrem unwahrscheinlich.
> Ansgars Hinweis, den Du ja schon aufgegriffen hast, erscheint mir da
> deutlich plausibler. Aber das sollte dann eben keine Frage von VM oder
> realer HW sein.
Genau das, wieso sollte sich der Austausch von Skripten nur auf virtuellen
Systemen auswirken.
--
Gruß Marcus
[eisfair-Team]
Gruß Marcus
|
|
|
|
| Re: Probleme bei eisman upgrade mit Upgrade von eisman (war: Re: Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar) [Beitrag #83194 ist eine Antwort auf Beitrag #83182] |
Thu, 07 January 2021 11:49 |
Daniel Vogel
Beiträge: 52
Registriert: July 2010
|
Member |
|
|
Hallo zusammen,
Am 07.01.21 um 09:46 schrieb Ansgar Püster:
> Ich vermute, dass das geänderte Locking von eisman hier eine Rolle
> spielt. Ggf. kann Daniel hier ja Näheres beitragen.
die Umgebungsvariable, die das Locking-Verzeichnis festlegt und sich in
der aktuellen eisman-Version geändert hat, wird im Skript
/usr/bin/eisman definiert. Zudem wird das Verzeichnis dort angelegt,
falls es nicht existiert.
Im Stapelupdate ruft die Installationsroutine für jedes Paket die
Deinstallationsroutine auf, die versucht eine Sperre einzurichten. Da
der Aufruf nicht über /usr/bin/eisman erfolgt (sondern direkt), kann die
Sperre nicht eingerichtet werden, wenn das Verzeichnis nicht existiert
und/oder die Variable falsch gesetzt ist. Daher hängt sich eisman in der
Update-Situation an der Stelle auf.
Vorübergehende Lösung:
Ctrl+C drücken und "eisman upgrade" erneut aufrufen.
Zum Thema "übel":
Wenn wir schon von einem Übel sprechen, dann ist es doch eher das, dass
wir eisman vor dem Release nicht im Stapelupdate testen. Es ist aber
nicht grundsätzlich so, dass es nicht in einem Stapel vorkommen darf.
Wenn das Problem vorher erkannt worden wäre hätte es z.B. ausgereicht,
in der vorliegenden Situation auf das Einrichten der Sperre zu verzichten.
Grüße,
Daniel
|
|
|
|
|
|
|
|
| Re: Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar [Beitrag #83197 ist eine Antwort auf Beitrag #83195] |
Thu, 07 January 2021 13:35 |
Marcus Roeckrath
Beiträge: 15197
Registriert: August 2010
|
Senior Member |
|
|
Hallo Stefan,
Stefan Puschek wrote:
>> Offenbar trat das aber nur auf virtualisierten Systemen auf.
>
> Einspruch!!! Meine Backup-Maschine UND der Rettungssystem-Stick laufen
> beide auf echter Hardware - ich schwörs!!!
Stimmt, ist in den sonstigen Meldungen bzgl. virtualisierter Systeme
untergegangen - somit hat sich das Unverständnis bzgl. der betroffenen
Systeme erledigt.
--
Gruß Marcus
[eisfair-Team]
Gruß Marcus
|
|
|
|
| Re: Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar [Beitrag #83205 ist eine Antwort auf Beitrag #83196] |
Thu, 07 January 2021 13:42 |
Marcus Roeckrath
Beiträge: 15197
Registriert: August 2010
|
Senior Member |
|
|
Hallo Heinz-Peter,
Heinz-Peter Faasen wrote:
> Marcus hatte lediglich aufgrund der Meldungen hier den Eindruck, dass
> nur virtuelle Systeme betroffen seien. Allerdings gab es dafür keine
> plausible Erklärung.
> Von daher ist Deine Nachricht jetzt sehr nützlich, denn sie erübrigt
> überflüssige, weil in Sackgassen führende, Denkprozesse.
Ansgars und Daniels Beitrag lenkt die Aufmerksamkeit auch weg vom Kernel und
die Lösung ist damit auch klar und in Arbeit.
--
Gruß Marcus
[eisfair-Team]
Gruß Marcus
|
|
|
|
| Re: Eiskernel-64-virt 5.4.0 hänger bei compress backup.tar [Beitrag #83206 ist eine Antwort auf Beitrag #83205] |
Fri, 08 January 2021 13:37 |
Heinz-Peter Faasen
Beiträge: 1196
Registriert: July 2010
|
Senior Member |
|
|
Hallo Marcus,
> Ansgars und Daniels Beitrag lenkt die Aufmerksamkeit auch weg vom Kernel und
> die Lösung ist damit auch klar und in Arbeit.
ich konnte mir auch nicht recht vorstellen, dass das ein Problem mit dem
Kernel selbst sein sollte. Schließlich machte der weder beim erneuten
Anstoß des Upgrades noch beim Reboot irgendwelche Zicken.
Danke für die Info, dass eine Lösung in Aussicht ist!
Gruß
Heinz-Peter
|
|
|
|
Gehe zum Forum:
aktuelle Zeit: Tue Jan 19 11:40:26 CET 2021
Insgesamt benötigte Zeit, um die Seite zu erzeugen: 0.01825 Sekunden
|
net(t)forum
Mitglieder
Suche
Hilfe
Registrieren
Anmelden
Startseite
