• Café
  • Automatisiertes Paketupgrade

Seit kurzem teste ich ein Skript, das das Systemupgrade automatisch mittels Service/Timer vornimmt und das auch einige Wartungsarbeiten am Paket-Cache und der Mirrorlist automatisch vornehmen kann.

Damit ein eventuelles Scheitern des automatisierten Upgrades beim User nicht lange unbemerkt bleiben kann, sorgt ein zweites Skript dafür, dass auf dem Desktop regelmäßig Nachricht darüber erfolgt, wann der letzte Upgrade-Versuch stattgefunden hat und ob er erfolgreich war.
(Es sind deshalb zwei separate Dienste, weil eine Nachricht auf dem Desktop andere Rechte benötigt als ein Paketupgrade)
Man könnte das zweite Skript auch schnell zu einem reinen `Upgrade-Reminder' abändern, falls das Paket-Upgrade weiterhin manuell stattfinden soll und lediglich daran erinnert werden soll.

Was haltet ihr davon?
Kann der Code noch vereinfacht bzw. verbessert werden?
Sieht jemand ernsthafte Gefahren bei diesem Vorgehen?

//Edit 3.8.2024 : Ich habe den vorläufigen Code an dieser Stelle gelöscht, weil das irritieren kann und zu Fehlern führt s.unten. Die Diskussion bleibt auch ohne den Code klar verständlich, weil die jeweiligen Argumente explizit den jeweiligen Syntax aufführen. Ganz unten steht jetzt das aktuelle Skript incl. Installationsanleitung.

  • Dirk hat auf diesen Beitrag geantwortet.

    paccache -vrk2 || error_handler
    das würde ich vor dem update laufen lassen, dann ist sicher, daß du nur eine (funktionierende) version im cache hast, und keine zweite brauchst => (paccache -rk1

    auch denkbar:

    ExecStartPre=/usr/bin/sh -c 'paccache -vr1'
    ExecStart=/usr/bin/sh -c 'pacman -Syu --noconfirm'

    den reflector start, könnte man sicher auch noch einbauen

    tuxnix Was haltet ihr davon?

    Das schreit doch förmlich danach, Probleme zu verursachen!

    Würde das niemandem empfehlen der sein System produktiv einsetzen möchte.

    • tuxnix hat auf diesen Beitrag geantwortet.
    • GerBra gefällt das.

      Wenn das für dich (in deinem Umfeld) funktioniert, dann finde ich das gut.

      Generell meine Meinung zu automatisierten Updates:

      • NIE solange User angemeldet sind bzw. mit dem System arbeiten.
        Ausnahme: Sicherheits-Updates/Patches
      • NIE ohne eine Möglichkeit zum Rollback
      • NIE ohne daß das Update in eine nachvollziehbare Transaktion eingebunden ist
        Eine Möglichkeit, die pacman leider von Haus aus nicht bietet.
      • NIE nicht eigentlich...
        Ein gesteuertes, regelmäßiges Update erfordert so wenig Zeit daß der Admin diese in den Prozeß investieren können sollte. Es spricht nichts dagegen neue Pakete schon pre-downzuloaden.

      Dein Kriterium für ein erfolgreiches Update ist ja IMHO nur, ob "irgendein" letztes Paketupgrade erfolgreich war. Mir (und dir mit Sicherheit auch) würden auf Anhieb noch drölfzig weitere Möglichkeiten einfallen, die "schief" gehen könnten (Murphy!).

      So ein (bzw. dein) Codeansatz kranken IMHO genauso wie z.B. ein "Installer":
      Der eigentliche Produktivcode (siehe z.B. @brikler's Post oben) ist meistens sehr überschaubar ("läßt sich gut automatisieren"). Problematisch wird die (auch automatisch zu erfolgende) Fehlerbehandlung. Für diesen Part mußt zu das zehn-, hundertfache an Code/Zeit/Gehirnschmalz aufwenden, wenn man es "richtig" machen will/muß.

      @brikler danke für den Tipp, habe oben
      paccache -rk1eingepflegt.
      @Dirk und @GerBra auch vielen Dank, ich brüte jetzt erst mal darüber nach und melde mich dann wieder.

      @tuxnix
      es müssten auch mehrere ExecStartPre= möglich sein
      wie machst du das mit dem db.lck, wenns mal einen gibt?

      • tuxnix hat auf diesen Beitrag geantwortet.

        NIE sollst du mich befragen, noch Wissens Sorge tragen (Lohengrin)

        @GerBra
        Ich habe meinen Ansatz jetzt komplett in Richtung - So gut wie NIE verändert.

        • Ein reminder-script ( timer - minutely ) erinnert nach einem Tag, ohne das ein upgrade stattgefunden hat, zunächst stündlich, später alle halbe Stunde: " x upgrades available. Run: # pacman -Syu"
        • Das upgrade-script (timer - daily) nimmt täglich Wartungsarbeiten vor incl. dem preload von Paketen.
        • Ein automatisches upgrade findet jetzt erst nach x Tagen satt und auch erst dann, wenn alle Erinnern nicht gefruchtet haben.
        • Vor einem automatischen Upgrade erscheint eine rote Warnung: "Upgrade in 2 min: - Save your aktiv documents now and\nkeep system running! - Nach dem Upgrade erscheint die Nachricht: "Upgrade done: - Reboot system now!"
        • Über eine Möglichkeit zum Rollback denke ich noch nach, aber unabhängig von diesem Skript.

        brikler wie machst du das mit dem db.lck, wenn's mal einen gibt?

        Ich weine 😭 und drücke mein tiefstes Bedauern aus 😇.
        Es gibt jetzt ein rotes Warnschild während das upgrade läuft. Ich hoffe es hilft.
        Natürlich kann man auch dann nicht jeden Bedienfehler ausschließen.

        Ein paccache -rk2 ist wieder ans Ende gerutscht und lässt jeweils 2 Paketversionen im cache. Die aktuelle und die vorhergehende. Selbst wenn das Skript ein zweites mal aufgerufen wird, sollte immer noch ein Downgrade möglich bleiben.

        Dirk Das schreit doch förmlich danach, Probleme zu verursachen!

        Das Problem gibt es oft allein schon dadurch, dass man jemanden Linux aufgespielt hat.
        Natürlich könnte man ein Debian stable installieren und kein rolling, aber selbst dort gibt es updates. Und anstatt, dass ich ständig nerven muss, soll lieber ein reminder so lange aufdringlich werden bis die Lektion gefressen ist. 😉 Wie lange und wie oft dies geschieht, bis dann doch das upgrade automatisch erfolgt, kann variieren.

        //Edit 3.8.2024 : Ich habe den vorläufigen Code an dieser Stelle gelöscht, weil das irritieren kann und zu Fehlern führt s.unten. Die Diskussion bleibt auch ohne den Code klar verständlich, weil die jeweiligen Argumente explizit den jeweiligen Syntax aufführen. Ganz unten steht jetzt das aktuelle Skript incl. Installationsanleitung.

          tuxnix Es gibt jetzt ein rotes Warnschild während das upgrade läuft. Ich hoffe es hilft.
          Natürlich kann man auch dann nicht jeden Bedienfehler ausschließen.

          Ich glaube, GerBra ging es mehr um die Situation, wie du bzw. dein Skript sich verhält, wenn es auf eine db.lck trifft. Darauf müsstest du ja auch irgendwie reagieren, also entweder so lange in einer Schleife warten bis sich die Situation erledigt hat (was aber zu einer Endlosschleife führen wird wenn das lockfile nach einem früheren Abbruch stehen geblieben ist), oder den Skript mit Fehlermeldung beenden und die möglicherweise danach noch geplanten Prozesse über den Fehlerstatus informieren.

          • GerBra hat auf diesen Beitrag geantwortet.

            tuxnix NIE sollst du mich befragen, noch Wissens Sorge tragen (Lohengrin)

            War Lohegrin eigentlich auch ein Ritter vom Nie, oder mehr einer der Minnesänger der Tafelrundenritter ;-)

            OnTipic: Was ist denn eigentlich die Intention und die Zielgruppe deines Autoupdate-Procederes? Hast du in deinem Umfeld konkreten Bedarf?

            tuxnix Es gibt jetzt ein rotes Warnschild während das upgrade läuft. Ich hoffe es hilft.
            Natürlich kann man auch dann nicht jeden Bedienfehler ausschließen.

            Martin-MS Ich glaube, GerBra ging es mehr um die Situation, wie du bzw. dein Skript sich verhält, wenn es auf eine db.lck trifft.

            Das wäre ja noch ein einfaches Ding. Wenn das Ziel wirklich ein "automatisches pacman für Alle" sein sollte, dann müßten IMHO wesentlich robustere Prüfungen erfolgen. Vor allem bei/für Systeme, die man nicht "kennt". Was kann denn alles "automatisch schiefgehen" bei so einem Unterfangen? (Das sind nur ungeordnete Gedanken)

            • pacman bricht zwischendrin ab, Strom fällt aus, User fährt Rechner runter,...
              Das kann auch fast alles passieren wenn das Update interaktiv läuft, aber dann ist der Bediener dafür verantwortlich, bekommt es auch direkt mit inkl. "Fehlermeldungen" und muß interaktiv reagieren. Von einem Automat wird erwartet, sowas eben automatisch zu lösen.
            • Kernelupdate ist dabei. 75% aller Hilferufe haben als Ursache ein fehlerhaft erstelltes initramfs-Image bzw. ein nicht passendes, da z.B. die Boot-Partition nicht eingehängt war - zu bootender Kernel und initrd also nicht zusammenpassen.
              Interaktiv ist Mensch dafür verantwortlich, von einem Automat wird erwartet daß sowas abgefangen bzw. bereinigt und automatisch gelöst wird. (Paßt lsinitcpio -a initramfs-*.img ->Version zum dazugehörenden vmlinuz in /boot und ist /boot auch die Partition von der der Bootloader startet?)
            • Der User benötigt zum Boot Fremdtreiber (z.B. aus dem AUR). Wie wird sowas Rechnung getragen? Braucht der "Automat" eine vorher zu erstellende Konfiguration?
            • Bei Nachfragen von pacman während einer interaktiven Sitzung (z.B. nach Programmalternativen): --noconfirm mag da nicht die richtige Auswahl treffen, muß sowas konfigurierbar sein?
            • Es ist (per News z.B.) erforderlich ein händisches Eingreifen während/vor dem Update. Wie behandelt ein Automat solche Situationen? Gibt es gesonderte "Skript-Patches" für den Automat? Woher?

            Abgesehen davon was noch schiefgehen kann ist für einen Automat IMHO Bedingung:

            • Ein wie immer auch als fehlerhaft, unvollständig ermitteltes Update muß der Automat als solches erkennen und behandeln. Entweder durch Lösen der Probleme oder durch Wiederherstellen der Ausgangssituation. Das erwartet der User von einem Automat, dafür macht er diesen VERANTWORTLICH. Der User ist fein raus, er hat ja "nichts gemacht"...<g>
              Ich bin mir nicht sicher, ob pacman's Return-Codes alles während des Procederes abdecken um ein wirklich erfolgreiches Update zu ermitteln.
              Es ist ja aktuell AFAIK nicht mal per pacman.log oder paclog zu ermitteln: Wann war dann eigentlich das letzte erfolgreiche Systemupdate? Es gibt zwar eine Startmeldung, aber keine dem eindeutig zuzuordnende "Finish"-Meldung, also z.B. eine Transaktions-Nummer/Pid. Von einem Status-Code über das Update ganz zu schweigen.

            Arghh, das wird jetzt alles zuviel, nur noch ein paar Gedanken:

            • Snapshots kann nicht jeder. Also müßte sowas wie ein Eintrag im Bootloader erstellt werden der bei einem festgestellten Problem das System z.B. per Rollback (-> ALA) beim nächsten Boot wieder auf den Zeitpunkt vor dem Update zurückrollen kann. Schöner Aufwand...

            • 90% aller pacman-Syu's funktionieren problemlos, auf Systemen die man kennt meist noch mehr. Das Nichtkennen anderer Systeme und die paar Prozent "Restrisiko", die sind das eigentlich Aufwändige. Und dafür wirst du gesteinigt.
              Windows ist ein halbwegs homogenes System, die Entwickler haben ein gutes Bild von der Software mit der sie bei einem Update umgehen müssen. (Arch)-Linux ist ein wilder Bazzar damit verglichen (und das ist auch gut so!).

            • Jeden Ansatz eines Automaten für Updates würde ich an den Zeitpunkt des Herunterfahrens koppeln. Kein eingeloggter/arbeitender User = ein kleines Problem weniger.

            • 80% der Fälle, bei dem mich Bekannte noch mit Ubuntu/Mint/sonstwas kontaktieren rühren von deren automatischen Updates her. Und deren Entwickler sind schon (nur ne Tatsache) eine ganze Ecke weiter als du mit deinem Ansatz.

            Im ersten Post führte ich den/einen "Installer" an, um dir ggf. den Aufwand für ein wie immer auch geartetes Automaten vor Auge zu führen.
            Ich bin wirklich riesenfroh das Archlinux keinen Installer mehr braucht(hat).
            Gerade weil die (eigentlich wenigen) Schritte zur Hardware-Konfig und Bootstrapping leicht dokumentierbar sind und:

            • der erfahrene User keine Bremsklötze verpaßt bekommt
            • der nicht erfahrene User selbst in der Verantwortung steht (oftmals z.B. einfach nur richtig lesen zu können)

            Stell dir mal vor, ein Automat sollte auch nur annähernd alles abfangen, "handeln" können, was so hier im Forum (oder der Pinguin bewahre uns!) auf .org aufschlägt.
            Und bei einem Update-Automaten ist es IMHO sogar noch schwieriger (noch mehr Code), da du ja nicht nur z.B. ein System nicht installieren kannst, sondern eines ggf. "kaputt" machst. Schreib schon mal den Disclaimer... <g>

            Sorry für überlanges (wirres) Posting. Ich finde du solltest halt sowas nur tun in einem Umfeld was du kennst und bei dem die Leute dich nicht gleich an die Wand stellen wollen.

            //Edit:
            Und: Kritisieren ist immer leicht. Der "Kritisierende" ist in der komfortablen Situation ungestraft viel mehr "Scheiß" von sich geben zu können als derjenige, der "kritisiert" wird. Und: er mußte nicht mal halb soviel "abliefern" als derjenige mit der "Idee"...
            Also: nicht in den falschen Hals kriegen und nicht entmutigen lassen wenn es dir wirklich wichtig ist.

            • tuxnix hat auf diesen Beitrag geantwortet.

              Man könnte den ganzen Automatismus auch weg lassen, und den User in die Verantwortung nehmen, das System „interaktiv“ zu updaten.

              # file: /etc/systemd/system/pacman-db-update.timer
              
              [Unit]
              Description = Package database update timer
              
              [Timer]
              OnCalendar = daily
              Unit = pacman-db-update.service
              
              [Install]
              WantedBy = multi-user.target
              # file: /etc/systemd/system/pacman-db-update.service
              
              [Unit]
              Description = Update package database
              
              [Service]
              ExecStart = pacman -Sy

              Und den Timer dann entsprechend im root-Kontext aktivieren, damit wird täglich die Pacman-Datenbank aktualisiert und Fehler auch entsprechend geloggt. (Denn die DB gelockt ist, z.B.)

              Dann im User-Kontext das „Gegenstück“ einrichten, das bei Updates alle Viertelstunde eine Notification sendet:

              # file: ~/.local/share/systemd/update-notifier.timer
              
              [Unit]
              Description = Update notification timer
              
              [Timer]
              OnCalendar = *:0,15,30,45
              Unit = update-notifier.service
              
              [Install]
              WantedBy = multi-user.target
              # file: ~/.local/share/systemd/update-notifier.service
              
              [Unit]
              Description = Notify about updates
              
              [Service]
              ExecStart = [ $(pacman -Qu | wc -l) -gt 0 ] && notify-send -a "Update verfügbar" "Es stehen $(pacman -Qu | wc -l) updates zur Installation bereit!"

              So aus dem Kopf heraus. Das geht sicher auch eleganter. Wobei ich auch nicht sicher bin, ob systemd in units Bash-Syntax mag. Stattdessen kann man da aber auch ein Script angeben, in dem man das ganze auch noch ein bisschen schöner machen kann, mit Icon, etc.

                Erst einmal herzlichen Danke für den vielen Input.
                Die Antwort folgt dann nach und nach. 🤔

                Zur: db.lck

                Der Normalfall ist, die /var/lib/pacman/db.lck ist nicht vorhanden.
                Die Funktion ist: Wird pacman aktiviert dann soll mit der db.lck die db vor paralellem Zugriff geschützt werden.
                Der Störfall ist: Die Datei existiert, aber es läuft kein Prozess der darauf zugreift.
                Siehe: https://wiki.archlinux.org/title/Pacman#%22Failed_to_init_transaction_(unable_to_lock_database)%22_error
                Das hab' ich jetzt mal eingefügt:

                if [ -f /var/lib/pacman/db.lck ] && [ ! $(pgrep -f /var/lib/pacman/db.lck) ]; then  # pgrep pacman
                    notify-send "Something went wrong. Read:" "ArchWiki - pacman database lock"
                    exit 1
                fi

                Das Skript muss nicht alles automatisch fixen. Der User muss nur wissen, dass etwas nicht stimmt und Informationen erhalten.
                Leider geht seit qt6 die Darstellung als Link nicht mehr, sonst hätte ich in der Notiz gleich zum Wiki Artikel verlinkt.

                • Martin-MS hat auf diesen Beitrag geantwortet.

                  Dirk ob systemd in units Bash-Syntax mag

                  nein, das mag systemd nicht, das müsste in einer eigenen shell laufen, zb:
                  ExecStart =/usr/bin/<shell> [ $(pacman -Qu | wc -l) -gt 0 ] && notify-send -a "Update verfügbar" "Es stehen $(pacman -Qu | wc -l) updates zur Installation bereit!"

                  Dirk Und den Timer dann entsprechend im root-Kontext aktivieren, damit wird täglich die Pacman-Datenbank aktualisiert und Fehler auch entsprechend geloggt.

                  Vor der Aktualisierung der Paketdatenbank ohne nachfolgendes Systemupdate kann ich nur warnen. Wenn nämlich der Benutzer danach ein Paket (und möglicherweise noch weitere Abhängigkeiten darauf) installiert und dieses Paket seit dem letzten Systemupdate anbieterseitig aktualisiert wurde, passen die Dateien nicht mehr zum restlichen System und man bekommt den typischen Zustand eines teilaktualisierten Systems, mit den bekannten Risiken.

                  ExecStart = [ $(pacman -Qu | wc -l) -gt 0 ] && notify-send -a "Update verfügbar" "Es stehen $(pacman -Qu | wc -l) updates zur Installation bereit!"

                  Dafür gibt es extra den Skript checkupdates aus dem pacman-contrib-Paket, das aus gutem Grund eben nicht die Paketdatenbank aktualisiert, sondern statt dessen unter /tmp Kopien der Master- und lokalen Datenbank abstellt und mit diesen den Vergleich auf aktualisierte Pakete durchführt. Das kann insbesondere auch von jedem Benutzer und nicht nur von root durchgeführt werden.
                  Da das Skript mit einem abfragbaren Status verlassen wird (2 No updates are available) erübrigt sich auch die Umleitung nach wc um die ausgegebenen Zeilen zu zählen.

                  • Dirk hat auf diesen Beitrag geantwortet.
                  • Dirk gefällt das.

                    Martin-MS Ich gehe natürlich vom Idealfall aus, dass der Anwender sofort nach der ersten Benachrichtigung ein Systemupdate fährt, und natürlich auch davon, dass der Anwender immer erst ein Systemupdate macht, bevor ein Paket explizit installiert wird. 🙂

                    Das checkupdate-Script ist tatsächlich besser als mein müde zusammengekloppter Einzeiler 👍 Einen wie beschrieben laufenden Updatebenachrichtiger sollte man daher natürlich besser um dieses Script herum bauen, da schenkt man sich dann auch gleich die Zweiteilung.

                    tuxnix Leider geht seit qt6 die Darstellung als Link nicht mehr, sonst hätte ich in der Notiz gleich zum Wiki Artikel verlinkt.

                    Versuche folgendes:
                    notify-send "Pacman database locked" "<a href='https://wiki.archlinux.org/title/Pacman#%22Failed_to_init_transaction_(unable_to_lock_database)%22_error'>How to solve the problem</a>"

                    • tuxnix hat auf diesen Beitrag geantwortet.

                      Martin-MS
                      Danke für den Tipp, aber genau das hatte ich schon probiert.
                      Leider wird das <a href="xyz">Link</a> von notify-send nur als html code dargestellt und nicht als anklickbarer Link
                      Und das war letztes Jahr noch anders.
                      Klappt das denn bei dir?

                      Habe einen Fehler in meinem reminder skript entdeckt.
                      Es muss [ $((86460%3600)) -lt "60" ] heißen und nicht [ $((86460%3600)) -eq "0" ], weil der timer nur jede Minute einmal in Aktion tritt, also ein mal in einem 60 sec intervall.
                      Ich verbesser das oben im Post wo das script steht, die Bedingung für die db.lck Sache ist dann auch gleich mit enthalten.

                      • Martin-MS hat auf diesen Beitrag geantwortet.

                        GerBra Das wäre ja noch ein einfaches Ding. Wenn das Ziel wirklich ein "automatisches pacman für Alle" sein sollte, dann müßten IMHO wesentlich robustere Prüfungen erfolgen.
                        Hat man das upgrade durchgeführt, wird man einen Tag in Ruhe gelassen.

                        Nein, ach du jeh , ein - automatisches pacman für alle - soll es gerade nicht werden.
                        Es soll lediglich informieren und dazu animieren ein pacman -Syu selbst durchzuführen und nur dann, wenn dies trotz zunehmend aufdringlich werdender Aufforderungen immer noch nicht erfolgt, erst dann soll das upgrade auch mal automatisch erfolgen.

                        Mir geht es um die Fälle menschlicher Natur, denen ich Arch Linux aufgespielt habe, die aber ohne eine Erinnerung keine upgrades durchführen. Die möchte ich da sanft heranführen es von ganz allein zu tun.
                        Neulich hab ich einen Freund besucht, Arch Linux lief immer noch munter auf dem Rechner, aber 2 Jahre lang war kein einziges update gemacht. Das ist der Störfall den ich vermeiden möchte. Wenn so etwas passiert, dann möchte ich gar niemanden mehr Linux aufspielen.

                        Zu deinen Unterpunkten:

                        • Stromausfall, kann ich nicht beeinflussen. Dazu aber weiter unten mehr. Gegen "Rechner während des upgrades runter fahren" gibt es jetzt die Warnung wenn das upgrade im Hintergrund läuft.
                        • Kernelupdates müssen beim manuellen pacman -Syu auch klappen.
                        • Kram aus dem AUR müssen die Leute selbst installieren und selbst warten können.
                          Je nachdem was dort installiert wird, kann es auch keinen automatischen Schutz davor geben.
                        • Bei Nachfragen von pacman während einer interaktiven Sitzung (z.B. nach Programmalternativen)
                          Die default Auswahl genügt. Der User der nicht selbst seine Updates fährt, muss von der Stange nehmen.
                        • Manuelles Eingreifen erforderlich Dazu muss ich mir erst noch Gedanken machen, wie ich die neueste Archnews mit notiy-send auf den Bildschirm zaubere.
                          Eigentlich müsste pacman so gestaltet werden, dass es selbstständig die Liste der installierten Pakete durchsucht und falls ein manueller Eingriff notwendig wird, die News anzeigt und falls notwenig dann sogar das upgrade mit entsprechender Fehlermedung abbricht. Nur mal so eine Idee dazu.
                          Insgesamt ist bei pacman ja schon viel passiert in der Richtung. Die j/n Kasskaden von früher gibt es nicht mehr. Mit Bestätigung der Vorauswahl läuft es eigentlich jetzt immer durch. Wahrscheinlich weil es jetzt auch so Sachen wie discover und software gibt, die das upgrade automatisch fahren.
                          Ja, ein Systemupgrade erfolgreich beendet fehlt im pacman.log
                        • Snapshots - Ich finde snapshots unnötig. Bisher bin ich immer mit einem paket-downgrade ausgekommen falls mal was hängt. Ohnehin benötige ich eine Sicherung auf einem getrennten Medium.
                          Um beides zu gewährleisten wäre eigentlich ein A/B boot system auf zwei getrennten Datenträgern ideal. Auf dem jeweils inaktiven findet das upgrade und die Datensicherung statt.
                          Dann bliebe das laufende System intakt, falls mal etwas beim upgrade schief läuft und der User in seiner Sitzung ungestört.
                        • War das jetzt nicht Windows, das gerade die halbe Welt mit einem automatischen System lahm gelegt hat? Nein, so etwas brauchen wir nicht. 😉

                        Jeden Ansatz eines Automaten für Updates würde ich an den Zeitpunkt des Herunterfahrens koppeln. Kein eingeloggter/arbeitender User = ein kleines Problem weniger.

                        Ist aber auch nervig. Und wenn dann mal etwas schief läuft, merkt der User es erst, wenn er den Rechner dringend braucht. Eine Freundin von mir schaltet auch immer den Strom an der Steckerleiste aus. Es gibt wirklich nichts was nicht auch vom user sabotiert werden könnte.

                        Danke dir für das Bainstorming und die vielen Punkte, die es dabei zu bedenken gilt.
                        Es ist gut das alles mal gründlich durchzugehen.
                        Aber wie schon oben bemerkt, das skript dient in erster Linie der Pädagogik und soll dazu animieren, ein manuelles upgrade durchzuführen. Zum automatischen upgrade kommt es erst wenn das alles nicht hilft und dann natürlich auf Verantwortung des users.
                        "Wer nicht hören will, muss...."

                        Lohegrin ist ein sagenhafter Superheld aus dem schwülstigen Wagneruniversum.
                        Natürlich klappt es mit dem NIE bei ihm auch nicht so ganz wie vorgesehen.
                        Vielleicht hätte ich auch "Sag niemals NIE" von 007 rezitieren sollen. 😉

                        Ich bekomme jetzt (1 Tag nachdem ich das skript aktiviert habe) sündlich eine Meldung:
                        "29 upgrades available. Run: # pacman -Syu"

                        Morgen wechselt die Farbe der Nachricht von grün auf gelb und der Takt auf halbstündiges Nerven.

                        Zusätzlich werden die mirrors aktuell gehalten und das paket cache geleehrt. Was ja auch schon recht beliebte Störfälle vermeiden hilft. Und zusätzlich wird auch das manuelle upgrade beschleunigt weil die meisten pakete schon vorab herunter geladen wurden.

                        • GerBra hat auf diesen Beitrag geantwortet.

                          tuxnix Es ist gut das alles mal gründlich durchzugehen.
                          Aber wie schon oben bemerkt, das skript dient in erster Linie der Pädagogik und soll dazu animieren, ein manuelles upgrade durchzuführen. Zum automatischen upgrade kommt es erst wenn das alles nicht hilft und dann natürlich auf Verantwortung des users.

                          Gut, das sehe ich ein. Ich handhabe das bei den wenigen "Fällen" die ich habe so, daß dann eben kein Update erfolgt, außer ich weiß definitiv von sicherheitsrelevanten Vorgängen. Irgendwann erledige ich dann halt mal ein "großes" Update. Ein selbständiges Update halte ich da für aussichtslos, ein Automatismus scheidet da aus, v.a. da ich dann nicht mehr den Zeitpunkt bestimmen kann wann ggf. um "Hilfe" gerufen wird.

                          Evtl. noch mal ein paar praktische Hinweise rund um pacman für dein Vorhaben, die ich mit der Zeit teils nutze:

                          • Die pacman-Hooks sind sehr mächtig, v.a. interessant die PreTransaction-Hooks.
                            V.a. deshalb, da zu dem Zeitpunkt noch nichts am System verändert wurde (außer DB-Sync)
                            Ich war mal dran etwas zu implementieren was die zu updatenden Pakete nach einer Auswahl hin durchsucht und je nach Kriterium den Update-Prozeß unterbrechen kann //Edit: bzw. genauer: erst gar nicht startet). Das konnten z.B. Kernel-Updates sein, oder - meine Intention damals - für bestimmte Pakete Major/Epoch-Upgrades oder Minor=0 Upgrades("= ggf. "Beta" einer neuen Major-Version). In diesen Fällen sollte ein pacman -Syu sich eben mit entsprechendem Hinweis beenden, um ggf. noch bestimmte Maßnahmen vorher durchführen zu können. Z.B. Obacht: es wird eine neue Gnome/KDE-Version installiert. Also dasselbe, was man per Lesen/Überfliegen der Paketupdate-Liste nach einiger Zeit intuitiv draufhat.
                            Ich habe das außer im Ansatz leider nicht mehr verfolgt.

                          • Zur pacman-Log und dem Feststellen des Status eines Updates
                            Evtl. wäre das mal ein Feature-Request wert, zum Vorgang eines Updates eine Transaktions-Nummer/Status zu implementieren, v.a. da libalpm das AFAIK von Haus aus kann/tut.
                            Meine Idee war/ist einen "Wrapper" rund um "pacman -Syu" zu legen, der per /usr/bin/logger eine generierte Transaktions-Nummer/Text hinterlegt (z.B. PID+Zufallszahl) und bei erfolgreichem Update eine dazugehörige "Beendet" Meldung, ebenfalls mit obiger Nummer und Status-Text. So wäre im pacman.log oder per paclog ermittelbar: Wann wurde das letzte erfolgreiche Update durchgeführt - Transaktions-Nummern von Start/Stop müssen aufeinanderfolgen und der "Status" muß OK sein.

                          Snapshots: Ich finde das die beste Methode, um unproblematisch einen bestimmten Zustand zu sichern und wiederherzustellen. Deswegen schaue ich immer, entweder Dateisysteme oder Volume-Manager zu verwenden, die sowas anbieten. V.a. aus dem Grund, daß ich dadurch Zeitpunkt(oder Ort/Art) bestimmen kann, wann ich bei einem etwaigen Problem mich mit "Frickelei am Lebenden" rumschlagen will/muß.

                          tuxnix Um beides zu gewährleisten wäre eigentlich ein A/B boot system auf zwei getrennten Datenträgern ideal

                          Oder man führt das Upgrade(oder die Aktion) im "Snapshot" durch, läßt also den aktuellen Zustand unverändert. Erst auf "Zuruf" würde dann der neue Zustand aktiv werden.