ProtonM
Anmeldungsdatum: 29. Dezember 2014
Beiträge: 166
Wohnort: Europa
|
Hallo Profis Bin dabei auf 20.04 zu migrieren und finde keinen Hinweis, weder im wiki noch im Forum, was update-grub macht, wenn es mal vom einen oder vom anderen System aus gestartet wird. Dual Boot behandelt die Koexistenz mit Windows. Sicher wird der letzte Start das aktive Grub-Menue gestalten. Kann dabei das andere System (18.04) in Mitleidenschaft gezogen werden? Solange die Migration nicht vollständig ist, möchte ich mir das alte 18.04er nicht zerschießen. Vielen Dank für einen beruhigenden Hinweis.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53611
Wohnort: Berlin
|
ProtonM schrieb: Bin dabei auf 20.04 zu migrieren und finde keinen Hinweis, weder im wiki noch im Forum, was update-grub macht, wenn es mal vom einen oder vom anderen System aus gestartet wird.
Es macht überall das gleiche: Es führt grub-mkconfig -o /boot/grub/grub.cfg aus, also liest die GRUB 2/Konfiguration und die GRUB 2/Skripte ein und erzeugt daraus die Booteinträge. Die werden dann an den jeweiligen Installationsort von GRUB (bzw. wird eine Weiterleiung auf /boot/grub/grub.cfg des Systems, aus dem es aufgerufen wurde) geschrieen. Das heißt: Hast du bei beiden Systemen GRUB an den selben Ort installiert überschreiben sich die Einträge jeweils gegenseitig.
Sicher wird der letzte Start das aktive Grub-Menue gestalten.
Nein. Wenn beide GRUB-Instanzen an den selben Ort installiert wurden ist nur der aktiv, der als letztes geschrieben wurde. Was zuletzt gestartet wurde ist da völlig wumpe. Kann dabei das andere System (18.04) in Mitleidenschaft gezogen werden?
GRUB verändert folgendes am System: Absolut gar nichts.
|
ProtonM
(Themenstarter)
Anmeldungsdatum: 29. Dezember 2014
Beiträge: 166
Wohnort: Europa
|
Hallo tomtomtom Erst mal vielen Dank für Deine Antworten und deine Geduld, auch in der Vergangenheit. Aber ich habe es noch nicht;-( 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 | label: dos
label-id: 0x86181828
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 1024000, type=7, bootable
/dev/sda2 : start= 1026048, size= 314519552, type=7
/dev/sda3 : start= 315547646, size= 309594114, type=5
/dev/sda5 : start= 315547648, size= 8388608, type=83
/dev/sda6 : start= 323938304, size= 4194304, type=83
/dev/sda7 : start= 328134656, size= 33554432, type=83
/dev/sda8 : start= 361691136, size= 33554432, type=83
/dev/sda9 : start= 395247616, size= 16777216, type=83
/dev/sda10 : start= 412026880, size= 8388608, type=83
/dev/sda11 : start= 428804096, size= 4194304, type=83
/dev/sda12 : start= 433000448, size= 16777216, type=83
/dev/sda13 : start= 565551104, size= 31248384, type=83
/dev/sda14 : start= 596801536, size= 28340224, type=82
/dev/sda15 : start= 458166272, size= 8388608, type=83
/dev/sda16 : start= 466556928, size= 4194304, type=83
/dev/sda17 : start= 470753280, size= 16785408, type=83
/dev/sda18 : start= 487540736, size= 33554432, type=83
/dev/sda19 : start= 521097216, size= 8388608, type=83
/dev/sda20 : start= 529487872, size= 4194304, type=83
/dev/sda21 : start= 533684224, size= 4194304, type=83
/dev/sda22 : start= 537880576, size= 16777216, type=83
|
Es gibt auf sda1 eine 500 MB Partition mit Marke bootable. Es gibt auf sda5 /, sda6/boot, usw. das 18.04 System. Es gibt auf sda15 /, sda16/boot, usw. das 20.04 System. Es gibt auf sda14 die swap-Partition für beide Systeme (weil ja immer nur eins läuft). Schreibt also das 18.04 grub nur auf sda6/boot/grub, findet aber auch das 20.04 System und umgekehrt. Was passiert auf sda1? Ich habe mit hexdump erfolglos versucht etwas zu erkennen.
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
Das sind aber viele Partitionen - zeig mal bitte die Ausgabe von
sudo parted --list
|
ProtonM
(Themenstarter)
Anmeldungsdatum: 29. Dezember 2014
Beiträge: 166
Wohnort: Europa
|
Ja, das sind ein paar Portionen, aber was soll's! Ein paar Partitionen sind leer, z.B. /srv. Anm: sda1 fs war mal ntfs. 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 | $ sudo parted --list
Modell: ATA WDC WD3200BEKT-7 (scsi)
Festplatte /dev/sda: 320GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 525MB 524MB primary ext4 boot
2 525MB 162GB 161GB primary ntfs # win 10 tot
3 162GB 320GB 159GB extended
5 162GB 166GB 4295MB logical ext4 # 18.04 /
6 166GB 168GB 2147MB logical ext4 # 18.04 /boot
7 168GB 185GB 17,2GB logical ext4 # 18.04 /home
8 185GB 202GB 17,2GB logical ext4 # 18.04 /usr
9 202GB 211GB 8590MB logical ext4 # 18.04 /var
10 211GB 215GB 4295MB logical ext4 # 18.04 /tmp
11 220GB 222GB 2147MB logical ext4 # 18.04 /srv
12 222GB 230GB 8590MB logical ext4 # 18.04 /opt
15 235GB 239GB 4295MB logical ext4 # 20.04 /
16 239GB 241GB 2147MB logical ext4 # 20.04 /boot
17 241GB 250GB 8594MB logical ext4 # 20.04 /home
18 250GB 267GB 17,2GB logical ext4 # 20.04 /usr
19 267GB 271GB 4295MB logical ext4 # 20.04 /var
20 271GB 273GB 2147MB logical ext4 # 20.04 /tmp
21 273GB 275GB 2147MB logical ext4 # 20.04 /srv
22 275GB 284GB 8590MB logical ext4 # 20.04 /opt
13 290GB 306GB 16,0GB logical ext4 # Rescue-System (Kali)
14 306GB 320GB 14,5GB logical linux-swap(v1)
|
Wenn das grub bootmenu angezeigt wird, sind alle ladbaren Kernel auf sda5/boot, sd15/boot und sda13/boot eingetragen. Jedes der 3 Systeme kann mit update-grub das grub-Menue erzeugen. Wenn das Menu während des Boot-Vorgangs erzeugt wird, dann muss doch der bootloader wissen, auf welchen Partitionen ladbare Systeme liegen? Oder sucht der os-prober alle Partitionen ab? Und was schreibt wer auf sda1?
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53611
Wohnort: Berlin
|
ProtonM schrieb: Wenn das Menu während des Boot-Vorgangs erzeugt wird, dann muss doch der bootloader wissen, auf welchen Partitionen ladbare Systeme liegen? Oder sucht der os-prober alle Partitionen ab?
Wurde die bereits erklärt: Das wird nicht beim Booten getan sondern wenn in einem System update-grub ausgeführt wird. Wie auch schon erklärt läuft dabei ein grub-mkconfig -o /boot/grub/grub.cfg im Hintergrund. Dabei (ja, wurde auch schon erklärt, die Links sind nicht zum verschönern des Textes gegeben worden) werden die GRUB-Skripte (zu denen auch os-prober gehört) abgearbeitet und aus ihnen zusammen mit den in der GRUB-Konfiguration gesetzten Optionen Booteinträge generiert, das -o steht hier lediglich für "output", so dass diese in die genannte Datei geschrieben werden.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej ProtonM, ProtonM schrieb: Ja, das sind ein paar Portionen
oopsala, da habe ich wohl was versäumt? Bislang ging ich davon aus, daß eine extended Partition max. 16 logische Partitionen enthalten kann. (habe gerade mal zum Spaß 22 Stck. angelegt, und das geht ^^ oh, oh.) aber was soll's! Ein paar Partitionen sind leer, z.B. /srv.
na ja, nicht nur die Anzahl, auch die Zuweisung innerhalb der Verzeichnisstruktur und vor allem die jeweiligen Größen. (Wäre mal ein cat /etc/fstab interessant)
Wenn das grub bootmenu angezeigt wird, sind alle ladbaren Kernel auf sda5/boot, sd15/boot und sda13/boot eingetragen.
wie oben geschrieben, Blick in die fstab, aber das nur am Rande (sda5 z.B. ist "/")
Jedes der 3 Systeme kann mit update-grub das grub-Menue erzeugen.
so soll das sein! Wenn das Menu während des Boot-Vorgangs erzeugt wird, dann muss doch der bootloader wissen, auf welchen Partitionen ladbare Systeme liegen?
der "bootloader" weiß lediglich, wo er denn das "core.img" suchen - und finden - soll. In einem MBR/MPT System kann das "BIOS" lediglich in dem Master_Boot_Record (die ersten 446 Byte) auf dem als erstes Bootmedium eingestellten Gerät nach einem Bootloader suchen und den dann starten. Es geht dann in einer Art Kettenreaktion weiter im Bereich vor der ersten Partition mit "core.img". Dieses zeigt dann die grub.cfg und bringt entsprechend der Auswahl und ggf. unter Hinzuziehung von Dateien (*.mod und dergl.) aus "/boot/grub..." das Betriebssystem zum Start. Bei einer Installation eines Linux wird der "Ort für den Bootloader" eben mit /dev/sdx - das sind die ersten 512 Byte - angegeben. Jedes weitere O/S installiert 'normaler' Weise in gleicher Weise in "den" MBR. Daraus folgt eben das o.g. von tomtomtom schon beschriebene Verhalten. Oder sucht der os-prober alle Partitionen ab?
das tut os-prober genau so. Und was schreibt wer auf sda1?
dahin "sollte" bestenfalls s.Z. Windows seine Systempartitionsdateien geschrieben haben. Schreibst Du bei einer Installation eines Linux nämlich auf eine Partition (sdxy und nicht in den MBR - ohne Zahl!), dann kann der dann dort befindliche Bootloader vom BIOS nicht erreicht werden. Er liegt quasi "tot" dort rum, ein entsprechendes update-grub eines solchen Systems ändert dann auch an der o.g. Reihenfolge → BIOS → MBR/Bootloader → core.img → O/S genau nichts. Gruß black tencate
|
Frieder108
Anmeldungsdatum: 7. März 2010
Beiträge: 8989
|
black_tencate schrieb: Hej ProtonM, ProtonM schrieb: Ja, das sind ein paar Portionen
oopsala, da habe ich wohl was versäumt? Bislang ging ich davon aus, daß eine extended Partition max. 16 logische Partitionen enthalten kann. (habe gerade mal zum Spaß 22 Stck. angelegt, und das geht ^^ oh, oh.)
Geht mir auch so - also 3 primäre, 12 logische und die erweiterte → dann landest du bei /dev/sda16 → das war zumindest mein letzter Stand der Dinge → aber gut, wieder was gelernt. 👍
|
ProtonM
(Themenstarter)
Anmeldungsdatum: 29. Dezember 2014
Beiträge: 166
Wohnort: Europa
|
Hallo Nach einer Frustpause habe ich den Punkt wieder aufgegriffen und die Lösung gefunden.
Der Vergleich der 3 /bootgrub/grub.cfg Dateien zeigte, dass 2 gleichen Inhalts waren. Die relevante grub.cfg des 18.04 Systems hatte aus nicht nachvollziehbareb Gründen einen Eintrag:
set root=(hd0, msdos7) was auf das /usr Verzeichis zeigt, also nicht auf /. Abhilfe brachte:
| sudo apt-get purge grub-* os-prober # grub-gfxpayload-lists
sudo apt-get update
sudo apt-get install grub-pc os-prober # grub-gfxpayload-lists
|
Und ganz entscheidend: zusätzliches Kreus bei /sda als Installationspunkt. Allen die mithalfen einen recht herzlichen Dank.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej ProtonM, ProtonM schrieb: ...
Die relevante grub.cfg
nur mal am Rande zur Klarstellung:
...aus nicht nachvollziehbareb Gründen einen Eintrag:
set root=(hd0, msdos7) was auf das /usr Verzeichis zeigt, also nicht auf /.
in der Tat seltsam, genau wie die 22 logischen Partitionen. Allerdings (hd0,7) zeigt nach Deinen Angaben auf "/home" Abhilfe brachte:
...
Und ganz entscheidend: zusätzliches Kreus bei /sda als Installationspunkt.
was auch immer das jetzt heißt, falls damit das Bootflag gemeint sein sollte ❓, ganz sicher nicht, das ist nämlich nur für Windows von Belang, Linux hat damit nichts am Hut. Gruß black tencate
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
black_tencate schrieb: oopsala, da habe ich wohl was versäumt? Bislang ging ich davon aus, daß eine extended Partition max. 16 logische Partitionen enthalten kann. (habe gerade mal zum Spaß 22 Stck. angelegt, und das geht ^^ oh, oh.)
Die höchst mögliche Partitionsnummer war schon immer die 63. Allerdings hat man bei Linux diese Anzahl bei der Umstellung von /dev/hda auf /dev/sda begrenzt und an SCSI angeglichen. Es ist schön zu wissen, dass das wieder geht. Ich habe nämlich noch eine alte Platte mit Ubuntu Warty Warthog auf hda17 im Keller. Da kann ich ja jetzt nochmal nach nützlichen Daten suchen, falls der externe Controller da mitspielt.
|
ProtonM
(Themenstarter)
Anmeldungsdatum: 29. Dezember 2014
Beiträge: 166
Wohnort: Europa
|
@ black tencate da 18.04 32 Bit durch 20.04 64 Bit abgelöst werden soll, nehme ich das in Kauf. Nur der Hinweis noch: grub_pc bot mir in einem Dialogfenster 3 Installationspunkte an. Beim 1. Versuch habe ich /sda ausgelassen, weil mir das etwas seltsam vorkam. Der Text im Dialog empfahl, wenn man es nicht besser wisse, alle installationspunkte zu nehmen. Das tat ich beim 2. Versuch. Und nun lässt sich 18.04 wieder starten. Warum und was dahinter steht, ich weiss es nicht.
|