• Arch Linux
  • Warnung bei pacman -Syyu: Was soll ich davon halten?

Hallo zusammen,

gerade habe ich einen Laptop nach vielen Monaten (von Kernel 6.10.3 auf Kernel 6.12.1) per pacman -Syyu geupdatet. Dabei erschien eine Warnung.

...
(366/394) Aktualisiert wird sudo                   [######################] 100%
Warnung: /boot/syslinux/syslinux.cfg wurde als /boot/syslinux/syslinux.cfg.pacsave gespeichert
(367/394) Aktualisiert wird syslinux               [######################] 100%
Syslinux BIOS update successful
(368/394) Aktualisiert wird systemd-sysvcompat     [######################] 100%
...

Was mich verwirrt, ist, das keine syslinux.cfg.pacsave angelegt wurde.
Eine syslinux.cfg ist vorhanden und hat den aktuellen heutigen Zeitstempel.

Muss ich mir deswegen Sorgen machen?

Beste Grüße

Edward

  • Martin-MS hat auf diesen Beitrag geantwortet.
    1. Warum benutzt du -yy anstatt -y?
    2. Hast du eine separate Partition für /boot?
    3. War diese zum Zeitpunkt des Updates unter /boot gemountet?
    4. Was war die Ausgabe von pacdiff (welches du nach jedem Upgrade ausführen solltest)?

      schard

      @1: pacman -Syyu: Das mache ich schon seit Urzeiten so.
      @2: Ja, /boot hat eine seperate Partition
      @3: Das kann ich nicht sicher beantworten (der Rechner war an, also sollten doch alle Partitionen eingebunden worden sein, oder?)
      @4: pacdiff habe ich noch nie benutzt.

        Edward d'Eath 4: pacdiff habe ich noch nie benutzt.

        Ich in meinen 13 Jahren Arbeit mit Arch-Derivaten auch noch nicht.
        Mir waere auch neu, das Archlinux so viel Aufmerksamkeit beim Aktualisierungsvorgang einfordert.

        pacdiff ist ein Skript, das in den Sicherungseinträgen der lokalen Pacman-Datenbank nach *.pacorig-, *.pacnew- und *.pacsave-Dateien sucht. Für jede der gefundenen Dateien können Sie auswählen, ob Sie die gefundenen *.pacorig-, *.pacnew- oder *.pacsave-Dateien betrachten, überspringen, die Unterschiede anzeigen, zusammenführen, sie löschen oder überschreiben wollen.

        Geben Sie einfach pacdiff -s ein und es wird sudoedit ausgeführt, um die Dateien zusammenzuführen. Verwenden Sie v , um vim mit der Pacnew-Datei auf der linken Seite und der Arbeitsdatei auf der rechten Seite mit dem Fokus auf der Pacnew-Datei zu öffnen. Gehen Sie die geänderten Blöcke mit ]c und dann dp durch, um den Block in die Arbeitsdatei zu verschieben, oder bearbeiten Sie die Arbeitsdatei nach Ihren Wünschen. Beenden Sie dann vim und geben Sie r ein, um das Pacnew zu entfernen. Manchmal kann ich Änderungen am Pacnew mit do abrufen (z. B. wenn Sie hauptsächlich die Pacnew-Version möchten) und dann o zum Überschreiben mit Pacnew.

        Und das soll so oder aehnlich angeblich nach jeder Aktualisierung gemacht werden, wenn pacdiff eine Aenderung bemerkt hat?
        Es soll Leute geben, die noch etwas anderes zu tun haben, als staendig zu kontrollieren, ob Arch alles richtig gemacht hat.

        • Martin-MS hat auf diesen Beitrag geantwortet.

          Archibaldo Es soll Leute geben, die noch etwas anderes zu tun haben, als staendig zu kontrollieren, ob Arch alles richtig gemacht hat.

          Du scheinst trotz (oder wegen?) deiner 13 Jahren Arbeit mit Arch-Derivaten immer noch nicht die von pacman angewandten Mechanismen verstanden zu haben.

          Es geht nicht um die Kontrolle, ob Arch alles richtig gemacht hat. Wenn pacman feststellt, dass sich eine Datei des Installationspakets von der auf dem System installierten Datei unterscheidet, was typisch bei Konfigurationsdateien der Fall ist, dann wird diese Datei nicht einfach ersetzt sondern als Kopie abgestellt, und es ist eine Benutzeraktion erforderlich.

          Es kommt durchaus vor, dass Entwickler Änderungen am Format ihrer Konfigurationsdateien vornehmen, sei es dass neue Variablen hinzukommen oder sich Bezeichner ändern. Wenn die Konfigurationsdatei nicht mehr zur Anwendung passt, kann es zu mehr oder weniger gravierenden Fehlfunktionen kommen.

          Wie sollte sich denn Arch verhalten, so dass es dir genehm ist? Einfach die bestehende Konfiguration mit der aktuellen Fassung unter Verlust der eigenen Modifikationen überschreiben, um die Programmfunktion sicherzustellen? Oder die eigenen Modifikationen respektieren und die Datei nicht ersetzen? Beides würde zu Problemen führen, und deswegen ist ein Benutzereingriff unerlässlich, indem eigene Modifikationen in die vom Entwickler bereitgestellte Konfigurationsdatei übernommen werden müssen. Wer glaubt das nicht machen zu müssen, muss sich später nicht ausheulen, wenn etwas nicht mehr so wie gewohnt oder erwartet läuft.

          Das machen andere Distributionen übrigens ähnlich. Bei Debian wird man beispielsweise direkt während der Installation gefragt, wie mit den geänderten Dateien verfahren werden soll. Hier muss man sofort eine Entscheidung treffen, während dieser Prozess bei Arch nachgelagert ist. Entbehrlich ist er aber nie, auch wenn du es noch nie gemacht hast und auch keine Notwendigkeit darin siehst; da arbeitest du eben auf eigenes Risiko.

          Edward d'Eath Das kann ich nicht sicher beantworten (der Rechner war an, also sollten doch alle Partitionen eingebunden worden sein, oder?)

          Dann guck mal nach. Wenn du die separate /boot Partition umountest und es dann noch unter /boot einen Verzeichnisbaum gibt, welcher z.B. die Datei in Frage enthält, war die separate /boot Partition während des Updates wohl nicht gemountet und du darfst dich auf Probleme einstellen.
          Ansonsten wäre es mysteriös, dass pacman von *.pacsave Dateien berichtet, welche nicht existieren.

          Also am besten mal die Ausgaben von

          # stat /boot/syslinux/syslinux.cfg.pacsave

          posten. Ein Mal mit und ein Mal ohne gemountete /boot Partition.

          Edward d'Eath @1: pacman -Syyu: Das mache ich schon seit Urzeiten so.

          https://unix.stackexchange.com/a/762068/599405

            4 Tage später

            schard

            cat /etc/fstab

            # Static information about the filesystems.
            # See fstab(5) for details.
            
            # <file system> <dir> <type> <options> <dump> <pass>
            # UUID=ce681908-5c76-4260-978d-2e49c1c40bc5 LABEL=root
            # /dev/sda3									/ext4	rw,relatime	0 1
            UUID=ce681908-5c76-4260-978d-2e49c1c40bc5	/		ext4	rw,relatime	0 1
            
            # UUID=269d7307-45d0-4e08-9fec-ef8965d12b6c LABEL=boot
            # /dev/sda1									/boot	ext4	rw,relatime	0 2
            UUID=269d7307-45d0-4e08-9fec-ef8965d12b6c	/boot	ext4	rw,relatime	0 2
            
            # UUID=f652b902-73bd-43f0-b080-8c74878bcff8 LABEL=home
            # /dev/sda4									/home	ext4	rw,relatime	0 2
            UUID=f652b902-73bd-43f0-b080-8c74878bcff8	/home	ext4	rw,relatime	0 2
            
            # UUID=a7b0d875-6838-4bd2-afaa-ba877d20d8dc LABEL=swap
            # /dev/sda2									none	swap	defaults	0 0
            UUID=a7b0d875-6838-4bd2-afaa-ba877d20d8dc	none 	swap	defaults	0 0
            

            /boot mounted

            # ls -ali /boot/
            insgesamt 171636
               2 drwxr-xr-x  4 root root      4096 27. Nov 13:27 .
               2 drwxr-xr-x 17 root root      4096 27. Nov 13:26 ..
              77 -rw-------  1 root root 138538285 27. Nov 13:27 initramfs-linux-fallback.img
              76 -rw-------  1 root root  15302723 27. Nov 13:27 initramfs-linux.img
              12 -rw-r--r--  1 root root   8139776 12. Nov 18:20 intel-ucode.img
              11 drwx------  2 root root     16384 25. Feb 2021  lost+found
            8193 drwxr-xr-x  2 root root      4096 27. Nov 13:27 syslinux
              75 -rw-r--r--  1 root root  13734400 27. Nov 13:27 vmlinuz-linux
            

            /boot unmounted

            # ls -ali /boot/
            insgesamt 8
            786433 drwxr-xr-x  2 root root 4096 25. Feb 2021  .
                 2 drwxr-xr-x 17 root root 4096 27. Nov 13:26 ..
            

            /boot mounted

            stat /boot/syslinux/syslinux.cfg.pacsave

            # stat /boot/syslinux/syslinux.cfg.pacsave
            stat: der Aufruf von statx für '/boot/syslinux/syslinux.cfg.pacsave' ist fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
            
            

            /boot unmounted

            stat /boot/syslinux/syslinux.cfg.pacsave

            <nix, nada, niente>
            

            Ich denke mal, dass eine mögliche Erklärung im .INSTALL-Skript des syslinux-Pakets zu finden ist:

            post_upgrade() {
              # Move /boot/syslinux/syslinux.cfg back now that it is not packaged anymore.
              if [ ! -f /boot/syslinux/syslinux.cfg -a -f /boot/syslinux/syslinux.cfg.pacsave ]; then
                mv /boot/syslinux/syslinux.cfg.pacsave /boot/syslinux/syslinux.cfg
              fi

            Demnach befindet sich /etc/syslinux.cfg nicht mehr im Paket und wird deswegen bei einer Aktualisierung in eine .pacsave-Datei umbenannt, was dann die Meldung von pacman auslöst.

            In der Folge wird dann geprüft, ob sich keine reguläre Datei /boot/syslinux/syslinux.cfg aber eine /boot/syslinux/syslinux.cfg.pacsave auf dem Dateisystem befindet, und wenn das zutrifft wird /boot/syslinux/syslinux.cfg.pacsave nach /boot/syslinux/syslinux.cfg umbenannt und damit wieder der ursprüngliche Zustand hergestellt.

            Das würde dann auch erklären, warum du keine syslinux.cfg.pacsave findest.

            Für

            Edward d'Eath Eine syslinux.cfg ist vorhanden und hat den aktuellen heutigen Zeitstempel.

            habe ich allerdings keine Erklärung, denn alleine durch das Umbenennen der Dateien ändert sich der Zeitstempel nicht; dazu müsste man schon an den Inhalt gehen.

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

              Martin-MS
              Das erklärt es... und macht die Meldung von pacman aber irreführend.
              Ich würde einen Bug-Report schreiben, habe aber keinen Bock mich mit der 2FA auseinanderzusetzen.

              • Martin-MS hat auf diesen Beitrag geantwortet.

                schard Das erklärt es... und macht die Meldung von pacman aber irreführend.

                Aus meiner Sicht hat pacman nichts falsch gemacht; woher soll er denn zum Zeitpunkt der Installation wissen, dass der Paketbetreuer im Nachgang die Aktion wieder rückgängig machen wird?
                Für Irritation hat eher die Rücknahme durch den Paketbetreuer geführt, er hätte vielleicht danach eine Meldung ausgeben sollen, dass er die Datei umbenannt hat.

                • schard hat auf diesen Beitrag geantwortet.