Beiträge von black_boot

Moin,

Zitat von Mischek

...stehen auch noch die alten Einträge von 15.3 im Bootlader.

du meinst wohlmöglich Bootmanager, denn der bootloader wird bei der Installation neu geschrieben, so das nicht explizit verhinderst.

Zeig mal sudo parted -l und sudo efibootmgr -v

LG b_b

Moin,

Zitat von Omegator

Kann ich diesen dann von einem Live-System aus ändern?

genau dafür ist eben efibootmgr das Werkzeug. -> man efibootmgr oder -> efibootmgr bei Wiki UU_de.

LG b_b

Moin,

Zitat von Omegator

Daß Windows die Einträge überschrieben hat, halte ich für möglich, das wäre ja nicht neues...

das gilt nur im CSM (BIOS) Modus! im EFI Modus ändert sich lediglich die Reihenfolge im NVRAM (Du solltest ja mal ein efibootmgr -v hier zeigen.

Zitat von Omegator

Gibt es denn eine Möglichkeit NVRAM zu sichern, und und diesen von außen zu ändern, wiederherzustellen, usw?

Das NVRAM wird von der firmware automatisch an Hand der Einträge in der ESP sowie weiterer in der firmware verankerten (Hardware, von der gebootet werden kann, entspricht BIOS auf Werkseinstellung zurücksetzen) erzeugt.

Von außen kann man mit jedem laufenden Linux (LiveSystem) eingreifen/ändern. Wiederherstellen geht nur, indem man ins BIOS "geht", und eben zurücksetzt resp. Einstellungen anpaßt.

LG b_b

Moin,

Zitat von 37431

Interessanter Artikel.

Ob es noch funktioniert?

Ich habe hier einen Rechner, der außer Win11 auch Tumbleweed und Fedora starten kann. Das habe ich gemacht und noch zusätzlich desinfec't (=Ubuntu) per USB.

Bei allen drei Distris scheitert die Beschreibung z.B. am Abschnitt zur SLIC-Tabelle. Die erforderliche Datei ist nicht vorhanden.

dann bist du bei deiner Lektüre aber nicht bis #Andere-Parallelsysteme gekommen. SLIC Tabelle ist doch nur für Windows wichtig.

Linux guest im Linux host sind doch im Prinzip letztlich nur ein paar Befehle

sudo VBoxManage createmedium disk --filename ~/VirtualBox\ VMs/RAW/<name>.vmdk --format=VMDK --variant RawDisk --property RawDrive=/dev/sdX --property Partitions=Y

sudo chown $USER ~/VirtualBox\ VMs/RAW/<name>.vmdk

sudo chown $USER ~/VirtualBox\ VMs/RAW/<name>-pt.vmdk 

-> sudo nano /etc/udev/rules.d/VBox<name>.rules -> -> KERNEL=="sdXY", OWNER="blackboot", MODE="0664"

sudo udevadm trigger 

'name', 'X' und 'Y' entsprechend anpassen. Maschine erstellen ohne Platte, danach die <name>.vmdk als Platte einbinden. Zum Starten SG²D (oder halt einen eigenen MBR in die virtuelle Maschine einbauen)

LG b_b

Moin,

Zitat von 37431

Mir fehlt die Fantasie, was man noch verändern könnte.

Man könnte Dualboot Windows virtualisieren #Angleichung Virtuell an Physikalisch versuchen, ob das aber noch mit ganz aktuellen Windowsversionen resp. vorinstallierter OEM-Version funktioniert? (! /sys/firmware/acpi/tables/MSDM !)

Wenn nicht, hat man aber (hoffentlich) zumindest für ein paar Tage ein virtualisiertes (nicht aktiviertes) Windows, welches man halt nach dem virtuellen Gebrauch mal wieder real starten sollte für den Erhalt der Aktivierung (! ohne Gewähr !)

LG b_b

Zitat von Omegator

So, Problem gelöst.

Mithilfe der Supergrub-Disk2 bin ich wieder in mein Bootmenü gelangt, und konnte ganz normal hochfahren.

Anschließend habe ich mit dem Befehl:

Code

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

dem Bootloader beigebracht das Bootmenü zu laden, und daß nun außer Linux auch Windows ausgewählt werden kann.

Moin,

sollte mich wundern, wenn durch dein o.g. genanntes Vorgehen (Windows update bei abgesteckter Linuxplatte) ein Veränderung an der grub.cfg stattgefunden haben soll.

Viel wahrscheinlicher ist wohl, daß die Reihenfolge (im NVRAM) zu Gunsten von Windows geändert wurde

efibootmgr -v

gibt darüber Auskunft und ein efibootmgr -o xxxx,yyyy hätte wohl gereicht.

LG b_b

Moin,

ich staune ein wenig darüber, daß zu diesem alten thread/67505 immer noch (?) neue Zugiffe erfolgen (ohne daß auch nur einer irgend etwas zum Thema zu sagen hat, schon seltsam ).

LG b_b

Moin,

Zitat von Freeisbetter

Auch ich habe jetzt die Warnung des Installers in den Wind geschlagen, und das System bootet einwandfrei.

schön, dann macht das der Installer halt so.

Ich habe aber nur ein 'gru2-install' auf einen Datenträger mit GPT durchgeführt, da "mault" ja 'grub2-install' nicht nur, sondern verweigert die Installation. Erst mit dem Schalter '-- force' kann man dann (ähnlich wie beim Versuch in einen PBR installieren zu wollen) 'grub2' dazu "überreden", die Installation durchzuführen.

Zitat von Freeisbetter

Ich verstehe das so, daß "BIOS" nicht gleich UEFI im Legacy Mode ist.

Ob jetzt CSM zu 100% mit "BIOS" gleichzusetzen ist, kann dir wohl nur der entsprechende Boardhersteller (resp. firmeware-Bräter) sagen.

Weiter unten in dem Artikel, den du zitierst, unter

Cause

steht gar, daß grub2 trotz verwendetem Schalter '--force'' nicht installiert werden kann, was imho nur sein kann, wenn die Partitionierung eben NICHT den Platz vor der Partition freigehalten hat; dann ist eben kein Platz für core.img.

LG b_b

Zitat von luigi

Das widerspricht m.E. zwar der offiziellen Lehrmeinung,

https://www.suse.com/de-de/support/kb/doc/?id=000021199

aber vielleicht lernen wir ja etwas dazu, nachdem du den Test gemacht hast ...

bitte sehr (-> SMI USB DISK)

:

black_boot@localhost:~> sudo parted -l

Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die
Regeln erklärt hat.  Normalerweise läuft es auf drei Regeln hinaus:

    #1) Respektieren Sie die Privatsphäre anderer.
    #2) Denken Sie nach, bevor Sie tippen.
    #3) Mit großer Macht kommt große Verantwortung.

Das eingegebene Passwort ist aus Sicherheitsgründen nicht sichtbar.

[sudo] Passwort für root:
Modell: ATA VBOX HARDDISK (scsi)
Festplatte  /dev/sda:  26,8GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang  Ende    Größe   Dateisystem     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   24,7GB  24,2GB  btrfs
 3      24,7GB  26,8GB  2149MB  linux-swap(v1)        swap


Modell: SMI USB DISK (scsi)
Festplatte  /dev/sdb:  4010MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang  Ende   Größe  Dateisystem  Name  Flags
 1      1049kB  106MB  105MB  ext4


black_boot@localhost:~> [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI
black_boot@localhost:~> sudo mount /dev/sdb1 /mnt
black_boot@localhost:~> sudo grub2-install --target=i386-pc --recheck --removable --boot-directory=/mnt/boot /dev/sdb
i386-pc wird für Ihre Plattform installiert.
grub2-install: Warnung: ../grub-core/fs/cpio_common.c:169:not a newc filesystem.
grub2-install: Warnung: Einbettung ist nicht möglich. GRUB kann in dieser Konfiguration nur mittels Blocklisten installiert werden. Blocklisten sind allerdings UNZUVERLÄSSIG und deren Verwendung wird daher nicht empfohlen..
grub2-install: Fehler: mit Blocklisten wird nicht fortgesetzt.
black_boot@localhost:~> sudo grub2-install --target=i386-pc --force --recheck --removable --boot-directory=/mnt/boot /dev/sdb
i386-pc wird für Ihre Plattform installiert.
grub2-install: Warnung: ../grub-core/fs/cpio_common.c:169:not a newc filesystem.
grub2-install: Warnung: Einbettung ist nicht möglich. GRUB kann in dieser Konfiguration nur mittels Blocklisten installiert werden. Blocklisten sind allerdings UNZUVERLÄSSIG und deren Verwendung wird daher nicht empfohlen..
Installation beendet. Keine Fehler aufgetreten.
black_boot@localhost:~>

black_boot@localhost:~> sudo bash -c "for d in \$(parted -l|grep -o \"/dev/[^ :]*\");do case \$(hexdump -v -s 0x80 -n 2 -e '2/1 \"%x\" \"\n\"' \$d) in 'aa75'|'5272') echo \$d: Grub Legacy;;'48b4'|'7c3c'|'020') echo \$d: Grub 2;;*) echo \$d;;esac;done"
/dev/sda
/dev/sdb: Grub 2
black_boot@localhost:~> 

Moin,

je nach verwendetem tool zum Anlegen der Partitionen kann es auch ohne extra Anlegen einer 'bios_boot' Partition funktionieren (z.B. gparted läßt immer Platz vorne frei)

Der grub in den debianoiden kann dorthin das core.img installieren, auch ohne Markierung, ob das bei Suse auch so klappt, müßte ich mal testen.

LG b_b