Beiträge von black_boot

Moin,

Zitat von su_lin_user

Also ich kann mich noch genau daran erinnern, dass im Yast - Bootloader unter Reiter "Bootcode-Optionen" unter "Speicherort des Bootcodes", die Option "In Master-Boot-Record schreiben (/dev/sda) markiert war.

das kann schon sein, wie aber hast du das bei den anderen Installationen (sda6,7 und gemacht; und in welcher ist zuletzt ein update-grub angestoßen worden (durch irgendeine Aktualisierung – kernel oder auch grub)?

Läßt sich nun nicht mehr ergründen, Partitionen gelöscht/überschrieben.

Zitat von su_lin_user

Kommandos wie z. B. "search"

nun ja, search ist ein grub cli Kommando. (in Linux heißt das dann find

LG b_b

Moin,

Ergänzung: In einem CSM Bootsystem muß grub in den MBR der Platte (sdX), sonst kann nicht gebootet werden.

grub war nicht in sdb9! sondern eins der gelöschten p6-8 hat vorher den grub "regiert". (grub stage1 im MBR, core.img im Bereich vor der 1. Partition, die übrigen grub Dateien in /boot/grub, also auf einer Partition, ehemals 6,7 oder 8, je nachdem, in welchem System zuletzt ein update-grub angestoßen wurde.)

Die grub Dateien sind jetzt weg, daher grub rescue>

Von dort kann man das System (mit etwas Glück) ebenfalls starten. Rettungsmodus

LG b_b

Moin,

Zitat von neoghb

Vermutlich war der Bootloader in P9 - was man auch gesehen hätte, hättest du mal mit fdisk da rein geschaut.

es handelt sich um diese Anordnung (vor den hiesigen Änderungen)

sdb
...
├─sdb6     btrfs        Suse_Leap_15.1  35d6f6e2-513c-41e8-964d-e3d96118b2b3             0x83
├─sdb7     btrfs        Suse_Tumb_32bit cf1882f5-f695-4f5e-8c31-a33e4dc1e6d4             0x83
├─sdb8     btrfs        Suse_Leap_15.2  5d257700-aebf-4329-8813-82114ee5ef87             0x83
└─sdb9     ext4   1.0   Suse_Tumb_64bit eee0f27c-2f88-4ade-9266-b6573ecd969f             0x83

ich vermute da eher, daß bei den jeweiligen Installationen grub jeweils in den MBR von /dev/sdb geschrieben wurde, sonst hätte die Platte im alten System (RE: MBR Multiboot: Getrennte Partitionen, System löschen und Benutzer löschen) gar nicht booten können.

Und verrückterweise soll die Platte ja auch im neuen System (EFI) weiter im CSM Modus betrieben werden, also jedesmal im UEFI den Modus umschalten.

Ich riet, per chroot oder mit SG²D das System zu starten und grub einfach durch grub-install /dev/sdb neu zu installieren.

Btw., (=> mal hier reinschauen grub analysieren)

LG b_b

Moin,

du mußt von der noch vorhandenen alten Partition die uuid ändern, auch in der alten fstab.

Dann bootest du mit SuperGrub2Disk (oder machst von einem livesystem ein chroot), und installierst grub neu in den MBR von sda.

LG b_b

Moin,

du hast doch die Partitionen #6,7 und 8 leer gemacht? Die hättest du aber auch gleich löschen können.

Dann verschiebst du mit gparted die Partiton #9 nach vorne. (da das aber extrem lange dauert, würde ich stattdessen P9 kopieren und hinter P5 einfügen, dann die alte P9 löschen.)

LG b_b

Moin

Zitat von su_lin_user

Kann die Zeile Kernel-Parameter auch leer bleiben ?

Gern weitere Vorschläge und Anregungen.

ich empfahl dir ja bereits ᐅ hier ᐊ

-> Lesestoff

LG b_b

Moin,

Zitat von Feli

naja, wohl eher ein

Code

grub2-mkconfig -o /boot/grub2/grub.cfg

stimmt, wird wohl eher in den debianoiden Distris als

UPDATE-GRUB(8)              System Manager's Manual             UPDATE-GRUB(8)

NAME
       update-grub, update-grub2 - stub for grub-mkconfig

SYNOPSIS
       update-grub

DESCRIPTION
       update-grub  is a stub for running grub-mkconfig -o /boot/grub/grub.cfg
       to generate a grub2 config file.

SEE ALSO
       grub-mkconfig(8)

                                  April 2009                    UPDATE-GRUB(8)

verwendet.

Im grub Handbuch finde ich auch keinen update-grub.

LG b_b

Moin,

Zitat von su_lin_user

ich habe mal einfach versucht die /etc/default/grub.old in grub umzubenennen, um zu sehen, ob damit wieder das Bootmenü auf den Stand vor dem Update ist. Das hat gar nichts gebracht, unverändert.

hätte wahrscheinlich, wenn du ein update-grub hättest folgen lassen. Das grub Menü wird aus den scripten (in erster Linie) aus /etc/default/grub und /etc/grub.d/* erzeugt, ändert man an den scripten etwas, wird das eben erst nach einem update-grub wirksam.

Zitat von su_lin_user

versuchen die Linux-Version, die ich behalten möchte als bestimmendes System markieren, damit davon gebootet wird ?

Ich hatte eigentlich hinreichend erklärt, wie du das gewünschte System (im CSM Bootmodus) zum "führenden" machen mußt (dachte ich wenigstens). Was du jetzt wieder mit markieren meinst, kann ich nicht nachvollziehen.

Boote in das System und führe dort ein

sudo grub-install /dev/sdX

aus, für "X" nimmst du die Platte, auf der sich auch "/" befindet. Im CSM Modus mußt du dann von genau dieser Platte booten.

btw., das Kopieren von /etc/default/grub nach /etc/default/grub.old dürfte eines der nicht ersichtlichen (gar nicht unüblen) features aus Yast-Bootloader Reiter Bootloader-Optionen Haken gesetzt bei "fremdes OS testen" sein? K.A.

-> Lesestoff

LG b_b

Moin,

Zitat von su_lin_user

Ich hab mal bei dem Open Build Service geschaut. Den bootinfoscript gibts für openSuse anscheinend nicht.

nun, bei dl_bootinfoscript wärst du fündig geworden, aus bootinfoscript-061.tar.gz die Datei bootinfoscript entpacken und dann im Terminal

sudo ./bootinfoscript Result.txt

In der Result.txt stehen dann die Informationen. Es ist ein script, das funktioniert in allen distris.

Zitat von su_lin_user

Grub2 ist anscheinend so gemacht, dass er alle auffindbaren Laufwerke nach Bootinformationen absucht und sammelt.

das tut er nur, wenn 'os-prober' auf aktiv geschaltet ist (in der Datei /etc/default/grub muß dazu einen Zeile GRUB_DISABLE_OS_PROBER=false stehen und ein update-grub ausgeführt werden.

LG b_b

Moin,

wo in sda3 sind denn da die jeweiligen "/home" der verschiedenen Distri user?

Zitat von su_lin_user

Neuigkeiten:

Also ich habe im Bootmanger der SSD (ssd, sr0) die Reaktionszeit von 72 sec. auf 7 sec. herabgesetzt. Danach hat Grub

hä? Aus deinem 2. post

Zitat von su_lin_user

Code

NAME       FSTYPE FSVER LABEL           UUID                                 MOUNTPOINTS PARTTYPE
sda                                                                                      
...
sdd                                                                                      
sr0                                                                                      
nvme0n1                                                                                  
...

(im Original die # 19 und 20 (hier #4 und 5)

Das sind 1. ein device (Platte, o.ä.), nämlich /dev/sdd und 2. das DVD LW, /dev/sr0. Die SSD ist die nvme0n1. Auf /dev/ssd scheint nichts zu sein, keine Partition oder Dateisystem.

Und so ein komisches GUI Tool (yast-bootloader) würde ich eher nicht benutzen, da weiß man ja überhaupt nicht mehr, was da im Hintergrund abläuft. An welcher Stelle sollte man denn da wählen können, welches device man bearbeitet.

Du solltest doch mal das bootinfoscript (download, entpacken und ausführen) laufen lassen und die Ergebnisdatei hier posten

LG b_b