eine minimale mkinitcpio wäre eine möglichkeit https://wiki.archlinux.org/title/Minimal_initramfs
da gibts ein tutorial von falconindy, aber das finde ich nicht mehr 🙁
wie dem auch sei, eine editierte mkinitcpo.conf wirds nicht rauß reißen, aber es spricht auch nix dagegen.

noch eine blöde frage hinten dran: so wie mich das anschaut, hat dein laptop zwei grakas, eine intel, und eine von nvidia, benutzt du beide, also mal die eine, mal die andere? wenn nicht, würde ich die nvidia in die blacklist schreiben.

die wesentlichen parameter meiner /etc/mkinitcpio.conf schaut so aus:

MODULES="f2fs sd_mod lz4hc_compress nvme nvme_core i915"
HOOKS="base autodetect modconf resume strip"
COMPRESSION="zstd"
COMPRESSION_OPTIONS="-T0"
MODULES_DECOMPRESS="yes"
  • primus hat auf diesen Beitrag geantwortet.

    brikler

    Das mit den zwei Grafikkarten ist mir erst heute aufgefallen, nachdem hwdetect installiert habe und ich den Befehl ausgeführt habe.
    sudo hwdetect --show-modules
    AGP : intel-agp intel-gtt

    Leider kenne ich mich da zu wenig aus um eine minimale bzw. optimierte mkinitcpio.conf zu erstellen.
    Vielleicht kannst du, oder jemand anderes mir mitteilen, welche Module von der oben aufgeführten Liste usw., ich am besten in meiner angepassten mkinitcpio.conf unbedingt eintragen sollte.
    Selbstverständlich werde ich in den nächsten Zeit mir diese Dinge durchlesen, nur möchte ich nichts Kaputt reparieren.

    Bis hierhin vielen Dank an euch beiden

    • brikler hat auf diesen Beitrag geantwortet.

      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 ().