[DE] [Gelöst] Titel im systemd-boot-Menu

[helux]

Hallo scholle1,
sollte im Menü nicht eigentlich auch die Kernelversion auftauchen?

Code: [Select]

bootctl list
         type: Boot Loader Specification Type #1 (.conf)
        title: Debian GNU/Linux trixie/sid (default) (selected)
           id: siduction-xfce-6.11.10-1-siduction-amd64.conf
       source: /boot//loader/entries/siduction-xfce-6.11.10-1-siduction-amd64.conf
     sort-key: debian
      version: 6.11.10-1-siduction-amd64
        linux: /boot//siduction-xfce/6.11.10-1-siduction-amd64/linux
       initrd: /boot//siduction-xfce/6.11.10-1-siduction-amd64/initrd.img-6.11.10-1-siduction-amd64
      options: root=UUID=bea05745-8e84-4eb8-932a-962038249826 ro quiet systemd.show_status=1 systemd.machine_id=b856f049e75d4cdca8aa>

         type: Boot Loader Specification Type #1 (.conf)
        title: siduction Giants XFCE (6.11.9-1-siduction-amd64)
           id: siduction-xfce-6.11.9-1-siduction-amd64.conf
       source: /boot//loader/entries/siduction-xfce-6.11.9-1-siduction-amd64.conf
     sort-key: siduction
      version: 6.11.9-1-siduction-amd64
        linux: /boot//siduction-xfce/6.11.9-1-siduction-amd64/linux
       initrd: /boot//siduction-xfce/6.11.9-1-siduction-amd64/initrd.img-6.11.9-1-siduction-amd64
      options: root=UUID=bea05745-8e84-4eb8-932a-962038249826 ro quiet systemd.show_status=1 systemd.machine_id=b856f049e75d4cdca8aa>


[scholle1]

Bei dir abhängig von deinem System und dem Ablauf im vorherigen Thread.

Welches Dateisystem für / ?

Vorheriger Thread:
Ablauf?
DU -> Fehler und danach, wie den Fehler behoben?

[helux]

Dateisystem für / ist ext4

zum Ablauf:
hatte ein apt update && apt full-upgrade gemacht -> keine Fehlermeldung

Nach einem Neustart wegen neuem Kernel (6.11.10-1) war der Eintrag zunächst wie folgt:
1. Debian GNU/Linux trixie/sid
2. siduction Giants XFCE (6.11.9-1-siduction-amd64)
3. siduction Giants XFCE (6.11.8-1-siduction-amd64)

bei einem zwischenzeitlichen "apt autoremove"  wurde dann der Kernel 6.11.8-1 entfernt. Die Anzeige im Bootmenü ist seitdem:
1. Debian GNU/Linux trixie/sid
2. siduction Giants XFCE

Code: [Select]

bootctl list
type: Boot Loader Specification Type #1 (.conf)
        title: Debian GNU/Linux trixie/sid (default) (selected)
           id: siduction-xfce-6.11.10-1-siduction-amd64.conf
       source: /boot//loader/entries/siduction-xfce-6.11.10-1-siduction-amd64.conf
     sort-key: debian
      version: 6.11.10-1-siduction-amd64
        linux: /boot//siduction-xfce/6.11.10-1-siduction-amd64/linux
       initrd: /boot//siduction-xfce/6.11.10-1-siduction-amd64/initrd.img-6.11.10-1-siduction-amd64
      options: root=UUID=bea05745-8e84-4eb8-932a-962038249826 ro quiet systemd.show_status=1 systemd.machine_>

         type: Boot Loader Specification Type #1 (.conf)
        title: siduction Giants XFCE
           id: siduction-xfce-6.11.9-1-siduction-amd64.conf
       source: /boot//loader/entries/siduction-xfce-6.11.9-1-siduction-amd64.conf
     sort-key: siduction
      version: 6.11.9-1-siduction-amd64
        linux: /boot//siduction-xfce/6.11.9-1-siduction-amd64/linux
       initrd: /boot//siduction-xfce/6.11.9-1-siduction-amd64/initrd.img-6.11.9-1-siduction-amd64
      options: root=UUID=bea05745-8e84-4eb8-932a-962038249826 ro quiet systemd.show_status=1 systemd.machine_>

         type: Automatic
        title: Reboot Into Firmware Interface
           id: auto-reboot-to-firmware-setup
       source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f


