grub.cfg mit falscher UUID

[Ulidor]

Hallo,

mein Standardsystem ist Stretch und befindet sich auf /dev/sda3. Auf /dev/sdb2 befindet sich Buster und das habe ich jetzt mit rsync -aHAX auf /dev/sdb3 kopiert. In der /etc/fstab von /dev/sdb3 habe ich die UUID der Root-Partition entsprechend angepasst und dann Grub neu konfiguriert:

Code: Alles auswählen

# update-grub
GRUB-Konfigurationsdatei wird erstellt …
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Linux-Abbild gefunden: /boot/vmlinuz-4.12.0-0.bpo.1-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.12.0-0.bpo.1-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-3-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-3-amd64
Linux-Abbild gefunden: /boot/vmlinuz-3.16.0-4-amd64
initrd-Abbild gefunden: /boot/initrd.img-3.16.0-4-amd64
Debian GNU/Linux 9 (stretch) auf /dev/sda2 gefunden
Debian GNU/Linux buster/sid auf /dev/sdb2 gefunden
Debian GNU/Linux buster/sid auf /dev/sdb3 gefunden
Ubuntu 14.04.1 LTS (14.04) auf /dev/sdb6 gefunden
erledigt

Die UUIDs:

Code: Alles auswählen

# lsblk --output NAME,LABEL,MOUNTPOINT,UUID,size
NAME   LABEL      MOUNTPOINT UUID                                   SIZE
sda                                                               111,8G
├─sda1                                                                1M
├─sda2                       2b93c349-f94d-4519-b11a-6974f32a8004    16G
├─sda3 ROOTFS     /          bbbadfa0-229c-4bf9-a65d-70cc92dfb58a    16G
├─sda4                       bc55052d-6dbb-4550-9f3e-bfc33ad45aef    16G
├─sda5                                                               16G
└─sda6                                                               16G
sdb                                                               931,5G
├─sdb1 HOME       /home      861c5104-db4f-4ec5-80ca-1aacee9b2f32 838,2G
├─sdb2                       591be478-ef29-43cc-8429-9b4f672a4860    14G
├─sdb3                       1103afdf-1762-411e-96d3-7d8ccea174a8    14G
├─sdb5                       828693c2-9500-4ca6-9c1b-b38e797bcf0c     2G
└─sdb6                       f30ce310-6ab4-4626-b32b-da51e0302f97  63,4G

Die fstab von /dev/sdb3:

Code: Alles auswählen

# cat /mnt/x/etc/fstab                                                                                                                
# /etc/fstab: static file system information.                                                                                                  
#                                                                                                                                              
# Use 'blkid' to print the universally unique identifier for a                                                                                 
# device; this may be used with UUID= as a more robust way to name devices                                                                     
# that works even if disks are added and removed. See fstab(5).                                                                                
#                                                                                                                                              
# <file system> <mount point>   <type>  <options>       <dump>  <pass>                                                                         
# / was on /dev/sdc2 during installation                                                                                                       
UUID=1103afdf-1762-411e-96d3-7d8ccea174a8 /               ext4    errors=remount-ro 0       1                                                  
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Der Eintrag für /dev/sdb3 in /boot/grub/grub.cfg enthält in der root-Zeile aber die UUID von /dev/sdb2, also der Partition, von der das System kopiert wurde:

Code: Alles auswählen

