• Arch Linux
  • installiertes Arch Linux will nicht starten

@"SUSEDJAlex"#p3830

Du fragst: "Welchen Bootloader willst du denn nun installieren?"

Ich will grub installieren (mit dem ich Erfahrung habe); habe die Anleitung https://wiki.archlinux.de/title/UEFI-Rechner_grub_brs durchgeführt. (Was ich oben geschrieben habe, stimmt also nicht ganz). Danach hat der reboot nicht funktioniert. Also habe ich den Abschnitt "systemd installieren und anpassen" der Anleitung https://wiki.archlinux.de/title/UEFI-Rechner_systemd-boot_brs durchgeführt. Das hat auch nicht zu einem startfähigen Arch System geführt.

Du schreibst 2.: "Wenn du allerdings die anderen Systeme mit einbinden willst, so muss der os prober in /etc/default/grub ( am Ende ) mit GRUB_DISABLE_OS_PROBER=false eingetragen werden. "

Das würde ich im nächsten Schritt tun, nachdem ich es geschafft habe, Arch zu starten.

Du schreibst 3.: "Danach mit grub-mkconfig das generieren, was dadurch die anderen Boot-Partitionen mit eingebunden werden..."

Gehe ich recht in der Annahme, dass ich vor dem "grub-mkconfig" die Partitionen, die der os-prober durchsuchen soll, irgendwohin mounten muss? Danach braucht es aber kein nochmaliges "grub-install", nicht wahr?

