Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

1

27.11.2017, 18:16

GRUB2 nach Umstellung von MBR auf GPT

Das Problem geht weit über Grub2 hinaus, aber irgendwo muß es schließlich einsortiert werden. Ich habe auf meinem Rechner 3 Linuxe real (also nicht in einer VM) installiert, die sich beim Bootvorgang in die Quere kommen. Der Rechner wurde mit einer Platte ausgeliefert die mit MBR versehen war; später habe ich eine zweite Platte eingebaut, die ich von Anfang an mit GPT partitioniert habe. Das System blieb aber insgesamt im BIOS-Modus (= EFI/legacy ?). Nach vielen Versuchen und Herumfragen im Manjaro-Forum entschloß ich mich, in einem ersten Schritt auch die erste Platte auf GPT umzustellen und danach in einem 2. Schritt vom BIOS-Modus zum EFI-Modus zu wechseln. Im letzten Schritt schließlich sollten alle Bootmanager angepaßt werden und wieder gängig gemacht werden. Im Erfolgsfall hätte ich ein System mit 3 voneinander entflochtenen Startvorgängen gehabt, so daß ich nie mehr das Problem gehabt hätte, welches von den dreien der "Chef" der anderen sein solle.

Die Entwicklung des Problems bis zum Stand "Wechsel der Partitionstabelle" ist im → Manjaro-Forum nachzulesen.

Die Umstellung auf GPT ging mit dem Programm gdisk recht einfach und schnell; erwartungsgemäß hat danach kein System mehr gebootet. Mit einer aktuellen Version von SuperGrub2Disk auf DVD gelingt es jedoch, sie einzeln von Hand zu starten und die Systeme scheinen vom Dateiinhalt alle drei noch heil zu sein. Weiter komme ich jedoch nicht, weil - egal was ich tue - alle Helferlein im BIOS-Modus starten und behaupten, deswegen keine EFI-spezifischen Änderungen vornehmen zu können. {→ Status }

Die Hauptplatine ist ein ASRock H97M Pro4 mit der EFI/BIOS-Version P1.20; für diese Platine hat der Hersteller ein eigenes Handbuch (englisches Manual), welches ich mir gestern geladen habe. In den Abschnitten über BIOS und EFI fällt auf, daß fast immer nur von BIOS die Rede ist und die Begriffe EFI / UEFI nur beiläufig eingeflochten werden. Kurz: ich verstehe nichts und finde im Bootmenü auch nichts, womit ich von BIOS nach EFI wechseln könnte. Im BIOS-Modus streiken aber die Werkzeuge (z.B. BootRepairDisk), wenn sie EFI-Einträge erstellen sollen. Die Hauptplatine stammt von 2014 und damals hatten doch 90% aller Rechner schon etwas mit Windows 7 oder 8. Weil Winzigweich den UEFI-Modus verpflichtend gemacht hat kann ich mir nicht vorstellen, daß meine Hauptplatine nur BIOS kann. Wie komme ich jetzt weiter?

Die Anleitungen von rodsbooks habe ich mir eingehend zu Gemüte geführt. Auch im Ubuntuuser-Forum findet sich sehr ausführliche → Dokumentation zum ganzen Fragenkomplex , aber je mehr ich darin lese um so schneller schwindet mir der Boden unter den Füßen. Ich habe das Gefühl in einem unergründlichen Sumpf gelandet zu sein. Auch ist mir immer noch nicht klar, ob ich auf dem Holzweg bin. Zwar werde ich nie ein Windows (als Beispiel) real parallel installieren, jedoch in Virtuellen Maschinen. Verwendet werden z.Z. KVM/qemu und VirtualBox. Meine Hoffnung ist, daß die Booteinstellung des Wirtssystems nicht in die virtuellen Maschinen und damit auf die Gastsysteme durchschlägt. Konkret: könnte ich auch im EFI-Modus des Wirtssystems noch ein Gastsystem im BIOS-Modus installieren und betreiben? Es gibt noch viele weitere Detailfragen, aber zuerst hoffe ich auf eine grundsätzliche Klärung, ob mein Vorhaben überhaupt erlaubt ist.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 9 mal editiert, zuletzt von »ebbi97a« (27.11.2017, 18:50)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

2

28.11.2017, 10:31

Panik zwischendurch (muß man nicht lesen)

Als wenn ich es geahnt hätte:
… Auch ist mir immer noch nicht klar, ob ich auf dem Holzweg bin. Zwar werde ich nie ein Windows (als Beispiel) real parallel installieren, jedoch in Virtuellen Maschinen. Verwendet werden z.Z. KVM/qemu und VirtualBox. Meine Hoffnung ist, daß die Booteinstellung des Wirtssystems nicht in die virtuellen Maschinen und damit auf die Gastsysteme durchschlägt. Konkret: könnte ich auch im EFI-Modus des Wirtssystems noch ein Gastsystem im BIOS-Modus installieren und betreiben? Es gibt noch viele weitere Detailfragen, aber zuerst hoffe ich auf eine grundsätzliche Klärung, ob mein Vorhaben überhaupt erlaubt ist.
Gerade eben ist die Katastrophe passiert:
Wegen einer dringenden Arbeit mußte ich ich Windows 7 in VirtualBox starten ― und was passiert? Statt Windows zu starten wird die Live-DVD im Laufwerk gestartet! In der VM !!! Die sollte doch von alledem nichts wissen!

Die DVD kann ich aber nicht herausnehmen, weil ich nur über diesen Umweg (SuperGrub2Disk) überhaupt irgendwas gestartet kriege. Es hängt also, wie in meinen schlimmsten Phantasien befürchtet, doch alles kreuz und quer und irgendwie zusammen und ist nicht auseinander zu klauben. Auch bestehende Sicherungspunkte von VirtualBox lassen sich nicht aktivieren, obwohl sie angezeigt werden.
Hätte ich doch nur die Finger davon gelassen!
____________________________________________
Nachtrag um 10:56h
Entschuldigung ― alles zurück!

Offenbar handelte es sich um eine Panikattacke und falschen Alarm:
Im "BIOS" der VM war das DVD-Laufwerk des Wirts (Host) eingebunden und hatte anscheinend erste Boot-Priorität; somit wurde die drinnen liegende DVD anstelle der virtuellen Festplatte gestartet. DVD entfernt ― alles wieder normal.
Wundert mich zwar, daß beim Benützen dieser VM nie was startfähiges im Laufwerk gelegen haben soll, muß mich aber wohl trotzdem schämen, so leichtgläubig gewesen zu sein. :whistling:
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »ebbi97a« (28.11.2017, 14:58) aus folgendem Grund: Erklärung für das Fehlverhalten nachgereicht


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

3

29.11.2017, 14:22

Kann das so klappen?

Im Heimanwenderbereich scheint so eine Umstellung kein Thema zu sein; vermutlich läßt jeder vernünftige Mensch die Finger davon. Das schließe ich jedenfalls aus den mageren Ergebnissen der Suchmaschinen bei diesbezüglichen Suchbegriffen und aus der geringen Resonanz in den Linuxforen. Deswegen will ich jetzt einen Versuch mit Linux Mint wagen, dessen Zerstörung mich nicht besonders hart treffen würde. Wie bereits erwähnt habe ich 2 Ubuntu-mäßige Systeme (Mint & Xubuntu), wobei Xubuntu das Produktivsystem ist, das ich keinen Risiken aussetzen möchte. Dann gibt es noch das anders gestrickte Manjaro, das von mit Xubuntu erzeugten Bootloadern nicht gestartet werden kann (wodurch diese ganze Aktion überhaupt erst ins Rollen gebracht wurde).

Als theoretische Grundlage und Anleitung wird mir dabei Managing EFI Boot Loaders for Linux (Stand 2012 mit Aktualisierungen von 2015) dienen, wobei sich der Verfasser durch seine hilfreiche Anleitung zur MBR/GPT-Umstellung bereits mein Vertrauen erworben hat.

