Seltsames in /boot/grub/device.map

[geier22]

Bin immer noch am überlegen, wie die Einträge in der grub.cfg zustande kamen, was ja leider in diesem Thread nicht gelöst wurde.
Dabei bin ich auf die Einträge in der /boot/grub/device.map gestoßen.

Code: Alles auswählen

(hd0)	/dev/disk/by-id/ata-Hitachi_HTS545025B9A300_090925PB5306Q6JXREYG
(hd1)	/dev/disk/by-id/usb-SanDisk_Cruzer_Blade_431850028AA0AAEA-0:0

Habe nicht die geringste Ahnung, wo die herkommen. Ein Hitachi- Laufwerk besitze ich überhaupt nicht, Der SanDisk ist ein Usb-Stick von dem ich ganz sicher noch nie gebootet habe.
in der grub.cfg ist davon auch nichts vermerkt. 39147

Die Fragen, die ich mir stelle:
Welchen Einfluss hat die /boot/grub/device.map überhaupt auf Grub, da ja hier was total Flansches drin steht.
Kann das eventuell der Grund für die chaotischen Einträge in der grub.cfg in dem oben genannten Thread sein?
Muss man die device.map korrigieren - wenn ja wie ?

meine Laufwerke:

Code: Alles auswählen

root@sparkymate:/home/hans# blkid
/dev/sda1: LABEL="Debian-Root" UUID="b4b15e5c-15f9-4a52-9fe3-f13662a74c97" TYPE="ext4" PARTUUID="0002f271-01"
/dev/sda3: LABEL="Debian-Home" UUID="37c9ae07-e2c7-48e4-9628-8c6a7d682085" TYPE="ext4" PARTUUID="0002f271-03"
/dev/sda5: UUID="b63faba7-5736-4179-b32d-a91b87dc33b9" TYPE="swap" PARTUUID="0002f271-05"
/dev/sdb1: LABEL="Xfce Root" UUID="6f9427a3-0897-4f59-8296-03676cc889c9" TYPE="ext4" PARTUUID="31088935-01"
/dev/sdb5: LABEL="Xfce Home" UUID="3bf6e217-677c-4f7d-bb6b-d69cada6fc5e" TYPE="ext4" PARTUUID="31088935-05"
/dev/sdd1: LABEL="Musik" UUID="8b535dfa-0c3f-4c55-aa95-a6bd61679344" TYPE="ext4" PARTUUID="b95d1636-8535-4d2d-815b-2cba98347c6f"
/dev/sdc1: LABEL="Daten" UUID="8dc5668b-4c06-41e0-934e-01dd0eff6db9" TYPE="ext4" PARTUUID="18de15c7-01"
/dev/sde1: LABEL="Enermax" UUID="f9ee572c-d216-4a7d-9b22-5d8e1fd4d9e4" TYPE="ext2" PARTUUID="00062524-01"
root@sparkymate:/home/hans# 

Wenn ich das richtig verstehe, sollte das an sich in der device.map ungefähr so aussehen:

Code: Alles auswählen

