primus das ist eigentlich ganz einfach, du kopierst deine /etc/mkinitcpo.conf in eine zb etc/mkinitcpo2.conf, mit der kannst du dann experimentieren 🙂
aus man mkinitcpio

   -c, --config config
           Use config file to generate the ramdisk. Default:
           /etc/mkinitcpio.conf.

https://wiki.archlinux.org/title/Mkinitcpio
eine minimierte mkinitcpio.conf befriedigt eher den spieltrieb, als großartig bootzeit zu sparen
normalerweise reicht das: HOOKS=(base udev modconf block filesystems fsck)

noch eine anleitung für eine schmale initcpio http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html

Gerry_Ghetto Die schlechte Nachricht ist, dass du die Zeit zwischen dem Laden des Bootloaders und dem Starten von Arch Linux verlierst.

Ich sehe das genauso.

Ist das ein Laptop? Welches Modell?
Ist gleichzeitig noch ein Windows installiert?
Ich würde prüfen:
Gäbe es für den Rechner ein aktuelleres BIOS/Firmware vom Hersteller?
Hast du wirklich zwei GPUs? Also Intel integriert und eine dedizierte NVidia? lspci kann dir das sagen. Wenn ja:
Du willst ja scheinbar nur die NVidia nutzen bzw. machst das aktuell so per Nouveau-Treiber. Versuche doch mal ob du im BIOS/UEFI die integrierte Intel abschalten kannst. Evtl. hilft das schon über die "Problem-Zeitspanne" in der Firmware hinweg.

Herumpfriemeln an der mkinitcpio.conf halte ich erstmal nicht für sinnvoll.