...
menuentry 'Debian GNU/Linux buster/sid (auf /dev/sdb3)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-1103afdf-1762-411e-96d3-7d8ccea174a8' {
	insmod part_gpt
	insmod ext2
	set root='hd1,gpt3'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt3 --hint-efi=hd1,gpt3 --hint-baremetal=ahci1,gpt3  1103afdf-1762-411e-96d3-7d8ccea174a8
	else
	  search --no-floppy --fs-uuid --set=root 1103afdf-1762-411e-96d3-7d8ccea174a8
	fi
	linux /boot/vmlinuz-4.12.0-1-amd64 root=UUID=591be478-ef29-43cc-8429-9b4f672a4860 ro quiet
	initrd /boot/initrd.img-4.12.0-1-amd64
	...

Hat das was mit der initrd zu tun? Ich habe beim Booten schon mal bei Grup in der root-Zeile temporär die richtige UUID eingetragen, das kopierte Buster gestartet, dort update-initramfs laufen lassen und zurück auf meinem Standard-System wieder update-grub ausgeführt. Das hat aber nichts gebracht.

Wo liest update-grub denn die falsche UUID?

Viele Grüße
Rolf

[maledora4]

Das Problem/die Verwirrung entsteht, weil man glaubt in eine entsprechend "vorbereitete" Partition zu kopieren. Das Vorbereiten bedeutet aber immer eine neue UUID.

Das muß aber nicht sein. Es gibt viele Tools, bei gparted z.B. erledigt man das durch kopieren und einfügen in den "nicht zugeteilt"en-Bereich und übernimmt ganz einfach die alte UUID.

Deine Versuche führen zu nichts, weil du das, wie du selbst schreibst temporär gemacht hast. Davon bekommt dein Hauptbootloader nichts mit.
Du müßtest in das neue, kopierte System chrooten oder, bei deiner Methode mit der "root-Zeile" dort dann nach dem Start

Code: Alles auswählen

dpkg-reconfigure grub-pc

ausführen. Dabei darauf achten, dass er das auch in den PBR von sdb3 macht.

Anschließend wäre nochmal

Code: Alles auswählen

update-grub

des Hauptbootloader notwendig, um die jetzt richtige UUID zu übernehmen.

[Ulidor]

Vielen Dank für die Antwort! Aber ich muss gestehen, ich kann nicht so ganz folgen.

Das Problem/die Verwirrung entsteht, weil man glaubt in eine entsprechend "vorbereitete" Partition zu kopieren. Das Vorbereiten bedeutet aber immer eine neue UUID.

Beide Partitionen hatten doch schon vorher unterschiedliche UUIDs. Ich habe die Partition ja nicht physikalisch mit dd kopiert, sonder auf logischer Ebene mit rsync, also nur die reinen Daten. Da wurde die UUID gar nicht mitkopiert.

Das muß aber nicht sein. Es gibt viele Tools, bei gparted z.B. erledigt man das durch kopieren und einfügen in den "nicht zugeteilt"en-Bereich und übernimmt ganz einfach die alte UUID.

Mit gparted kenne ich mich nicht aus, ich partitioniere meistens von Hand.

Deine Versuche führen zu nichts, weil du das, wie du selbst schreibst temporär gemacht hast. Davon bekommt dein Hauptbootloader nichts mit.
Du müßtest in das neue, kopierte System chrooten oder, bei deiner Methode mit der "root-Zeile" dort dann nach dem Start

Code: Alles auswählen

dpkg-reconfigure grub-pc

ausführen. Dabei darauf achten, dass er das auch in den PBR von sdb3 macht.

Temporär musste ich den Bootmenüeintrag ändern, damit ich überhaupt ins neue System booten konnte. Das fand ich einfacher als mit chroot. Aber ich dachte, ein vom Hauptsystem aus ausgeführtes

Code: Alles auswählen

update-grub

liest selbst die korrekten Daten aus den Partitionen und erzeugt ein passendes Bootmenü für jede bootfähige Partition. Jedenfalls hat das bisher immer einwandfrei geklappt. Ich mache das immer so, wenn ich mal ein neues System zum Testen installiere. Ich bin mir allerdings nicht sicher, ob ich schon mal ein System kopiert habe.

Liegt es denn am PBR, dass das bei mir nicht klappt? Aber trotzdem verstehe ich nicht, woher Grub für den sdb3-Menüeintrag die zu sdb2 gehörende UUID nimmt.

[Ulidor]

Holt Grub seine Daten fürs Bootmenü aus boot/grub/grub.cfg der jeweiligen Partition?

[smutbert]

Leicht vereinfacht dargestellt, enthält das vom BIOS oder UEFI geladene grub-image eine eingebettete Konfiguration, mit der es mit Hilfe der UUID das Dateisystem mit /boot/grub findet, aus dem es dann die grub.cfg und weitere grub-Module nachlädt.
(Wobei das ganze so gemacht ist, dass grub in vielen Situationen auch mit geänderter UUID noch booten kann, indem es nicht nur nach der UUID geht sondern auch die Partitionsnummern berücksichtigt.)

update-grub trägt die UUID des Dateisystems für root=... in die grub.cfg ein, das gerade unter / gemountet ist.

Die eingebettete Konfiguration wird gemeinsam mit dem kompletten grub-Image mit grub-install neu geschrieben.


Die initrd soll nur dafür sorgen, dass alle Dateisysteme über ihre UUID zugänglich sind. Es sollte selbst also nirgends eine UUID für / beinhalten, allerdings wird uU die UUID einer swap-Partition eingetragen (zum Wiederaufwachen aus Suspend2Disk).

[Ulidor]

update-grub trägt die UUID des Dateisystems für root=... in die grub.cfg ein, das gerade unter / gemountet ist.

Aber das macht es doch für die anderen bootfähigen Partitionen auch, oder?

Die initrd soll nur dafür sorgen, dass alle Dateisysteme über ihre UUID zugänglich sind. Es sollte selbst also nirgends eine UUID für / beinhalten, allerdings wird uU die UUID einer swap-Partition eingetragen (zum Wiederaufwachen aus Suspend2Disk).

Ah, okay.

Das mit Grub ist ja doch recht komplex. Ich habe es jetzt so gemacht, wie maledora4 geschrieben hat: Ich bin mit chroot in die Partition mit dem kopierten Inhalt gegangen, habe dort

Code: Alles auswählen

dpkg-reconfigure grub-pc

ausgeführt und dabei angewählt, dass nur in /dev/sdb3 installiert wird. Zurück aus chroot habe ich

Code: Alles auswählen

update-grub

ausgeführt. Nun klappt es.

Allerdings dauert es beim Booten jetzt von der Anzeige „Loading Operating System" bis zum Erscheinen des Bootmenüs ca. 20 Sekunden. Vorher waren es höchsten ein paar Sekunden.

Woran liegt das und wie kann ich das wieder beschleunigen?

[maledora4]

update-grub trägt die UUID des Dateisystems für root=... in die grub.cfg ein, das gerade unter / gemountet ist.

Aber das macht es doch für die anderen bootfähigen Partitionen auch, oder?

Nein.
Das gilt nur in der Partition, wie @smutbert schreibt.

Allerdings dauert es beim Booten jetzt von der Anzeige „Loading Operating System" bis zum Erscheinen des Bootmenüs ca. 20 Sekunden. Vorher waren es höchsten ein paar Sekunden.

Woran liegt das und wie kann ich das wieder beschleunigen?

Grub2 erstellt selbst keine device.map mehr. Deshalb ist es bei zwei oder mehr Festplatten empfohlen, diese selbst manuell zu erstellen.

Code: Alles auswählen

grub-mkdevicemap --no-floppy

und danach

Code: Alles auswählen

update-grub

[Ulidor]

Grub2 erstellt selbst keine device.map mehr. Deshalb ist es bei zwei oder mehr Festplatten empfohlen, diese selbst manuell zu erstellen.

Code: Alles auswählen

grub-mkdevicemap --no-floppy

und danach

Code: Alles auswählen

update-grub

Das habe ich jetzt genauso gemacht und die Datei /boot/grub/device.map (die es vorher gar nicht gab) ist erstellt worden. Aber es dauert noch genauso lange, bis das Bootmenü erscheint. Sollte ich vielleicht noch ein

Code: Alles auswählen

grub-install /dev/sda

ausführen? (Mein Hauptsystem befindet sich auf sda.)

[maledora4]

Was du hier beschreibst, kann ich nicht nachvollziehen.
Mir erscheint das auch hardwarespezifisch zu sein. Denn bei mir sehe ich:

- Loading Asus-Express-Gate...
- der Motherboard-Bildschirm (wo man in's BIOS wechseln kann)
- einen weiteren kurz mit Hardwaredaten(?)
- dann den Grub-Menü-Textbildschirm

Alles zusammen um die 10Sec.

[Ulidor]

Nach den Hardwaredaten kommt bei mir die vom BIOS generierte Meldung „Loading Operating System..." und bisher kam ein oder zwei Sekunden später das Bootmenü. Seit der Aktion mit chroot habe ich nach der Meldung für ca. 20 Sekunden einen schwarzen Bildschirm bevor das Bootmenü kommt. Das scheint also mit der unter chroot in sdb3 durchgeführten Rekonfiguration von grub-pc zu tun zu haben. Ich denke, dass müsste sich dann auch irgendwie mit grub wieder beheben lassen. Aber wie?

[maledora4]

Die Frage mußt du dir selbst beantworten, wenn du da möglicherweise einen Zusammenhang siehst.

- z.B. wo war denn der Grub von JETZT sdb3 vorher, bereits im PBR oder im MBR von welcher Platte?
- oder, brauch dein BIOS vielleicht ein Bootflag? Ich weiß, dass Linux dies eigentlich nicht braucht, dennoch habe ich schon BIOS'e gesehen, die "wollten das haben"
- oder, steht sda auch als 1.Platte im BIOS oben?

[Ulidor]

Ich weiß gar nicht mehr, was vorher mal auf sdb3 war. Es kann sein, dass ich da noch nie ein System drauf hatte.

Nein, mein BIOS braucht kein Bootflag.

Welche Platte im BIOS oben steht, weiß ich nicht, aber daran habe ich ja nichts verändert. Alles, was ich verändert habe, habe ich hier geschrieben. Und vor den Änderungen kam das Bootmenü immer sofort. Seit mittlerweile 6 Jahren auf diesem Rechner und einigen Installationen.

Ich habe jetzt ein

Code: Alles auswählen

grub-install /dev/sda

auf meinem Hauptsystem durchgeführt. Das hat aber auch nichts gebracht.

Wenn ich sdb3 neu formatiere, ist dann der PBR auch weg?
Vielleicht klappt es dann ja wieder. Es wäre schön gewesen, wenn ich das darauf kopierte System booten könnte (was je im Moment geht), aber wenn ich dafür in Kauf nehmen muss, dass ich beim Booten immer 20 Sekunden zusätzlich warten muss, dann verzichte ich lieber darauf.

[Ulidor]

Jetzt habe ich sdb3 mit shred gelöscht und anschließend update-grub ausgeführt. Nun bootet der Rechner wieder so schnell wie vorher.
Dann benutze ich eben sdb3 nur als temporären Zwischenspeicher von sdb2, ohne die Möglichkeit, in sdb3 booten zu können.

Vielen Dank für eure Hilfe und Infos, maledora4 und smutbert!