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 🙂

            Und wie machst du das? Mit einem Live-System oder aus deinem installierten System heraus? Im zweiten Fall müsstest du die /boot zuerst aushängen, bevor du ans Partitionieren gehst.

            Wo sind die Befehle fürs Sichern der Partitionstabelle und der Partitionen? Hast du dir auch die Befehle und Schritte überlegt, die du bräuchtest, falls du die Partitionstabelle zurück spielen müsstest? (Habe ich selber noch nie gemacht, weswegen ich mich da auch zuerst einlesen müsste.) Insbesondere beim Partitionieren sind die Befehle wichtig, da: MiB versus MB, Sektoren etc.

            Ich würde zuerst die fstab anpassen und danach mit einem systemctl daemon-reload; mount -a (falls vom installierten System aus gearbeitet wird) gleich überprüfen, ob der Eintrag in der fstab korrekt ist.

            Dann fehlen dir immer noch etliche Dateien in /boot. Ich würde da einfach ein pacman -S linux grub intel-ucode ausführen. Das enthält auch gleich den mkinitcpio-Schritt.

            Wozu brauchst du die /dev/sda1 (BIOS Boot Partition)? Hast du vor, dein System in einen 20 Jahre alten PC einzubauen, der aber schon mit GPT umgehen kann? Du hast bis jetzt ein funktionierendes UEFI-System. Ich würde da einfach bei UEFI bleiben und keine alternative Methode reinbasteln, um im BIOS-Modus booten zu können. Ausserdem reichen 1 MiB, du brauchst keine 10 MiB für die geplante sda1.

            Guckst du https://wiki.archlinux.de/title/Fdisk
            Machst du # sfdisk -d /dev/sda > sda.dumpzum Sichern der Partitionstabelle und # sfdisk /dev/sda < sda.dump zum zurückspielen. 😉
            Aber so wie dir GG rät, ist das eigentlich schon das Beste.

            @Gerry_Ghetto:
            herzlichen dank für Dein wertvolles Feedback!
            Ich hätte tatsächlich aus dem Live-System die Änderung vorgenommen, aber das Aushängen NICHT bedacht, danke!
            Partitionstabelle kann man aus gdisk heraus sichern und auch wieder rückspielen.
            Die Partitionen werde ich mit

            dd bs=1M if=/dev/sda1 | pv -s 529m | gzip > /media/Backup/sda1.img.gz sichern, für sda2 entsprechend und bei Bedarf entsprechend zurückspielen.

            Danke für den Hinweis zur fstab-Kontrolle.

            mkinitcpio -p linux werde ich dann durch pacman -S linux grub intel-ucode ersetzen

            Die BIOS Variante ist glaube ich noch ein Relikt von der Win-Installation; ich lass sie weg.

            @tuxnix
            Vielen Dank für den Hinweis; ich glaube sfdisk und gdisk sind Geschmackssache; allerdings schaut die sfdisk Variante wirklich trivial aus... ich mach mit beiden eine Sicherung ;-)

            @GerBra
            Das hatte ich tatsächlich auch im Kopf; ich habe gparted auf dem Rechner, gerade weil ich es doch nicht soooo gewohnt bin solche Dinge in der Konsole zu machen. Ich werde kurzfristig entscheiden und berichten 🙂

            Vielen Dank Euch; morgen Vormittag sollte ich Zeit für die Aktion haben; ich werde berichten!

            Schönen Abend Euch

            Ardbeg

            • tuxnix hat auf diesen Beitrag geantwortet.