Zusatzfrage 1: UEFI Boot ist für mich neu. Ich würde gerne wissen, in welchem Ordner welche Objekte (.img- Dateien, .efi-Dateien, grub.cfg usw vorausgesetzt werden, damit ein Systemstart funktioniert. Mich verwirrt der Umstand, dass ich sowohl /boot/grub/grub.cfg als auch /boot/efi/grub/grub.cfg bei mir sehe. Welche grub.cfg ist die richtige?

Zusatzfrage 2: Darf ich aus meiner EFI Partition alle seit dem 11.11. erzeugten Dateien und Ordner löschen oder besteht die Gefahr, dass dann einige meine lauffähigen Linuxe nicht mehr starten?

Starte mal dein Ubuntu und mache ein sudo update-grub. Vielleicht wird dein Arch Linux schon gefunden.
Falls ja, starte dein Arch Linux vom Ubuntu-Grub aus. Falls der Fehler immer noch auftritt, hast du etwas in der Arch Linux Installation verbastelt (/etc/fstab oder /etc/mkinitcpio.conf).

Im Prinzip brauchst du unter Arch Linux keinen Bootloader zu installieren, wenn dein Hauptsystem sowieso nicht Arch Linux ist. Bei korrekter Ubuntu-Installation kannst du den Bootloader von Ubuntu nutzen.

Die Installation von Grub via pacman installiert nur das Grub-Paket im Arch Linux. Es installiert aber nicht den Bootloader auf der ESP (oder im MBR bei CSM/Legacy). Dafür brauchst du grub-install, was allerdings voraussetzt, dass du die ESP korrekt eingebunden hast und gegebenenfalls die richtigen Optionen mitgibst.

Zur Zusatzfrage 1: Alle Kerneldateien (vmlinuz, initramfs, config, System.map, etc) gehören nach /boot. Alle .efi Dateien gehören auf die ESP in ein Verzeichnis irgendwo unter EFI abgelegt. Im Normalfall musst du dich nicht damit herumschlagen, wo welche Dateien hingehören, weil das von pacman und grub-install im richtig konfigurierten System auch richtig gemacht wird.
Das Blöde ist, dass du die ESP nach /boot eingehängt hast. Dann wird die ESP sowohl für deine Kerneldateien als auch für die Bootloader-Dateien gebraucht. Und wenn Manjaro die ESP auch nach /boot eingehängt hat, dann kann es sein, dass die Systeme sich gegenseitig die gleich lautenden Dateien überschreiben.
Ich an deiner Stelle würde /boot auf der Partition mit dem Wurzelverzeichnis belassen (nicht vergessen, den Linuxkernel mit pacman neu zu installieren) und die ESP nach /boot/efi einhängen (/etc/fstab entsprechend anpassen). Schau dir https://wiki.archlinux.org/title/GRUB#Installation_2 mal genauer an. Mit grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ArchLinux installierst du dann Grub, falls du wirklich auch einen Bootloader für Arch Linux installieren willst.

Zur Zusatzfrage 2: Das kann man nicht beantworten, weil man nicht weiss, welche Dateien es betrifft.

  • jolexin hat auf diesen Beitrag geantwortet.

    Der derzeitige Stand ist teilweise erfreulich:

    Ich habe die Vorschläge von GerBra auasgeführt, also

    • die Labels meiner Partitionen abgeglichen mit denen in der fstab Datei,
    • den freien Platz in meiner EFI System Partition geprüft
    • das initramfs neu erstellt und überprüft.

    Das Booten von Arch wurde immer noch mit einer Fehlermeldung abgebrochen, die nach arch-uefi.conf gerochen hat.

    • Also hab ich auch die Labels in /boot/loader/entries/arch-uefi.conf und arch-uefi-fallback.conf korrigiert; danach "bootctl update".

    Nun konnte ich meinen PC normal booten, es gab die Auswahl zwischen Arch, Arch-fallback und Windows. Konnte alle drei starten.

    Nach dem nächsten Boot von Arch habe ich die Partitonen mit anderen Linuxen gemountet; grub-mkconfig mit OS Prober hat alle Linuxe gefunden. Die sind jedoch beim nächsten Boot nicht in der Auswahl erschienen. Daraus habe ich geschlossen, dass bei mir defacto Arch mit Systemd bootet !

    Normalerweise starte ich Manjaro (mit GRUB). Deshalb habe ich in Manjaro ein grub-mkconfig durchgeführt.; Arch wurde gefunden und beim nächsten Boot hat mir GRUB auch Arch zum Start angeboten, doch der Start von Arch aus dem Grub-Menü läuft weiterhin auf Fehler! Starten kann ich Arch derzeit, indem ich den Bootvorgang unterbreche, mit F12 kann ich ein temporäres Bootmedium wählen, in der Liste finde ich ArchLinux. Wähle ich ArchLinux, dann erscheint das vorher genannte (systemd?)-Startmenü und ich kann Arch starten.

    Ich habe also scheinbar (ungewollt) eine inkompatible Mischung zweier Boot-Mechanismen auf meiner EFI-Boot Partition. Das beantwortet teilweise Gerry_Ghetto's weitere Fragen und Anmerkungen.

    Gerry_Ghetto hat geschrieben:

    1. Starte mal dein Ubuntu und mache ein sudo update-grub. Vielleicht wird dein Arch Linux schon gefunden. Falls ja, starte dein Arch Linux vom Ubuntu-Grub aus. Falls der Fehler immer noch auftritt, hast du etwas in der Arch Linux Installation verbastelt (/etc/fstab oder /etc/mkinitcpio.conf).

    Siehe oben mit Manjaro statt Ubuntu. Arch wurde gefunden, wird im Grub Menü angeboten, lässt sich aber nicht von dort starten.

    1. Im Prinzip brauchst du unter Arch Linux keinen Bootloader zu installieren, wenn dein Hauptsystem sowieso nicht Arch Linux ist. Bei korrekter Ubuntu-Installation kannst du den Bootloader von Ubuntu nutzen.

    Das habe ich mir auch gedacht und arbeite noch daran ...

    1. Die Installation von Grub via pacman installiert nur das Grub-Paket im Arch Linux. Es installiert aber nicht den Bootloader auf der ESP (oder im MBR bei CSM/Legacy). Dafür brauchst du grub-install, was allerdings voraussetzt, dass du die ESP korrekt eingebunden hast und gegebenenfalls die richtigen Optionen mitgibst.

    Das "korrekte Einbinden" ist die Aufgabe, an der ich bereits 1 Woche lang vergeblich getüftelt habe. Vor der Arch Installation habe ich in der Manjaro-fstab gesehen, dass meine EFI-System Partition /dev/nvme0n1p1 nach /boot/efi gemountet wurde. Deshalb hab auch bei Arch (vor dem chroot) nach /mnt/boot/efi gemountet, obwohl ich laut Spickzettel nach /mnt/boot mounten sollte. Nach diversen Fehlern beim Arch Boot habe ich dann gemäß Spickzettel nach /mnt/boot gemountet - war auch vegebens.

    4.a Zur Zusatzfrage 1: ... Im Normalfall musst du dich nicht damit herumschlagen, wo welche Dateien hingehören, weil das von pacman und grub-install im richtig konfigurierten System auch richtig gemacht wird.

    Mit einer Ausnahme: grub-mkconfig -o /xxx Hier bestimme ich, wohin die grub.cfg geht und da kann ich etwas falsch machen, wenn ich nirgends lesen kann, wohin sie gehört. Bei allen Beispielen habe ich gesehen: grub-mkconfig -o /boot/grub/grub.cfg.
    Weil der Grub nie funktioniert hat, habe ich dann auch mal
    grub-mkconfig -o /boot/efi/grub/grub.cfg
    versucht. Hat auch nicht geholfen.

    4.b Das Blöde ist, dass du die ESP nach /boot eingehängt hast. Dann wird die ESP sowohl für deine Kerneldateien als auch für die Bootloader-Dateien gebraucht. Und wenn Manjaro die ESP auch nach /boot eingehängt hat, dann kann es sein, dass die Systeme sich gegenseitig die gleich lautenden Dateien überschreiben.
    Ich an deiner Stelle würde /boot auf der Partition mit dem Wurzelverzeichnis belassen (nicht vergessen, den Linuxkernel mit pacman neu zu installieren) und die ESP nach /boot/efi einhängen (/etc/fstab entsprechend anpassen). Schau dir https://wiki.archlinux.org/title/GRUB#Installation_2 mal genauer an. Mit grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ArchLinux installierst du dann Grub, falls du wirklich auch einen Bootloader für Arch Linux installieren willst.

    Das klingt jetzt echt komplex; da bin ich geistig erst mal ausgestiegen.
    Muss ich diese Vorschläge verstehen, wenn es mir genügt, mein Arch Linux aus dem Grub-Bootmenü von Manjaro zu starten? Ich müsste dann nur noch die Hürde überwinden, dass Arch tatsächlich startet, wenn ich es ausgewählt habe. Dazu muss ich vielleicht "nur noch" den systemd-boot beseitigen? Aber wie?

    Wenn du dich entscheidest, ein anderes System als Hauptsystem zu nutzen, dann brauchst du unter Arch Linux keinen Bootloader zu installieren und du musst die ESP auch nicht einbinden.

    Das heisst, du kannst die ESP aus der /etc/fstab entfernen und die ESP aushängen.
    Dann solltest du mit pacman auch alle Bootloader-Pakete entfernen (also Grub und systemd-boot). Und anschliessend solltest du den Kernel nochmal installieren (pacman -S linux), damit die Kerneldateien ordnungsgemäss in /boot installiert werden. Sicherheitshalber solltest du auch das initramfs neu bauen (mkinitcpio -P).
    /boot befindet sich dann ganz natürlich auf deiner Arch Linux Partition.

    Wenn dein Arch Linux dann an und für sich richtig installiert ist, boote dein anderes System (Manjaro) und aktualisiere die grub.cfg (grub-mkconfig -o /boot/grub/grub.cfg) und dein Arch Linux sollte auftauchen.
    Nach einen Neustart sollteTM dein Arch Linux aus dem Manjaro-Grub-Menu startbar sein. Ist dies nicht der Fall, dann probiere es mit Ubuntu (sudo update-grub) und dem Ubuntu-Grub-Menu. Funktioniert auch das nicht, dann ist dein Arch Linux wahrscheinlich immer noch nicht korrekt aufgesetzt.

    • jolexin hat auf diesen Beitrag geantwortet.

      Gerry_Ghetto

      Ich habe

      1. /dev/nvme0n1p1 aus der fstab entfernt

      2. pacman -R grub

      3. pacman -R systemd-boot gibt es nicht, auch nicht systemd*

      4. pacman -S linux

      5. mkinitcpio -P

      6. in Manjaro: grub-mkconfig -o /boot/grub/grub.cfg

      7. reboot

      Ergebnis: Arch ist aus dem Manjaro Grub Menü verschwunden (auch aus dem von Ubuntu), lässt sich auf dem Umweg (boot Unterbrechen - F12 ...) noch starten. Bei der login Aufforderung erscheinen Fehler:

      • ACPIO Bios error und
      • ACPIO error SB.PCIO.GFX0.GETB,
      • ACPIO error SB.PCIO.GFX0.ATRM.

      Ich kann mich aber als root einloggen.

      Wenn das kein schwieriges Problem ist ! ?

      systemd-boot scheint schon im Paket systemd enthalten zu sein. Kann man also nicht so leicht entfernen und muss man auch nicht.

      Deine Situation stellt sich wie folgt dar: Du kannst Arch Linux noch via Firmware starten, weil ein Arch Linux Kernel auf der ESP vorhanden ist und auch ein Bootloader, (systemd-boot vermutlich), der diesen Kernel startet.
      Da die Booteinträge für Arch Linux aus den anderen Grubs verschwunden sind, hast du Arch Linux nicht richtig installiert.

      Starte mal dein Arch Linux und zeige die kompletten Ein- und Ausgaben von:

      ls -l /boot
      lsblk -f
      efibootmgr -v
      cat /etc/fstab
      cat /etc/mkinitcpio.conf

      Gegebenenfalls musst du efibootmgr nachinstallieren.

      Hier der output:

      ls -l /boot
      insgesamt 57080
      drwx------ 2 root root     4096 19. Mär 2019  $RECYCLE.BIN
      drwx------ 2 root root     4096 10. Nov 18:57 a4eabb5e1e70419faab7df6978c45228
      drwx------ 2 root root     4096 19. Mär 2019  BOOT
      drwx------ 9 root root     4096 10. Nov 22:34 EFI
      drwx------ 2 root root     4096 14. Nov 01:54 fb8ba95607f24c159431e63ea08bdf35
      drwx------ 7 root root     4096 15. Nov 10:52 grub
      -rwx------ 1 root root 34840711 17. Nov 21:01 initramfs-linux-fallback.img
      -rwx------ 1 root root  8416930 17. Nov 21:01 initramfs-linux.img
      -rwx------ 1 root root  4769792  8. Jun 20:31 intel-ucode.img
      drwx------ 3 root root     4096 21. Nov 22:49 loader
      drwx------ 2 root root     4096 19. Mär 2019  System Volume Information
      -rwx------ 1 root root 10383328 17. Nov 21:01 vmlinuz-linux
      
      lsblk -f
      NAME         FSTYPE FSVER LABEL               UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
      nvme0n1                                                                                           
      ├─nvme0n1p1  vfat   FAT32 SYSTEM              EE3E-787C                             253,5M    29% /boot
      ├─nvme0n1p2  ntfs         P2-ntfs-MS-reserved 5736F2C71D06F7E0                                    
      ├─nvme0n1p3  ntfs         P3-50G-ntfs-win     46D0404CD0404501                                    
      ├─nvme0n1p4  ntfs         P4-hidden-nttfs     4C2CC8352CC81C38                                    
      ├─nvme0n1p5  ntfs         P5-40G-ntfs-Win-Lin 7A94A9AE198762CF                                    
      ├─nvme0n1p6  ext4   1.0   Ubmate21            e1bb37d2-d8eb-4d4d-9384-34981dda0f6c                
      ├─nvme0n1p7  ext4   1.0   P7-50G-LM20         a16fb4ca-57c2-4e70-98f3-07feb055d85c                
      ├─nvme0n1p8  ext4   1.0   100G-ext4-home      2a8b2f3d-ce7c-4565-a217-b7866f71885b   33,7G    60% /home
      ├─nvme0n1p9  ext4   1.0   P9-100G-bifimu      4c66d81d-d9e2-4274-bae3-8f590b3609f4                
      ├─nvme0n1p10 ext4   1.0   P10-22G-Manjaro     998b345a-6cba-4808-8fb2-f9984ffe120a                
      ├─nvme0n1p11 vfat   FAT32                     0847-6D72                                           
      ├─nvme0n1p12 swap   1     swap                903e6ef2-91fd-49d1-8f4a-a8c3dfff4c31                [SWAP]
      ├─nvme0n1p13 ntfs         WinRE_DRV           AAFC41A4FC416C1F                                    
      └─nvme0n1p14 ext4   1.0   Arch                83a50b91-c580-41de-ab0e-a88447142d23   28,1G     6% /
      
      efibootmgr -v
      BootCurrent: 0005
      Timeout: 2 seconds
      BootOrder: 0003,0001,0005,0006,0004,001D,0002,0000,0018,0019,001A,001B,001C,001E
      Boot0000* Windows Boot Manager	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...j................
      Boot0001* ubuntu	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0xb4000)/File(\EFI\ubuntu\shimx64.efi)
      Boot0002  opensuse-secureboot	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\opensuse\shim.efi)
      Boot0003* manjaro	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0xb4000)/File(\EFI\manjaro\grubx64.efi)
      Boot0004* arch	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\arch\grubx64.efi)
      Boot0005* Linux Boot Manager	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\systemd\systemd-bootx64.efi)
      Boot0006* archlinux	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\archlinux\grubx64.efi)
      Boot0010  Setup	FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
      Boot0011  Boot Menu	FvFile(126a762d-5758-4fca-8531-201a7f57f850)
      Boot0012  Diagnostic Splash Screen	FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
      Boot0013  Lenovo Diagnostics	FvFile(3f7e615b-0d45-4f80-88dc-26b234958560)
      Boot0014  Regulatory Information	FvFile(478c92a0-2622-42b7-a65d-5894169e4d24)
      Boot0015  Startup Interrupt Menu	FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
      Boot0016  Rescue and Recovery	FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
      Boot0017  MEBx Hot Key	FvFile(ac6fd56a-3d41-4efd-a1b9-870293811a28)
      Boot0018  USB CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
      Boot0019  USB FDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
      Boot001A* NVMe0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,001c199932d94c4eae9aa0b6e98eb8a400)
      Boot001B* ATA HDD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
      Boot001C* ATA HDD1	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
      Boot001D* USB HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
      Boot001E  PCI LAN	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
      Boot001F* IDER BOOT CDROM	PciRoot(0x0)/Pci(0x14,0x0)/USB(11,1)
      Boot0020* IDER BOOT Floppy	PciRoot(0x0)/Pci(0x14,0x0)/USB(11,0)
      Boot0021* ATA HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
      Boot0022* ATAPI CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
      
      cat /etc/fstab
      ### /dev/nvme0n1p14 LABEL=Arch
      UUID=83a50b91-c580-41de-ab0e-a88447142d23	/         	ext4      	rw,relatime	0 1
      
      ## /dev/nvme0n1p8 LABEL=100G-ext4-home
      UUID=2a8b2f3d-ce7c-4565-a217-b7866f71885b	/home     	ext4      	rw,relatime	0 2
      
      ## nicht benötigt, wenn ich Arch jeweils über das Manjaro Grubmenü starte !
      ## /dev/nvme0n1p1 LABEL=SYSTEM
      ## UUID=EE3E-787C      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2
      
      ## /dev/nvme0n1p12 LABEL=swap
      UUID=903e6ef2-91fd-49d1-8f4a-a8c3dfff4c31	none      	swap      	defaults  	0 0
      
      
      cat /etc/mkinitcpio.conf
      ## vim:set ft=sh
      ## MODULES
      ## The following modules are loaded before any boot hooks are
      ## run.  Advanced users may wish to specify all system modules
      ## in this array.  For instance:
      ##     MODULES=(piix ide_disk reiserfs)
      MODULES=()
      
      ## BINARIES
      ## This setting includes any additional binaries a given user may
      ## wish into the CPIO image.  This is run last, so it may be used to
      ## override the actual binaries included by a given hook
      ## BINARIES are dependency parsed, so you may safely ignore libraries
      BINARIES=()
      
      ## FILES
      ## This setting is similar to BINARIES above, however, files are added
      ## as-is and are not parsed in any way.  This is useful for config files.
      FILES=()
      
      ## HOOKS
      ## This is the most important setting in this file.  The HOOKS control the
      ## modules and scripts added to the image, and what happens at boot time.
      ## Order is important, and it is recommended that you do not change the
      ## order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
      ## help on a given hook.
      ## 'base' is _required_ unless you know precisely what you are doing.
      ## 'udev' is _required_ in order to automatically load modules
      ## 'filesystems' is _required_ unless you specify your fs modules in MODULES
      ## Examples:
      ###   This setup specifies all modules in the MODULES setting above.
      ###   No raid, lvm2, or encrypted root is needed.
      ##    HOOKS=(base)
      ##
      ###   This setup will autodetect all modules for your system and should
      ###   work as a sane default
      ##    HOOKS=(base udev autodetect block filesystems)
      ##
      ###   This setup will generate a 'full' image which supports most systems.
      ###   No autodetection is done.
      ##    HOOKS=(base udev block filesystems)
      ##
      ###   This setup assembles a pata mdadm array with an encrypted root FS.
      ###   Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
      ##    HOOKS=(base udev block mdadm encrypt filesystems)
      ##
      ###   This setup loads an lvm2 volume group on a usb device.
      ##    HOOKS=(base udev block lvm2 filesystems)
      ##
      ###   NOTE: If you have /usr on a separate partition, you MUST include the
      ##    usr, fsck and shutdown hooks.
      HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)
      
      ## COMPRESSION
      ## Use this to compress the initramfs image. By default, zstd compression
      ## is used. Use 'cat' to create an uncompressed image.
      ##COMPRESSION="zstd"
      ##COMPRESSION="gzip"
      ##COMPRESSION="bzip2"
      ##COMPRESSION="lzma"
      ##COMPRESSION="xz"
      ##COMPRESSION="lzop"
      ##COMPRESSION="lz4"
      
      ## COMPRESSION_OPTIONS
      ## Additional options for the compressor
      ##COMPRESSION_OPTIONS=()
      • Dirk hat auf diesen Beitrag geantwortet.

        jolexin Ich habe deinen Kaputten Codeblock mal repariert 🙂 Code-Blöcke bitte in dreifache Backticks setzen (``` auf jeweils einer eigenen Zeile), oder erst den Code einfügen, und dann den Code-Button im Editor anklicken.

        • jolexin hat auf diesen Beitrag geantwortet.

          Dirk

          Für deinen Hinweis danke ich sehr!

          Versuch "...Blöcke bitte in dreifache Backticks setzen (``` auf jeweils einer eigenen Zeile) ...": Backtick ist bei mir accent-grave, d.h. ich muss 6 Mal die Taste drücken, damit 3 Backticks in der Zeile stehen Doch bei mir entsteht das graue Codefenster mit dem Rollbalken nicht. Warum nicht?

          Erkenntnis: Das Codeblock-Fenster mit Rollbalken ist "nur" in der Vorschau unsichtbar!

          drwx------ 9 root root     4096 10. Nov 22:34 EFI
          drwx------ 2 root root     4096 14. Nov 01:54 fb8ba95607f24c159431e63ea08bdf35
          drwx------ 7 root root     4096 15. Nov 10:52 grub
          -rwx------ 1 root root 34840711 17. Nov 21:01 initramfs-linux-fallback.img
          -rwx------ 1 root root  8416930 17. Nov 21:01 initramfs-linux.img
          -rwx------ 1 root root  4769792  8. Jun 20:31 intel-ucode.img
          drwx------ 3 root root     4096 21. Nov 22:49 loader
          drwx------ 2 root root     4096 19. Mär 2019  System Volume Information
          -rwx------ 1 root root 10383328 17. Nov 21:01 vmlinuz-linux
          
          lsblk -f
          NAME         FSTYPE FSVER LABEL               UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
          nvme0n1                                                                                           
          ├─nvme0n1p1  vfat   FAT32 SYSTEM              EE3E-787C                             253,5M    29% /boot
          ├─nvme0n1p2  ntfs         P2-ntfs-MS-reserved 5736F2C71D06F7E0                                    
          ├─nvme0n1p3  ntfs         P3-50G-ntfs-win     46D0404CD0404501                                    
          ├─nvme0n1p4  ntfs         P4-hidden-nttfs     4C2CC8352CC81C38                                    
          ├─nvme0n1p5  ntfs         P5-40G-ntfs-Win-Lin 7A94A9AE198762CF                                    
          ├─nvme0n1p6  ext4   1.0   Ubmate21            e1bb37d2-d8eb-4d4d-9384-34981dda0f6c                
          ├─nvme0n1p7  ext4   1.0   P7-50G-LM20         a16fb4ca-57c2-4e70-98f3-07feb055d85c                
          ├─nvme0n1p8  ext4   1.0   100G-ext4-home      2a8b2f3d-ce7c-4565-a217-b7866f71885b   33,7G    60% /home
          ├─nvme0n1p9  ext4   1.0   P9-100G-bifimu      4c66d81d-d9e2-4274-bae3-8f590b3609f4                
          ├─nvme0n1p10 ext4   1.0   P10-22G-Manjaro     998b345a-6cba-4808-8fb2-f9984ffe120a                
          ├─nvme0n1p11 vfat   FAT32                     0847-6D72                                           
          ├─nvme0n1p12 swap   1     swap                903e6ef2-91fd-49d1-8f4a-a8c3dfff4c31                [SWAP]
          ├─nvme0n1p13 ntfs         WinRE_DRV           AAFC41A4FC416C1F                                    
          └─nvme0n1p14 ext4   1.0   Arch                83a50b91-c580-41de-ab0e-a88447142d23   28,1G     6% /

          Versuch Ende

          Eine Bemerkung rein sprachlicher Natur: Ich würde bei einem frisch aufgesetzten Arch Linux, das nicht startet, nicht von einem installierten System sprechen. Das Starten macht ja erst den ganzen Haufen einzelner Dateien zu einem System.
          Die Thread-Überschrift könnte deshalb auch lauten: "Hilfe, ich wollte 3 Dinge auf einmal die ich alle noch nicht ganz überblicke und habe in irgend einer oder auch mehreren Konfigurationsdateien das Falsche stehen." Aber lass es mal so, es haben ja alle hier verstanden um was es dir geht.

          Vorgehensweise:

          1. Wie hier schon begonnen, kann man sich jede config-Datei ansehen oder Logs posten um der Sache gemeinsam auf den Hund zu kommen.
          2. Ich hätte da aber noch einen Alternativorschlag: Du nimmst eine leere Festplatte, hängst alle anderen Platten ab und die leere Platte dran und installierst erst einmal Arch, so wie du es brauchst.
            Der Vorteil bei diesem Vorgehen ist, dass du dir nichts kaputt machen kannst und erst einmal lernst wie Arch aufgesetzt wirst. Solltest du danach überhaupt noch Ubuntu brauchen (es gibt eigentlich Nichts was Ubuntu besser kann als Arch) reduziert sich das Problem auf das Dualboot zweier intakter Systeme.

          @Gerry_Ghetto Ja, ich denke auch, dass du hier schon präzise auf den Hund gekommen bist. Und der Tipp von dir ist ja auch eigentlich der Gleiche, nur das Vorgehen in der Pädagogik ist bei mir ein Anderes.

          @jolexin
          Offenbar wird bei deinen Ausgaben vom Arch Linux immer noch die ESP nach /boot eingehängt. In diesem Fall solltest du nochmal Arch Linux starten, die ESP aushängen, nachschauen, was sich jetzt in /boot befindet und nochmal den Kernel installieren und das initramfs neu bauen.

          umount /boot
          ls -l /boot  # ist vermutlich leer
          pacman -S linux
          mkinitcpio -p linux

          Anschliessend ins Manjaro neustarten und die Grub-Konfiguration aktualisieren. Dann wird vermutlich auch dein Arch Linux gefunden.

          Falls nvme0n1p11 als ESP gedacht war: Die wird von keinem Bootloader referenziert. Falls sie leer sein sollte, kannst du sie im Prinzip löschen. Und falls sie nicht leer ist, solltest du nachschauen, was für Daten da vorhanden sind. Aber für eine Datenpartition gibt es bessere Dateisysteme als FAT.

          Und laut den Ausgaben hast du für Arch Linux zweimal Grub und einmal systemd-boot "erfolgreich" installiert. Das kann man dann aufräumen, wenn es via Manjaro bootet.

            Ich habe die Anleitung von Gerry_Ghetto befolgt. Kann jetzt aus dem Manjaro Grub Menü auch ArchLinux starten.

            Nach dem Start habe ich folgendes gesehen:

            2021-11-22 2045 (ca)
            lsblk
            NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
            nvme0n1      259:0    0 476,9G  0 disk 
            ├─nvme0n1p1  259:1    0   360M  0 part 
            ├─nvme0n1p2  259:2    0    16M  0 part 
            ├─nvme0n1p3  259:3    0  48,2G  0 part 
            ├─nvme0n1p4  259:4    0   515M  0 part 
            ├─nvme0n1p5  259:5    0  24,4G  0 part 
            ├─nvme0n1p6  259:6    0  29,3G  0 part 
            ├─nvme0n1p7  259:7    0  29,3G  0 part 
            ├─nvme0n1p8  259:8    0  97,7G  0 part /home
            ├─nvme0n1p9  259:9    0 139,7G  0 part 
            ├─nvme0n1p10 259:10   0  29,3G  0 part 
            ├─nvme0n1p11 259:11   0   100M  0 part 
            ├─nvme0n1p12 259:12   0   4,9G  0 part [SWAP]
            ├─nvme0n1p13 259:13   0  1000M  0 part 
            └─nvme0n1p14 259:14   0  32,4G  0 part /
            ls -l /boot
            insgesamt 52388
            -rw-r--r-- 1 root root 34840711 22. Nov 20:39 initramfs-linux-fallback.img
            -rw-r--r-- 1 root root  8416930 22. Nov 20:39 initramfs-linux.img
            -rw-r--r-- 1 root root 10383328 22. Nov 20:37 vmlinuz-linux
            #diese habe ich soeben erzeugt.
            #und die stehen NICHT in der ESP.

            Gerry_Ghetto schrieb ferner zur Partition p11:

            Falls nvme0n1p11 als ESP gedacht war: Die wird von keinem Bootloader referenziert. Falls sie leer sein sollte, kannst du sie im Prinzip löschen. Und falls sie nicht leer ist, solltest du nachschauen, was für Daten da vorhanden sind.

            Einmal war ich gezwungen, Win10 neu installieren, weil keine der Win10 Recovery Maßnahmen mehr funktioniert hat. Dabei ist jene Partition entstanden. Vermutlich braucht Win10 sie zum Starten.

            Die Partition p11 kannst du also lassen, wie sie ist. Ich kenne mich in den Tiefen von Windows auch nicht so gut aus, als dass ich dir dabei helfen könnte.

            Falls du dich traust, mitdenkst und exakt arbeitest, kannst du jetzt deine ESP etwas aufräumen (aus Arch Linux heraus):

            mount /dev/nvme0n1p1 /mnt
            cd /mnt
            rm -rf grub # Grub
            rm initramfs-linux-fallback.img
            rm initramfs-linux.img
            rm intel-ucode.img
            rm -rf loader loader # systemd-boot
            rm vmlinuz-linux

            Dann noch die Bootloader entfernen:

            cd /mnt/EFI/
            ls -l

            Die Verzeichnisse arch, archlinux und systemd inklusive Inhalte kannst du ziemlich sicher löschen. Den Rest solltest du lassen. Dann solltest du die Bootloader für Windows, OpenSUSE, Ubuntu und Manjaro haben.

            Wahrscheinlich entfernt die Firmware die ungültigen Einträge nach einem Neustart aus dem NVRAM. Nach dem Neustart mit efibootmgr -v nachschauen, ob da noch Einträge auf EFI\archlinux EFI\arch oder EFI\systemd vorhanden sind.

            Falls du noch Einträge à la:

            Boot0004* arch	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\arch\grubx64.efi)
            Boot0005* Linux Boot Manager	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\systemd\systemd-bootx64.efi)
            Boot0006* archlinux	HD(1,GPT,75822dc2-6e36-48c1-b31e-d730ae7ee00d,0x800,0x82000)/File(\EFI\archlinux\grubx64.efi)

            hast, dann kannst du sie entfernen (beispielhaft für Boot0004, bitte die richtige Bootnummer angeben:

            sudo efibootmgr --bootnum 0004 --delete-bootnum

            Und ansonsten viel Spass mit Arch Linux.

            • jolexin hat auf diesen Beitrag geantwortet.
              5 Tage später

              Für jedes System eine eine Festplatte bzw. SSD habe ich vor 5 Jahren bereits realisiert. Es ist ein UEFI-Boot ohne secure eingestellt. Es sind als Systeme M$ Windows 10, Arch-Linux, Free-BSD und mittlerweile eine weitere kleine Test-SSD vorhanden.
              Problem 1:
              Wird wie in der "Anleitung für Einsteiger" beschrieben eine /boot - Partition in fat32 verwendet, um diese als EFI-Bootpartition zu verwenden, liegt der Linux-Kernel da wo er eigentlich nicht hin sollte. Richtiger wäre es diese Partition als /boot/efi einzuhängen. So ist dann nur die Bootloaderdatei in der EFI-Partition.
              Problem 2:
              Das FreeBSD will ganz stur eine eigene EFI-Bootpartiton auf seiner SSD.
              Problem 3:
              W$ und Linux nehmen standardmäßig eine einzige EFI - Bootpartiton gemeinsam her. So kann ein System leichter die Boot-Dateien der anderen zerstören.

              So habe ich mittlerweile knallhart jedem System auf seiner SSD eine eigene EFI-Partiton gegönnt und habe mein Grub-Menü um die anderen EFI-Partitonen ergänzt. Was für FreeBSD funktioniert, das funktioniert auch für die anderen. Fällt eine SSD aus, kann ich im UEFI-Bios eine andere zum Start direkt einstellen bzw. auswählen.

              Gruß Markus

              Gerry_Ghetto
              Vielen Dank!
              Ich habe P11 gelassen, die ESP nach deinem Vorschlag aufgeräumt, die Bootloader entfernt, mit efibootmgr verifiziert, dass keine Einträge der Form Boot004 / 005 /006 mehr existieren.

              Ergebnis:
              Arch-Linux lässt sich booten (aus dem Manjaro Grub Menü) und Manjaro ebenso. So wie gewollt.

              @dby656
              Zu Problem 1:
              Am richtigsten wäre es, den Einhängepunkt passend für den gewählten Bootloader zu wählen. Grub nutzt standardmässig /boot/efi, kommt aber auch mit /efi klar. Falls der Benutzer in der Lage ist, Grub dann auch entsprechend zu installieren/konfigurieren.
              Für systemd-boot muss das nicht zwingend stimmen. systemd-boot nutze ich aber nicht. Kann demzufolge nur recht wenig darüber schreiben.

              Zu Problem 2:
              Tönt nach einem Bug (Feature) in FreeBSD (wobei auch dort alles eine Datei ist) oder es liegt am Nutzer.

              Zu Problem 3:
              Falls ein System die Bootloaderdateien von anderen Systemen überschreibt, liegt es wohl am Nutzer. In den letzten 7 Jahren ist mir noch nie ein Bug untergekommen, der dieses Verhalten gehabt hätte.

              @jolexin
              Du darfst dann diese Diskussion als gelöst markieren.