Bisher habe ich daraus verstanden, daß ich den vorhandenen Grub2 (bei mir die Version grub-pc 2.02~beta2-36ubuntu3.14), der nur für 32bit-CPU taugt, durch einen anderen (grub-efi-ia32 2.02~beta2-36ubuntu3.14) - 64bit-tauglichen - ersetzen muß. Erwartungsgemäß bestehen zwischen beiden Paketkonflikte, so daß ich den alten erst deinstallieren muß, bevor ich den neuen installieren kann. Dazu interessiert natürlich die Frage brennend, was nach einem "Unfall" auf halber Strecke los ist. Dann habe ich ein System ganz ohne Grub; die SuperGrub2disk versagt da vermutlich. Kriege ich das irgendwie gestartet, um die Reparatur fortsetzen zu können? Weiterhin interessiert mich, ab die Installtionsroutine alle Verknüpfungen richtig erledigt (z.B. mounten von der ESP in /boot oder /boot/efi oder wo genau ???).

Insgeheim gehe ich natürlich davon aus, daß bei diesem Vorgang nichts passiert und daß ich mit diesem neuen Grub wieder funktionierende Bootloader - diesmal in der ESP - erzeugen kann. Die ESP habe ich bereits als fat32 mit 113 MB angelegt; sie ist allerdings nicht die erste, sondern die zweite Partition laut GPT. Muß ich das noch ändern? Sollte das alles funktionieren, hätte ich anschließend ein System (Mint), das ganz normal über das Grub-Menü starten kann, während die beiden anderen vermutlich unsichtbar bleiben, aber von SuperGrub2Disk noch erreichbar sein werden. Noch völlig unklar ist, ob ich dazu noch Änderungen im EFI-Menü der Hauptplatine ("Mutterbrett") vornehmen muß. Ein Menüpunkt, der von BIOS auf EFI umstellt ist nirgends zu finden.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »ebbi97a« (29.11.2017, 14:30)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

4

29.11.2017, 21:30

Hallo!

Ich hab zwar jetzt viel gelesen, aber ehrlich gesagt, wenig verstanden. Bevor ich mir das noch mal anschaue, bitte ein paar verwertbare Daten liefern. Dazu bitte unten den Link in meiner Signatur betätigen und ganz unten die Terminalausgaben aus dem Bereich "Informationsgewinnung" hier posten.

Dann sieht man ggf. weiter.

Zitat

In den Abschnitten über BIOS und EFI fällt auf, daß fast immer nur von BIOS die Rede ist und die Begriffe EFI / UEFI nur beiläufig eingeflochten werden
Nicht weiter ernst nehmen. Bis zu den Autoren solcher Anleitungen, hat sich noch nicht herum gesprochen, dass das jetzt UEFI heißt. Und da sie meisten USER auch nur den Begriff BIOS kennen, wird er halt fröhlich weiter benutzt, auch für UEFI.

Gruß
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

5

30.11.2017, 07:43

Danke für deine Antwort; so völlig allein fühle ich mich wirklich im Wald, weil das angefangene Abenteuer mir über den Kopf gewachsen ist. Zum Glück sind die 3 Systeme noch nicht ganz kaputt. Deinen Leitfaden habe ich übrigens auch schon durchgelesen, aber ich traute mich die Sache immer noch nicht anzugehen (weil eben ständig neue und unerwartete Überraschungen mit teils weitreichenden Konsequenzen auftreten) und habe gestern nachmittag den Beitrag verfaßt, in dem ich die mir zwingend erscheinenden nächsten Schritte zusammengestellt habe, um mich rückzuversichern. Kann mir einfach nicht vorstellen, daß ich der erste sein soll, der so eine Umstellung macht.

Jetzt also zur Informationsgewinnung:

Quellcode

1
2
ebbi@i5tuxedo ~ $ mount | grep efivars
ebbi@i5tuxedo ~ $ 

Somit erfolgte eine leere Anwort. Der Aufruf erfolgte aus dem laufenden Mint-System, was natürlich im Legacy-Mode (BIOS) gestartet war, weil es so installiert ist. Anders kann ich das (und die beiden anderen) nicht starten, denn die Umstellung auf EFI ist ja gerade das Ziel.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
ebbi@i5tuxedo ~ $ sudo parted -l 
[sudo] Passwort für ebbi: 
Modell: ATA ST1000LM014-1EJ1 (scsi)
Festplatte  /dev/sda:  1000GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende	Größe   Dateisystem 	Name          	Flags
 1  	1049kB  16,4GB  16,4GB  linux-swap(v1)  Linux swap
 2  	16,4GB  16,5GB  118MB   fat32       	EFI System    	boot, esp
 5  	16,5GB  32,1GB  15,6GB  ext4        	Linux filesystem
 8  	32,1GB  396GB   364GB   ext4        	Linux filesystem
 6  	396GB   446GB   49,5GB  ext4        	Linux filesystem
 7  	446GB   1000GB  554GB   ext4        	Linux filesystem


Modell: ATA WDC WD40EZRZ-00W (scsi)
Festplatte  /dev/sdb:  4001GB
Sektorgröße (logisch/physisch): 512B/4096B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende	Größe   Dateisystem 	Name   	Flags
 1  	1049kB  929GB   929GB   ext4        	HOME
 2  	929GB   964GB   35,3GB  linux-swap(v1)
 3  	964GB   4001GB  3037GB  btrfs       	SICHERUNG


Warnung: /dev/sr0 kann nicht zum Schreiben geöffnet werden (Das Dateisystem ist
nur lesbar). /dev/sr0 wurde nur lesbar geöffnet.
Fehler: /dev/sr0: unbekannte Partitionstabelle
Modell: HL-DT-ST DVDRAM GH24NSC0 (scsi)                               	
Festplatte  /dev/sr0:  8363MB
Sektorgröße (logisch/physisch): 2048B/2048B
Partitionstabelle: unknown
Disk-Flags: 

Quellcode

1
2
3
4
5
6
ebbi@i5tuxedo ~ $ sudo apt-get install efibootmgr
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut. 
Statusinformationen werden eingelesen.... Fertig
»efibootmgr« ist bereits die neuste Version (0.12-4).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 12 nicht aktualisiert.

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
ebbi@i5tuxedo ~ $ sudo dmidecode -t 0
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: P2.10
	Release Date: 06/13/2016
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 16384 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 4.6

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ebbi@i5tuxedo ~ $ sudo dmidecode -t 1
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: To Be Filled By O.E.M.
	Product Name: To Be Filled By O.E.M.
	Version: To Be Filled By O.E.M.
	Serial Number: To Be Filled By O.E.M.
	UUID: 03000200-0400-0500-0006-000700080009
	Wake-up Type: Power Switch
	SKU Number: To Be Filled By O.E.M.
	Family: To Be Filled By O.E.M.

Quellcode

1
2
ebbi@i5tuxedo ~ $ sudo efibootmgr -v
efibootmgr: EFI variables are not supported on this system.

Falls das jetzt verwirrend und mein vorangehendes Geschreibsel zu lang war:
  1. Drei Linux-System sind auf /dev/sda installiert, welche(s) bis vor wenigen Tagen einen MBR hatte.
  2. Eine zweite Platte /dev/sdb, die nur Daten enthält, war von Anfang an mit GPT partitioniert.
  3. Die erste Platte habe ich vor wenigen Tagen erfolgreich mit gdisk auf GPT umgestellt und eine EFI-Partition von 113 MB als fat32 dazu gebastelt (/dev/sda2), jedoch noch nicht mit sinnvollem Inhalt gefüllt (das ist eine der Aufgaben, an denen ich noch knabbere).
  4. Alle 3 Systeme waren danach erwartungsgemäß nicht startfähig.
  5. Mit einer DVD, die SuperGrub2Disk enthält, kann ich aber alle 3 von Hand starten.
  6. Leider starten DVD/CD auch nur im BIOS-Modus, so daß sich beispielsweise die BootRepairDisk beschwert, sie könne nichts ausrichten, weil sie im falschen Modus gestartet sei.
Das ist die Lage, in der ich nicht recht weiterkomme und dabei Angst, etwas so falsch zu machen, daß die Systeme zerstört werden. Bis jetzt sind ja nur die Bootmimiken kaputt, was aber ein bekanntes Risiko darstellte und nicht unerwartet kam.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »ebbi97a« (30.11.2017, 09:35)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

