Hi zusammen,
seit einigen Updates beschwert sich pacman, dass zu wenig Speicher zur Verfügung ist:

==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
zstd: error 70 : Write error : cannot write block : No space left on device
==> ERROR: Image generation FAILED: 'zstd reported an error'

Meine Festplatte schaut wie folgt aus:

Number Start (sector) End (sector) Size Code Name
1 2048 1085439 529.0 MiB 2700 Basic data partition
2 1085440 1290239 100.0 MiB EF00 EFI system partition
3 1290240 68634623 32.1 GiB 0700 VM_Linux
6 68634624 135743487 32.0 GiB 8300 SYSTEM_Linux
7 135743488 269961215 64.0 GiB 8300 HOME_Linux
8 269961216 286738431 8.0 GiB 8200 SWAP_Linux
9 286738432 500118158 101.7 GiB 8300 Media

Ich hatte mal ein Dualboot mit Win, aber das habe ich schon lange nicht mehr auf dem Rechner. Kann man das irgendwie korrigieren, oder die Maschine zu zerschießen? 🙂

Danke und Gruß

Ardbeg

Josephus Miller : sehr gerne, danke für den Hinweis 🙂 :

Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
dev 3,9G 0 3,9G 0% /dev
run 3,9G 1,6M 3,9G 1% /run
/dev/sda6 32G 21G 8,9G 71% /
tmpfs 3,9G 2,6M 3,9G 1% /dev/shm
tmpfs 3,9G 8,0K 3,9G 1% /tmp
/dev/sda7 63G 34G 27G 56% /home
/dev/sda9 100G 69G 26G 73% /media
/dev/sda2 96M 96M 0 100% /boot
tmpfs 784M 68K 784M 1% /run/user/1000

  • Andy@Arch hat auf diesen Beitrag geantwortet.

    _Ardbeg_ /dev/sda2 96M 96M 0 100% /boot

    Deine Boot-Partition ist voll ....... entweder vergrößern oder ausmisten

    • _Ardbeg_ hat auf diesen Beitrag geantwortet.

      Andy@Arch
      Hi Andi,
      dass die Partition voll ist, habe ich auch aus der Fehlermeldung rauslesen können. Die Frage ist nur, wie ich das ohne das System zu zerstören beheben kann.

      Die Partition zu vergrößern fällt vermutlich weg, da ich doch die sda1 nicht verkleinern kann, oder? Von der sda3 etwas abzwacken geht auch nicht, da sind ja auch Daten drauf. Oder sehe ich das falsch?

      Bleibt Ausmisten. Der Inhalt schaut wie folgt aus:

      EFI grub initramfs-linux-fallback.img initramfs-linux.img intel-ucode.img vmlinuz-linux

      EFI und grub sind Verzeichnisse, die zusammen 38Mb ausmachen, die restlichen vier Dateien machen 57Mb aus... also auch nicht viel zu holen...

      96 M ist schon sehr klein. Verzichte auf das fallback-image, wenn Vergrößern schwierig oder unmöglich ist. briklers Links sollten dir da helfen.

        stefanhusmann 96 M ist schon sehr klein

        reichen aber mit einer minimal initramfs
        /dev/nvme0n1p2 100M 56M 45M 56% /boot
        ich hab zwei verschiedene kernel, inclusive fallback image und intel-ucode.img in /boot

        zb, im wesentlichen schaut meine initramfs so aus:

        MODULES="f2fs nvme"
        HOOKS="base strip resume 
        COMPRESSION="zstd"
        COMPRESSION_OPTIONS="-9 -T0"

        Hi zusammen,

        vielen Dank für eure Hinweise. Dazu noch folgende Frage:

        stefanhusmann Wenn ich das fallback-image weglasse, werde ich die Fehlermeldung los. Defacto ist es aber schon so, dass ich darauf nicht zurückgreifen könnte, da er ja in den Fehler läuft, oder?

        Ich werde den verlinkten Inhalt mal durchforsten und bevor ich etwas ändere, würde ich das hier entsprechend nochmal zur Diskussion stellen.

        Danke und viele Grüße

        Ardbeg

        Noch eine Verständnisfrage. Im Initramfs werden die Treiber und die Reihenfolge, in der sie geladen werden, definiert. Werden auch die entsprechenden Treiber selbst darin dann gespeichert und somit würde eine Veringerung der Anzahl der zu ladenden Treiber das Image verkleinern?

        Danke und Gruß

        Ardbeg

        • GerBra hat auf diesen Beitrag geantwortet.

          _Ardbeg_ Werden auch die entsprechenden Treiber selbst darin dann gespeichert und somit würde eine Veringerung der Anzahl der zu ladenden Treiber das Image verkleinern?

          Ja. Was aktuell in deinem initramfs-Image drin ist kannst du dir (als root oder per sudo) mittels:
          lsinitcpio /boot/initramfs-linux.img
          anzeigen lassen.

          Zum Problem:
          Ich würde aktuell auch den Vorschlag von @stefanhusmann verwenden, also kein Fallback-Image generieren lassen. Bei mir ist das Fallback ~ 35MB groß, das eigentliche ~ 9MB. Du würdest also wohl ebenfalls (bei einem Kernel, mehr geht ja sowieso nicht) rund 35 MB gewinnen. Und wärst beim zukünftigen Generieren des "normalen" Images auf der sicheren Seite, selbst wenn das mal ein paar MB größer werden würde.

          Langfristig (wenn z.B. mal eine Neuinstallation anstehen würde o.ä.) würde ich mir notieren, die /boot-Partition größer anzulegen, z.B. das mindest zwei Kernel (z.B. vmlinuz + vmlinuz-lts) plus alle initramfs-Images mit ausreichend Platz haben.

          Die initramfs-Images so wie brikler zu spezialisieren wird dir wohl nichts wesentliches bringen, auch dann hättest du wohl Probleme - entweder das dein Fallback auch zusammengestrichen ist (dann nutzlos) oder weil es wegen der Größe dann auch nicht passen würde.

          Was ist der Nachteil ohne Fallback-Image?
          Bei einem Hardware-Wechsel (DiskController,USB,Disk-Arten wie HD,SSD,nvme,...) kann es sein, daß dein System sich nicht booten läßt - da eben ggf. andere Treiber für Hardware,Dateisysteme,... benötigt werden. Der mkinitcpio-Hook autodetect zusammen mit udev packt eigentlich nur die momentan benötigten Treiber ins Image. Beim Fallback (ist ohne autodetect) sind es alle Treiber die zum Laden des eigentlichen Kernels nötig sein können.
          Nach einem Hardware-Wechsel wäre es also ggf. nötig das System mittels des Fallback-Images zu starten (und dann ein neues normales zu generieren).
          Ohne das Fallback müßtest du das z.B. von einem externen Bootmedium (Arch Install ISO z.B.) machen.
          Das läßt sich IMHO aber verschmerzen...

          • brikler hat auf diesen Beitrag geantwortet.

            Wenn man das Problem behalten möchte, kann man natürlich auf das Fallback-Image verzichten.

            Wenn man das Problem lösen möchte, hat man zwei Varianten:

            • Man passt die Grösse der ESP an, damit man sie auch weiterhin als /boot missbrauchen kann
            • Man nutzt die ESP nicht als /boot

            Ob die erste Variante geht, kann ich anhand der Informationen hier nicht abschliessend beurteilen. Aber wenn man bei der Umsetzung dieser Variante Fehler macht, dann kann es sein, dass ein Herstellen des Systems schwierig bis unmöglich wird.

            Die zweite Variante ist da natürlich besser, da man auch weiterhin mittels chroot alles wieder reparieren könnte. Nichtsdestotrotz empfiehlt es sich, jeden Schritt genau zu überlegen, damit man ohne chroot auskommt. Und durchs genaue Überlegen lernt man sein System auch etwas besser kennen.

            GerBra Langfristig (wenn z.B. mal eine Neuinstallation anstehen würde o.ä.) würde ich mir notieren, die /boot-Partition

            langfristig gesehen, würde ich mir überhaupt keine /boot partition mehr machen, von den allermeisten dateisysteme aus kann man ohne weiteres booten, lediglich fürs efi braucht man eine vfat partition

            ich möchte nicht auf ein fallback image verzichten, ich finds ziemlich praktisch beim basteln^^
            aber ich denke mir, eine kopie der normalen initramfs, würde es für mich auch tun, wenn ichs nämlich benutze, führts mich blos ins muli-users.target, und wenn wirklich was nicht geht, hab ich einen funktionierenden, alten, selbst gebauten kernel 🙂

            GerBra Der mkinitcpio-Hook autodetect zusammen mit udev packt eigentlich nur die momentan benötigten Treiber ins Image.

            in den minimal initramfs erstell anleitungen steht drin, wie man die wirklich notwendigen module findet, um die anderen kümmert sich das fette monster udev 🙂

            Wird die sda1 überhaupt noch für irgendwas verwendet? sda1+sda2 zusammen wäre ja erstmal ausreichend.

            Hi zusammen,

            herzlichen Dank Euch allen für die tollen Hinweise in unterschiedliche Richtungen hinzuarbeiten.
            @GerBra : Vielen Dank für Deine Ausführungen. Grundsätzlich steht ein zweiter Rechner zu Erstellung eines Bootmediums zu Verfügung. D.h. für mich ist das Risiko, das Fallback-Image zu entfernen überschaubar.
            Meine aktuelle /etc/mkinitcpio.d/linux.preset schaut wie folgt aus:

            # mkinitcpio preset file for the 'linux' package
            #ALL_config="/etc/mkinitcpio.conf"
            ALL_kver="/boot/vmlinuz-linux"
            ALL_microcode=(/boot/*-ucode.img)
            PRESETS=('default' 'fallback')
            #default_config="/etc/mkinitcpio.conf"
            default_image="/boot/initramfs-linux.img"
            #default_uki="/efi/EFI/Linux/arch-linux.efi"
            #default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"
            #fallback_config="/etc/mkinitcpio.conf"
            fallback_image="/boot/initramfs-linux-fallback.img"
            #fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"
            fallback_options="-S autodetect"

            Ich würde sie nun wie folgt abändern:

            # mkinitcpio preset file for the 'linux' package
            #ALL_config="/etc/mkinitcpio.conf"
            ALL_kver="/boot/vmlinuz-linux"
            ALL_microcode=(/boot/*-ucode.img)
            PRESETS=('default')
            #default_config="/etc/mkinitcpio.conf"
            default_image="/boot/initramfs-linux.img"
            #default_uki="/efi/EFI/Linux/arch-linux.efi"
            #default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"
            #fallback_config="/etc/mkinitcpio.conf"
            #fallback_image="/boot/initramfs-linux-fallback.img"
            #fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"
            #fallback_options="-S autodetect"

            d.h. bei presets den eintrag fallback raus und alle fallback Optionen auskommentieren. Ist das soweit richtig? Damit wäre auf jeden Fall eine kurzfristige Lösung da, um sicher zu gehen, dass ich nicht mal Probleme bei Erstellung des normalen Images bekomme.

            @Gerry_Ghetto ; @frostschutz :

            Eure Hinweise darauf, das eigentliche Problem zu lösen, finde ich an sich besser, vor allem der Hinweis darauf, das eigene System besser kennenzulernen. Kann es sein, dass die sda1 ein Überbleibsel der Windows Installation ist? Wie kann ich feststellen, ob ich sie noch brauche?

            @brikler :
            Deine Lösung ist bestimmt auch verfolgenswert, allerdings übersteigt sie meine Kompetenzen um ein Vielfaches 🙂

            Danke Euch und b.t.w. mal wieder ein Lob an dieses tolle Forum; nicht nur was den Inhalt anbetrifft, sondern auch die Art und Weise WIE hier Einträge formuliert werden bezüglich des Umgangs miteinander und der Sprache!

            Danke und viele Grüße

            Ardbeg

              _Ardbeg_ Ich würde sie nun wie folgt abändern:

              ...

              d.h. bei presets den eintrag fallback raus und alle fallback Optionen auskommentieren. Ist das soweit richtig?

              Es sollte genügen, einfach nur den fallback Eintrag aus dem PRESETS-Array rauszunehmen. Ohne Eintrag würden die fallback_* Optionen nicht benutzt, egal ob du sie "aktiv" läßt oder ganz auskommentierst.

              _Ardbeg_ Kann es sein, dass die sda1 ein Überbleibsel der Windows Installation ist? Wie kann ich feststellen, ob ich sie noch brauche?

              Wenn kein Windows mehr auf dem PC ist (auch nicht als Wechseldatenträger o.ä.), dann wäre das Zusammenlegen beider Partitionen definitiv eine (dauerhafte) Alternative. Ist allerdings halt ein "destruktiver" Ansatz - normalerweise unkompliziert möglich (von purer Kommandozeilen-Orgie bis zu komfortablem Mausgeschubse); aber wenn es halt "blöd" kommt bzw. man/frau "blöd" ist <g>, dann ist das Problem größer als auf ein Fallback-Image zu verzichten.

              Wenn du bisher nie was mit Partitionen/Dateisystemen zu tun hattest auf dieser Ebene, könntest du das ggf. (sofern du sowas ggf. schon nutzt) in einer virtuellen Maschine (angelehnt an dein richtiges System vom momentanen Partitionslayout) ja mal "üben". Auf dieser virt. Machine müßte ja nicht mal ein System installiert sein - es reichen Partitionen und Dateisysteme ("formatieren").

              _Ardbeg_ Kann es sein, dass die sda1 ein Überbleibsel der Windows Installation ist? Wie kann ich feststellen, ob ich sie noch brauche?

              Ja, es kann sein, dass das von Windows übrig ist (Windows RE = Windows Recovery Environment).

              Du kannst die Partition einhängen und mal schauen, was für Dateien sich darauf befinden.

              @GerBra; @Gerry_Ghetto

              Ich habe die Partition eingehängt und es scheinen wirklich Win-Umfänge zu sein:

              .:
              Recovery Recovery.txt 'System Volume Information'
              ./Recovery:
              Logs WindowsRE
              ./Recovery/Logs:
              'BootUX (1).sqml' Reload.xml
              ./Recovery/WindowsRE:
              boot.sdi ReAgent.xml Winre.wim
              './System Volume Information':
              tracking.log

              Ich würde das gerne zu Übungszwecken mal angehen wollen, allerdings nur mit Eurer Unterstützung 🙂

              Ich würde einfach mal die Partitionstabelle sichern, und sda1 und sda2 mit dd als Image sichern, damit kann ich ja zur Not alles wieder herstellen, oder?

              Wie wäre dann das weitere Vorgehen?

              1. Die Partitionen sda1 und sda2 löschen
              2. Eine neue sda1 anlegen --> mit welchem Dateiformat? Wie die jetzige sda2?
              3. Mit Grub den Bootloader auf neuer Partition installieren
              4. Edit: fstab aktualisieren
              5. Neustarten und hoffen, dass gebootet wird 🙂

              VG

              Ardbeg

              Fürs Kopieren reicht cp, was auch Platz sparen wird, da nicht bitweise alles unnötige kopiert wird wie bei dd.

              Bei deiner Liste fehlen noch viele Dinge, die essenziell sind.
              So löschst du bestehende Partitionen und legst eine neue Partition mit einem neuen Dateisystem an. Allerdings hängst du sie nicht ein, was dafür sorgen würde, dass Grub entweder nicht installierbar ist oder sich am falschen Ort installiert.

              Ich gehe davon aus, dass du mit "Grub installieren" wohl ein grub-install ... meinst. Das würde nur ein paar hundert KiB installieren. Die Dateien, die Grub braucht und unter /boot/grub liegen, fehlen dir dann allerdings. Unter anderem auch die grub.cfg, die du noch nicht erzeugt hast. Aber die grub.cfg würde dir auch nicht viel nützen, da du auch keine Kernel, initramfs und Mikrocodes für den Prozessor installiert hast.

              Du müsstest dir also noch ein paar zusätzliche Schritte ausdenken. Am besten schreibst du auch gleich die Befehle auf, die du dann ausführen müsstest. Aber für deinen ersten Versuch, hast du auch schon einiges richtig gemacht.

              Die ESP muss zwingend mit FAT formatiert sein und einen speziellen Partitionstyp besitzen. Am besten folgst du den gängigen Installationsanleitungen betreffend Erstellung der ESP.

              • _Ardbeg_ hat auf diesen Beitrag geantwortet.

                Gerry_Ghetto

                Vorbereitungen: Sicherung der Partitionstabelle mit gdisk Option -b, und der Partitionen mit dd oder cp

                dann erst mal die Partitionsgeschichte; aktuell schaut sie wie folgt aus:

                Number Start (sector) End (sector) Size Code Name
                1 2048 1085439 529.0 MiB 2700 Basic data partition
                2 1085440 1290239 100.0 MiB EF00 EFI system partition
                3 1290240 68634623 32.1 GiB 0700 VM_Linux
                6 68634624 135743487 32.0 GiB 8300 SYSTEM_Linux
                7 135743488 269961215 64.0 GiB 8300 HOME_Linux
                8 269961216 286738431 8.0 GiB 8200 SWAP_Linux
                9 286738432 500118158 101.7 GiB 8300 Media

                daraus machen würde ich folgendes:

                Number Start (sector) End (sector) Size Code Name
                1 2048 22527 10.0 MiB EF02 BIOS boot partition
                2 22528 1290239 619.0 MiB EF00 EFI system partition
                3 1290240 68634623 32.1 GiB 0700 VM_Linux
                6 68634624 135743487 32.0 GiB 8300 SYSTEM_Linux
                7 135743488 269961215 64.0 GiB 8300 HOME_Linux
                8 269961216 286738431 8.0 GiB 8200 SWAP_Linux
                9 286738432 500118158 101.7 GiB 8300 Media

                Zur Formatierung:`

                sda1 bleibt wie es ist, sda2 mit

                mkfs.fat -F32 /dev/sda2

                als FAT32 formatieren.

                Einbinden der sda2: mount /dev/sda2 /boot

                In der fstab die UUID der sda2 korriegen

                Initramfs erzeugen, die config bleibt, wie sie ist, d.h. mit Backup-Image:

                mkinitcpio -p linux

                BIOS-Boot erstellen:

                grub-install /dev/sda

                UEFI-Boot erstellen:

                grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=Arch-Linux-grub

                Grub-Config erstellen:

                grub-mkconfig -o /boot/grub/grub.cfg

                Das wäre mein Plan 🙂