Beiträge von black_boot

  • efi Einträge komisch

    Moin,


    löschen und neu anlegen.


    Ein vorheriges

    Code
    efibootmgr -v

    zeigt dir, wie der Eintrag aussehen müßte

    Code
    sudo efibootmgr --create --disk /dev/sdx --part y --label "mein Booteintrag" --loader \\EFI\\<Distri>\\grubx64.efi

    (aus UU de Wiki efibootmgr)

    je nachdem statt 'grubx64.efi' für secure boot halt 'shimx64.efi' oder was da sonst noch in der ESP steht.


    LG b_b

  • nach Installation 15.5 startet System mit grub prompt grub>

    Moin,

    frage mich, warum niemand wenigstens mal nach einem 'parted -l' fragt?


    So analysiert man das Bootverhalten im EFI Modus:

    Code
    parted -l

    # zeigt, welches device die ESP ist

    Code
    lsblk -o name,partuuid,uuid

    # gibt die zugehörige PartUUID, sowie die UUID von ESP und "/" aus

    Code
    efibootmgr -v

    # zeigt, welcher Booteintrag auf welche ESP zugreift (die lange Ziffenrfolge)

    ''BootOrder'' zeigt die Reihenfolge

    im Dualboot mit Windows kann es bei bestimmten PC notwendig sein, Windows zwar an 1. Stelle zu setzen, aber auf "inaktiv"

    Code
    mount /dev/<ESP> /mnt &&  ls -R /mnt &&  umount /mnt

    zeigt den Inhalt der ESP (und für <Distri> eine …/efi/<Distri>/grub.cfg, für Windows …/efi/Windows/Boot/boomgfw.efi)

    Mit

    Code
    mount /dev/<ESP> /mnt &&  cat /mnt/efi/<Distri>/grub.cfg &&  umount /mnt

    sieht man den Inhalt der grub.cfg mit der UUID für das zugehörige "/" und damit den Ort derjenigen grub.cfg, die beim Booten als Menü angezeigt wird.

    Bei mehreren ESP untersucht man die entsprechend.


    Und so findet man im "legacy" Modus den/die Ort/e des Bootloaders grub:

    Code
    sudo fdisk -l 2>/dev/null | egrep "Disk /|/dev/" | sed "s#^/dev/#Part /dev/#" | awk '{print $2}' | sed 's/://' | xargs -n1 -IX sudo sh -c "dd if=X  bs=1 count=512 2>/dev/null | grep GRUB > /dev/null && echo Grub gefunden: X || echo Kein Grub: X"

    Nur die auf /dev/sdx können vom BIOS direkt gebootet werden, gem. der Bootreihenfolge.


    (jedenfalls bei debianioden ist das so)

    LG b_b

  • Partition klonen

    Moin,


    noch 'n Nachtrag: Mein Vorschlag, die Partition #9 auf die #6 zu kopieren, war im Nachhinein suboptimal.

    Begründung: Das prefix ist ein ebensolches und dort steht eben in der alten Installation prefix='(hd1,msdos9)/boot/grub2' und auch nach dem Kopieren auf sdb6 ändert sich da nichts. Ist die Partition (#9) gelöscht, werden die erforderlichen Daten (auf /dev/sdb9) eben nicht gefunden, was ein grub rescue> zur Folge hat

    Um aus grub rescue> heraus zu starten muß man (in dieser Konstellation)

    1. prefix=(hd1,6)/boot/grub2
    2. root=(hd1,6)
    3. insmod normal
    4. normal
    5. return

    dann erhält man das richtige grub Menü und kann starten. Danach dann im laufenden System einfach grub erneut nach sdb installieren sudo grub2-install /dev/sdb


    LG b_b

  • Partition klonen

    Moin,


    ich hänge mal noch eine Bemerkung zum chroot (über kreuz EFI-CSM) an.

    Das funktioniert schon


    1. prüfen, ob im EFI Sytem grub2-i386-pc installiert ist (zypper se grub2)

    2. chroot

    test-VB-efi@localhost:~> sudo mount /dev/sdb6 /mnt

    [sudo] Passwort für root:

    test-VB-efi@localhost:~> sudo mount -o bind /dev /mnt/dev

    test-VB-efi@localhost:~> sudo mount -o bind /sys /mnt/sys

    test-VB-efi@localhost:~> sudo mount -t proc /proc /mnt/proc

    test-VB-efi@localhost:~> sudo chroot /mnt /bin/bash

    3. grub installieren

    localhost:/ # grub2-install --target=i386-pc /dev/sdb

    Installing for i386-pc platform.

    Installation finished. No error reported.

    localhost:/ # exit

    exit

    test-VB-efi@localhost:~>

    4. fertig

    Der wichtige Punkt ist grub2-install --target=i386-pc /dev/sdb


    LG b_b

  • unbekannter GnuPG-Schlüssel

    Moin,


    ich habe jetzt eigentlich nicht vor, stundenlang (versprochene 16 MB/s, tatsächlich meist nur im 100er KB/s Bereich) ein wie auch immer geändertes iso zu ziehen für die Testzwecke, die ich im Auge habe. (Daß ich veraltete Pakete bekomme, nun gut, aber der Zugang zu den Repos sollte schon funktionieren)


    LG b_b

  • unbekannter GnuPG-Schlüssel

    Moin,

    was muß ich denn davon halten?

    tritt gerade auf bei einer frischen efi-Installation (in VirtuaBox) mit openSUSE-Tumbleweed-DVD-x86_64-Snapshot20220608-Media.iso


    LG b_b

  • Partition klonen

    Moin,

    hattest du nicht schon geschrieben, daß du das System auf (neu) sdb6 gebootet hast? Deine Anstrengungen jetzt sagen mir, Suse auf sdb6 booten nicht, oder warum das Ganze?

    Ich hatte dir empfohlen, per SG²D dieses Suse auf sdb6 zu booten, und dann aus dem laufenden System heraus mit sudo grub-install /dev/sdb zu reparieren.

    Wenn du das per chroot machen möchtest, mußt du auch im CSM Modus booten (z.B. von dem LiveSystem, welches auch zur Installation verwendet wurde)


    (Es geht evt. auch von einem System im EFI Modus, dann muß aber das Paket grub-pc nachinstalliert werden, es dürfte im EFI System nicht vorhanden sein. Ein solches chroot habe ich noch nicht gemacht!)


    LG b_b


    Edit Was willst du? die alte Bootvariante (sdb6 etc.) auf efi umstellen?

    Wenn nein, dann hat grub (und seine Teile stage1 und core.img) nur etwas im MBR und in dem Bereich vor der ersten Partition zu suchen.

    Im EFI Boot wird dafür eine extra Partition (ESP) eingerichtet, die firmware sucht also nicht im MBR, sondern eben in dieser ESP. (!CSM=>MBR; EFI=>ESP)

    Im CSM (früher BIOS) Modus muß der Bootloader im MBR und nicht in einer Partition stehen. (steht er in einer Partition, brauchst du einen Bootloader, der den im PBR (Partitions Boot Record) per 'chainload' bootent