Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: knorki on 2023/09/07, 16:02:54
-
Hallo,
ich habe auch das Problem nach dem letzem Update Das mein PC nur noch ins BIOS bootet.
Ich habe die bisherigen Problemlösungen gelesen, aber da ich im Englisch nicht gut bin und ich nur ein einfaches System aus eine EVO 250GB SSD:
sda1 200M /boot/efi
sda2 224.6G /
bin ich aus den Hilfen nicht schlau geworden.
Ich habe auch den Install-USB-Stick mit dem chroot helper.
Gibt es eine Schritt für Schritt Anweisung für die Lösung?
-
1. siduction Live System starten
2. chroot-helper starten
3. im nun folgenden terminal folgendes eintippen:
grub-install
update-grub
exit
Nun Rebooten und es sollte wieder funktionieren.
-
Leider klapt das nicht,
da ich nicht weiß ob das mit dem Foto einfügen geklappt hat, hier das ganze als text:
Gewählte disk: sda
Nicht verschlüsselt
mount: /mnt/sys/firmware/efivars mount point does niot exist.
dmesg(1) may have more information after failt mount system call.
Betrete instalietes System
Verlassen Sie das CHroor mittles'exit'..
root@linciota-b55.../#
Ich habe dann noch ein lsblk aufgerufen
/# lsblk
Name ... size RO ... Type
loop0 ... 2,6G 1 loop
loop1 ... 4K 1 loop
sda ... 232,6G 0 disk
sda1 ... 200M 0 part/boot/efi
sda2 ... 224,6G 0 part/
sdb ... 14,3G 0 disk
sdb1... 154K 0 part
sdb2... 2,8M 0 part
sdb3... 2,7G 0 part
sr0 1024M 0 rom
.... /# grub-install
i368-pc wird für Ihre Plattform installiert.
.../' update-grub
Found linux image: /boot/vm-linuz-6.5.2-1-siduction-amd64
... weitere boot/vm-linz-6.....
Warnig: os-prober will not be added to the GRUB boot cnfiguration.
Adding boot menu entry fot UEFI Fireware Settings...
done
# exit
Nach herunterfahren und Neustart ohne USB Stick
Meldung:
Reboot and select propper Boot device
Im Bios steht an 'boot Option #1 Samsung SSD 860 EVO 250G
Nun weiß ich nicht weiter
-
Was bei mir half:
siduction live system starten
Partitionen entsprechend mounten (hab mich ans ubuntuwiki bezüglich chroot orientiert)
hab dann die Pakete in der alten Version runtergeladen und installiert (ubuntuwiki bezüglich grub Umstieg bios auf uefi)
dort dann grub-install
update-grub brachte mir einen Fehler wenn ich es richtig im Kopf hab.
Danach ging das ganze
-
Bist du sicher, dass das ISO im EFI Mode gebootet wurde? Das sieht nämlich nicht danach aus!
-
Hallo towo,
ich habe gestern eine Neuinstallation gemacht, ein Update auf den neusten Stand, Neustart ok, nach 2. Neustart wieder das Problem des boot error.
Für mich stellt sich nun die Frage wie denn die richtigen BIOS Boot Einstellungen aussehen müssen.
In den einem PC werden 3! Bootmöglichkeiten angeboten:
P1: samung SSD 860 EVO 250GB
siduction(P1:Samsung SSD 860EVO 250G) ,funktioniert auch nicht
UEFI:Sandisk,Partition 2
CSM Unterstützung: aktiviert
Scherheits Optionen: System
Preferred Operating Mode: Auto
Ich bin mit meinem Wissen so ziehmlich am Ende, da inzwischen 3 PCs von dem Problem betroffen sind.
Bei diesem PC (mit dem ich gerade schreibe) hatte ich rechtzeitig vor dem problemhaften Updates die grub-pakete auf "Halten" in aptitude gestellt und erst nach den korrigierten Packeten das Update durchgeführt.
Die BIOS Einstellungen auf den verschiedenen PC-Bords sehen sehr unterschiedlich aus (verschiedendes Begriffe)
so das ich diese nicht direckt miteinander vergleichen kann.
-
Schau mal nach ob Du im Bios booten nur UEFI einstellen kannst.
Normal hast Du die Auswahl beim Booten von DVD zwischen Bios und UEFI in den Einstellungen. Manchmal noch die Option UEFI oder Bios falls UEFI nicht geht.
-
Wenn du CSM deaktivierst, so bedeutet dies, dass der Kompatibilitätsmodus ausgeschalten ist, der vorgaukelt, dass es sich um ein klassisches BIOS und nicht um ein UEFI handelt. Ergo: deaktivieren.
edlin
-
mh. ich lese da auf dem Foto, Fehler. kein Installationsgerät angegeben!
grub-install /dev/sda könnte helfen!
-
mh. ich lese da auf dem Foto, Fehler. kein Installationsgerät angegeben!
grub-install /dev/sda könnte helfen!
Nein, da es sich um eine EFI Installation handelt.
-
Boote das live System, öffne ein Terminal und zeige die Ausgabe von:
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
zeigen.
-
Hallo edlin,
Du bist der King und natürlich auch alle anderen die geholfen haben und der chroot helper!
Das Problem war tatsächlich die CSM Unterstützung: aktiviert
Diese muss auf deaktiviert stehen, und auch vor dem Start des siduction InstallationsUSB-Stick!
Dann noch nach Chroot helper aufrufen
grub-install
update-grub
alles sauber duchgelaufen
PC herunterfahren USB Stick raus, PC starten, erst noch im Bios Bootreihenfolege ändern das
"siduction Samsung SSD 860..." an erster Stelle steht.
noch mal CSM-Ünterstützung auf deakiviert setzen und Neustart.
So hat nun meine PC-Installation mit dem neuem grub 2.12~rc1-9 funkioniert.
Hinweis: bei der Kontrolle im Bios hat sich die CSM-Unterstützung automatisch wieder auf Akiviert gesetzt!
Das scheint aber ok da nun der PC trotz meherer Neutarts einwandfrei läuft.
-
Jetzt hab ich auch ein Problem mit Grub (hatte den Desktop eine Weile nicht an)
siducer@siduction:~$ su -
root@siduction:~# inxi -SD
System:
Host: siduction Kernel: 6.5.2-1-siduction-amd64 arch: x86_64 bits: 64
Console: pty pts/2 Distro: siduction 2023.1.1 giants - kde - (202309091853)
Drives:
Local Storage: total: 4.58 TiB used: 0 KiB (0.0%)
ID-1: /dev/sda vendor: Western Digital model: WD40EZRZ-00GXCB0
size: 3.64 TiB
ID-2: /dev/sdb vendor: SanDisk model: SSD G5 BICS4 size: 931.51 GiB
ID-3: /dev/sdc vendor: Intenso model: Alu Line size: 29.3 GiB type: USB
root@siduction:~# [ -d /sys/firmware/efi ] && echo UEFI || ECHO BIOS
UEFI
[ This attachment cannot be displayed inline in 'Print Page' view ]
Gewaehlte Disk: sda
chroot task
using chroot to enter installed system
use 'ctrl + d' or type exit and [enter] to leave the chroot
root@chroot-helper:/# grub-install
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
root@chroot-helper:/# update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/patience/theme.txt
Found linux image: /boot/vmlinuz-6.5.2-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.5.2-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.14-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.14-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.9-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.9-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.7-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.7-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.6-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.6-1-siduction-amd64
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
Nach dem Reboot kommt:
error: symbol `grub_is_lockdown` not found
grub rescue>
Irgendwas stimmt mit der Zuordnung nicht, lt. inxi ist die SSD /sdb.
Hat jemand eine Idee?
Ich hab's nochmal versucht, diesmal wurde sdb erkannt, aber wieder neue Fehler.
Gewaehlte Disk: sdb
chroot task
using chroot to enter installed system
use 'ctrl + d' or type exit and [enter] to leave the chroot
root@chroot-helper:/# grub-install
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
root@chroot-helper:/# update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/patience/theme.txt
Found linux image: /boot/vmlinuz-6.5.2-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.5.2-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.14-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.14-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.9-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.9-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.7-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.7-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.6-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.6-1-siduction-amd64
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
Ich kann mir nicht vorstellen, dass das was ausmacht, aber ich wollte sehen was gemounted wird und hab folgende Zeile (Nr. 372) ins Script eingefügt:echo "chroot $target/mnt /bin/sh -c \"mount -a || true && loadkeys de && /bin/bash\""
-
Schau mal weiter oben, wie schaut es mit CSM, Legacy BIOS und UEFI aus?
Ist der Kompatibilitätsmodus scharf geschaltet? Wenn ja, bitte deaktivieren und nur UEFI aktivieren.
-
@hendrikL
danke, das könnte damit zu tun haben.
Allerdings hab ich auf der SSD kein UEFI, kann man das nachinstallieren?
Wenn ich von CSM auf UEFI umschalte, wird mir nicht mal mehr der Stick angezeigt.
-
ähm, ja.
Boot Reihenfolge ändern?
sdb als erstes dann sda?
-
Dann müsste ich Grub auf sdb1 installieren?
-
Ne, wo ist den /boot/efi beheimatet, auf welcher Festplatte, ist dies nirgends so nutzt das System kein UEFI, sondern legacy BIOS, dann müsste grub-install /dev/sdX ausgeführt werden, wobei sdX halt entsprechende Festplatte ist von der gebootet wird und das BIOS entsprechend eingestellt werden, in diesem falle halt csm bzw, legacy.
-
Beim fdisk -l kommt folgende Meldung, auch nach einem fdisk /dev/sdb mit write kommt sie wieder.
Device Start End Sectors Size Type
/dev/sdb1 4096 618495 614400 300M EFI System
/dev/sdb2 618496 1808593063 1807974568 862,1G Linux filesystem
/dev/sdb3 1808593064 1953520064 144927001 69,1G Linux swap
GPT PMBR size mismatch (6416023 != 61439999) will be corrected by write.
The backup GPT table is not on the end of the device.
könnte das was damit zu tun haben?
-
Es scheint ja grub installiert worden zu sein, und zwar nach sdb.
Ich würde jetzt erst einmal im BIOS nachschauen, ob auch sdb als Erstes genommen wird, bzw das efi welches dort hin installiert ist, also die Bootreihenfolge anschauen!
-
Was noch helfen könnte, ist es uns die Ausgabe von "lsblk -l" und "efibootmgr -v" zu zeigen.
-
Danke, mache ich wenn ich wieder Zuhause bin.
Bin gerade für drei Wochen in Urlaub, hatte gehofft den Rechner vorher zum Laufen zu bringen.
-
Melde mich aus dem Urlaub zurück :)
Hier die Ausgabe:
root@chroot-helper:/# lsblk -l
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 3G 1 loop
loop1 7:1 0 4K 1 loop
sda 8:0 0 931,5G 0 disk
sda1 8:1 0 300M 0 part /boot/efi
sda2 8:2 0 862,1G 0 part /
sda3 8:3 0 69,1G 0 part
sdb 8:16 0 3,6T 0 disk
sdb1 8:17 0 3T 0 part /home/manfred/data
sdb2 8:18 0 654G 0 part
sdc 8:32 1 29,3G 0 disk
sdc1 8:33 1 154K 0 part
sdc2 8:34 1 2,8M 0 part
sdc3 8:35 1 3,1G 0 part
root@chroot-helper:/# efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0000,0003,0002,0005,0006
Boot0000* siduction_2019.1.0 HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION_2019.1.0\GRUBX64.EFI)
Boot0002* siduction HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0003* UEFI OS HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0004* UEFI: Intenso Alu Line 8.07, Partition 2 PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/USB(10,0)/HD(2,GPT,dc3243a7-854f-4c05-a7fd-94540304da60,0x174,0x1680)..BO
Boot0005* Hard Drive BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)..GO..NO..........S.a.n.D.i.s.k. .S.S.D. .G.5. .B.I.C.S.4...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L.0.2.5.2.7.1.0.8.7.4.8.1. . . . . . . . ........BO..NO..........W.D.C. .W.D.4.0.E.Z.R.Z.-.0.0.G.X.C.B.0...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.7.C.6.K.X.R.6.6.F.X........BO
Boot0006* USB KEY BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0b00)..GO..NO........o.I.n.t.e.n.s.o. .A.l.u. .L.i.n.e. .8...0.7...................\.,.@.r.d.=.X..........A.............................&..Gd-.;.A..MQ..L.9.D.7.6.4.E.1.0........BO
root@chroot-help
-
BootOrder: 0004,0000,0003,0002,0005,0006
Boot0000* siduction_2019.1.0 HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION_2019.1.0\GRUBX64.EFI)
Boot0002* siduction HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0003* UEFI OS HD(1,GPT,a48ff773-6774-e642-a579-7d5e5785a217,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0004* UEFI: Intenso Alu Line 8.07, Partition 2 PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/USB(10,0)/HD(2,GPT,dc3243a7-854f-4c05-a7fd-94540304da60,0x174,0x1680)..BO
Boot0005* Hard Drive BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)..GO..NO..........S.a.n.D.i.s.k. .S.S.D. .G.5. .B.I.C.S.4...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L.0.2.5.2.7.1.0.8.7.4.8.1. . . . . . . . ........BO..NO..........W.D.C. .W.D.4.0.E.Z.R.Z.-.0.0.G.X.C.B.0...................\.,.@.r.d.=.X..........A.................................>..Gd-.;.A..MQ..L. . . . .W. .-.D.C.W.7.C.6.K.X.R.6.6.F.X........BO
Boot0006* USB KEY BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0b00)..GO..NO........o.I.n.t.e.n.s.o. .A.l.u. .L.i.n.e. .8...0.7...................\.,.@.r.d.=.X..........A.............................&..Gd-.;.A..MQ..L.9.D.7.6.4.E.1.0........BO
BootOrder: 4=Intenso - und wenn der nicht eingesteckt ist?
Vermutlich würden/werden nur 0=siduction_2019.1.0 und 2=siduction "grub" booten (und damit Siduction).
3=UEFI OS scheint auf "Secure Boot" getrimmt zu sein, könnte aber vielleicht auch "grub" booten.
Bei 3,4,5,6 verstehe ich die Bedeutung von ..BO am Ende der Zeile nicht.
Falls die BootOrder nicht gleich geändert werden soll, würde ich die Tastenkombination suchen, die eine (UEFI-)Bootselection aus dem UEFI/BIOS heraus erlaubt (bei Thinkpads oft F12) und früh in der Rechner-Boot-Phase drücken. Dann sollten alle Optionen von 0 bis 6 (außer 1, das scheint zu fehlen, vielleicht deinstalliert/gelöscht) zur Auswahl stehen = alle mit "*" markierten.
"siduction_2019.1.0" und "siduction" sollten dann das entsprechende Betriebssystem (sauber) booten. Falls das klappt, kann man dann mit "efibootmgr" die Reihenfolge neu/anders anordnen.
-
Wenn im Bios UEFI ausgewählt ist, habe ich nur eine Platte zur Auswahl:
"UEFI Hard Disk: siduction_2019.1.0"
Was mich irritiert, ist dass der chroot helper mal die Datenplatte als sda und mal als sdb sieht.
Während die Systemplatte (SSD) keinen Identifier hat.
Normalerweise ist die SSD sda und die Datenplatte sdb.
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
Was mich irritiert, ist dass der chroot helper mal die Datenplatte als sda und mal als sdb sieht.
Ist zwar nicht schön, kann aber vorkommen. Je nachdem welche HD "zuerst" gesehen wird. Kann an (verschiedenen) Controllern oder "Hochlauf-Eigenschaften" (z.B. Kaltstart/Warmstart) etc. liegen.
Während die Systemplatte (SSD) keinen Identifier hat.
Ist sie denn per SATA angeschlossen? Falls ja, verstehe ich es nicht, falls nein, wird vielleicht nur NVME nicht angezeigt.
Was mich irritiert, ist, daß nur eine Boot-Variante angeboten wird, obwohl beide "Siduction-Boots" auf derselben EFI-Partition liegen.
Nach einem erfolgreichen Boot bitte einfach mal nachsehen, ob auch Pfad und Datei (/boot/efi)/EFI/SIDUCTION/GRUBX64.EFI existieren. Falls nicht würde das erklären, warum der zweite Eintrag fehlt.
Genauso sollte "UEFI OS" angeboten werden, wenn dort /EFI/BOOT/BOOTX64.EFI existiert.
-
Hab's nochmal versucht, jetzt wird das EFI Verzeichnis nicht gefunden.
root@chroot-helper:/# ls -l /boot/efi/EFI
insgesamt 12
drwx------ 2 root root 4096 22. Dez 2020 boot
drwx------ 2 root root 4096 18. Sep 10:32 siduction
drwx------ 2 root root 4096 22. Dez 2020 siduction_2019.1.0
root@chroot-helper:/# ls -l /boot/efi/EFI/siduction
insgesamt 136
-rwx------ 1 root root 139264 12. Okt 12:11 grubx64.efi
root@chroot-helper:/# ls -l /boot/efi/EFI/siduction_2019.1.0/
insgesamt 128
-rwx------ 1 root root 131072 22. Dez 2020 grubx64.efi
root@chroot-helper:/# grub-install
x86_64-efi wird für Ihre Plattform installiert.
grub-install: Fehler: EFI-Verzeichnis kann nicht gefunden werden.
Aber der anschließende update-grub läuft ohne Fehlermeldung.
root@chroot-helper:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.5.2-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.5.2-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.14-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.14-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.9-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.9-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.7-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.7-1-siduction-amd64
Found linux image: /boot/vmlinuz-6.4.6-1-siduction-amd64
Found initrd image: /boot/initrd.img-6.4.6-1-siduction-amd64
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings
Nach Neustart kommt aber immer noch:
"error: symbol `grub_is_lockdown` not found."
Die SSD ist übrigens eine M.2 SATA
-
Gut, danke.
Hab's nochmal versucht, jetzt wird das EFI Verzeichnis nicht gefunden.
Das verstehe ich nicht. In den folgenden "ls" taucht es doch jeweils auf!? Sieht auch richtig aus.
[Wenn alles wieder funktioniert würde es sich lohnen, das /EFI/boot Verzeichnis nach (/boot/efi)/BOOT zu kopieren (generischer Boot der Festplatte auch ohne Eintrag in den UEFI Variablen).]
Und ein paar neue Erkenntnisse:
grubx64.efi in EFI/siduction ist neu(er) (12. Oktober) als die Datei in EFI/siduction_2019.1.0 (20 Dez 2020).
Wenn im Bios UEFI ausgewählt ist, habe ich nur eine Platte zur Auswahl:
"UEFI Hard Disk: siduction_2019.1.0"
Wenn das weiterhin so ist wird also das "alte" grubx64.efi gebootet und daher der Fehler
"error: symbol `grub_is_lockdown` not found."
Er "paßt" nicht zur "Grub-Installation" in /boot/grub. Dasselbe dürfte derzeit für "BOOTX64.EFI" in /EFI/boot gelten!
Ich habe allerdings keine Idee, warum "siduction" (ohne 2019) nicht im UEFI Boot-Menu auftaucht. Dort ist ja der neue "grub".
grub-install: Fehler: EFI-Verzeichnis kann nicht gefunden werden.
Auch das verstehe ich nicht. Gerade vorher wurde es doch beim "ls" an der "richtigen Stelle" /boot/efi gefunden!
Aber wenn "grub-install" funktioniert, wie gerade vorher einmal (12. Oktober), wird es per Default unter dem Namen "siduction" im Verzeichnis "siduction" (nicht siduction_2019.1.0) installiert. Das ist "normal". Man müßte Parameter anpassen, damit es unter dem Namen "siduction_2019.1.0" in gleichnamigen Verzeichnis installiert wird.
Im jetzigen Zustand wäre es wichtig, den UEFI "siduction"-Eintrag booten zu können! Der ist (einigermaßen) aktuell.
Die SSD ist übrigens eine M.2 SATA
Dann muß sie auch als ein /dev/sd? "Device" in /dev auftauchen. Oh Moment, mein Fehler. Sie ist vermutlich das jeweils "andere" "sd?" Gerät? Es gibt keine zweite (HD-)Festplatte? Dann verstehe ich lediglich nicht, warum bei der SSD (jeweils) kein "sd?" auftaucht. Das ist aber (zumindest derzeit) wohl vernachlässigbar.
Als nächstes muß "siduction" beim Booten auftauchen!
Falls gar nichts anderes hilft, mit Hilfe von "efibootmgr" in "BootOrder" "0002" vor "0000" einsortieren.
[Der siduction_2019.1.0 Eintrag dürfte für nichts mehr gut sein - zu alter grub. Ich würde ihn derzeit aber noch nicht löschen.]
Eine nachträgliche Idee: Falls grub-install nach/in(!) einem "chroot" ausgeführt wird, muß /boot/efi (auch) dort, also im neuen /(root) unter /boot/efi auftauchen!
Viel Erfolg!
-
Danke für die Tipps,
mit ".. nicht gefunden" hab ich mich auf die Meldung von grub-install bezogen, sorry hab ich mich wohl schlecht ausgedrückt.
Ich hab mal grub64.efi von siduction nach siduction_2019.1.0 kopiert.
Jetzt kommt immerhin schon mal ein Boot-Menü. Leider mit uralten Kernels zur Auswahl, die nicht mehr existieren.
Wenn ich mit efibootmgr die Reihenfolge ändere, wird sie zwar angezeigt, aber nach Neustart hab ich wieder die alte.
-
Ich hab mal grub64.efi von siduction nach siduction_2019.1.0 kopiert.
Jetzt kommt immerhin schon mal ein Boot-Menü. Leider mit uralten Kernels zur Auswahl, die nicht mehr existieren.
Normalerweise - und ich vermute, das ist hier genauso - sucht grub nach /boot/grub/grub.cfg für das Bootmenu. Wenn /boot nicht in eine Partition ausgelagert ist, was möglich ist, aber nicht oft praktiziert wird und worauf das "lsblk -l" keinen Hinweis liefert, befindet sich /boot in der Partition des /(root)-Verzeichnisses. Da der unten dargestellte grub-Verlauf ganz offensichtlich neue Kernel installiert, die aber wohl im Menu nicht auftauchen, muß das /(root)-Verzeichnis von siduction_2019.1.0 ein anderes sein, als das von siduction.
Wenn es also gelingt entweder "siduction" doch anzuzeigen (bevorzugt!) oder "siduction_2019.1.0" das /(root)-Verzeichnis von "siduction" unterzuschieben, sollten die neuen Kernel auswählbar sein.
Wenn ich mit efibootmgr die Reihenfolge ändere, wird sie zwar angezeigt, aber nach Neustart hab ich wieder die alte.
Das "darf" nicht sein. Ich weiß, das ist wenig tröstlich, da es hier ja passiert, deutet für mich aber auf ein Problem beim Eintragen der UEFI Variablen hin. Mir paßt es ja auch nicht :), daß "siduction" gar nicht auftaucht. Ist eventuell "secure boot" aktiviert und verhindert eine Änderung der UEFI Variablen?
Nach einer Änderung per efibootmgr, welcher Art auch immer, muß diese erhalten bleiben, bis sich ein anderes Betriebssystem - oder auch eine Selektion im UEFI Setup - daran zu schaffen macht. Sonst bedeutet das, daß die Änderung gar nicht durchgeführt wurde.
Vielleicht führt das zu neuen Erkenntnissen.
-
Nachdem ich im chroot-helper-Fenster einen DU gemacht habe, läuft mein System wieder :) :) :)
Vielen Dank für eure Hilfe.
-
Ich hab hier auch noch das Problem mit grub 2.12
Als es im d-u auftauchte landete ich nach dem reboot auch im Bios.
Vorläufig löste ich das Problem, in dem ich wieder grub 2.06.-13 installierte.
Vor etwa 1,5 Wochen versuchte ich es erneut mit grub 2.12
Nach dem d-u machte ich
grub-install
update-grub
Nach dem reboot hatte ich dann folgende Meldung:
Loading Linux 6.5.5.-1-siduction-amd64...
Fehler: Symbol >>grub_efi_load_image>> nicht gefunden.
Loading initial ramdisk...
Fehler: Symbol >>grub_efi_load_image>> nicht gefunden.
Beliebige Taste drücken, um fortzufahren...
Ergebnis war dann das ich wieder den alten grub 2.06.-13 installierte
Gebootet wird von sda (insgesamt 3 SSD verbaut).
sda ist im Bios auch als erste zu bootende Festplatte hinterlegt.
Wie krieg ich jetzt den neuen grub zu laufen?
Danke,
Jürgen
-
NochEinNeuer,
hört sich ähnlich an wie mein problem, oder wie von ro_sid in diesem thread vorher.
schau dir mal mit efibootmgr -v die optionen an. ggf ist da aufzuräumen und der richtige boot eintrag zu wählen
https://forum.siduction.org/index.php?topic=9115.msg72443#new
absolut
-
efibootmgr -v liefert mir folgendes:
jf@tuxl:~$ efibootmgr -v
BootCurrent: 000B
Timeout: 1 seconds
BootOrder: 000B,000A,0009,0002
Boot0002* siduction HD(1,GPT,f873896c-fad3-864e-b225-1943217fac49,0x800,0x100000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0009* UEFI OS HD(1,GPT,18aad0ec-4ea2-3044-a992-8c51d7730ecf,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot000A* UEFI OS HD(4,MBR,0x50259418,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot000B* UEFI OS HD(1,GPT,f873896c-fad3-864e-b225-1943217fac49,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
jf@tuxl:~$
Installiert sind 3 Festplatten mit je 1 eigenen siduction je Platte.
Also erst mal das neue grub installieren, dann
grub-install
update-grub
Und danach mit efibootmgr -v nachschauen was sich verändert hat?
Ggf. mit
efibootmgr -b <bootnumber> -B
aktualisieren?
NochEinNeuer
-
efibootmgr -v liefert mir folgendes:
jf@tuxl:~$ efibootmgr -v
BootCurrent: 000B
Timeout: 1 seconds
BootOrder: 000B,000A,0009,0002
Boot0002* siduction HD(1,GPT,f873896c-fad3-864e-b225-1943217fac49,0x800,0x100000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0009* UEFI OS HD(1,GPT,18aad0ec-4ea2-3044-a992-8c51d7730ecf,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot000A* UEFI OS HD(4,MBR,0x50259418,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot000B* UEFI OS HD(1,GPT,f873896c-fad3-864e-b225-1943217fac49,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Derzeit wird 000B gebootet = \EFI\BOOT\BOOTX64.EFI, was bestimmt nicht an den neuen Grub angepaßt ist/wurde.
"siduction" wäre 0002 = \EFI\SIDUCTION\GRUBX64.EFI
Also erst mal das neue grub installieren, dann
grub-install
update-grub
Und danach mit efibootmgr -v nachschauen was sich verändert hat?
Ist anfänglich vielleicht gar nicht erforderlich, aber später sollte man schon aufräumen.
Ggf. mit
efibootmgr -b <bootnumber> -B
aktualisieren?
Jetzt schon umstellen, dann funktioniert es vielleicht schon so.
-
Danke! Damit hat es erst einmal geklappt. Der Neustart klappte und BootOrder konnte ich (hoffentlich) auch dauerhaft ändern.
-
Korrektur. Nach Neustart kommt noch grub Menü und dann war’s das!
Hab wieder
Loading Linux 6.5.5.-1-siduction-amd64...
Fehler: Symbol >>grub_efi_load_image>> nicht gefunden.
Loading initial ramdisk...
Fehler: Symbol >>grub_efi_load_image>> nicht gefunden.
Beliebige Taste drücken, um fortzufahren...
Alten grub installieren half leider diesmal auch nicht.
Mit chroot meckert das Terminal wenn ich efibootmgr aufrufen will.
Ebenso kann ich im Live System zwar sdb1 -als /boot einhängen aber kein /boot/EFI
Ich bin jetzt kurz vor ner Neuinstallation!!
-
Mit chroot meckert das Terminal wenn ich efibootmgr aufrufen will.
Als "root"? Mal mit "vollem Pfad" probieren (/bin/efibootmgr). Falls so nicht erreichbar, efibootmgr aus dem "normalen System"
ins (z.B.) /tmp des chroot Baums kopieren und (mit vollen Pfad) aufrufen. Im (chroot) /tmp hinterläßt es keine Rückstände, da dieses Verzeichnis (später) beim Start geleert wird.
Ebenso kann ich im Live System zwar sdb1 -als /boot einhängen aber kein /boot/EFI
Das ist ein Irrtum! /boot/efi (efi klein!) muß im "/ (root)"-Verzeichnis existieren. Allenfalls wenn man für /boot eine eigene Partition reserviert (heutzutage recht selten!) muß man diese einhängen.
Die EFI "Boot" Partition gehört nach /boot/efi! Danach gibt es dort (eventuell u.a.) ein EFI/... (also /boot/efi/EFI)!
Ich bin jetzt kurz vor ner Neuinstallation!!
Na ja, wenn's hilft ... ;).
-
Stimmt. Das ich /boot einhängen wollte war mein Fehler. Bei mir ist es keine extra Partition.
/boot/efi konnte ich dann richtig einhängen.
efibootmgr brachte ich dennoch nicht zum Laufen.
Auf /bin/efibootmgr -v kam
"EFI variables ar not supported on this system".
Mit Google fand ich raus das evtl. das Modul efivars bzw. efivarfs geladen werden müsste. Ein modprobe efivars bzw. modprobe efivars brachte auch keinen Erfolg.
Ich hab dann nochmals das alte grub installiert und jetzt konnte ich zumindest neu booten. Ich hoffe das bleibt in Zukunft auch so. die efibootmgr hab ich jetzt nochmals angepasst.
Bis auf weiteres werde ich meine Finger von grub lassen. Hab grad keine Lust mehr mich damit zu ärgern.
-
Update:
Da meine SSD das zeitliche segnete, so kam eine neue SSD mit neuer Installation ins Haus.
Ergebnis: Siduction installiert, du -upgrade, inkl. neuem Grub, und beim Neustart landete ich dann im Bios. Bis zum Bootmenü kam ich also nicht.
Ein
root@tuxi:/home/jf# efibootmgr -v
BootCurrent: 000E
Timeout: 1 seconds
BootOrder: 0001,000E,0000,000F,0010
Boot0000* siduction HD(1,GPT,45a86f58-a034-ea4c-8eeb-3395b1391f1b,0x800,0x96000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0001* rEFInd Boot Manager HD(1,GPT,45a86f58-a034-ea4c-8eeb-3395b1391f1b,0x800,0x96000)/File(\EFI\refind\refind_x64.efi)
Boot000E* UEFI OS HD(1,GPT,45a86f58-a034-ea4c-8eeb-3395b1391f1b,0x800,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot000F* UEFI OS HD(1,GPT,18aad0ec-4ea2-3044-a992-8c51d7730ecf,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0010* UEFI OS HD(2,GPT,bee519d2-2500-4b4f-a57f-a95235a7e90a,0x174,0x1680)/File(\EFI\BOOT\BOOTX64.EFI)..BO
root@tuxi:/home/jf#
sieht derzeit so aus.
Einerseits habe ich gerade wenig Lust mich damit rum zuärgern, aber andererseits ist doch etwas Ergeiz da um das Problem zu lösen.
Hab gerade neu gestartet und da sieht das dann jetzt so aus:
root@tuxi:/home/jf# efibootmgr -v
BootCurrent: 000E
Timeout: 1 seconds
BootOrder: 000E,0000,000F,0010,0001
Boot0000* siduction HD(1,GPT,45a86f58-a034-ea4c-8eeb-3395b1391f1b,0x800,0x96000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0001* rEFInd Boot Manager HD(1,GPT,45a86f58-a034-ea4c-8eeb-3395b1391f1b,0x800,0x96000)/File(\EFI\REFIND\REFIND_X64.EFI)
Boot000E* UEFI OS HD(1,GPT,45a86f58-a034-ea4c-8eeb-3395b1391f1b,0x800,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot000F* UEFI OS HD(1,GPT,18aad0ec-4ea2-3044-a992-8c51d7730ecf,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0010* UEFI OS HD(2,GPT,bee519d2-2500-4b4f-a57f-a95235a7e90a,0x174,0x1680)/File(\EFI\BOOT\BOOTX64.EFI)..BO
root@tuxi:/home/jf#
Die BootOrder hat somit eine andere Reihenfolge erhalten.
Irgendwie werde ich aus dem ganzen nicht schlau.
-
Schlau werde ich daraus auch nicht, kann mir bei diesem Verhalten aber auch nur schlecht vorstellen, daß Siduction der schuldige Part ist.
Es ist doch rEFInd als unabhängiger Bootmanager installiert (Glückwunsch!). Wenn man das startet - sofern das geht -, müßte es drei Möglichkeiten zum Booten von Siduction daraus geben:
- Direkter Boot des Kernels - bietet er bei mir jedenfalls an (man kann es am Boot-Symbol erkennen und auch am eingeblendeten Text)
- Start über den UEFI-Eintrag zu Siduction - Grub wird gestartet *GRUBX64.EFI"-Eintrag (Boot0000)
- Start über den UEFI-Eintrag des Datenträgers - Bootmanager (vermutlich auch der Siduction Grub) wird gestartet *BOOTX64.EFI"-Eintrag (Boot000E)
Funktionieren die (drei) Methoden? Dann ist Siduction unschuldig.
Gar nicht verstehen kann ich den Eintrag Boot000F: Nochmal ein BOOTX64 auf derselben Platte? Eine andere Partition (18aad0ec-4ea2-3044-a992-8c51d7730ecf)???? Sind da zwei UEFI-(Boot-)Partitionen auf derselben Platte?
Dann gibt es (laut BOOT0010) noch eine zweite Platte mit Bootmanager BOOTX64.EFI. Wenn das so ist und diese bootfähig ist, geht das in Ordnung so. Bootet denn dieser Eintrag richtig?
Gar nicht verstehe ich die Verwürfelung der UEFI BootOrder! Für die Tests würde ich aber mal eine zeitlang rEFInd als Default-Boot-Eintrag (efibootmgr) festlegen. Das darf sich dann nicht ändern!
[Ein grub-install kann/wird die Reihenfolge ändern. Dies während der Tests also bitte nicht ausführen.]