Eine Bitte noch:
Es ist gut, das du deine Ausgaben in Code-Tags einbindest. Deine Posts sind aber (wie du bemerkt haben dürftest) trotzdem "grauenhaft" formatiert. Das liegt an einer Eigenheit der Forensoftware:
Einzeilige Ausgaben können mit dem Code-Tag ` formatiert werden.
Mehrzeilige Ausgaben erfordern zwingend eine Einbettung in jeweils drei ```, diese müssen auch in einer eigenen Zeile stehen.
Der eingebaute Editor macht das dann richtig, wenn vor dem Setzten des Code-Tags im Editor entweder nur eine Zeile oder halt mehrere markiert/selektiert sind. Du kannst das ja anhand deiner alten Posts mal üben.
//Edit Siehe auch: https://wiki.archlinux.de/title/Foren-FAQs#Was_ist_mit_Formatierung_und_Rechtschreibung?

  • primus hat auf diesen Beitrag geantwortet.

    @primus Code-Blöcke hier im Forum bitte in drei einzelne Backticks (```) jeweils vor und nach dem Codeblock auf einer eigenen Zeile einfügen – oder erst den Codeblock einfügen, diesen dann markieren, und dann erst den Code-Button im Editor drücken. Wenn man den Code-Button vorher drückt, können nur einzelne Codezeilen und keine Code-Blöcke benutzt werden.

    Ich hab das bei deinen vorherigen Posts hier mal korrigiert.

    • primus hat auf diesen Beitrag geantwortet.

      GerBra

      Es handelt sich um ein Laptop
      Archlinux installiert. Kein Dualboot mit Windows 10/11 oder andere OS.

      Technische Daten:
      Marke: Acer Aspire 7738G
      ProzessorIntel Dual Core Intel Core2 Duo T6600
      GrafikkarteNVIDIA GeForce GT 240M - 1024 MB VRAM
      Arbeitsspeicher - 8GB DDR3
      SAMSUNG SSD - 250GB
      Das Laptop ist 13 Jahre alt.
      Erscheinungsdatum: 2009

      lspci | grep VGA
      01:00.0 VGA compatible controller: NVIDIA Corporation GT216M [GeForce GT 240M] (rev a2)
      Deshalb habe ich mich für den xf86-video-nouveau Treiber entschieden.
      Das Programm hwdetect, was ich gestern installiert habe, hat mich eine wenig verwirrt und deshalb habe ich testweise xf86-video-intel installiert/konfiguriert.
      Die Xorg0.log teilte mir mit, dass es keine Hardware findet: No devices detected.

      Leider gibt es für dieses alte Hündchen kein BIOS Update.

      Wie von euch empfohlen, werde ich an der mkinitcpio.conf nichts ändern.
      Ich werde nun einige Zeit abwarten, ob durch irgendwelche Updates (Kernel, Firmware, Grub usw.) die Boot bzw. Startproblematik behoben wird.
      Sollte sich zu dem Problem etwas ändern, dann werde ich dies hier im Ticket hinterlegen und dieses anschließend schließen.

      Vielen herzlichen Dank an euch allen für eure großartige Unterstützung.

      P.S. Sorry für die Formatierung des Tickets, habe leider den Link den du hier hinterlegt hast nicht gefunden.

      • GerBra hat auf diesen Beitrag geantwortet.

        Dirk

        Ich hab das bei deinen vorherigen Posts hier mal korrigiert.
        Dankeschön.

        Die Ausgaben sehen im Prinzip alle gut aus. Ich würde jetzt gezielt Dinge ändern und schauen, ob sich dadurch das Verhalten ändert.

        Als erstes würde ich beim Start im Grub Menu die Taste "E" drücken, um den Booteintrag zu bearbeiten. In der Zeile mit initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img würde ich abändern zu zu initrd /boot/initramfs-linux-lts.img und danach mit CTRL+X starten.

        Ansonsten kannst du mal schauen, welchen Grub du installiert hast (im System und im Bootsektor). Und danach installierst du dir eine vorherige Version von Grub https://wiki.archlinux.org/title/Downgrading_packages und auch im Bootsektor mit grub-install. Bringt dies auch nichts, nicht vergessen, wieder die aktuelle Version zu installieren.

        primus Ich werde nun einige Zeit abwarten, ob durch irgendwelche Updates (Kernel, Firmware, Grub usw.) die Boot bzw. Startproblematik behoben wird.

        Darauf wird es wohl rauslaufen.
        Von 5.x auf 6.x gab es wohl einige Änderungen, was auch bei meinem alten Thinkpad z.B. irgendeine Regression bewirkt so daß ich den 6.xer nicht ohne Kernelparameter komplett ausschalten kann per Poweroff (Lüfter und Batterieentladung geschehen weiter nach dem Shutdown).

        Zwei Ideen/Ansätze noch:
        a) Was @Gerry_Ghetto sagt ist sicher ein Ansatz, v.a. wenn dein System noch vor 8/2022 installiert worden ist. Da gab es eine News zu Grub:
        https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/
        Das muß jetzt nicht für deinen Fall ausschlaggebend sein, aber ein Neuinstallieren bzw. Reinstallieren nach folgendem Grub-Versionswechsel kann ein Ansatz sein. Ein weiterer Test wäre evtl. ein Test/wechsel zu einem anderen Bootloader. Da du ja wohl kein (U)EFI hast, sondern eine normale BIOS/MBR-Installation bliebe da wohl nur der syslinux-Bootloader übrig.

        //Edit: Bzgl. syslinux: Da du ja nur eine Partition hast (ext4): In den Wikis (hier auf .de und auch bei .org) gibt es den Warnhinweis bzgl. syslinux und der Standard-Formatierung bei mkfs.ext4. Das betrifft die 64bit-Features in aktuellen ext4-Dateisystemen (hat nichts mit 32 vs 64 Bit zu tun). Ab Version 6.04 von syslinux (in den Repos) sollte das nun auch unterstützt sein, ich habe es nicht getestet bisher. Was ich damit sagen will: Falls du syslinux austesten wolltest, dann würde ich einen bootfähiges Medium vom aktuellen Archlinux-Install-ISO parat haben und mich vertraut machen von da aus den ggf. nicht funktionierenden syslinux wieder durch Grub zu ersetzen zu können.

        b) Du verwendest ja keine eigene Bootpartition bzw. auch "nur" eine Partition (was vollkommen ok ist). Ist auf dieser Partition noch genügend freier Speicherplatz (Im Gigabyte-Bereich), oder ist das eher "knapp"? Weil:
        https://wiki.archlinux.org/title/GRUB#GRUB_loads_slowly

        • primus hat auf diesen Beitrag geantwortet.

          GerBra

          Es ist noch ausreichend Platz auf meiner Festplatte.

          df -h
          Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
          dev             3,9G       0  3,9G    0% /dev
          run             3,9G    1,1M  3,9G    1% /run
          /dev/sda1       229G     30G  188G   14% /
          tmpfs           3,9G    124M  3,8G    4% /dev/shm
          tmpfs           3,9G    9,8M  3,9G    1% /tmp
          tmpfs           795M     48K  795M    1% /run/user/1000

          Den ersten Teil von Gerry_Ghetto Vorschlag habe ich bereits getestet, leider ohne sichtbaren Erfolg.
          initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img
          initrd /boot/initramfs-linux-lts.img

          angepasst und CTRL+X starten.

          Wie bereits geschrieben, werde ich erst einmal abwarten.
          Das System läuft rund und ich bin auch damit sehr zufrieden.
          Der Bootvorgang ist ein kleines Übel, was ich aber erst einmal so in Kauf nehmen werde.

          Sobald sich die Situation durch Updates ändert, werde ich es hier Posten.

          Vielen herzlichen Dank euch beiden für eure weitere Unterstützung!

          primus HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)

          mir viel vorher auf, daß du kms nutzt, dafür gibts izwischen einen hook: kms, den würde ich an deiner stelle mal versuchen
          aus meiner /etc/mkinitcpio.conf.pacnew
          HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)

          • primus hat auf diesen Beitrag geantwortet.

            brikler

            mir viel vorher auf, daß du kms nutzt, dafür gibts izwischen einen hook: kms, den würde ich an deiner stelle mal versuchen

            Was genau meinst du damit?

            Wie du aus meiner geposteten mkinitcpio.conf entnehmen kannst, ist doch unter HOOKS = kms und unter MODULES (nouveau) bereits dort hinterlegt.
            MODULES=(nouveau)
            HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)
            Ansonsten bitte eine kurze Beschreibung, was genau ich ausprobieren sollte.

            • brikler hat auf diesen Beitrag geantwortet.

              primus HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)

              genau, das meine ich damit, aber ich hätte vielleicht etwas genauer hin schauen sollen 🙁
              nichts gewonnen, und nichts verloren.

              ein Monat später

              Hallo Forenmitglieder,
              ich konnte das Problem erst einmal mit folgen Eintrag "notsc" in der /etc/default/grub beheben.

              GRUB boot loader configuration
              GRUB_DEFAULT=0
              GRUB_TIMEOUT=3
              GRUB_DISTRIBUTOR="Arch"
              GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet"
              GRUB_CMDLINE_LINUX_DEFAULT="notsc"
              GRUB_CMDLINE_LINUX=""

              Anschließend:
              sudo grub-mkconfig -o /boot/grub/grub.cfg

              Neustart durchführen.

              Infos zu notsc
              Hiermit wird der Zeitstempelzähler deaktiviert. Diese Option dient der Umgehung von Timing-Problemen auf Ihren Systemen. Es handelt sich um eine recht neue Funktion, die insbesondere dann nützlich sein kann, wenn Sie auf Ihrem
              Rechner Rückwärtsentwicklungen bemerken, insbesondere zeitbezogene Rückwärtsentwicklungen.
              Gilt auch für Fälle, in denen keinerlei Reaktion mehr zu verzeichnen ist.

              sudo journalctl -b -1 | grep tsc
              Apr 01 15:52:23 ArchXFCE kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux-lts root=UUID=71d8e9de-d37d-47c4-a003-56b959b00e9c rw notsc
              Apr 01 15:52:23 ArchXFCE kernel: tsc: Fast TSC calibration using PIT
              Apr 01 15:52:23 ArchXFCE kernel: tsc: Detected 2194.377 MHz processor
              Apr 01 15:52:23 ArchXFCE kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux-lts root=UUID=71d8e9de-d37d-47c4-a003-56b959b00e9c rw notsc
              Apr 01 15:52:23 ArchXFCE kernel: tsc: Marking TSC unstable due to boot parameter notsc

              Bootvorgang dauert jetzt ca. 10 Sekunden.

              Vielen Dank noch einmal an euch allen, die mich hierbei unterstützt haben.

              primus hat den Titel zu [Gelöst] Problem "Initiale Ramdisk wird geladen" seit Linux-lts Kernel v6... geändert ().