[scholle1]

Dateisystem für / ist ext4

Das war wichtig.

bei einem zwischenzeitlichen "apt autoremove"  wurde dann der Kernel 6.11.8-1 entfernt. Die Anzeige im Bootmenü ist seitdem:
1. Debian GNU/Linux trixie/sid
2. siduction Giants XFCE

Das ist dann folgerichtig. Kann man ändern,  siehe unten.

Erklärung zum derzeitigen Menü:
Nr. 2 stammt noch von siduction-btrfs Version 0.2.0
Nr. 1 wurde mit (bzw. ohne) Version 0.3.0 erstellt.

Erklärung zu den siduction-btrfs Versionen:
Version 0.2.0 wurde immer installiert, egal welches Dateisystem für / verwendet wurde.
Das hat mir nie so richtig gefallen.
Ab Version 0.3.0 wird siduction-btrfs nur noch installiert, wenn / auf Btrfs beheimatet ist.
Deshalb benötigen wir für eine Übergangszeit von max. 2 Jahren über das übliche Maß
hinausgehende pre- und post-Installationsskripte. Dort hat sich der im vorherigen Thread
beschriebene Fehler eingeschlichen.
Mit dieser Version wird siduction-btrfs auf Systemen ohne Btrfs stillgelegt.

Korrektur deines Menüs:
Lösche

Code: [Select]

/boot/loader/entries/siduction-xfce-6.11.9-1-siduction-amd64.conf
und das Verzeichnis
/boot/siduction-xfce/6.11.9-1-siduction-amd64/
Der default Eintrag "Debian GNU/Linux trixie/sid" bleibt erhalten.
Er wurde von systemd-boot erstellt und nicht mehr von siduction-btrfs geändert.
Die Kernelversion zeigt systemd-boot nur dann zusätzlich an, wenn zwei identische
Einträge vorliegen.
Anschließend konfigurierst du den alten Kernel neu, wodurch systemd-boot auch
für ihn einen Booteintrag erzeugt. Da jetzt der Titeltext für beide Einträge gleich
ist, erscheint im Menü auch die Kernelversion.

Code: [Select]

dpkg-reconfigure linux-image-6.11.9-1-siduction-amd64Das sollte es gewesen sein und siduction-btrfs belästigt dich nicht mehr.

[helux]

Das hat funktioniert. Danke auch für deine Erläuterungen dazu. Das erleichtert das Verständnis enorm. Find ich gut.

[scholle1]

[...] Das erleichtert das Verständnis enorm. [...]

Dann noch eine Ergänzung zu siduction-btrfs.
Warum überhaupt das Bootmenü manipulieren?

Ganz einfach. Weder GRUB noch systemd-boot sind bei Btrfs Systemen in der Lage
nach einem Rollback Booteinträge zu generieren, die genau dem Zustand des Rollbackziels
entsprechen und die bei einem Reboot automatisch zum Rollbackziel führen.
Da werden beliebige Kernel (teilweise sogar von Fremdsystemen) verwendet, die überhaupt
nicht im Rollbackziel existieren. Zusätzlich findet sich die exakte Snapshotbezeichnung nicht
im Booteintrag wider und die Reihenfolge der Einträge entspricht nicht der Entwicklung des
Systems.
Bemerkenswert ist auch, dass Snapper zwar bei SUSE entwickelt wurde, SUSE aber die
in Snapper enthaltene Rollbackfunktion nicht benutzt. Dort wird, wie bei den meisten anderen
Distributionen, das Rollbackziel innerhalb Btrfs verschoben und erhält die Bezeichnung "@".
Der Benutzer weiß nicht in welchem der von Btrfs nummerierten Snapshots er sich befindet.

Wir haben uns in siduction entschieden Snapper vollständig einzusetzen. Meiner Meinung
nach sollte der Benutzer wissen wie viele Snapshost er auf dem System hat und in welchem
er sich befindet.