6

30.11.2017, 14:11

Hallo!

Ich brauche dann auch noch mal die Ausgabe fokgenden "kleinen" Befehls:

Quellcode

1
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 "hexdump -v -s 0x80 -n  2 -e '2/1 "%x" "\\n"' X | xargs -n1 -IY sh -c "case  "Y" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder v1.98 ;; '020') echo X: GRUB 2 v1.99 ;; *) echo X: Kein GRUB Y ;; esac"" 
Keine Angst, einfach ins Terminal kopieren und abschicken. Die Ausgabe ist dann eher kurz und übersichtlich und sagt uns, wo sich Grub eingenistet hat. Ausgabe wieder hier posten.

Die Terminalabfragen aus deinem letzten Post, wurden die aus dem laufenden System heraus gemacht, wenn ja welchem, oder aus der Live-Session (Installationsmedium im Ausprobieren-Modus)?

Was soll am Ende raus kommen? Also kurz, welches OS wo? Über den Modus UEFI oder BIOS reden wir später noch mal.

Wenn ich mich nicht irre, hast du irgendwo weiter vorne "Boot-Repair" erwähnt. Falls ja, starte das doch noch mal, aber keinesfalls die Reparaturfunktion starten, sondern nur das Info-Summary. An dessen Ende bekommst du einen Link zu Ubuntu-Irgendwas angezeigt, wo das Summary gespeichert ist. Dieses Link hier auch noch mal posten.

Gruß
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Klaus P« (30.11.2017, 14:19)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

7

30.11.2017, 19:16

Ich brauche dann auch noch mal die Ausgabe fokgenden "kleinen" Befehls:

Quellcode

1
2
3
4
5
6
7
8
ebbi@i5tuxedo ~ $ 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 "hexdump -v -s 0x80 -n  2 -e '2/1 "%x" "\\n"' X
 | xargs -n1 -IY sh -c "case  "Y" in '48b4') echo X: GRUB 2 v1.96 ;; 