(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
(hd3) /dev/sdd 

Für ein bisschen Aufklärung wäre ich dankbar

[NAB]

Dafür gibt es einen eigenen Befehl:

Code: Alles auswählen

man grub-mkdevicemap

Bei der Hitatchi-Platte sei dir mal nicht so sicher ... vielleicht steht ein anderer Hersteller drauf.

Und es werden alle Laufwerke eingetragen, nicht nur die, von denen du bereits gebootet hast.

[geier22]

Und es werden alle Laufwerke eingetragen, nicht nur die, von denen du bereits gebootet hast.

Das oben ist die vollständige device.map

Bei der Hitatchi-Platte sei dir mal nicht so sicher ... vielleicht steht ein anderer Hersteller drauf.

Dann müsste doch aber wenigsten die UUID in meiner Laufwerksliste zu finden sein ???

Die Hitachi HTS545025B9A300 ist eine 250 GB 2,5 Zoll Platte, die ich höchsten mal in meinem Laptop hatte (müsste erst mal nachschauen ob das so ist) Die fristet ihr Dasein jetzt im CubieTruck. Die einzige 2.5 Zoll Platte in meinem Rechner ist eine Samsung SSD (=sdb)

[NAB]

Dann müsste doch aber wenigsten die UUID in meiner Laufwerksliste zu finden sein ???

Festplatten haben keine UUIDs. Die haben Seriennummern. Schau nach mit ls -la /dev/disk/by-id/

[geier22]

Ist - wenn ich nicht blind bin nicht zu finden

Code: Alles auswählen

root@sparkymate:/home/hans# ls -la /dev/disk/by-id/
insgesamt 0
drwxr-xr-x 2 root root 680 Feb 11 14:53 .
drwxr-xr-x 7 root root 140 Feb 11 15:38 ..
lrwxrwxrwx 1 root root   9 Feb 11 14:38 ata-HL-DT-ST_DVDRAM_GH24NSC0_K11EBSB1924 -> ../../sr0
lrwxrwxrwx 1 root root   9 Feb 11 14:53 ata-SAMSUNG_HD753LJ_S13UJ1BQ716728 -> ../../sdc
lrwxrwxrwx 1 root root  10 Feb 11 14:53 ata-SAMSUNG_HD753LJ_S13UJ1BQ716728-part1 -> ../../sdc1
lrwxrwxrwx 1 root root   9 Feb 11 14:53 ata-Samsung_SSD_850_PRO_128GB_S24ZNSAG339073V -> ../../sdb
lrwxrwxrwx 1 root root  10 Feb 11 14:53 ata-Samsung_SSD_850_PRO_128GB_S24ZNSAG339073V-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Feb 11 14:53 ata-Samsung_SSD_850_PRO_128GB_S24ZNSAG339073V-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  10 Feb 11 14:53 ata-Samsung_SSD_850_PRO_128GB_S24ZNSAG339073V-part5 -> ../../sdb5
lrwxrwxrwx 1 root root   9 Feb 11 14:53 ata-ST3000DM001-1CH166_W1F54F1T -> ../../sdd
lrwxrwxrwx 1 root root  10 Feb 11 14:53 ata-ST3000DM001-1CH166_W1F54F1T-part1 -> ../../sdd1
lrwxrwxrwx 1 root root   9 Feb 11 14:53 ata-WDC_WD1003FBYX-01Y7B1_WD-WCAW36278516 -> ../../sde
lrwxrwxrwx 1 root root  10 Feb 11 14:53 ata-WDC_WD1003FBYX-01Y7B1_WD-WCAW36278516-part1 -> ../../sde1
lrwxrwxrwx 1 root root   9 Feb 11 15:43 ata-WDC_WD5000HHTZ-04N21V0_WD-WXN1E32MDENJ -> ../../sda
lrwxrwxrwx 1 root root  10 Feb 11 15:43 ata-WDC_WD5000HHTZ-04N21V0_WD-WXN1E32MDENJ-part1 -> ../../sda1
lrwxrwxrwx 1 root root  10 Feb 11 15:43 ata-WDC_WD5000HHTZ-04N21V0_WD-WXN1E32MDENJ-part2 -> ../../sda2
lrwxrwxrwx 1 root root  10 Feb 11 15:43 ata-WDC_WD5000HHTZ-04N21V0_WD-WXN1E32MDENJ-part3 -> ../../sda3
lrwxrwxrwx 1 root root  10 Feb 11 15:43 ata-WDC_WD5000HHTZ-04N21V0_WD-WXN1E32MDENJ-part5 -> ../../sda5
lrwxrwxrwx 1 root root   9 Feb 11 14:53 wwn-0x50000f0007177682 -> ../../sdc
lrwxrwxrwx 1 root root  10 Feb 11 14:53 wwn-0x50000f0007177682-part1 -> ../../sdc1
lrwxrwxrwx 1 root root   9 Feb 11 14:53 wwn-0x5000c5007388e41a -> ../../sdd
lrwxrwxrwx 1 root root  10 Feb 11 14:53 wwn-0x5000c5007388e41a-part1 -> ../../sdd1
lrwxrwxrwx 1 root root   9 Feb 11 14:38 wwn-0x5001480000000000 -> ../../sr0
lrwxrwxrwx 1 root root   9 Feb 11 14:53 wwn-0x50014ee208cd0dd4 -> ../../sde
lrwxrwxrwx 1 root root  10 Feb 11 14:53 wwn-0x50014ee208cd0dd4-part1 -> ../../sde1
lrwxrwxrwx 1 root root   9 Feb 11 15:43 wwn-0x50014ee3556a31e8 -> ../../sda
lrwxrwxrwx 1 root root  10 Feb 11 15:43 wwn-0x50014ee3556a31e8-part1 -> ../../sda1
lrwxrwxrwx 1 root root  10 Feb 11 15:43 wwn-0x50014ee3556a31e8-part2 -> ../../sda2
lrwxrwxrwx 1 root root  10 Feb 11 15:43 wwn-0x50014ee3556a31e8-part3 -> ../../sda3
lrwxrwxrwx 1 root root  10 Feb 11 15:43 wwn-0x50014ee3556a31e8-part5 -> ../../sda5
lrwxrwxrwx 1 root root   9 Feb 11 14:53 wwn-0x50025388a09db653 -> ../../sdb
lrwxrwxrwx 1 root root  10 Feb 11 14:53 wwn-0x50025388a09db653-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  10 Feb 11 14:53 wwn-0x50025388a09db653-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  10 Feb 11 14:53 wwn-0x50025388a09db653-part5 -> ../../sdb5

[NAB]

Stimmt, da gibt's keine Hitachi-Platte (mehr)

[geier22]

dann müsste also die korrekte device.map etwa so aussehen:

Code: Alles auswählen

(hd0) /dev/disk/by-id/ata-WDC_WD5000HHTZ-04N21V0_WD-WXN1E32MDENJ
(hd1) /dev/disk/by-id/ata-Samsung_SSD_850_PRO_128GB_S24ZNSAG339073V

Was mich wundert und nicht zu erklären ist:

Das Mainboard ist neu und hat die Hitachi- Platte definitiv (falls die Platte in meinem CubieTruck so eine ist) noch nie gesehen.

KDE (auf hd0 /sda) habe ich vor 2 Monaten komplett neu installiert. Das Wurzelverzeichnis hab ich neu formatiert, /home von der alten installation übernommen.

Xfce (auf hd1/sdb) hab ich gerade vor einer Woche neu installiert ( wg. Ärger mit Grub - s.O.)

Beide Systeme haben aber dieselbe device.map.

Hängt das eventuell mit os-prober zusammen ???
irgendwo her müssen doch die Einträge kommen
Nach dem GRUB Manual scheint es ja zu reichen, die device.map zu löschen damit eine neue erstellt wird. Es scheint mir aber so, als würde irgendenetwas in Grub (os-prober ??)
diese Datei vom jeweils anderen System abschreibt. Anders kann ich es mir nicht erklären, warum zwei unterschiedliche Debian-Systeme,
identisch falsche Einträge haben.

[rendegast]

Bei mir, jessie grub 2.02, scheint im Normalfall keine device.map mehr angelegt zu werden.
Nur wenn ich explizit grub-devicemap aufrufe.
Sie wird wohl auch nicht mehr benötigt.

Vielleicht stammt Deine "falsche" device.map aus längst vergangenen Zeiten?

[geier22]

Vielleicht stammt Deine "falsche" device.map aus längst vergangenen Zeiten?

Ich erinnere mich dunkel daran (da hatte ich noch OpenSuse), dass ich Debian auf einer 2,5 Zoll- Wechselplatte installiert hatte.
Diese Wechselplatte war dann auch letztendlich der Grund, warum ich zu Debian gewechselt bin. Da OpenSuse zu dieser Zeit recht
instabil war, und gerade diese Platte (nach Einschub in den Schacht) mich mehrmals vor dem "Verderben" gerettet hat. Dann müsste aber sich die device.map aber wie ein Virus durch meine Installationen fortgepflanzt haben. Da ich (meistens) 2 Systeme
im Dualboot hatte, und nie ein System per Restore erneuert habe, muss es also einen "Schuldigen" geben. Ich vermute,
dass es os-prober ist.

Sie wird wohl auch nicht mehr benötigt.

So ähnlich habe ich das auch verstanden.
Ich werde die beiden device.map (in KDE und Xfce - beides Stretch) also dann mal löschen, und sehen was dann passiert.

[NAB]

hmmm ... welches Alter hat denn diese mysteriöse Datei? -> ls -la /boot/grub/device.map

Edit: Ach, übrigens ... bei der Hitatchi-Platte "HTS545025B9A300" handelt es sich um eine "HGST Travelstar 5K500.B 250GB", 2,5 Zoll. Vielleicht hilft da ja der Aufklärung.

[geier22]

hmmm ... welches Alter hat denn diese mysteriöse Datei?

Wenn ich nach Hause komme, werde ich mal nachsehen.
Aber wie gesagt, die Platte kann nur aus meinem Laptop bzw. aus einem EE-PC stammen. in beiden hab ich die Platten gegen SSD's ausgetauscht. Das ist aber gut 2 Jahre her. Den EE-PC hab ich verkauft, und die Laptop-Platte sitzt seit gut einem Jahr im CubieTruck. Die andere fristet in meinem Platten-Museum in einem Pappkarton ihr Dasein

[maledora4]

Bei mir wird eine device.map immer dann angelegt, wenn der Installer erkennt, auf dem System sind mehrere OS.
Also, Multiboot.
Dazu reicht es aus, es ist nur eine Platte im System und installiert wird vom Stick.

Dann habe ich das Szenario, wie vom TE oben geschrieben.

Die Fragen, die ich mir stelle:
Welchen Einfluss hat die /boot/grub/device.map überhaupt auf Grub, da ja hier was total Flansches drin steht.
Kann das eventuell der Grund für die chaotischen Einträge in der grub.cfg in dem oben genannten Thread sein?

Das "Seltsame" der chaotischen Einträge in der /grub.cfg passiert m.E. (aus dem anderen Faden)

Code: Alles auswählen

...
ii  grub-customizer   4.0.6-0ubuntu1~ppa1w amd64        Grub Customizer - A graphical Grub2/BURG configuration application                                
...

Eins muß man den *buntus in ihrem Wiki lassen, sie weißen immer daraufhin, dass Fremdpakete das System unsicher machen können.

Jetzt kann man noch die Frage klären, wie oft sind denn die Konsole und dann wieder die GUI benutzt wurden. Seltsamerweise
sitzt der Fehler immer in 99,9% der Fälle die berühmten 50cm vor dem Schirm.

[geier22]

Heute früh hatte ich an sich noch einen Beitrag geschrieben.... futsch
Die device.map in Xfce hab ich nach dem (vermeintlich abgeschickten) Betrag gelöscht. sie stammt aus 2013 ebenfalls aus 2012
Die Inhaltlich identische aus KDE :

Code: Alles auswählen

root@sparkyxfce:/home/hans# ls -la /media/hans/Debian-Root/boot/grub/device.map
-rw-r--r-- 1 root root 139 Sep  4  2012 /media/hans/Debian-Root/boot/grub/device.map

Eins muß man den *buntus in ihrem Wiki lassen, sie weißen immer daraufhin, dass Fremdpakete das System unsicher machen können.

Das ist nur halb richtig. Ich benutze kein ppa
Allerdings hab ich SparkyLinux installiert. Da ist er in den Repos.
Die zweite Wahrheit:
Den Grub-customizer hab ich zum allerersten mal benutzt (und installiert) als ich das "Chaos bemerkte und Xfce nicht mehr startete. Schlicht und einfach,
weil ich mit der Syntax von Grub überfordert bin.
Die Frage stellt sich trotzdem: Wie kann eine 3 Jahre alte Datei sich durch X- Installationen "fortpflanzen"?
Was aber auch stimmt, (soweit ich mich erinnern kann) dass ich meist ein Dualboot-System hatte), wenn ich ein neues System installierte. (aber nie auf der selben Platte) Das kann aber nur bedeuten, das die devvice.map immer vom jeweils bestehenden System abgeschrieben wurde und sich so über die Jahre forpflanzte.