'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 
oder v1.98 ;; '020') echo X: GRUB 2 v1.99 ;; *) echo X: Kein GRUB Y ;; 
esac""
bash: Syntaxfehler beim unerwarteten Wort `)' 

Das war wohl nicht so gedacht ?

Die Terminalabfragen aus deinem letzten Post, wurden die aus dem laufenden System heraus gemacht, wenn ja welchem, oder aus der Live-Session (Installationsmedium im Ausprobieren-Modus)?

Die wurden aus dem seit mehreren Monaten installierten System gemacht (Linux Mint "Sonya", eines von den dreien, die ich umstellen will); gebootet mithilfe von SuperGrub2Disk.

Was soll am Ende raus kommen? Also kurz, welches OS wo? Über den Modus UEFI oder BIOS reden wir später noch mal.

Das gleiche OS; unverändert wie es läuft und konfiuriert ist -- mit Ausnahme der Bootmimik. Es soll auch in genau der gleichen Partition stehen, mit unveränderter UUID; es belegt mit Ausnahme von Swap nur diese einzige Partition (/dev/sda7).

Wenn ich mich nicht irre, hast du irgendwo weiter vorne "Boot-Repair" erwähnt. Falls ja, starte das doch noch mal, aber keinesfalls die Reparaturfunktion starten, sondern nur das Info-Summary. An dessen Ende bekommst du einen Link zu Ubuntu-Irgendwas angezeigt, wo das Summary gespeichert ist. Dieses Link hier auch noch mal posten.

Kommt später; dazu muß ich erst neu vom Rettungssystem booten, um die Ausgabe kopieren zu können.
Du meinst sicher die Zusammenfassung am Schluß, worin BootRepair seine Vorschläge präsentiert, was es wie reparieren würde, wenn es dürfte und könnte. Ich habe mir das schon einige Male angeschaut und es geht immer sinngemäß so:
Dieses und jenes wäre zu ändern, aber ich (das Programm) kann nicht, weil ich im falschen Modus gebootet bin.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (30.11.2017, 19:38)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

8

30.11.2017, 19:31

Mach's noch mal! Vielleicht hast du oder ich was nicht richtig kopiert. Auf keinen Fall abtippen!!!!

Quellcode

1
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 "hexdump -v -s 0x80 -n  2 -e '2/1 "%x" "\\n"' X | xargs -n1 -IY sh -c "case  "Y" in '48b4') echo X: GRUB 2 v1.96 ;; 'aa75' | '5272') echo X: GRUB Legacy ;; '7c3c') echo X: GRUB 2 v1.97 oder v1.98 ;; '020') echo X: GRUB 2 v1.99 ;; *) echo X: Kein GRUB Y ;; esac"" 


Bei mir würde es auch erst später wieder klappen!

Gruß
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

9

30.11.2017, 19:55

Kommt später; dazu muß ich erst neu vom Rettungssystem booten, um die Ausgabe kopieren zu können.
Jetzt aus dem Livesystem der Schluß:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Boot Info Script e7fc706 + Boot-Repair extra info      [Boot-Info 9Feb2015]


============================= Boot Info Summary: ===============================

 => Grub2 (v1.99-2.00) is installed in the MBR of /dev/sda and looks at sector 
    1 of the same hard drive for core.img, but core.img can not be found at 
    this location.
 => No boot loader is installed in the MBR of /dev/sdb.

            {ganz lang gekürzt}

(debug) reinstall grub2 place-in-all-MBRs no-BIOS_boot (sda5)
 
=================== Suggested repair
The default repair of the Boot-Repair utility would purge (in order to) and reinstall the grub2 of sda5 into the MBRs of all disks (except USB without OS).
Additional repair would be performed: unhide-bootmenu-10s


=================== Blockers in case of suggested repair
GPT detected. Please create a BIOS-Boot partition (>1MB, unformatted filesystem, bios_grub flag). This can be performed via tools such as Gparted. Then try again.


=================== Final advice in case of suggested repair
Please do not forget to make your BIOS boot on sda (1000GB) disk!


=================== User settings
The settings chosen by the user will not act on the boot.

Weil ich nicht sicher bin ob du das wirklich gemeint hast, hänge ich zur Sicherheit die ganze Ausgabedatei an.

Das Reparatursystem ist offenbar fest entschlossen, mich im BIOS-Modus zu halten und nicht zu EFI zu lassen. Bei früheren Versuchen hatte es immerhin Vorschläge gemacht, die zu EFI führen würden, aber dann geklagt, daß das nicht möglich wäre weil dieses und jenes nicht paßt.

Es war leider nicht die originale BootRescue, sondern BootInfo aus Rescatux 0.40b6 . Soll ich das andere Programm suchen?


Dein Spezialkommando ging übrigens auch beim 2. Mal nicht; werde mir das noch genauer anschauen.
Im ganzen Kommando sehe ich nur 5 schließende runde Klammern: gegen Ende mit ;; *) echo X: und weiter vorne mit und '48b4') echo X: und '5272') echo X: und '7c3c') echo X: und '020') echo X:; keine einzige öffnende.
»ebbi97a« hat folgende Datei angehängt:
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »ebbi97a« (30.11.2017, 20:30)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

10

30.11.2017, 21:27

Es war leider nicht die originale BootRescue, sondern BootInfo aus Rescatux 0.40b6 . Soll ich das andere Programm suchen?

Dem wird jetzt abgeholfen: Die aktuelle BootRepairDisk startet vom USB-Stock und produziert folgende Ausgabe (im Zitat stark gekürzt und im Anhang vollständig):

Quellcode

1
2
3
4
5
6
7
8
9
10
 Boot Info Script 8f991e4 + Boot-Repair extra info      [Boot-Info 25oct2017]


============================= Boot Info Summary: ===============================

 => Grub2 (v1.99-2.00) is installed in the MBR of /dev/sda and looks at sector 
    1 of the same hard drive for core.img, but core.img can not be found at 
    this location.
 => No boot loader is installed in the MBR of /dev/sdb.
 => ISOhybrid (Syslinux 4.05 and higher) is installed in the MBR of /dev/sdg.

{stark gekürzt}

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
=================== Suggested repair
The default repair of the Boot-Repair utility would purge (in order to fix packages) and reinstall the grub-efi-amd64-signed of sda5, using the following options:        sda2/boot/efi,
Additional repair would be performed: unhide-bootmenu-10s    use-standard-efi-file


=================== Blockers in case of suggested repair
Die aktuelle Sitzung befindet sich im Legacy-Modus. Bitte starten Sie den Rechner neu und nutzen Sie diese Anwendung in einer EFI-Sitzung. Dies wird diese Funktion aktivieren. Nutzen Sie zum Beispiel Boot-Repair-Disk-64bit ([url]www.sourceforge.net/p/boot-repair-cd[/url]) als Live-USB-Stick, nach dem Sie Ihr BIOS darauf eingestellt haben von USB im EFI-Modus zu starten.


=================== Advice in case of suggested repair
Ihr PC startet im Modus Legacy. Bitte ändern Sie den auf EFI und versuchen es ggf. erneut.
Oder versuchen Sie nach Deaktivierung von Option [Separate /boot/efi-Partition:] es erneut.
Möchten Sie fortfahren?


=================== Final advice in case of suggested repair
Bitte stellen Sie sicher, dass Ihr BIOS von Datei sda2/efi/.../grub*.efi startet!

Ihr PC startet im Modus Legacy. Bitte ändern Sie den auf EFI und versuchen es ggf. erneut.


=================== User settings
The settings chosen by the user will not act on the boot.


Und schon geht es wieder so, wie ich es in Erinnerung hatte: das Programm schlägt mir Wege nach EFI vor (wie ich es möchte), kann sie aber nicht ausführen.
»ebbi97a« hat folgende Datei angehängt:
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »ebbi97a« (30.11.2017, 21:41)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

11

30.11.2017, 22:34

So denn !

Der Endlosbefehl funktioniert hier auch nicht. Komisch wenn ich ihn von der Website, wo ich ihn kopiert habe, nehme geht er...!? Egal, wir haben jetzt das Boot-Info-Summary. Von Boot-Repair lässt du künftig die Finger! Das sollte man nur einsetzen, wenn man genau weiß, was bei rum kommen soll. Bei deinen ganzen Aktionen hast du dich irgendwie heillos verzettelt.

Auf der Platte schaut's jetzt so aus:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
============================= Boot Info Summary: ===============================

 => Grub2 (v1.99-2.00) is installed in the MBR of /dev/sda and looks at sector 
    1 of the same hard drive for core.img, but core.img can not be found at 
    this location.
 => No boot loader is installed in the MBR of /dev/sdb.
 => ISOhybrid (Syslinux 4.05 and higher) is installed in the MBR of /dev/sdg.

sda1: __________________________________________________________________________

    File system:       swap
    Boot sector type:  -
    Boot sector info: 

sda2: __________________________________________________________________________

    File system:       vfat
    Boot sector type:  FAT32
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  
    Boot files:        

sda5: __________________________________________________________________________

    File system:       ext4
    Boot sector type:  -
    Boot sector info: 
    Operating System:  Ubuntu 16.04.3 LTS
    Boot files:        /boot/grub/grub.cfg /etc/fstab 
                       /boot/grub/i386-pc/core.img

sda6: __________________________________________________________________________

    File system:       ext4
    Boot sector type:  -
    Boot sector info: 
    Operating System:  
    Boot files:        

sda7: __________________________________________________________________________

    File system:       ext4
    Boot sector type:  -
    Boot sector info: 
    Operating System:  Linux Mint 18.2
    Boot files:        /boot/grub/grub.cfg /etc/fstab 
                       /boot/grub/i386-pc/core.img

sda8: __________________________________________________________________________

    File system:       ext4
    Boot sector type:  -
    Boot sector info: 
    Operating System:  Manjaro Linux
    Boot files:        /boot/grub/grub.cfg /etc/fstab 
                       /boot/grub/i386-pc/core.img


  • Grub ist also noch im MBR, wie ursprünglich

  • 3 OS, davon Ubuntu auf einer kleinen und Mint sowie Manjaro auf großen Partitionen.

  • Die Platte wurde auf GPT umgestellt aber der Rechner startet nach wie vor im CSM/Legacy Modus (simuliertes BIOS auf UEFI-Boards).

  • Aktuelle kann nur mit Hilfe von SuperGrub2Disk gestartet werden.


Soweit korrekt?

Fragen:

Warum hast du überhaupt diese Umstellung gemacht?
Müssen alle OS erhalten bleiben?
Kann neu installiert werden?
Ist eine Datensicherung vorhanden?
Welches OS wurde zuletzt installiert bzw. welches ist das federführende für Grub?

Anmerkung: Ich hege gewisse begründete Ressentiments gegenüber diesem LinuxMint! Überleg dir also gut, was du sagst....!? ;)

Gruß

(Schätze, es geht dann wohl erst morgen weiter!)
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

12

01.12.2017, 08:01

Guten Morgen!
Erst mal vielen Dank, daß du die langen Analysedateien durchgeschaut hast.


  • Grub ist also noch im MBR, wie ursprünglich

  • 3 OS, davon Ubuntu auf einer kleinen und Mint sowie Manjaro auf großen Partitionen.

  • Die Platte wurde auf GPT umgestellt aber der Rechner startet nach wie vor im CSM/Legacy Modus (simuliertes BIOS auf UEFI-Boards).

  • Aktuelle kann nur mit Hilfe von SuperGrub2Disk gestartet werden.


Soweit korrekt?

Im Prinzip JA.
Möglicherweise gibt es noch andere Startwege, aber ich habe sie noch nicht entdeckt.

Was mich an der Vermutung, daß Grub noch im MBR sei, zweifeln läßt ist die Tatsache, daß gdisk ausdrücklich einen protective MBR ausweist. Allerdings fand ich an anderer Stelle (bei dir? / bei Rod Smith? / sonstwo?) auch diesbezüglich Zeifel. So habe ich also die ersten 512 Byte mit dd ausgenullt und alles war "kaputt". Zum Glück war ich vorsichtig genug, die ersten 2048 Byte vorher mit dd in eine feste Datei zu speichern und der Fehler war schnell behoben. Solche Erlebnisse fördern natürlich nicht gerade das Selbstvertrauen, alles im Griff zu haben.

Fragen:
Warum hast du überhaupt diese Umstellung gemacht?

Weil die 3 Linux-Systeme bootloadermäßig nicht zu entflechten waren und es nicht gelungen ist ein einziges Grubmenü abzulegen, welches alle 3 starten kann. Manjaro hat nur nach der ersten oder zweiten Installation (beide einige Monate her) zusammen mit den anderen funktioniert. Anscheinend hat (aufgrund meiner Unwissenheit?) der Grub von Manjaro die Oberhoheit an sich gerissen. Das Problem wurde bereits im → Manjaro-Forum diskutiert, aber ich habe nicht viel verstanden. Die Quintessenz war jedenfalls, den Grub anzupacken und zu Manjaro zum "Chef" zu machen. Das Resumé der Manjaro-Kenner, warum das nötig wäre, steht in diesem → Beitrag.

Das ist mißlungen und um endlich reinen Tisch zu haben reifte bei mir der Entschluß, die ganzen MBR-Altlasten über Bord zu werfen und ein sauberes EFI-System daraus zu machen. Danach folgt die ganze langweilige Geschichte mit vielen Einzelheiten und Irrwegen (letzter Stand). Mit dem Problem bin ich dann in's Ubuntu-Forum gewechselt, weil ich mich damit besser auskenne und dort mit der Umstellung anfangen wollte.

Müssen alle OS erhalten bleiben?

Es wäre sehr wünschenswert! "Unbedingt" gilt aber nur für Xubuntu. Mindestens bis 18.04 ― lieber aber länger (also "upgrade" statt Neuinstallation).

Kann neu installiert werden?

Xubuntu erst mal nicht.

Ist eine Datensicherung vorhanden?

Es existiert eine Plattenkopie (ganz /dev/sda ― also nicht nur einzelne Partitionen) mit Clonezilla von vor Beginn der Basteleien: also MBR statt GPT, funktionierendes Grub-Menü für Xubuntu und Mint und noch ohne die ESP auf /dev/sda2, die ich nach der GPT-Umstellung händisch hinzugefügt habe. Außerdem habe ich danach noch die Größe von swap auf /dev/sda1 verändert.

Zwar habe ich auch tagesaktuelle Systemsicherungen von allen 3 Systemen mit Timeshift, aber ob das nach den Eingriffen in die Partitionstabelle noch alles richtig macht bezweifle ich. Das /home-Verzeichnis (auf /dev/sdb1) ist kaum gefährdet, die Benutzerdaten werden aber ab und zu mit Back in Time gesichert. Vor gefährlichen Eingriffen (wie Grub2 austauschen) würde ich sowieso eine klassische Sicherung der betroffenen Partition mit dem altbewährten tar machen; bei den Probiersystemen Mint und Manjaro ist das immer nur die root-Partition und bei Xubuntu kommen /var und /home auf eigenen Partitionen hinzu.

Welches OS wurde zuletzt installiert bzw. welches ist das federführende für Grub?

Anmerkung: Ich hege gewisse begründete Ressentiments gegenüber diesem LinuxMint! Überleg dir also gut, was du sagst....!? ;)

Manjaro wurde zuletzt installiert und bekam immer Kernel Panic, wenn es vom MBR-Bootloader gestartet wurde, der offenbar (ganz sicher bin ich nicht ― wie stellt man das fest?) von Xubuntu geschrieben worden war. Xubuntu war das erste System, vom Rechnerlieferanten installiert und ist mein Produktivsystem. Danach kam Mint zum Ausprobieren von riskanten Sachen und zum Schluß Manjaro um zu evaluieren, ob ich evtl. den Anforderungen von RollingRelease-Systemen gewachsen bin. Bisher habe ich es schon 2mal zerstört ― die Antwort lautet also NEIN.

Mit Mint habe ich die Fernwartungssoftware Teamviever ausprobiert und den Messenger Viber; beide betrachte ich als potentielle Schnüffelkandidaten, die ich nicht auf dem Produktivsystem haben wollte. Inzwischen habe ich allerdings gelernt, wie man sowas mit Firejails in Quarantäne steckt.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »ebbi97a« (01.12.2017, 08:50)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

13

01.12.2017, 15:07

Hallo!

Machen wir weiter! Aber es wird noch nicht zum Abschluss kommen, um es vorweg zu nehmen. Du hast das so gründlich verbastelt, dass ich auch nicht sicher bin, wie man das aufdröselt. Am liebsten wär mir eine Neuinstallation von Xubuntu, aber das willst du ja nicht.

Vorab noch mal eine Frage. Wie alt ist das gute Stück denn? Mich wundert, dass die hier bei Auslieferung noch kein UEFI-Boot eingerichtet haben. So alt kann der Rechner doch nicht sein.

Zitat

Was mich an der Vermutung, daß Grub noch im MBR sei, zweifeln läßt
Doch, das ist schon so. Das Summary sagt ja eindeutig

Quellcode

1
Grub2 (v1.99-2.00) is installed in the MBR of /dev/sda 
. Nutzt durch deine ganzen Aktionen aber nix. Du hast zwar die Platte auf gpt umgestellt, dabei aber vieles außer Acht gelassen (Unkenntnis) was dies alles noch erfordert hätte. Die Erstellung eine EFI-Bootpartition (EBP) alleine nützt ja nix. Denn wenn ich das richtig sehe, bootet der Rechner ja immer noch mit CSM/Legacy. Eine Umstellung des Boot-Modus alleine auf UEFI würde aber auch nichts nutzen, da keine Einträge im NVRAM und in der EBP vorhanden sind.
Umgekehrt läuft MBR/BIOS zwar auch auf gpt, man müsste bei Installation aber eine kleine bios_grub Partition ohne Dateisystem (RAW) einrichten. Siehe Info!

Du siehst also das ganze Dilemma!? So wie's aktuell ist, kann kein Boot-Modus funktionieren.

Man könnte versuchen, auf UEFI-Boot umszustellen und dann aus der Live-Session heraus den Xubuntu-Grub neu installieren. Das aber nach dem Prinzip "try and error"! Wie und ob das dann mit der Einbindung der anderen beiden OS klappt........???? Ich hab mir den Manjaro-Thread auch (noch) nicht angesehen. Ich bleib (erst mal) bei meinen Leisten und konzentriere mich auf "ubuntuoides".

Gruß
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

14

01.12.2017, 18:08

Vorab noch mal eine Frage. Wie alt ist das gute Stück denn? Mich wundert, dass die hier bei Auslieferung noch kein UEFI-Boot eingerichtet haben. So alt kann der Rechner doch nicht sein.

Der Rechner wurde im Juni 2015 geliefert. Leider kann ich mich nicht mehr erinnern, ob ich damals bzgl. des Boot-Modus Vorgaben gemacht habe.
Die MBR-Reste habe ich ja (wie weiter oben beschrieben) zu löschen versucht; hat aber nicht geklappt.

Zitat

Du hast zwar die Platte auf gpt umgestellt, dabei aber vieles außer Acht gelassen (Unkenntnis) was dies alles noch erfordert hätte. Die Erstellung eine EFI-Bootpartition (EBP) alleine nützt ja nix. Denn wenn ich das richtig sehe, bootet der Rechner ja immer noch mit CSM/Legacy. Eine Umstellung des Boot-Modus alleine auf UEFI würde aber auch nichts nutzen, da keine Einträge im NVRAM und in der EBP vorhanden sind.
Umgekehrt läuft MBR/BIOS zwar auch auf gpt, man müsste bei Installation aber eine kleine bios_grub Partition ohne Dateisystem (RAW) einrichten. Siehe Info!

Das mit der bios_grub Partition habe ich gelesen und erwogen, sie einzurichten. Sie stand schon mit 1 MB, aber ich habe sie sofort wieder gelöscht und stattdessen die ESP mit 113 MB eingerichtet, weil ich ja von BIOS weg und hin zu EFI wollte und will. Daß da noch jede Menge fehlt weiß ich auch; ich suche ja gerade hierfür Hilfe, weil es so komplex ist und man so viele Fehler machen kann, wie ich sie mir noch gar nicht vorstellen kann. Du schreibst z.B. EBP wo ich ESP geschrieben habe; habe ich schon wieder was verwechselt?

Mir ist klar, daß ich das grub-Paket für BIOS durch das grub-Paket für EFI ersetzen. Das muß richtig verknüpft und mit Inhalt gefüllt werden. Deswegen habe ich ja weiter oben gefragt, ob ich mich hierbei auf die Paketverwaltung verlassen darf oder ob ich selbst Hand anlegen muß. Wenn das alles erledigt ist, müßte Grub2 in der Lage sein, neue Bootloader zu erzeugen; dieses Mal aber nicht im MBR, sondern in der EFI-Partition. So habe ich es mir zusammengereimt.

Zitat

Du siehst also das ganze Dilemma!? So wie's aktuell ist, kann kein Boot-Modus funktionieren.

Richtig - aber das war ja auch meine Absicht. Habe ich mich unklar ausgedrückt?

Zitat

Man könnte versuchen, auf UEFI-Boot umszustellen und dann aus der Live-Session heraus den Xubuntu-Grub neu installieren.

JA - JA - JA ! Genau das will ich erreichen und darauf arbeite ich mit aller Kraft hin. Der MBR muß weg!
Hoffentlich kriege ich dann immer noch herkömmliche CDs und DVDs gestartet.

Zitat

Das aber nach dem Prinzip "try and error"! Wie und ob das dann mit der Einbindung der anderen beiden OS klappt........???? Ich hab mir den Manjaro-Thread auch (noch) nicht angesehen. Ich bleib (erst mal) bei meinen Leisten und konzentriere mich auf "ubuntuoides".

Müßte doch ganz analog gehen?

Erst stelle ich Mint um. Falls das klappt, stelle ich Xubuntu genauso um. Wenn das fertig mache ich mich schlau, was bei Manjaro anders und passe die Umstellung an. Danach sollte alles entflochten sein und kein Betriebssytem sollte mehr federführend sein müssen.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (01.12.2017, 18:19)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

15

01.12.2017, 18:58

Hallo!

Zitat

Der Rechner wurde im Juni 2015 geliefert. Leider kann ich mich nicht mehr erinnern, ob ich damals bzgl. des Boot-Modus Vorgaben gemacht habe.
O.K.! Schon eher ungewöhnlich.

Zitat

Richtig - aber das war ja auch meine Absicht. Habe ich mich unklar ausgedrückt?
Du hast so viel geschrieben, dass man am Ende nicht mehr weiß, was am Anfang stand. Deshalb versuche ich das hier Schritt für Schritt anzugehn.

Zitat

JA - JA - JA ! Genau das will ich erreichen und darauf arbeite ich mit aller Kraft hin. Der MBR muß weg!
Weiß zwar nicht warum du so versessen darauf bist, den MBR zu killen, aber gehn wir es an.

1. Falls du mit einer Ubuntu-DVD (64Bit) arbeitest, kannst du die verwenden. Falls du USB-Stick benutzt, muss der erst für GPT/UEFI eingerichtet werden. Siehe dazu im Leitfaden Tipps/Links (der 2. Punkt).

2. Du gehst ins Set/Up (UEFI) des Rechners (wie musst du wissen bzw. im Manual nachschlagen), dort in den Bereich Boot. Hier stellst du konsequent auf UEFI (only) ein. Secureboot bleibt (erst mal) aus (disabled).

3. Dann bootest du vom Installationsmedium. Du kannst auch in das direkte Bootmenü des Rechners gehn (meist eine höhere F-Taste) und dort das UEFI-Bootmedium explizit auswählen. Wenn sich dieses Menü zeigt, bist du im UEFI-Modus. Hier "Try-Ubuntu" auswählen. Du kannst aber auch noch mal zur Sicherheit dann im Terminal der Live-Session überprüfen mit

Quellcode

1
 [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS 
ob's wirklich UEFI ist oder doch BIOS.

Falls soweit alles O.K., gehts los mit der Grub-Installation, via Terminal, mit der sogenannten chroot-Methode. DAS BEZIEHT SICH AUF XUBUNTU. WENN DU MINT NEHMEN WILLST, MUSST DU IM ERSTEN BEFEHL DIE SYSTEMPARTITION ÄNDERN AUF sda7.
(was hinter ## steht ist auskommentiert und dient nur der Information,brauchst also nicht einzugeben. wenn doch auch nicht schlimm)

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sudo mount /dev/sda5 /mnt  ## Systempartition einbinden
sudo mount /dev/sda2 /mnt/boot/efi  ## EFI Partition einbinden
sudo mount -o bind /dev /mnt/dev 
sudo mount -o bind /sys /mnt/sys 
sudo mount -t proc /proc /mnt/proc 
sudo cp /proc/mounts /mnt/etc/mtab 
sudo chroot /mnt /bin/bash
 
## bis hierher wurde ins System „gechrootet“, nun folgt die Grub-Neuinstallation

grub-install 
update-grub
exit

sudo umount /mnt/dev /mnt/proc /mnt/sys /mnt
Falls hier Fehlermeldungen kommen, bitte den ganzen Vorgang kopieren und hier posten.


Neustart
Vorher eine Kerze spenden oder ähnliches könnte u.U. hilfreich sein! Falls

Falls was unklar ist oder dein Set-Up Überraschungen bereit hält, frag noch mal nach.
Falls nix geht und SuperGrubDisk mit UEFI nicht bootet, alles wieder so einstellen, wie vordem. Also ggf. die Einstellung notieren.

Viel Erfolg!

Edit: Kann nicht genau sagen, wann ich heute (oder erst morgen) wieder hier rein schaue.

Edit 2:

Zitat


Erst stelle ich Mint um. Falls das klappt, stelle ich Xubuntu genauso um. Wenn das fertig mache ich mich schlau, was bei Manjaro anders und passe die Umstellung an.
Die sollten alle in Grub eingebunden werden. Da muust du nix "umstellen". Manjaro kann ein Sonderproblem bleiben.
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Klaus P« (01.12.2017, 19:05)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

16

01.12.2017, 20:16

Kann nicht genau sagen, wann ich heute (oder erst morgen) wieder hier rein schaue.

Kein Problem und vielen Dank erstmal für deine schnelle und ausführliche Anleitung. Es eilt nicht: Morgen ab 6 Uhr werde ich außer Haus sein und erst am Abend wiederkommen. Dann werde ich erstmal den Umstellungskandidaten Mint auf /dev/sda7 mittels tar sichern. Nach meinem Verständnis gibt es seit grub2 nichts mehr, was in der Systempartition an festen Plattenadressen stehen müßte, so daß tar mit Systemverwalterrechten ausgeführt für eine erfolgreiche Rücksicherung (im Fehlerfall) genügen müßte. Heute lasse ich mir alles nochmal durch den Kopf gehen und werde noch die eine oder andere Verständnisfrage stellen; am Sonntag soll es dann ernst werden.

Fragen:
  1. Das USB-Stick einrichten wäre eine gewesen, aber das hast du schon erwähnt.
  2. Mir ist aber nicht klar, warum ich von extern arbeiten muß (also Livesystem starten und mit chroot arbeiten).
    Warum darf ich nicht einfach das bestehende Mint-System starten und mit der Paketverwaltung erst den grub für BIOS deinstallieren und anschließend den für EFI installieren?
  3. Zum UEFI des Rechners ist auch noch was unklar. Das muß ich aber erst nochmal anschauen bevor ich hier Blödsinn schreibe.
  4. Was ist das mit dem Einbinden der anderen 2 Systeme? Wären die dann nicht wieder unlösbar aneinander gekoppelt?
    Ich hatte geglaubt, daß jedes Einzelsystem seinen eigenen Bootloader in der ESP bekommt, der nicht an einen anderen gekoppelt ist. Dabei ließ ich mich vom Abschnitt Copying Boot Loader Files in http://www.rodsbooks.com/efi-bootloaders….html#accessing leiten.
    Der scheint da für jedes bootfähige System ein eigenes Verzeichnis im ESP anzulegen; habe wohl wieder irgendwas verwechselt. Schaut auch ziemlich kompliziert aus.
  5. Das mit der Kerze überlege ich mir. Komme morgen an Altötting vorbei; vielleicht ist ein Besuch der Wallfahrtskapelle angeraten.

Jetzt bin ich wohl noch eine Erklärung schuldig, warum ich da so bohre:
Unter EFI Deinstallieren finde ich beispielsweise

Zitat

"Eine native Installation auf einem Rechner im BIOS-Modus greift immer in die Basis ein und beeinflusst das Bootverhalten - es wird unter GRUB 2 u.a. ein neuer MBR gesetzt.
Anders sieht es aus, wenn man einen Rechner mit einem EFI Bootmanagement hat, dann kann man (im Prinzip) beliebig viele Betriebssysteme auf diesem Rechner installieren, betreiben sowie wenn erforderlich auch deinstallieren, ohne das diese sich gegenseitig beeinträchtigen."
Das ist genau das, was mich an der Sache so reizt!
Schon der nächste Satz irritiert wieder vollständig:

Zitat

Eingeschränkt wird diese Unabhängigkeit der Betriebssysteme innerhalb eines EFI Bootmanagement nur durch die interne System-ID (ubuntu, kubuntu, linuxmint usw.). Hier muss man dann manuell eingreifen und Regeln aufstellen, welches der Betriebssysteme das primäre und welche die sekundären sind - es kann außerhalb des EFI-Menü nur ein (GRUB 2)-Bootmenü geben - siehe dazu auch Bootverzeichnis.

Wie paßt das alles zusammen? die meinen vermutlich alle was ganz anderes als das, was ich herauslese. Das dagegen paßt schon wieder zum Verständnis, auch wenn es mir nicht schmeckt (hatte was anderes erhofft):

Zitat

Erstellung Bootloader
Da der Installer keine anderen EFI-Installationen erkennt, muss man die ggf. anderen, vorhandenen Betriebssysteme bis einschließlich Ubuntu 13.04 manuell in das GRUB 2-Menü einbinden, wenn man nicht ausschließlich über das EFI-Menü auswählen will.

Daraus würde folgen, daß ich beim Starten immer erst F11 drücken muß um das EFI-Menü zu erhalten, wo die Systeme völlig entflochten sind ? ? ?

Wiederholung zum Verständnis -- ganz wichtig:
Der Auslöser der ganzen Aktion (die ungeahnte Weiterungen nach sich gezogen hat) war folgende Erkenntnis:

Zitat

Du musst unbedingt den Manjaro-GRUB zum Chef machen, sprich: Manjaro-GRUB in den Startsektor deiner Startpartition (also vermutlich nach sda) installieren und aktualisieren lassen, damit dieser deinen Ubuntu-GRUB ersetzt. Es scheint also immer noch so zu sein, dass Ubuntu-GRUBs Manjaro nicht starten können. Die Ubuntu-Entwickler schlafen also scheinbar immer noch den Schlaf der Gerechten, obwohl dieser Umstand schon mindestens zwei Jahre bekannt ist. Oder liegt es vielleicht doch an den Manjaro-Entwicklern ?? >:D
Das wollte ich tun, es ist nicht gelungen und jetzt ärgert es mich nur noch. Schaut fast so aus, als wäre noch lange nicht alles klar.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »ebbi97a« (01.12.2017, 20:58)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

17

01.12.2017, 23:27

Hallo!

Zitat

Mir ist aber nicht klar, warum ich von extern arbeiten muß (also Livesystem starten und mit chroot arbeiten).
Warum darf ich nicht einfach das bestehende Mint-System starten und mit der Paketverwaltung erst den grub für BIOS deinstallieren und anschließend den für EFI installieren?
Weil ich mir nicht sicher bin, ob das bei deiner vertrackten Konfiguration was wird. Deshalb lieber "zu Fuss" von außen. Des weiteren musst du nichts deinstallieren. Der MBR ist bei UEFI-Boot quasi nicht existent. Wurscht, ob da was drin steht oder nicht. Erzeugt wird ein Eintrag im NVRAM, direkt auf dem Motherboard (nicht mehr auf der Platte). Darauf greift der Rechner als erstes zu bei Neustart. Von da aus auf die EFI-Bootpartition, jeweils gemäß der Bootorder im NVRAM-Eintrag, für den federführenden Grub.

Wenn du es aus dem laufenden System heraus versuchen willst, wäre das via

Quellcode

1
2
sudo apt-get --reinstall install grub-common grub-efi-amd64 os-prober 
sudo update-grub
Danach muss der Rechner aber UEFI booten.

Zitat

Was ist das mit dem Einbinden der anderen 2 Systeme? Wären die dann nicht wieder unlösbar aneinander gekoppelt?
Was heißt unlösbar gekoppelt? Mit dem "update-grub" Befehl werden die anderen OS in den Grub des federführenden OS mit eingebunden, um diese starten zu können. mehr nicht!

Zitat

Ich hatte geglaubt, daß jedes Einzelsystem seinen eigenen Bootloader in der ESP bekommt, der nicht an einen anderen gekoppelt ist
Nein, dort legen nur alle OS ihre Bootdateien ab. Gebootet wird der federführende Grub. Es geht vermutlich auch anders, aber so wie ich es hier beschrieben habe, ist der normale Weg.

Zitat

Das ist genau das, was mich an der Sache so reizt!
Was ist so reizvoll an "beliebig viele"? ich habe hier auf meinem Produktivrechner 1x Windows, 1x Ubuntu-Mate und 1 *buntu, das ich aus irgendwelchen Gründen mir mal via Festinstallation näher anschauen möchte. "Experimente" mach ich auf nem anderen Crash-Test-Dummie.
Was das Handling von mehreren OS auf einem Rechner anbetrifft, unterscheiden sich UEFI und MBR/BIOS nicht sooo großartig. In beiden Fällen muss man sehen, dass man einen federführenden Grub hat. Fliegt das OS eines federführenden Grub runter, muss man vorher den Grub eines verbleibenden OS neu einrichten. Steht in einem Grub noch ein alter Booteintrag drin, verschwindet der mit dem nächsten "update-grub". Macht man dies nicht selbst, ist er spätestens nach dem nächsten Kernel-Update fällig, das immer ein "update-grub" ausführt.

Zitat

Erstellung Bootloader
Da der Installer keine anderen EFI-Installationen erkennt, muss man die ggf. anderen, vorhandenen Betriebssysteme bis einschließlich Ubuntu 13.04 manuell in das GRUB 2-Menü einbinden, wenn man nicht ausschließlich über das EFI-Menü auswählen will.
Im nächsten Satz steht da aber auch, dass das ab 14.04 nicht mehr gültig ist. Das waren noch die Anfangszeiten! Jetzt erkennt der Installer andere EFI-Systeme. Jedenfalls der von Ubuntu. Bei Mint würde ich die Hand nicht für ins Feuer legen. Die sind der aktuellen UEFI-Entwicklung immer mindestens 2 Jahre hinterher gehinkt und am Installer auch rum geschraubt. Da zeigen sich halt die Nachteile einer solchen Distro. So lange es Open Source Software betrifft, können sie sich nach Lust und Liebe bedienen. Bei UEFI/Secureboot gehts aber um erforderliche Signaturen, die von der "Microsoft UEFI Certificate Authority (CA)" eingeholt werden müssen.

Zitat


Daraus würde folgen, daß ich beim Starten immer erst F11 drücken muß um das EFI-Menü zu erhalten, wo die Systeme völlig entflochten sind ? ? ?
Nein, werden eingebunden.

Manjaro mag ein anderes Problem sein. Ich weiß es nicht, kenn mich nicht damit aus, weiß z.B. auch nicht, wie die das mit UEFI-Secureboot gelöst haben, da gab es unterschiedliche Ansätze in der Linuxwelt. Ich kann hier nur versuchen dir zu einem funktionierendem Bootsystem mit Ubuntu, egal ob MBR oder UEFI, zu verhelfen. Mint sollte man auch hin bekommen, aber alles andere musst du ggf. woanders klären, wenn sich hier nicht noch jemand anders dazu zu Wort meldet.

Gruß
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Klaus P« (01.12.2017, 23:32)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

18

02.12.2017, 06:15


Warum darf ich nicht einfach das bestehende Mint-System starten und mit der Paketverwaltung erst den grub für BIOS deinstallieren und anschließend den für EFI installieren?
Weil ich mir nicht sicher bin, ob das bei deiner vertrackten Konfiguration was wird. Deshalb lieber "zu Fuss" von außen. Des weiteren musst du nichts deinstallieren. Der MBR ist bei UEFI-Boot quasi nicht existent. Wurscht, ob da was drin steht oder nicht. Erzeugt wird ein Eintrag im NVRAM, direkt auf dem Motherboard (nicht mehr auf der Platte). Darauf greift der Rechner als erstes zu bei Neustart. Von da aus auf die EFI-Bootpartition, jeweils gemäß der Bootorder im NVRAM-Eintrag, für den federführenden Grub.
...
Wenn du es aus dem laufenden System heraus versuchen willst, wäre das via ...
Danach muss der Rechner aber UEFI booten.


Entschuldige bitte, daß ich schon wieder frage -- wahrscheinliche nerve ich dich schon gewaltig --, aber ich möchte nichts Vermeidbares falsch machen.

Sicher muß ich das installierte Grubpaket austauschen. Am 29.11. (siehe weiter oben) hatte ich dazu herausgefunden:

Zitat

Bisher habe ich daraus verstanden, daß ich den vorhandenen Grub2 (bei mir die Version grub-pc 2.02~beta2-36ubuntu3.14), der nur für 32bit-CPU taugt, durch einen anderen (grub-efi-ia32 2.02~beta2-36ubuntu3.14) - 64bit-tauglichen - ersetzen muß. Erwartungsgemäß bestehen zwischen beiden Paketkonflikte, so daß ich den alten erst deinstallieren muß, bevor ich den neuen installieren kann. Dazu interessiert natürlich die Frage brennend, was nach einem "Unfall" auf halber Strecke los ist. Dann habe ich ein System ganz ohne Grub; die SuperGrub2disk versagt da vermutlich. Kriege ich das irgendwie gestartet, um die Reparatur fortsetzen zu können? Weiterhin interessiert mich, ab die Installtionsroutine alle Verknüpfungen richtig erledigt (z.B. mounten von der ESP in /boot oder /boot/efi oder wo genau ???).

Wie soll ich den Paketkonflikt denn anders auflösen als durch Deinstallation des alten?

Secure Boot müssen wir nicht berücksichtigen; Windows kommt da nie drauf.

Was ist so reizvoll an "beliebig viele"?
Das Problem wurde doch von Manjaro ausgelöst, weil das von den Ubuntu-Grub-Bootloadern nicht gestartet werden kann; also muß ich Manjaro federführend machen, zumindestens solange es drauf ist. Ich weiß aber noch gar nicht, ob und wie lange das bleibt. Deswegen wollte ich keine Abhängigkeiten haben dazu haben. Mir dämmert aber schon, daß ich mir da aus einigen falsch verstandenen Sprüchen eine falsche Hoffnung eingebildet habe. Was ich gelesen habe geht nur mit dem EFI-Menü, welches man bei jedem Start umständlich selbst erzwingen muß.

Nochmals Entschuldigung! Soll keine Rechthaberei sein - ich will nur verstehen.Ist wohl doch nicht so weit her mit der Zukunft von (U)EFI, wenn man weiterhin MBR und den Legacy Mode braucht und das nicht ohne Verzicht auf Komfort loswerden kann.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »ebbi97a« (02.12.2017, 06:30)


  • »Klaus P« ist männlich

Beiträge: 4 388

Registrierungsdatum: 25.10.2009

Derivat: anderes Ubuntu-Derivat

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: anderer Desktop

Andere Betriebssysteme: 7/10

  • Nachricht senden

19

02.12.2017, 10:59

Moin!

Du hast doch ein 64Bit System. Wie kommst du drauf, dass obige Version nur 32Bit tauglich wäre? Was willst du denn deinstallieren? Durch die Neuinstallation von Grub im UEFI-Modus wird Grub völlig neu eingerichtet und fertig. Irgendwelche Reste im MBR kannst löschen oder stehn lassen. Is egal, der MBR wird nicht mehr angesprochen bei UEFI-Boot. Jetzt komm nicht vom Hölzchen zum Stöckchen, sonder mach was. Wird schon früh genug schief gehn :S . Wie gesagt, ich garantiere nichts, da deine Konfiguration völlig vermurkst ist. Wenn du Garantie haben willst, geh zum Profi oder versuchs mal beim Tuxedo-Support. Nur verlinke denen nicht die ganzen bisherigen Threads, dann winken die gleich ab, weil sie dafür keine Zeit haben, sich das alles rein zu ziehn.

Primär ist erst mal angesagt ein funktionierendes (UEFI-) Boot hin zu bekommen. Dann sieht man weiter. Ich hatte von Anfang geraten sauber neu zu installieren. Das ist das sinnvollste, wenn man so eine Umstellung macht und eine vernünftige Sicherung hat. Und das in der richtigen Reihenfolge bei mehreren OS.

Zitat

Secure Boot müssen wir nicht berücksichtigen; Windows kommt da nie drauf.
Das hat mit Windows jetzt nichts zu tun. Es ist Teil des UEFIs und muss ggf. berücksichtigt werden. Bei manchen Herstellern (Acer z.B.) gehts gar nicht anders bei Dualboot. Es bringt daher nichts, so zu tun, als ginge es dich nichts an. Es ist vermutlich so, da es vom Hersteller entsprechend eingerichtet wurde, aber du willst ja unbedingt auf UEFI umstellen und ich weiß nicht wie dein UEFI tickt. das werden wir erst sehn, wenn es aktiviert ist.

Wie gesagt, zu Manjaro äußere ich mich nicht.

Zitat

ich will nur verstehen.Ist wohl doch nicht so weit her mit der Zukunft von (U)EFI, wenn man weiterhin MBR und den Legacy Mode braucht und das nicht ohne Verzicht auf Komfort loswerden kann.
Nein, das stimmt so nicht. Man braucht weder UEFI noch BIOS/MBR um irgendwas komfortabel zu haben. Es funktioniert beides bis ans Ende der Tage deines Rechners. Sollte es zu Konflikten zwischen den einzelnen Linux-OS kommen, hat das (höchstwahrscheinlich) nur bedingt mit dem Modus oder der Firmware zu tun. Du hättest das ganze etwas "defensiver" angehen können, dann wärst du vermutlich jetzt nicht in dem Schlamassel.

Gruß
Des modernen Menschen Computer ist sein Himmelreich! :rolleyes: Der Weg zur Hölle, ist allzu kurz auf dem falschen "EFI-Pfad" ;( : Kleiner Leitfaden zur UEFI-Installation

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Klaus P« (02.12.2017, 14:53)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 119

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: 16.04 LTS (Xenial Xerus)

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

20

02.12.2017, 16:49

Du hast doch ein 64Bit System. Wie kommst du drauf, dass obige Version nur 32Bit tauglich wäre? Was willst du denn deinstallieren? Durch die Neuinstallation von Grub im UEFI-Modus wird Grub völlig neu eingerichtet und fertig. Irgendwelche Reste im MBR kannst löschen oder stehn lassen. Is egal, der MBR wird nicht mehr angesprochen bei UEFI-Boot.

Auweja! Da ist mir ja ein übler Zitierfehler unterlaufen.
Der aktuell installierte Grub ist 2.02~beta2-36ubuntu3.9+linuxmint1 und als Erklärung steht dabei: GRand Unified Bootloader, Version 2 (PC/BIOS version). Das sagt für mich aus, daß er nicht UEFI-tauglich ist und folglich ersetzt werden. Entschuldige, daß ich den falschen beim Kopieren erwischt habe; mir schwirrt schon der Kopf von den vielen Fallunterscheidungen. Der richtige Grub müßte 2.02~beta2-36ubuntu3.9+linuxmint1 mit dem Erklärungstext GRand Unified Bootloader, version 2 (EFI-AMD64 binaries) sein. Ist das soweit noch richtig?

Falls ja mußte ich berücksichtigen, daß die beiden Pakete in Konflikt stehen; das alte also erst weg muß bevor das neue installiert werden kann. Richtig?

Durcheinandergekommen bin ich, weil unmittelbar darunter die 32bit-Varianten für EFI stehen -- tut mir leid.

Zitat

Primär ist erst mal angesagt ein funktionierendes (UEFI-) Boot hin zu bekommen.

Volle Zustimmung! Wie gestern angekündigt werde ich heute abend eine Sicherung von /dev/sda7 machen (da steht Mint drin); die ersten2048 Byte vom Bootrecord habe ich ja noch (hoffentlich ist da die ganze GPT drin); wenn etwas schief geht komme ich wieder zurück. Schlimmstenfall verliere ich Mint, aber nicht Xubuntu und nicht Manjaro.

Mit Mint will ich jetzt mal ein Experiment wagen. Geht das ganze schief, lasse ich die beiden anderen wie sind, stelle wieder auf EFI/legacy (= BIOS ?) um und richte diese kleine 1MB-Partition namens bios_grub Partition am Plattenanfang ein, damit von GPT statt MBR mittels grub2 gebootet werden kann. Dann wirst du mich natürlich kräftig verfluchen, weil ich soviel Wirbel gemacht habe ohne zum Ziel zu kommen, aber ich konnte wirklich nicht ahnen, in welche Fangstricke man da gerät. Ich habe eben einfach die Texte und die Vorteile von EFI gelesen, aber mit der unausweichlichen Zukunft scheint es doch nicht so weit her zu sein, wenn man von BIOS/MBR so schwer loskommen kann.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »ebbi97a« (02.12.2017, 16:57)


Zurzeit ist neben Ihnen 1 Benutzer in diesem Thema unterwegs:

1 Besucher

Verwendete Tags

BIOS, Booten, Efi, GPT, grub2, MBR, partition