Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Inhalt von /boot/grub/device.map
313 views
Skip to first unread message
Ch. Hanisch
Mar 15, 2012, 10:05:07 AM3/15/12
to
Hallo,
unter GRUB2 gibt es die /boot/grub/device.map.
Welchen Inhalt sollte diese Datei haben, wenn ich neben der internen
Festplatte noch eine externe USB-Platte angeschlossen habe?
Kann ich da /dev/disk heranziehen und welche Variante:
/dev/disk/by-id
/dev/disk/by-label
/dev/disk/by-uuid
wird empfohlen und wie finde ich den jeweils richtigen Eintrag für meine
Platten?
Gruß
Ch. Hanisch
unter GRUB2 gibt es die /boot/grub/device.map.
Welchen Inhalt sollte diese Datei haben, wenn ich neben der internen
Festplatte noch eine externe USB-Platte angeschlossen habe?
Kann ich da /dev/disk heranziehen und welche Variante:
/dev/disk/by-id
/dev/disk/by-label
/dev/disk/by-uuid
wird empfohlen und wie finde ich den jeweils richtigen Eintrag für meine
Platten?
Gruß
Ch. Hanisch
Uwe Borchert
Mar 15, 2012, 11:19:20 AM3/15/12
to
Hallo,
Ausdrücklich nicht empfohlen, aber von mir verwendet:
root@grafix:~# cat /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdb
root@grafix:~#
Grund: Ich kann das komplette System mit tar klonen ohne irgendwas
an den beteiligten Dateien (auch /etc/fstab) zu ändern.
MfG
Uwe Borchert
root@grafix:~# cat /boot/grub/device.map
(hd0) /dev/sda
(hd1) /dev/sdb
root@grafix:~#
Grund: Ich kann das komplette System mit tar klonen ohne irgendwas
an den beteiligten Dateien (auch /etc/fstab) zu ändern.
MfG
Uwe Borchert
Ch. Hanisch
Mar 15, 2012, 11:33:25 AM3/15/12
to
Hallo Uwe,
Am 15.03.2012 16:19, schrieb Uwe Borchert:
> Ausdrücklich nicht empfohlen, aber von mir verwendet:
>
> root@grafix:~# cat /boot/grub/device.map
> (hd0) /dev/sda
> (hd1) /dev/sdb
> root@grafix:~#
Warum nicht empfohlen?
Das war doch bei GRUB1 so.
Da ich von der externen Platte boote habe ich stehen bei GRUB1:
(hd0) /dev/sdb
(hd1) /dev/sda
Bei mir habe ich jetzt:
$ sudo cat /boot/grub/device.map
[sudo] password for benutzer:
(hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
(hd1) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
Aber ich bin mir nicht sicher, ob ich da die richtigen Einträge genommen
habe.
Gruß
Ch. Hanisch
Am 15.03.2012 16:19, schrieb Uwe Borchert:
> Ausdrücklich nicht empfohlen, aber von mir verwendet:
>
> root@grafix:~# cat /boot/grub/device.map
> (hd0) /dev/sda
> (hd1) /dev/sdb
> root@grafix:~#
Das war doch bei GRUB1 so.
Da ich von der externen Platte boote habe ich stehen bei GRUB1:
(hd0) /dev/sdb
(hd1) /dev/sda
Bei mir habe ich jetzt:
$ sudo cat /boot/grub/device.map
[sudo] password for benutzer:
(hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
(hd1) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
Aber ich bin mir nicht sicher, ob ich da die richtigen Einträge genommen
habe.
>
> Grund: Ich kann das komplette System mit tar klonen ohne irgendwas
> an den beteiligten Dateien (auch /etc/fstab) zu ändern.
Wie machst Du das, Befehlsfolge?
> Grund: Ich kann das komplette System mit tar klonen ohne irgendwas
> an den beteiligten Dateien (auch /etc/fstab) zu ändern.
Gruß
Ch. Hanisch
Henning Paul
Mar 15, 2012, 11:37:13 AM3/15/12
to
Ch. Hanisch wrote:
> Bei mir habe ich jetzt:
> $ sudo cat /boot/grub/device.map
> [sudo] password for benutzer:
> (hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
Das ist ein DVD-Laufwerk.
> Bei mir habe ich jetzt:
> $ sudo cat /boot/grub/device.map
> [sudo] password for benutzer:
> (hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
> (hd1) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
> Aber ich bin mir nicht sicher, ob ich da die richtigen Einträge
> genommen habe.
(hd0) muss die Platte sein, von der Du bootest. Hast Du nur eine, ist
> Aber ich bin mir nicht sicher, ob ich da die richtigen Einträge
> genommen habe.
die Sache eindeutig. Dann brauchst Du an der device.map aber auch
überhaupt nicht herumzudoktern.
Gruß
Henning
Ch. Hanisch
Mar 15, 2012, 11:51:49 AM3/15/12
to
Hallo Henning,
Am 15.03.2012 16:37, schrieb Henning Paul:
> Ch. Hanisch wrote:
>
>> Bei mir habe ich jetzt:
>> $ sudo cat /boot/grub/device.map
>> [sudo] password for benutzer:
>> (hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
> Das ist ein DVD-Laufwerk.
Ist es so vielleicht besser?
(hd0) /dev/disk/by-id/ata-ST9500420AS_5VJCLASL
(hd1) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
> (hd0) muss die Platte sein, von der Du bootest. Hast Du nur eine, ist
> die Sache eindeutig. Dann brauchst Du an der device.map aber auch
> überhaupt nicht herumzudoktern.
Ich habe aber zwei Platten (eine Interne und eine Externe). Wenn die
externe angeschlossen ist, dann bootet er von dieser (Ist im BIOS so
eingestellt).
Wie ist das nun bei GRUB2. Ist da hd0 immer die interne Platte, obwohl
ich von der hd1 boote? Bei GRUB1 mußte die Boot-Platte immer hd0 sein.
Gruß
Ch. Hanisch
Am 15.03.2012 16:37, schrieb Henning Paul:
> Ch. Hanisch wrote:
>
>> Bei mir habe ich jetzt:
>> $ sudo cat /boot/grub/device.map
>> [sudo] password for benutzer:
>> (hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
> Das ist ein DVD-Laufwerk.
(hd0) /dev/disk/by-id/ata-ST9500420AS_5VJCLASL
(hd1) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
> (hd0) muss die Platte sein, von der Du bootest. Hast Du nur eine, ist
> die Sache eindeutig. Dann brauchst Du an der device.map aber auch
> überhaupt nicht herumzudoktern.
externe angeschlossen ist, dann bootet er von dieser (Ist im BIOS so
eingestellt).
Wie ist das nun bei GRUB2. Ist da hd0 immer die interne Platte, obwohl
ich von der hd1 boote? Bei GRUB1 mußte die Boot-Platte immer hd0 sein.
Gruß
Ch. Hanisch
Henning Paul
Mar 15, 2012, 12:00:14 PM3/15/12
to
braucht die device.map aber nicht zwingend, da man in der grub.cfg die
Dateisysteme auch über ihre UUIDs finden kann.
Gruß
Henning
Ch. Hanisch
Mar 15, 2012, 12:14:41 PM3/15/12
to
Hallo Henning,
Am 15.03.2012 17:00, schrieb Henning Paul
(hd0) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
(hd1) /dev/disk/by-id/ata-ST9500420AS_5VJCLASL
Meine Frage bleibt aber noch unbeantwortet. Sind diese
/dev/disk/by-id/... Einträge relevant für meine Konstellation, obwohl
sie eigentlich gar nicht ausgewertet werden?
Wie kann ich das prüfen?
Gruß
Ch. Hanisch
Am 15.03.2012 17:00, schrieb Henning Paul
> Bei GRUB2 genau so. hd0 ist die erste Platte in Bootreihenfolge. GRUB2
> braucht die device.map aber nicht zwingend, da man in der grub.cfg die
> Dateisysteme auch über ihre UUIDs finden kann.
Dann müßte es also so aussehen in der device.map:
> braucht die device.map aber nicht zwingend, da man in der grub.cfg die
> Dateisysteme auch über ihre UUIDs finden kann.
(hd0) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
(hd1) /dev/disk/by-id/ata-ST9500420AS_5VJCLASL
Meine Frage bleibt aber noch unbeantwortet. Sind diese
/dev/disk/by-id/... Einträge relevant für meine Konstellation, obwohl
sie eigentlich gar nicht ausgewertet werden?
Wie kann ich das prüfen?
Gruß
Ch. Hanisch
Henning Paul
Mar 15, 2012, 12:22:53 PM3/15/12
to
nur dann ausgewertet.
Gruß
Henning
Christoph
Mar 15, 2012, 12:49:41 PM3/15/12
to
Am 15.03.2012 16:33, schrieb Ch. Hanisch:
> Hallo Uwe,
>
> Am 15.03.2012 16:19, schrieb Uwe Borchert:
>
>> Ausdrücklich nicht empfohlen, aber von mir verwendet:
>>
>> root@grafix:~# cat /boot/grub/device.map
>> (hd0) /dev/sda
>> (hd1) /dev/sdb
>> root@grafix:~#
> Warum nicht empfohlen?...
> Hallo Uwe,
>
> Am 15.03.2012 16:19, schrieb Uwe Borchert:
>
>> Ausdrücklich nicht empfohlen, aber von mir verwendet:
>>
>> root@grafix:~# cat /boot/grub/device.map
>> (hd0) /dev/sda
>> (hd1) /dev/sdb
>> root@grafix:~#
weil mit SATA die Zuordnung, welche Platte sda und welche sdb
wird, sich zufällig ändern kann. Ich habe das hier in einem
Laptop, in dem ich zur Datensicherung Platten klone. Eine Platte
steckt im normalen Einbauort, eine zweite in einem Einschub (wo
normalerweise das CD-LW steckt) an einem anderen SATA Kanal. Wenn
ich den Rechner mit einer Linux-CD boote (z.B. parted-magic),
dann ist die Zuordnung mal
sda - interne HD
sdb - Einschub
und mal umgekehrt! Ein System habe ich noch nicht gefunden.
Soweit ich das bisher verstanden habe, liegt das grundsätzlich an
SATA. Oder an der Art, wie Linux damit umgeht.
Christoph
--
email:
nurfuerspam -> gmx
de -> net
Ch. Hanisch
Mar 15, 2012, 1:00:26 PM3/15/12
to
Hallo Henning,
Am 15.03.2012 17:22, schrieb Henning Paul:
> Ch. Hanisch wrote:
>> (hd1) /dev/disk/by-id/ata-ST9500420AS_5VJCLASL (Interne Systemplatte)
# grub-install /dev/sdb
habe ich da noch keinerlei Auswirkungen beobachtet.
Sind meine Eintragungen nun wenigstens richtig?
Gruß
Ch. Hanisch
Am 15.03.2012 17:22, schrieb Henning Paul:
> Ch. Hanisch wrote:
>> Dann müßte es also so aussehen in der device.map:
>> (hd0) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0 (Externe MEDION-Platte)
>> (hd1) /dev/disk/by-id/ata-ST9500420AS_5VJCLASL (Interne Systemplatte)
>>
>> Meine Frage bleibt aber noch unbeantwortet. Sind diese
>> /dev/disk/by-id/... Einträge relevant für meine Konstellation, obwohl
>> sie eigentlich gar nicht ausgewertet werden?
>
> Sie werden eigentlich nur für die Installation des GRUB benötigt, d.h.
> nur dann ausgewertet.
Ich kann da rein schreiben, was ich will. Bei
>> Meine Frage bleibt aber noch unbeantwortet. Sind diese
>> /dev/disk/by-id/... Einträge relevant für meine Konstellation, obwohl
>> sie eigentlich gar nicht ausgewertet werden?
>
> Sie werden eigentlich nur für die Installation des GRUB benötigt, d.h.
> nur dann ausgewertet.
# grub-install /dev/sdb
habe ich da noch keinerlei Auswirkungen beobachtet.
Sind meine Eintragungen nun wenigstens richtig?
Gruß
Ch. Hanisch
Thomas Bächler
Mar 15, 2012, 1:56:14 PM3/15/12
to
Am 15.03.2012 17:49, schrieb Christoph:
> Wenn ich den Rechner mit einer Linux-CD boote
> (z.B. parted-magic), dann ist die Zuordnung mal
> sda - interne HD
> sdb - Einschub
> und mal umgekehrt! Ein System habe ich noch nicht gefunden. Soweit ich
> das bisher verstanden habe, liegt das grundsätzlich an SATA. Oder an der
> Art, wie Linux damit umgeht.
Das hängt davon ab, welcher SATA-Treiber/Controller sich zuerst
> Wenn ich den Rechner mit einer Linux-CD boote
> (z.B. parted-magic), dann ist die Zuordnung mal
> sda - interne HD
> sdb - Einschub
> und mal umgekehrt! Ein System habe ich noch nicht gefunden. Soweit ich
> das bisher verstanden habe, liegt das grundsätzlich an SATA. Oder an der
> Art, wie Linux damit umgeht.
initialisiert (sofern mehrere SATA-Controller vorhanden sind). Linux
gibt hier grundsätzlich keine Garantie zu irgendeiner festen Reihenfolge.
Das Problem mit GRUB ist schlimmer: Beim Zugriff auf die Platten via
BIOS gibt es eine eindeutige Reihenfolge: (hd0), (hd1), etc. Diese
Reihenfolge lässt sich bei gebootetem Linux nicht feststellen, sondern
nur erraten (und das BIOS kann diese bei geänderter Bootreihenfolge
ändern). Die device.map kann benutzt werden, um ein inkorrektes Raten
seitens GRUB zu reparieren: Man ordnet einem Linux-Gerät ein BIOS-Gerät
zu, damit GRUB vorhersagen kann, wo es die Platten beim Booten wiederfindet.
Allerdings ist das ein Problem das nur GRUB hat: GRUB hat den Anspruch,
den Zugriff auf andere Festplatten als die Bootfestplatte ermöglichen.
Andere Bootloader erlauben meist nur Zugriff auf die Bootfestplatte, was
diese Raterei und das Gefummel an der device.map überflüssig macht.
Helmut Hullen
Mar 15, 2012, 3:46:00 PM3/15/12
to
Hallo, Christoph,
Du meintest am 15.03.12:
[...]
> weil mit SATA die Zuordnung, welche Platte sda und welche sdb
> wird, sich zufällig ändern kann. Ich habe das hier in einem
> Laptop, in dem ich zur Datensicherung Platten klone. Eine Platte
> steckt im normalen Einbauort, eine zweite in einem Einschub (wo
> normalerweise das CD-LW steckt) an einem anderen SATA Kanal. Wenn
> ich den Rechner mit einer Linux-CD boote (z.B. parted-magic),
> dann ist die Zuordnung mal
> sda - interne HD
> sdb - Einschub
> und mal umgekehrt! Ein System habe ich noch nicht gefunden.
> Soweit ich das bisher verstanden habe, liegt das grundsätzlich an
> SATA. Oder an der Art, wie Linux damit umgeht.
Am ehesten spielt auch die Kernel-Konfiguration eine Rolle, und die kann
von Distribution zu Distribution verschieden sein.
Vermutlich kann auch die Init-Ramdisk noch einiges je nach Distribution
anders abarbeiten.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Du meintest am 15.03.12:
[...]
> weil mit SATA die Zuordnung, welche Platte sda und welche sdb
> wird, sich zufällig ändern kann. Ich habe das hier in einem
> Laptop, in dem ich zur Datensicherung Platten klone. Eine Platte
> steckt im normalen Einbauort, eine zweite in einem Einschub (wo
> normalerweise das CD-LW steckt) an einem anderen SATA Kanal. Wenn
> ich den Rechner mit einer Linux-CD boote (z.B. parted-magic),
> dann ist die Zuordnung mal
> sda - interne HD
> sdb - Einschub
> und mal umgekehrt! Ein System habe ich noch nicht gefunden.
> Soweit ich das bisher verstanden habe, liegt das grundsätzlich an
> SATA. Oder an der Art, wie Linux damit umgeht.
von Distribution zu Distribution verschieden sein.
Vermutlich kann auch die Init-Ramdisk noch einiges je nach Distribution
anders abarbeiten.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Uwe Borchert
Mar 15, 2012, 9:49:58 PM3/15/12
to
Hallo,
Am 15.03.2012 16:33, schrieb Ch. Hanisch:
> Da ich von der externen Platte boote habe ich stehen bei GRUB1:
> (hd0) /dev/sdb
> (hd1) /dev/sda
>
> Bei mir habe ich jetzt:
> $ sudo cat /boot/grub/device.map
> [sudo] password for benutzer:
> (hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
> (hd1) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
> Aber ich bin mir nicht sicher, ob ich da die richtigen Einträge genommen
> habe.
>>
>> Grund: Ich kann das komplette System mit tar klonen ohne irgendwas
>> an den beteiligten Dateien (auch /etc/fstab) zu ändern.
> Wie machst Du das, Befehlsfolge?
Wegpacken des gesamten Systems mit tarsys.sh
#!/bin/bash
#
# docs:
#
a2ps -1 -f 9 -o 00_lesen.ps 00_lesen.txt
ps2pdf 00_lesen.ps
rm -f 00_lesen.ps
zip restore_scripts.zip 00_lesen.txt *.sh
#
# debian 6.0 system:
#
dpkg --get-selections > selections.list
dpkg -l > packages.list
a2ps -4 -o packages.ps packages.list
ps2pdf packages.ps
rm packages.ps*
sync
tar --exclude=/home/* \
--exclude=/mnt/* \
--exclude=/tmp/* \
--exclude=/proc/* \
--exclude=/sys/* \
--exclude=/var/log/samba/* \
--exclude=/var/log/cups/* \
--exclude=/var/run/* \
--exclude=/var/spool/* \
-cvzf system.tar.gz /
sync
echo "Generating filelist from tarball"
tar -tvzf system.tar.gz > system.list
# --- #
# EoF #
# --- #
Wiederauspacken von einer umgebauten Installationscd mit restore.sh
#
# Script for RescueCD
#
tar -C /target -xvzf /cdrom/restore/system.tar.gz
rm -f /target/etc/udev/rules.d/*persistent*.rules
# --- #
# EoF #
# --- #
Hier mal meine etwas unvollständigen Notizen:
Rettungs-DVD fuer Debian (6.0 Squeeze)
Hier ein sehr einfacher Ansatz eine modifizierte Netinstall-CD
zu einer Wiederherstellungs-CD/DVD umzubauen. Typische Anwendung
sind die Wiederherstellung von Systemen nach Hardwareausfaellen
und Festplattentausch oder das Erzeugen eines oder weniger
Klone eines bestehenden System.
Entpacken des Netinstaller-ISO mit bsdtar
Man lade ein Netinstall-ISO-Image herunter und entpacke dieses
im Wiederherstellungsverzeichnis:
bsdtar -C boot_dvd -xf debian-6.0.0-i386-netinst.iso
Damit befindet sich das enpackte ISO-Image in boot_dvd/
(Kein bsdtar? "apt-get install bsdtar"!)
Zusammenstellung der Rettungs-DVD
Alle lokalen Dateien befinden sich im Verzeichniss restore.
Dieses legt man als Unterverzeichnis von boot_dvd/ an.
* diverse Hilfsscripte und Dokumentation (+)
* gepacktes System und Liste der verpackten Dateien
* Listen fuer apt-setselections
(+) Siehe restore_scripts.zip -> Diese Dateien nach
dvd/restore/ verschieben. Damit bleiben diese Dateien auf
der Wiederherstellungs-DVD und koennen als Vorlage fuer
andere Systeme wieder herangezogen werden.
Wichtig! Das zusammengepackte System darf keine UUID mehr
enthalten. Diese befinden sich in:
grub: /boot/grub/device.map
linux: /etc/fstab
Bitte die UUID durch die passenden devices (zB /dev/sda fuer
grub und /dev/sda1 fuer Linux in der /etc/fstab) ersetzen. In
der fstab helfen die auskommentierten Eintraege der
Installationsroutinen weiter, in device.map reicht der Eintrag
der Platte mit der Bootpartition (zB /dev/sda).
---[/boot/grub/device.map]---
(hd0) /dev/sda
(hd1) /dev/sdb
---[.....................]---
---[.....................]---
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' 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>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
# UUID=56f74aa1-c0ce-4838-baa2-481724efa9a7 / ext3 errors=remount-ro 0 1
/dev/sda1 / ext3 errors=remount-ro 0 1
#
# /home was on /dev/sdb1 during installation
# UUID=111b870b-6574-429d-89ba-a8ad30e84982 /home ext3 defaults 0 2
/dev/sdb1 /home ext3 defaults 0 2
#
# /tmp was on /dev/sda3 during installation
# UUID=0b215e7a-792c-43dc-87ea-50ac49116918 /tmp ext3 defaults 0 2
#
/dev/sda3 /tmp ext3 defaults 0 2
# swap was on /dev/sda2 during installation
#UUID=81a5a752-a68c-44be-aa57-314d110278c6 none swap sw 0 0
/dev/sda2 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
#
/dev/sdc1 /media/usb0 auto rw,user,noauto 0 0
/dev/sdd1 /media/usb1 auto rw,user,noauto 0 0
---[.....................]---
Im Verzeichnis restore/ befindet sich das Skript tarsys.sh
(u.U. anpassen) zum Verpacken des kompletten System. Weitere
Dokumente kann man nach restore/ in ein Unterverzeichnis
(zB restore/localdoc) kopieren. Externe Pakete (Adobe,
Source und andere Dinge aus/fuer /usr/local/ ...) kann man
unter restore in restore/packages packen. Damit hat man
alles schoen an Fleck.
Erstellen der Rettungs-DVD
Dieser Vorgang ist mit make_iso.sh automatisiert und besteht
aus zwei Schritten:
1) Neuberechnug der md5 checksums im Verzeichnis dvd/
md5sum `find ! -name "md5sum.txt" ! -path "./isolinux/*" -follow -type f` > md5sum.txt
2) Erstellen des neuen Bootimage mit mkisofs
mkisofs \
-o ../boot_dvd.iso \
-r -J -no-emul-boot -boot-load-size 4 -boot-info-table \
-b isolinux/isolinux.bin -c isolinux/boot.cat dvd
Damit liegt eine fertige ISO-Datei vor. Diese kann nun mit
cdrecord o.ae. nun gebrannt werden.
Wiederherstellung des System
Booten von DVD, Optionen Rettungsmodus, Sprache und Tastatur
waehlen. Falls die Festplatte noch nicht partitioniert wurde
kann man in einer Konsole (ALT+F2, +F3 ...) sfdisk aufrufen,
die Partitionen anlegen und danach formatieren. Alternativ kann
man diesen Schritt vorab mit einer bequemer zu bedienenden
Live-CD machen.
Sobald die Zielpartition(en) fertig formatiert ist kann man
diese als Installationsziel waehlen. In der zweiten Konsole
(ALT+F2, +F3 ...) mit mount ueberruefen ob target und cdrom
richtig sitzen:
/dev/sda1 on /target ...
/dev/sr0 on /cdrom ...
Dann "/cdrom/restore/restore.sh" aufrufen. Damit wird das
System auf /target entpackt. Die udev-rules enthalten leider
ebenfalls noch Eintraege von alter Hardware: Netzwerkkarten
und CD/DVD-Laufwerke/Brenner. Auch das macht noch das Skript.
rm -f /target/etc/udev/rules.d/*persistent*.rules
Danach ist das System fertig auf der Festplatte aber noch
nicht bootbar. Dies muss leider noch manuell geschehen.
Debian Rettungs-Menu -> Shell in Target-Verzeichnis oeffnen:
$ grub-mkconfig
$ install-grub --force /dev/sda
Der Paramter --force ist notwendig, da grub2 der Meinung ist
das UUID viel sicher und besser als devices sind. Das ist fuer
Wechseldatentrager (externe Festplatten, USB-Stoeckchen) zwar
richtig, aber in unserem Fall kontraproduktiv.
Nach abschliessender Kontrolle kann man reboot eingeben und
ist fertig?
...[Ende der Notizen]...
Nachtrag make_iso.sh
#!/bin/bash
#
# Erstellen des neuen Bootimage
# create a new bootimage
#
# md5sum:
#
cd ..
md5sum `find ! -name "md5sum.txt" ! -path "./isolinux/*" -follow -type f` > md5sum.txt
#
mkisofs -o ../boot_dvd.iso \
-r -J -no-emul-boot -boot-load-size 4 -boot-info-table \
-b isolinux/isolinux.bin -c isolinux/boot.cat .
Ok, das war jetzt etwas viel auf ein Mal ... Aber ich bin echt zu
faul das ganze richtig aufzubereiten.
MfG
Uwe Borchert
Am 15.03.2012 16:33, schrieb Ch. Hanisch:
> Am 15.03.2012 16:19, schrieb Uwe Borchert:
>
>> Ausdrücklich nicht empfohlen, aber von mir verwendet:
>>
>> root@grafix:~# cat /boot/grub/device.map
>> (hd0) /dev/sda
>> (hd1) /dev/sdb
>> root@grafix:~#
> Warum nicht empfohlen?
> Das war doch bei GRUB1 so.
Ja, und mit grub2 sollte alles anders werden ...
>
>> Ausdrücklich nicht empfohlen, aber von mir verwendet:
>>
>> root@grafix:~# cat /boot/grub/device.map
>> (hd0) /dev/sda
>> (hd1) /dev/sdb
>> root@grafix:~#
> Warum nicht empfohlen?
> Das war doch bei GRUB1 so.
> Da ich von der externen Platte boote habe ich stehen bei GRUB1:
> (hd0) /dev/sdb
> (hd1) /dev/sda
>
> Bei mir habe ich jetzt:
> $ sudo cat /boot/grub/device.map
> [sudo] password for benutzer:
> (hd0) /dev/disk/by-id/ata-HL-DT-STDVD+_-RW_GT32N_KYSB6A80222
> (hd1) /dev/disk/by-id/usb-WDC_WD10_EARS-00Y5B1_DCA5A085959F-0:0
> Aber ich bin mir nicht sicher, ob ich da die richtigen Einträge genommen
> habe.
>>
>> Grund: Ich kann das komplette System mit tar klonen ohne irgendwas
>> an den beteiligten Dateien (auch /etc/fstab) zu ändern.
> Wie machst Du das, Befehlsfolge?
#!/bin/bash
#
# docs:
#
a2ps -1 -f 9 -o 00_lesen.ps 00_lesen.txt
ps2pdf 00_lesen.ps
rm -f 00_lesen.ps
zip restore_scripts.zip 00_lesen.txt *.sh
#
# debian 6.0 system:
#
dpkg --get-selections > selections.list
dpkg -l > packages.list
a2ps -4 -o packages.ps packages.list
ps2pdf packages.ps
rm packages.ps*
sync
tar --exclude=/home/* \
--exclude=/mnt/* \
--exclude=/tmp/* \
--exclude=/proc/* \
--exclude=/sys/* \
--exclude=/var/log/samba/* \
--exclude=/var/log/cups/* \
--exclude=/var/run/* \
--exclude=/var/spool/* \
-cvzf system.tar.gz /
sync
echo "Generating filelist from tarball"
tar -tvzf system.tar.gz > system.list
# --- #
# EoF #
# --- #
Wiederauspacken von einer umgebauten Installationscd mit restore.sh
#
# Script for RescueCD
#
tar -C /target -xvzf /cdrom/restore/system.tar.gz
rm -f /target/etc/udev/rules.d/*persistent*.rules
# --- #
# EoF #
# --- #
Hier mal meine etwas unvollständigen Notizen:
Rettungs-DVD fuer Debian (6.0 Squeeze)
Hier ein sehr einfacher Ansatz eine modifizierte Netinstall-CD
zu einer Wiederherstellungs-CD/DVD umzubauen. Typische Anwendung
sind die Wiederherstellung von Systemen nach Hardwareausfaellen
und Festplattentausch oder das Erzeugen eines oder weniger
Klone eines bestehenden System.
Entpacken des Netinstaller-ISO mit bsdtar
Man lade ein Netinstall-ISO-Image herunter und entpacke dieses
im Wiederherstellungsverzeichnis:
bsdtar -C boot_dvd -xf debian-6.0.0-i386-netinst.iso
Damit befindet sich das enpackte ISO-Image in boot_dvd/
(Kein bsdtar? "apt-get install bsdtar"!)
Zusammenstellung der Rettungs-DVD
Alle lokalen Dateien befinden sich im Verzeichniss restore.
Dieses legt man als Unterverzeichnis von boot_dvd/ an.
* diverse Hilfsscripte und Dokumentation (+)
* gepacktes System und Liste der verpackten Dateien
* Listen fuer apt-setselections
(+) Siehe restore_scripts.zip -> Diese Dateien nach
dvd/restore/ verschieben. Damit bleiben diese Dateien auf
der Wiederherstellungs-DVD und koennen als Vorlage fuer
andere Systeme wieder herangezogen werden.
Wichtig! Das zusammengepackte System darf keine UUID mehr
enthalten. Diese befinden sich in:
grub: /boot/grub/device.map
linux: /etc/fstab
Bitte die UUID durch die passenden devices (zB /dev/sda fuer
grub und /dev/sda1 fuer Linux in der /etc/fstab) ersetzen. In
der fstab helfen die auskommentierten Eintraege der
Installationsroutinen weiter, in device.map reicht der Eintrag
der Platte mit der Bootpartition (zB /dev/sda).
---[/boot/grub/device.map]---
(hd0) /dev/sda
(hd1) /dev/sdb
---[.....................]---
---[.....................]---
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' 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>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
# UUID=56f74aa1-c0ce-4838-baa2-481724efa9a7 / ext3 errors=remount-ro 0 1
/dev/sda1 / ext3 errors=remount-ro 0 1
#
# /home was on /dev/sdb1 during installation
# UUID=111b870b-6574-429d-89ba-a8ad30e84982 /home ext3 defaults 0 2
/dev/sdb1 /home ext3 defaults 0 2
#
# /tmp was on /dev/sda3 during installation
# UUID=0b215e7a-792c-43dc-87ea-50ac49116918 /tmp ext3 defaults 0 2
#
/dev/sda3 /tmp ext3 defaults 0 2
# swap was on /dev/sda2 during installation
#UUID=81a5a752-a68c-44be-aa57-314d110278c6 none swap sw 0 0
/dev/sda2 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
#
/dev/sdc1 /media/usb0 auto rw,user,noauto 0 0
/dev/sdd1 /media/usb1 auto rw,user,noauto 0 0
---[.....................]---
Im Verzeichnis restore/ befindet sich das Skript tarsys.sh
(u.U. anpassen) zum Verpacken des kompletten System. Weitere
Dokumente kann man nach restore/ in ein Unterverzeichnis
(zB restore/localdoc) kopieren. Externe Pakete (Adobe,
Source und andere Dinge aus/fuer /usr/local/ ...) kann man
unter restore in restore/packages packen. Damit hat man
alles schoen an Fleck.
Erstellen der Rettungs-DVD
Dieser Vorgang ist mit make_iso.sh automatisiert und besteht
aus zwei Schritten:
1) Neuberechnug der md5 checksums im Verzeichnis dvd/
md5sum `find ! -name "md5sum.txt" ! -path "./isolinux/*" -follow -type f` > md5sum.txt
2) Erstellen des neuen Bootimage mit mkisofs
mkisofs \
-o ../boot_dvd.iso \
-r -J -no-emul-boot -boot-load-size 4 -boot-info-table \
-b isolinux/isolinux.bin -c isolinux/boot.cat dvd
Damit liegt eine fertige ISO-Datei vor. Diese kann nun mit
cdrecord o.ae. nun gebrannt werden.
Wiederherstellung des System
Booten von DVD, Optionen Rettungsmodus, Sprache und Tastatur
waehlen. Falls die Festplatte noch nicht partitioniert wurde
kann man in einer Konsole (ALT+F2, +F3 ...) sfdisk aufrufen,
die Partitionen anlegen und danach formatieren. Alternativ kann
man diesen Schritt vorab mit einer bequemer zu bedienenden
Live-CD machen.
Sobald die Zielpartition(en) fertig formatiert ist kann man
diese als Installationsziel waehlen. In der zweiten Konsole
(ALT+F2, +F3 ...) mit mount ueberruefen ob target und cdrom
richtig sitzen:
/dev/sda1 on /target ...
/dev/sr0 on /cdrom ...
Dann "/cdrom/restore/restore.sh" aufrufen. Damit wird das
System auf /target entpackt. Die udev-rules enthalten leider
ebenfalls noch Eintraege von alter Hardware: Netzwerkkarten
und CD/DVD-Laufwerke/Brenner. Auch das macht noch das Skript.
rm -f /target/etc/udev/rules.d/*persistent*.rules
Danach ist das System fertig auf der Festplatte aber noch
nicht bootbar. Dies muss leider noch manuell geschehen.
Debian Rettungs-Menu -> Shell in Target-Verzeichnis oeffnen:
$ grub-mkconfig
$ install-grub --force /dev/sda
Der Paramter --force ist notwendig, da grub2 der Meinung ist
das UUID viel sicher und besser als devices sind. Das ist fuer
Wechseldatentrager (externe Festplatten, USB-Stoeckchen) zwar
richtig, aber in unserem Fall kontraproduktiv.
Nach abschliessender Kontrolle kann man reboot eingeben und
ist fertig?
...[Ende der Notizen]...
Nachtrag make_iso.sh
#!/bin/bash
#
# Erstellen des neuen Bootimage
# create a new bootimage
#
# md5sum:
#
cd ..
md5sum `find ! -name "md5sum.txt" ! -path "./isolinux/*" -follow -type f` > md5sum.txt
#
mkisofs -o ../boot_dvd.iso \
-r -J -no-emul-boot -boot-load-size 4 -boot-info-table \
-b isolinux/isolinux.bin -c isolinux/boot.cat .
Ok, das war jetzt etwas viel auf ein Mal ... Aber ich bin echt zu
faul das ganze richtig aufzubereiten.
MfG
Uwe Borchert
Thomas Bächler
Mar 16, 2012, 6:53:32 AM3/16/12
to
Am 15.03.2012 20:46, schrieb Helmut Hullen:
>> weil mit SATA die Zuordnung, welche Platte sda und welche sdb
>> wird, sich zufällig ändern kann. Ich habe das hier in einem
>> Laptop, in dem ich zur Datensicherung Platten klone. Eine Platte
>> steckt im normalen Einbauort, eine zweite in einem Einschub (wo
>> normalerweise das CD-LW steckt) an einem anderen SATA Kanal. Wenn
>> ich den Rechner mit einer Linux-CD boote (z.B. parted-magic),
>> dann ist die Zuordnung mal
>> sda - interne HD
>> sdb - Einschub
>> und mal umgekehrt! Ein System habe ich noch nicht gefunden.
>> Soweit ich das bisher verstanden habe, liegt das grundsätzlich an
>> SATA. Oder an der Art, wie Linux damit umgeht.
>
> Am ehesten spielt auch die Kernel-Konfiguration eine Rolle, und die kann
> von Distribution zu Distribution verschieden sein.
> Vermutlich kann auch die Init-Ramdisk noch einiges je nach Distribution
> anders abarbeiten.
Du stellst es so dar, als hätte man die Möglichkeit, über die
>> weil mit SATA die Zuordnung, welche Platte sda und welche sdb
>> wird, sich zufällig ändern kann. Ich habe das hier in einem
>> Laptop, in dem ich zur Datensicherung Platten klone. Eine Platte
>> steckt im normalen Einbauort, eine zweite in einem Einschub (wo
>> normalerweise das CD-LW steckt) an einem anderen SATA Kanal. Wenn
>> ich den Rechner mit einer Linux-CD boote (z.B. parted-magic),
>> dann ist die Zuordnung mal
>> sda - interne HD
>> sdb - Einschub
>> und mal umgekehrt! Ein System habe ich noch nicht gefunden.
>> Soweit ich das bisher verstanden habe, liegt das grundsätzlich an
>> SATA. Oder an der Art, wie Linux damit umgeht.
>
> Am ehesten spielt auch die Kernel-Konfiguration eine Rolle, und die kann
> von Distribution zu Distribution verschieden sein.
> Vermutlich kann auch die Init-Ramdisk noch einiges je nach Distribution
> anders abarbeiten.
Kernel-Konfiguration oder das Verhalten des /init Programms im initramfs
deterministisch die Reihenfolge der sd? festzulegen. Wie ich bereits
zuvor geschrieben habe, gibt es hier keinerlei Garantien und es wird sie
auch in Zukunft nicht geben.
Wenn du eine Methode gefunden hast, die dir eine bestimmte Reihenfolge
gibt, sei darauf gefasst, dass sie eines Tages nicht mehr funktioniert.
Henning Paul
Mar 16, 2012, 9:00:34 AM3/16/12
to
Thomas Bächler wrote:
> Wenn du eine Methode gefunden hast, die dir eine bestimmte Reihenfolge
> gibt, sei darauf gefasst, dass sie eines Tages nicht mehr
> funktioniert.
ACK. Ich hatte mal ein ähnliches Problem mit DVB-Karten, die ebenfalls
> Wenn du eine Methode gefunden hast, die dir eine bestimmte Reihenfolge
> gibt, sei darauf gefasst, dass sie eines Tages nicht mehr
> funktioniert.
bei jedem Boot als anderer /dev/dvb/adapterX/ zu finden waren. Nun hielt
ich mich für so schlau, mittels Schweinereien in der modprobe.conf eine
bestimmte Kernelmodulladereihenfolge zu erzwingen. Das flog mir bei
irgend einem Update dann auch um die Ohren und ich benutze seitdem
einfach den Modulparameter adapter_nr=. :-)
Gruß
Henning
Helmut Hullen
Mar 16, 2012, 2:24:00 PM3/16/12
to
Hallo, Thomas,
Du meintest am 16.03.12:
>>> Wenn ich den Rechner mit einer Linux-CD boote (z.B. parted-magic),
>>> dann ist die Zuordnung mal
>>> sda - interne HD
>>> sdb - Einschub
>>> und mal umgekehrt! Ein System habe ich noch nicht gefunden.
>>> Soweit ich das bisher verstanden habe, liegt das grundsätzlich an
>>> SATA. Oder an der Art, wie Linux damit umgeht.
>> Am ehesten spielt auch die Kernel-Konfiguration eine Rolle, und die
>> kann von Distribution zu Distribution verschieden sein.
>> Vermutlich kann auch die Init-Ramdisk noch einiges je nach
>> Distribution anders abarbeiten.
> Du stellst es so dar, als hätte man die Möglichkeit, über die
> Kernel-Konfiguration oder das Verhalten des /init Programms im
> initramfs deterministisch die Reihenfolge der sd? festzulegen.
Nein - "deterministisch" habe ich nirgendwo angeboten oder auch nur
angedeutet. "Aus gegebenem Anlass" ...
Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA, S-ATA
und SCSI, wo ich mit immerwährender Freude beobachten kann, wie
verschiedene Distributionen (und innerhalb der Distribution verschiedene
Kernel-Versionen) die Festplatten-Ausstattung interpretieren.
Du meintest am 16.03.12:
>>> Wenn ich den Rechner mit einer Linux-CD boote (z.B. parted-magic),
>>> dann ist die Zuordnung mal
>>> sda - interne HD
>>> sdb - Einschub
>>> und mal umgekehrt! Ein System habe ich noch nicht gefunden.
>>> Soweit ich das bisher verstanden habe, liegt das grundsätzlich an
>>> SATA. Oder an der Art, wie Linux damit umgeht.
>> Am ehesten spielt auch die Kernel-Konfiguration eine Rolle, und die
>> kann von Distribution zu Distribution verschieden sein.
>> Vermutlich kann auch die Init-Ramdisk noch einiges je nach
>> Distribution anders abarbeiten.
> Du stellst es so dar, als hätte man die Möglichkeit, über die
> Kernel-Konfiguration oder das Verhalten des /init Programms im
> initramfs deterministisch die Reihenfolge der sd? festzulegen.
angedeutet. "Aus gegebenem Anlass" ...
Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA, S-ATA
und SCSI, wo ich mit immerwährender Freude beobachten kann, wie
verschiedene Distributionen (und innerhalb der Distribution verschiedene
Kernel-Versionen) die Festplatten-Ausstattung interpretieren.
Marc Haber
Mar 17, 2012, 3:54:01 AM3/17/12
to
Hel...@Hullen.de (Helmut Hullen) wrote:
>Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA, S-ATA
>und SCSI, wo ich mit immerwährender Freude beobachten kann, wie
>verschiedene Distributionen (und innerhalb der Distribution verschiedene
>Kernel-Versionen) die Festplatten-Ausstattung interpretieren.
Etwas anderes als /dev/sdx ist seit über drei Jahren aus der Mode.
>Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA, S-ATA
>und SCSI, wo ich mit immerwährender Freude beobachten kann, wie
>verschiedene Distributionen (und innerhalb der Distribution verschiedene
>Kernel-Versionen) die Festplatten-Ausstattung interpretieren.
Selbst die immer schon als seltsam bekannten cciss-Controller werden
seit Debian squeeze als /dev/sdx erkannt. Das funktioniert bei
halbwegs aktueller Software also _immer_, auch wenn man bei solch
aktueller Software in aller Regel besser fährt, die von udev
bereitgestellten Devicenodes unter /dev/disk zu verwenden.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Helmut Hullen
Mar 17, 2012, 4:03:00 AM3/17/12
to
Hallo, Marc,
Du meintest am 17.03.12:
>> Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA,
>> S-ATA und SCSI, wo ich mit immerwährender Freude beobachten kann,
>> wie verschiedene Distributionen (und innerhalb der Distribution
>> verschiedene Kernel-Versionen) die Festplatten-Ausstattung
>> interpretieren.
> Etwas anderes als /dev/sdx ist seit über drei Jahren aus der Mode.
Das ändert einige Namen, das ändert nicht die immer wieder überraschende
Reihenfolge der Zuordnungen.
Noch mal: ist von Distribution zu Distribution verschieden, kann
innerhalb einer Distribution von Kernelversion zu Kernelversion
verschieden sein. Auch dann, wenn ich "udev" abschalte.
Du meintest am 17.03.12:
>> Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA,
>> S-ATA und SCSI, wo ich mit immerwährender Freude beobachten kann,
>> wie verschiedene Distributionen (und innerhalb der Distribution
>> verschiedene Kernel-Versionen) die Festplatten-Ausstattung
>> interpretieren.
> Etwas anderes als /dev/sdx ist seit über drei Jahren aus der Mode.
Reihenfolge der Zuordnungen.
Noch mal: ist von Distribution zu Distribution verschieden, kann
innerhalb einer Distribution von Kernelversion zu Kernelversion
verschieden sein. Auch dann, wenn ich "udev" abschalte.
ds_Dieter_Schultheis
Mar 17, 2012, 12:11:16 PM3/17/12
to
Am 15.03.2012 17:49, schrieb Christoph:
PATA/IDE. Daher sollte man beim seriellen SATA immer die UUID oder ein
beim Partitionieren festgelegtes Label für das Mounten verwenden. Nur
das erspart die SDx Lotterie.
--
MfG
Dieter
Marc Haber
Mar 18, 2012, 12:53:06 PM3/18/12
to
Hel...@Hullen.de (Helmut Hullen) wrote:
>Du meintest am 17.03.12:
>>> Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA,
>>> S-ATA und SCSI, wo ich mit immerwährender Freude beobachten kann,
>>> wie verschiedene Distributionen (und innerhalb der Distribution
>>> verschiedene Kernel-Versionen) die Festplatten-Ausstattung
>>> interpretieren.
>
>> Etwas anderes als /dev/sdx ist seit über drei Jahren aus der Mode.
>
>Das ändert einige Namen, das ändert nicht die immer wieder überraschende
>Reihenfolge der Zuordnungen.
Mich hat das lange nicht mehr überrascht.
>Du meintest am 17.03.12:
>>> Aber ich habe hier einiges an Test-Maschinen, bestückt mit P-ATA,
>>> S-ATA und SCSI, wo ich mit immerwährender Freude beobachten kann,
>>> wie verschiedene Distributionen (und innerhalb der Distribution
>>> verschiedene Kernel-Versionen) die Festplatten-Ausstattung
>>> interpretieren.
>
>> Etwas anderes als /dev/sdx ist seit über drei Jahren aus der Mode.
>
>Das ändert einige Namen, das ändert nicht die immer wieder überraschende
>Reihenfolge der Zuordnungen.
>Noch mal: ist von Distribution zu Distribution verschieden, kann
>innerhalb einer Distribution von Kernelversion zu Kernelversion
>verschieden sein. Auch dann, wenn ich "udev" abschalte.
diese lästigen Unterschiede ein für alle Mal wegschafft (/dev/disk)
aus, um Dich dann in Schritt 2 über diese lästigen Unterschiede zu
beschweren.
Helmut Hullen
Mar 18, 2012, 2:10:00 PM3/18/12
to
Hallo, Marc,
Du meintest am 18.03.12:
>> Noch mal: ist von Distribution zu Distribution verschieden, kann
>> innerhalb einer Distribution von Kernelversion zu Kernelversion
>> verschieden sein. Auch dann, wenn ich "udev" abschalte.
> Du bist schon eigenwillig. In Schritt 1 schaltest Du das Tool, das
> diese lästigen Unterschiede ein für alle Mal wegschafft (/dev/disk)
> aus, um Dich dann in Schritt 2 über diese lästigen Unterschiede zu
> beschweren.
Ich habe "udev" vor allem deswegen abgewürgt, weil es zu oft andere
Vorstellungen von der besten Benennung der Geräte hat als ich. Betrifft
in meinem Bauspielplatz am ehesten Netzwerkkarten und Festplatten.
Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich habe
hier mehr als 30 Festplatten für solche Basteleien. Und dann will ich
nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der u.a. steht,
dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse "/dev/sdq" und die
32-GByte-CFcard heisse "/dev/sdw".
Du meintest am 18.03.12:
>> Noch mal: ist von Distribution zu Distribution verschieden, kann
>> innerhalb einer Distribution von Kernelversion zu Kernelversion
>> verschieden sein. Auch dann, wenn ich "udev" abschalte.
> Du bist schon eigenwillig. In Schritt 1 schaltest Du das Tool, das
> diese lästigen Unterschiede ein für alle Mal wegschafft (/dev/disk)
> aus, um Dich dann in Schritt 2 über diese lästigen Unterschiede zu
> beschweren.
Vorstellungen von der besten Benennung der Geräte hat als ich. Betrifft
in meinem Bauspielplatz am ehesten Netzwerkkarten und Festplatten.
Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich habe
hier mehr als 30 Festplatten für solche Basteleien. Und dann will ich
nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der u.a. steht,
dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse "/dev/sdq" und die
32-GByte-CFcard heisse "/dev/sdw".
Henning Paul
Mar 19, 2012, 3:22:34 AM3/19/12
to
Helmut Hullen wrote:
> Ich habe "udev" vor allem deswegen abgewürgt, weil es zu oft andere
> Vorstellungen von der besten Benennung der Geräte hat als ich.
> Betrifft in meinem Bauspielplatz am ehesten Netzwerkkarten und
> Festplatten.
>
> Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich
> habe hier mehr als 30 Festplatten für solche Basteleien. Und dann will
> ich nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der u.a.
> steht, dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse "/dev/sdq"
> und die 32-GByte-CFcard heisse "/dev/sdw".
Mir scheint, Du hast die Funktionsweise von udev bis heute nicht
> Ich habe "udev" vor allem deswegen abgewürgt, weil es zu oft andere
> Vorstellungen von der besten Benennung der Geräte hat als ich.
> Betrifft in meinem Bauspielplatz am ehesten Netzwerkkarten und
> Festplatten.
>
> Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich
> habe hier mehr als 30 Festplatten für solche Basteleien. Und dann will
> ich nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der u.a.
> steht, dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse "/dev/sdq"
> und die 32-GByte-CFcard heisse "/dev/sdw".
verstanden. Der _Kernel_ wird die Blockdevices immer bei sda anfangen
durchzunummerieren. Wenn Du keine 23 Blockdevices _gleichzeitig_ in
Betrieb hast, wird niemals ein sdw auftauchen. Und udev ist überhaupt
nicht in der Lage, Plattendevices umzubenennen, also wirst Du immer nur
die ersten Buchstaben des Alphabets "dort" antreffen. udev wird
lediglich symbolische Links auf Basis von Plattenmodellbezeichnung, UUID
und Pfad anlegen - die man aber selbstverständlich nicht zu benutzen
braucht.
Der Effekt, den Du beschreibst, tritt nur bei Netzwerkinterfaces und
optischen Laufwerken auf.
Du solltest Dich schon korrekt daran erinnern, warum Du udev zu hassen
gedenkst.
Gruß
Henning
Helmut Hullen
Mar 19, 2012, 3:50:00 AM3/19/12
to
Hallo, Henning,
Du meintest am 19.03.12:
>> Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich
>> habe hier mehr als 30 Festplatten für solche Basteleien. Und dann
>> will ich nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der
>> u.a. steht, dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse
>> "/dev/sdq" und die 32-GByte-CFcard heisse "/dev/sdw".
> Mir scheint, Du hast die Funktionsweise von udev bis heute nicht
> verstanden. Der _Kernel_ wird die Blockdevices immer bei sda anfangen
> durchzunummerieren. Wenn Du keine 23 Blockdevices _gleichzeitig_ in
> Betrieb hast, wird niemals ein sdw auftauchen. Und udev ist überhaupt
> nicht in der Lage, Plattendevices umzubenennen, also wirst Du immer
> nur die ersten Buchstaben des Alphabets "dort" antreffen. udev wird
> lediglich symbolische Links auf Basis von Plattenmodellbezeichnung,
> UUID und Pfad anlegen - die man aber selbstverständlich nicht zu
> benutzen braucht.
Wenn ich mir die vielen Links anschaue, die "udev" anlegt: da sind auch
Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden von
"udev" angelegt.
Du meintest am 19.03.12:
>> Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich
>> habe hier mehr als 30 Festplatten für solche Basteleien. Und dann
>> will ich nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der
>> u.a. steht, dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse
>> "/dev/sdq" und die 32-GByte-CFcard heisse "/dev/sdw".
> Mir scheint, Du hast die Funktionsweise von udev bis heute nicht
> verstanden. Der _Kernel_ wird die Blockdevices immer bei sda anfangen
> durchzunummerieren. Wenn Du keine 23 Blockdevices _gleichzeitig_ in
> Betrieb hast, wird niemals ein sdw auftauchen. Und udev ist überhaupt
> nicht in der Lage, Plattendevices umzubenennen, also wirst Du immer
> nur die ersten Buchstaben des Alphabets "dort" antreffen. udev wird
> lediglich symbolische Links auf Basis von Plattenmodellbezeichnung,
> UUID und Pfad anlegen - die man aber selbstverständlich nicht zu
> benutzen braucht.
Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden von
"udev" angelegt.
Sieghard Schicktanz
Mar 19, 2012, 5:41:24 PM3/19/12
to
Hallo Helmut,
Du schriebst am 19 Mar 2012 08:50:00 +0100:
> Wenn ich mir die vielen Links anschaue, die "udev" anlegt: da sind auch
> Links z.B. nach "/dev/sdf1" dabei.
Eben, _nach_. Das ist genau, was Henning Dir zu vermitteln versuchte, udev
vergibt _diese_ Bezeichnungen nicht selber.
> Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden von
> "udev" angelegt.
Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device" genau ist:
ist das der Eintrittspunkt in den Kernel-Treiber, ist das das physische
Gerät selber, ist das der logische "Anknüpfungspunkt" Geräte-Knoten (device
node)?
Der erstere hat mit udev nichts zu tun, der wird evtl. dadurch erzeugt, daß
der Kernel durch Erkennen eines physischen Gerätes aufgrund eines
Datenaustauschs mit diesem einen Treiber entweder aktiviert (falls
einkompiliert) oder als Modul lädt (und dann auch aktiviert).
Dieser Treiber erzeugt dann (soweit ich das sehe) in Zusammenwirken mit dem
Kernel einen Namen und einen Geräte-Knoten (/dev/<Treiberanschluß>) für das
Gerät. Der Name wird dann vom Kernel an udev übergeben, das daraufhin seine
Regeln durchgeht und alle Aktionen abarbeitet, die darauf passen. Diese
Aktionen können dann das Anlegen von Links auf diesen Geräte-Knoten, das
Laden weiterer Module, die mit diesem Treiber zusammenhängen, das Starten
von Systemdiensten für das Gerät oder sogar - bei Speichergeräten - das
Mounten der damit zur Verfügung gestellten Datenbereiche sein.
Diese ganzen Aktionen kannst Du natürlich genausogut manuell durchführen.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Du schriebst am 19 Mar 2012 08:50:00 +0100:
> Wenn ich mir die vielen Links anschaue, die "udev" anlegt: da sind auch
> Links z.B. nach "/dev/sdf1" dabei.
vergibt _diese_ Bezeichnungen nicht selber.
> Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden von
> "udev" angelegt.
ist das der Eintrittspunkt in den Kernel-Treiber, ist das das physische
Gerät selber, ist das der logische "Anknüpfungspunkt" Geräte-Knoten (device
node)?
Der erstere hat mit udev nichts zu tun, der wird evtl. dadurch erzeugt, daß
der Kernel durch Erkennen eines physischen Gerätes aufgrund eines
Datenaustauschs mit diesem einen Treiber entweder aktiviert (falls
einkompiliert) oder als Modul lädt (und dann auch aktiviert).
Dieser Treiber erzeugt dann (soweit ich das sehe) in Zusammenwirken mit dem
Kernel einen Namen und einen Geräte-Knoten (/dev/<Treiberanschluß>) für das
Gerät. Der Name wird dann vom Kernel an udev übergeben, das daraufhin seine
Regeln durchgeht und alle Aktionen abarbeitet, die darauf passen. Diese
Aktionen können dann das Anlegen von Links auf diesen Geräte-Knoten, das
Laden weiterer Module, die mit diesem Treiber zusammenhängen, das Starten
von Systemdiensten für das Gerät oder sogar - bei Speichergeräten - das
Mounten der damit zur Verfügung gestellten Datenbereiche sein.
Diese ganzen Aktionen kannst Du natürlich genausogut manuell durchführen.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Helmut Hullen
Mar 20, 2012, 3:40:00 AM3/20/12
to
Hallo, Sieghard,
Du meintest am 19.03.12:
>> Wenn ich mir die vielen Links anschaue, die "udev" anlegt: da sind
>> auch Links z.B. nach "/dev/sdf1" dabei.
> Eben, _nach_. Das ist genau, was Henning Dir zu vermitteln versuchte,
> udev vergibt _diese_ Bezeichnungen nicht selber.
>> Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden
>> von "udev" angelegt.
> Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device" genau
> ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist das das
> physische Gerät selber, ist das der logische "Anknüpfungspunkt"
> Geräte-Knoten (device node)?
In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
"MAKEDEV" erzeugt wird und zu dem ein (hoffentlich passendes) Gerät
(z.B. eine Festplatte oder eine Partition) gehört.
> Der erstere hat mit udev nichts zu tun, der wird evtl. dadurch
> erzeugt, daß der Kernel durch Erkennen eines physischen Gerätes
> aufgrund eines Datenaustauschs mit diesem einen Treiber entweder
> aktiviert (falls einkompiliert) oder als Modul lädt (und dann auch
> aktiviert). Dieser Treiber erzeugt dann (soweit ich das sehe) in
> Zusammenwirken mit dem Kernel einen Namen und einen Geräte-Knoten
> (/dev/<Treiberanschluß>) für das Gerät.
Ok.
Und da versucht "udev", für jedes weitere Gerät (hier: Platte) sowie für
deren (erkannte) Partitionen je einen (immerwährenden) Eintrag ins
Verzeichnis "/dev" zu packen.
Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich mit
etlichen SCSI-, PATA- und SATA-Platten herum.
Bei den anderen ist das kein Problem, da ist "udev" abgeschaltet. Oder
(insbesondere bei den Laptops) da ist (meistens/immer) nur 1 Festplatte
eingebaut.
Du meintest am 19.03.12:
>> Wenn ich mir die vielen Links anschaue, die "udev" anlegt: da sind
>> auch Links z.B. nach "/dev/sdf1" dabei.
> Eben, _nach_. Das ist genau, was Henning Dir zu vermitteln versuchte,
> udev vergibt _diese_ Bezeichnungen nicht selber.
>> Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden
>> von "udev" angelegt.
> Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device" genau
> ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist das das
> physische Gerät selber, ist das der logische "Anknüpfungspunkt"
> Geräte-Knoten (device node)?
"MAKEDEV" erzeugt wird und zu dem ein (hoffentlich passendes) Gerät
(z.B. eine Festplatte oder eine Partition) gehört.
> Der erstere hat mit udev nichts zu tun, der wird evtl. dadurch
> erzeugt, daß der Kernel durch Erkennen eines physischen Gerätes
> aufgrund eines Datenaustauschs mit diesem einen Treiber entweder
> aktiviert (falls einkompiliert) oder als Modul lädt (und dann auch
> aktiviert). Dieser Treiber erzeugt dann (soweit ich das sehe) in
> Zusammenwirken mit dem Kernel einen Namen und einen Geräte-Knoten
> (/dev/<Treiberanschluß>) für das Gerät.
Und da versucht "udev", für jedes weitere Gerät (hier: Platte) sowie für
deren (erkannte) Partitionen je einen (immerwährenden) Eintrag ins
Verzeichnis "/dev" zu packen.
Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich mit
etlichen SCSI-, PATA- und SATA-Platten herum.
Bei den anderen ist das kein Problem, da ist "udev" abgeschaltet. Oder
(insbesondere bei den Laptops) da ist (meistens/immer) nur 1 Festplatte
eingebaut.
Henning Paul
Mar 20, 2012, 3:49:07 AM3/20/12
to
Helmut Hullen wrote:
> Du meintest am 19.03.12:
>
>>> Wenn ich mir die vielen Links anschaue, die "udev" anlegt: da sind
>>> auch Links z.B. nach "/dev/sdf1" dabei.
>
>> Eben, _nach_. Das ist genau, was Henning Dir zu vermitteln versuchte,
>> udev vergibt _diese_ Bezeichnungen nicht selber.
>
>>> Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden
>>> von "udev" angelegt.
>
>> Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device" genau
>> ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist das das
>> physische Gerät selber, ist das der logische "Anknüpfungspunkt"
>> Geräte-Knoten (device node)?
>
> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
> "MAKEDEV" erzeugt wird und zu dem ein (hoffentlich passendes) Gerät
> (z.B. eine Festplatte oder eine Partition) gehört.
Also ein Deviceknoten.
> Du meintest am 19.03.12:
>
>>> Wenn ich mir die vielen Links anschaue, die "udev" anlegt: da sind
>>> auch Links z.B. nach "/dev/sdf1" dabei.
>
>> Eben, _nach_. Das ist genau, was Henning Dir zu vermitteln versuchte,
>> udev vergibt _diese_ Bezeichnungen nicht selber.
>
>>> Links z.B. nach "/dev/sdf1" dabei. Und die nötigen Devices werden
>>> von "udev" angelegt.
>
>> Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device" genau
>> ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist das das
>> physische Gerät selber, ist das der logische "Anknüpfungspunkt"
>> Geräte-Knoten (device node)?
>
> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
> "MAKEDEV" erzeugt wird und zu dem ein (hoffentlich passendes) Gerät
> (z.B. eine Festplatte oder eine Partition) gehört.
> Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich
> mit etlichen SCSI-, PATA- und SATA-Platten herum.
ihn brauchst. Das heißt also, wenn Du mit angeschlossenem USB-
Kartenleser bootest, musst Du erst einmal sde erzeugen, damit Du an
Deine Festplatte kommst, weil sda-sdd die Slots des Kartenlesers sind.
Das ist natürlich sehr praktisch. Ach nein, jetzt verstehe ich, Du bist
ja Profi und wirst selbstverständlich stets daran denken, den
Kartenleser vor dem Reboot abzuziehen, ja dann hast Du recht, dann
brauchst Du kein udev.
Gruß
Henning
Helmut Hullen
Mar 20, 2012, 4:18:00 AM3/20/12
to
Hallo, Henning,
Du meintest am 20.03.12:
>>> Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device"
>>> genau ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist
>>> das das physische Gerät selber, ist das der logische
>>> "Anknüpfungspunkt" Geräte-Knoten (device node)?
>>
>> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
>> "MAKEDEV" erzeugt wird und zu dem ein (hoffentlich passendes) Gerät
>> (z.B. eine Festplatte oder eine Partition) gehört.
> Also ein Deviceknoten.
>> Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich
>> mit etlichen SCSI-, PATA- und SATA-Platten herum.
> Das heißt, Du erzeugst den Deviceknoten erst mit mknod selbst, sobald
> Du ihn brauchst.
Nein.
Klassisch (ohne udev): ich erzeuge sie vorsorglich schon eine Weile
vorher. z.B. für das Device "sdq", mit vorsorglich 16 Partitionen.
Mit "udev": allemal beim Booten schaut "udev" nach, was an Festplatten
gefunden wird und wieviele Partitionen die einzelnen Platten haben. Nur
die dazu nötigen Einträge werden (beim Booten) angelegt.
Wenn ich bei laufendem Rechner weitere Platten einbinde, dann werden
(ähnlich wie bei USB-Sticks) weitere Einträge angelegt.
Ich müsste mal ein wenig mit "fdisk", "dd if=/dev/zero" und "mkfs"
herumspielen - da kann es haken.
> Das heißt also, wenn Du mit angeschlossenem USB-
> Kartenleser bootest, musst Du erst einmal sde erzeugen, damit Du an
> Deine Festplatte kommst, weil sda-sdd die Slots des Kartenlesers
> sind. Das ist natürlich sehr praktisch.
Nein - die Einträge liegen seit Jahren auf Verdacht unterhalb von "/
dev". Das Konzept dürfte es seit etwa 20 Jahren geben. Nichts Neues.
Und USB kommt auch ohne "udev" nicht so früh, dass die dort
angeschlossenen Massenspeicher z.B. bei "/dev/sda" landen.
Du meintest am 20.03.12:
>>> Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device"
>>> genau ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist
>>> das das physische Gerät selber, ist das der logische
>>> "Anknüpfungspunkt" Geräte-Knoten (device node)?
>>
>> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
>> "MAKEDEV" erzeugt wird und zu dem ein (hoffentlich passendes) Gerät
>> (z.B. eine Festplatte oder eine Partition) gehört.
> Also ein Deviceknoten.
>> Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich
>> mit etlichen SCSI-, PATA- und SATA-Platten herum.
> Das heißt, Du erzeugst den Deviceknoten erst mit mknod selbst, sobald
> Du ihn brauchst.
Klassisch (ohne udev): ich erzeuge sie vorsorglich schon eine Weile
vorher. z.B. für das Device "sdq", mit vorsorglich 16 Partitionen.
Mit "udev": allemal beim Booten schaut "udev" nach, was an Festplatten
gefunden wird und wieviele Partitionen die einzelnen Platten haben. Nur
die dazu nötigen Einträge werden (beim Booten) angelegt.
Wenn ich bei laufendem Rechner weitere Platten einbinde, dann werden
(ähnlich wie bei USB-Sticks) weitere Einträge angelegt.
Ich müsste mal ein wenig mit "fdisk", "dd if=/dev/zero" und "mkfs"
herumspielen - da kann es haken.
> Das heißt also, wenn Du mit angeschlossenem USB-
> Kartenleser bootest, musst Du erst einmal sde erzeugen, damit Du an
> Deine Festplatte kommst, weil sda-sdd die Slots des Kartenlesers
> sind. Das ist natürlich sehr praktisch.
dev". Das Konzept dürfte es seit etwa 20 Jahren geben. Nichts Neues.
Und USB kommt auch ohne "udev" nicht so früh, dass die dort
angeschlossenen Massenspeicher z.B. bei "/dev/sda" landen.
Henning Paul
Mar 20, 2012, 5:35:44 AM3/20/12
to
Helmut Hullen wrote:
>> Das heißt, Du erzeugst den Deviceknoten erst mit mknod selbst, sobald
>> Du ihn brauchst.
>
> Nein.
>
> Klassisch (ohne udev): ich erzeuge sie vorsorglich schon eine Weile
> vorher. z.B. für das Device "sdq", mit vorsorglich 16 Partitionen.
Und was ist daran besser, als nur die Deviceknoten in /dev/ liegen zu
>> Das heißt, Du erzeugst den Deviceknoten erst mit mknod selbst, sobald
>> Du ihn brauchst.
>
> Nein.
>
> Klassisch (ohne udev): ich erzeuge sie vorsorglich schon eine Weile
> vorher. z.B. für das Device "sdq", mit vorsorglich 16 Partitionen.
haben, "hinter denen" auch tatsächlich vorhandene Blockdevices stecken?
> Ich müsste mal ein wenig mit "fdisk", "dd if=/dev/zero" und "mkfs"
> herumspielen - da kann es haken.
"Deviceknoten /dev/sde1 nicht gefunden"?
Gruß
Henning
Helmut Hullen
Mar 20, 2012, 7:06:00 AM3/20/12
to
Hallo, Henning,
Du meintest am 20.03.12:
Du meintest am 20.03.12:
>>> Das heißt, Du erzeugst den Deviceknoten erst mit mknod selbst,
>>> sobald Du ihn brauchst.
>> Nein.
>>
>> Klassisch (ohne udev): ich erzeuge sie vorsorglich schon eine Weile
>> vorher. z.B. für das Device "sdq", mit vorsorglich 16 Partitionen.
> Und was ist daran besser, als nur die Deviceknoten in /dev/ liegen zu
> haben, "hinter denen" auch tatsächlich vorhandene Blockdevices
> stecken?
Im ersten Durchlauf: nichts. Es ist aber auch nicht schlechter.
>>> sobald Du ihn brauchst.
>> Nein.
>>
>> Klassisch (ohne udev): ich erzeuge sie vorsorglich schon eine Weile
>> vorher. z.B. für das Device "sdq", mit vorsorglich 16 Partitionen.
> Und was ist daran besser, als nur die Deviceknoten in /dev/ liegen zu
> haben, "hinter denen" auch tatsächlich vorhandene Blockdevices
> stecken?
Auf meinen Rechnern liegen sehr viele Dateien, die ich seit der
Installation niemals benutzt habe - na und?
Nur als Beispiel: "/sbin/detectups" - meine APC-USV braucht das Programm
nicht, die anderen USVs hier im Rechnerzoo auch nicht. Na und?
>> Ich müsste mal ein wenig mit "fdisk", "dd if=/dev/zero" und "mkfs"
>> herumspielen - da kann es haken.
> Was ist besser an "Blockdevice /dev/sde1 antwortet nicht" als an
> "Deviceknoten /dev/sde1 nicht gefunden"?
lästig.
--------------------------
Eben habe ich meinen Masochismus mal wieder gepflegt und ausprobiert,
wie Knoppix 6.3 und Artistx 1.1 (Ubuntu-Fork) damit umgehen.
Maschine ohne SCSI-Platten gebootet, anschliessend die SCSI-Platten
hinzugeschaltet. Weder Knoppix noch Artistx hat sie erkannt (bei Artistx
könnte es sein, dass das System sich trotzdem irgendwie verhedderte; die
1. SATA-Platte tauchte plötzlich doppelt auf).
"udev" ist damit also nicht zurechtgekommen. Und auch "dmesg" zeigte
nichts an.
Wenn ich das bei meiner Slackware-Installation mache, ohne "udev" und
mit vorher definierten Einträgen unterhalb von "/dev": kein Problem.
Sieghard Schicktanz
Mar 20, 2012, 5:18:50 PM3/20/12
to
Hallo Helmut,
Du schriebst am 20 Mar 2012 08:40:00 +0100:
> > Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device" genau
> > ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist das das
> > physische Gerät selber, ist das der logische "Anknüpfungspunkt"
> > Geräte-Knoten (device node)?
>
> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
D.h. der _Geräte-Knoten_ (device node). Der wird aber vom Kernel erzeugt,
auf Veranlassung des Treibers, der auch den Namen vergibt (bzw. dem der
Name vom Programmierer vorgegeben ist). Z.B.:
device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR, port->number),
NULL, "parport%d", port->number);
> Und da versucht "udev", für jedes weitere Gerät (hier: Platte) sowie für
> deren (erkannte) Partitionen je einen (immerwährenden) Eintrag ins
> Verzeichnis "/dev" zu packen.
Ähh - was ist jetzt _darunter_ zu verstehen? Was soll da einen
"(immerwährende[r]) Eintrag" darstellen?
(Wie kann in einem tmpfs ein Eintrag überhaupt "immerwährend" sein?)
> Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich mit
> etlichen SCSI-, PATA- und SATA-Platten herum.
Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel einen
solchen transient angelegten Geräte-Knoten wieder, wenn das Gerät wieder
entfernt wird. Das geht natürlich nicht, wenn das Gerät entfernt wird,
während die Maschine ausgeschaltet ist.
Das gilt im übrigen auch für die angelegten Links.
Du schriebst am 20 Mar 2012 08:40:00 +0100:
> > Hier erhebt sich die (bange) Frage, _was_ für Dich ein "Device" genau
> > ist: ist das der Eintrittspunkt in den Kernel-Treiber, ist das das
> > physische Gerät selber, ist das der logische "Anknüpfungspunkt"
> > Geräte-Knoten (device node)?
>
> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
auf Veranlassung des Treibers, der auch den Namen vergibt (bzw. dem der
Name vom Programmierer vorgegeben ist). Z.B.:
device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR, port->number),
NULL, "parport%d", port->number);
> Und da versucht "udev", für jedes weitere Gerät (hier: Platte) sowie für
> deren (erkannte) Partitionen je einen (immerwährenden) Eintrag ins
> Verzeichnis "/dev" zu packen.
"(immerwährende[r]) Eintrag" darstellen?
(Wie kann in einem tmpfs ein Eintrag überhaupt "immerwährend" sein?)
> Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich mit
> etlichen SCSI-, PATA- und SATA-Platten herum.
solchen transient angelegten Geräte-Knoten wieder, wenn das Gerät wieder
entfernt wird. Das geht natürlich nicht, wenn das Gerät entfernt wird,
während die Maschine ausgeschaltet ist.
Das gilt im übrigen auch für die angelegten Links.
Helmut Hullen
Mar 21, 2012, 3:05:00 AM3/21/12
to
Hallo, Sieghard,
Du meintest am 20.03.12:
>> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
> D.h. der _Geräte-Knoten_ (device node). Der wird aber vom Kernel
> erzeugt, auf Veranlassung des Treibers, der auch den Namen vergibt
> (bzw. dem der Name vom Programmierer vorgegeben ist). Z.B.:
> device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR,
> port->number), NULL, "parport%d", port->number);
Meine Kernel erzeugen so etwas nicht. So etwas pflege ich (wenn der
Eintrag nicht sowieso seit vielen Jahren existiert) von Hand anzulegen,
meistens mit dem Programm "MAKEDEV", notfalls mit "mknod".
>> Und da versucht "udev", für jedes weitere Gerät (hier: Platte) sowie
>> für deren (erkannte) Partitionen je einen (immerwährenden) Eintrag
>> ins Verzeichnis "/dev" zu packen.
> Ähh - was ist jetzt _darunter_ zu verstehen? Was soll da einen
> "(immerwährende[r]) Eintrag" darstellen?
> (Wie kann in einem tmpfs ein Eintrag überhaupt "immerwährend" sein?)
"/dev/" ist nicht zwingend als "tmpfs" angelegt. Bei meinen
Installationen sind die Einträge dauerhafte Einträge im Verzeichnis "/
dev", seit mehr als 15 Jahren.
Kernel-Konfiguration (seit etlichen Jahren):
CONFIG_DETMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
>> Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich
>> mit etlichen SCSI-, PATA- und SATA-Platten herum.
> Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
> einen solchen transient angelegten Geräte-Knoten wieder,
Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind, insbesondere
"udev" und "tmpfs".
Du meintest am 20.03.12:
>> In diesem Umfeld: ein Eintrag unterhalb von "/dev", der z.B. mit
> D.h. der _Geräte-Knoten_ (device node). Der wird aber vom Kernel
> erzeugt, auf Veranlassung des Treibers, der auch den Namen vergibt
> (bzw. dem der Name vom Programmierer vorgegeben ist). Z.B.:
> device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR,
> port->number), NULL, "parport%d", port->number);
Eintrag nicht sowieso seit vielen Jahren existiert) von Hand anzulegen,
meistens mit dem Programm "MAKEDEV", notfalls mit "mknod".
>> Und da versucht "udev", für jedes weitere Gerät (hier: Platte) sowie
>> für deren (erkannte) Partitionen je einen (immerwährenden) Eintrag
>> ins Verzeichnis "/dev" zu packen.
> Ähh - was ist jetzt _darunter_ zu verstehen? Was soll da einen
> "(immerwährende[r]) Eintrag" darstellen?
> (Wie kann in einem tmpfs ein Eintrag überhaupt "immerwährend" sein?)
Installationen sind die Einträge dauerhafte Einträge im Verzeichnis "/
dev", seit mehr als 15 Jahren.
Kernel-Konfiguration (seit etlichen Jahren):
CONFIG_DETMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
>> Ist bei einem meiner Rechner ausgesprochen lästig, an dem spiele ich
>> mit etlichen SCSI-, PATA- und SATA-Platten herum.
> Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
> einen solchen transient angelegten Geräte-Knoten wieder,
"udev" und "tmpfs".
Sieghard Schicktanz
Mar 21, 2012, 4:11:03 PM3/21/12
to
Hallo Helmut,
Du schriebst am 21 Mar 2012 08:05:00 +0100:
> > device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR,
> > port->number), NULL, "parport%d", port->number);
>
> Meine Kernel erzeugen so etwas nicht. So etwas pflege ich (wenn der
Doch, Deine Kernel erzeugen sowas auch.
> Eintrag nicht sowieso seit vielen Jahren existiert) von Hand anzulegen,
> meistens mit dem Programm "MAKEDEV", notfalls mit "mknod".
Nein, das obige kannst Du nicht per mknod anlegen - das ist eine interne
Datenstruktur des Kernels, die lediglich durch den Geräte-Knoten eine
Schnittstelle für Anwendungen zugeordnet bekommt.
> > Ähh - was ist jetzt _darunter_ zu verstehen? Was soll da einen
> > "(immerwährende[r]) Eintrag" darstellen?
> > (Wie kann in einem tmpfs ein Eintrag überhaupt "immerwährend" sein?)
>
> "/dev/" ist nicht zwingend als "tmpfs" angelegt. Bei meinen
Noch nicht, jedenfalls. Aber es wird wohl nicht mehr lange dauern, das
"devtmpfs" mountet der Kernel schon selber, wenn er so eingerichtet ist.
> Kernel-Konfiguration (seit etlichen Jahren):
> CONFIG_DETMPFS=y
^VT
> > Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
> > einen solchen transient angelegten Geräte-Knoten wieder,
>
> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind, insbesondere
> "udev" und "tmpfs".
Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind Deine /dev-
Einträge doch eher _nicht_ transient, sondern von _Dir_ angelegt.
(Ich bin mir da eher nicht sicher, weil ich schon länger keine festen
Einträge mehr benutze. Aber vielleicht weiß hier wer anders was definitves.)
Du schriebst am 21 Mar 2012 08:05:00 +0100:
> > device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR,
> > port->number), NULL, "parport%d", port->number);
>
> Meine Kernel erzeugen so etwas nicht. So etwas pflege ich (wenn der
> Eintrag nicht sowieso seit vielen Jahren existiert) von Hand anzulegen,
> meistens mit dem Programm "MAKEDEV", notfalls mit "mknod".
Datenstruktur des Kernels, die lediglich durch den Geräte-Knoten eine
Schnittstelle für Anwendungen zugeordnet bekommt.
> > Ähh - was ist jetzt _darunter_ zu verstehen? Was soll da einen
> > "(immerwährende[r]) Eintrag" darstellen?
> > (Wie kann in einem tmpfs ein Eintrag überhaupt "immerwährend" sein?)
>
> "/dev/" ist nicht zwingend als "tmpfs" angelegt. Bei meinen
"devtmpfs" mountet der Kernel schon selber, wenn er so eingerichtet ist.
> Kernel-Konfiguration (seit etlichen Jahren):
> CONFIG_DETMPFS=y
> # CONFIG_DEVTMPFS_MOUNT is not set
Ja, solange's das noch gibt. ;-)
> > Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
> > einen solchen transient angelegten Geräte-Knoten wieder,
>
> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind, insbesondere
> "udev" und "tmpfs".
Einträge doch eher _nicht_ transient, sondern von _Dir_ angelegt.
(Ich bin mir da eher nicht sicher, weil ich schon länger keine festen
Einträge mehr benutze. Aber vielleicht weiß hier wer anders was definitves.)
Henning Paul
Mar 22, 2012, 3:35:30 AM3/22/12
to
Sieghard Schicktanz wrote:
> Du schriebst am 21 Mar 2012 08:05:00 +0100:
>
>> > device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR,
>> > port->number), NULL, "parport%d", port->number);
>>
>> Meine Kernel erzeugen so etwas nicht. So etwas pflege ich (wenn der
>
> Doch, Deine Kernel erzeugen sowas auch.
>
>> Eintrag nicht sowieso seit vielen Jahren existiert) von Hand
>> anzulegen, meistens mit dem Programm "MAKEDEV", notfalls mit "mknod".
>
> Nein, das obige kannst Du nicht per mknod anlegen - das ist eine
> interne Datenstruktur des Kernels, die lediglich durch den
> Geräte-Knoten eine Schnittstelle für Anwendungen zugeordnet bekommt.
Der Kerneltreiber teilt dem Kernel mit, dass mit ihm ab jetzt über
> Du schriebst am 21 Mar 2012 08:05:00 +0100:
>
>> > device_create(ppdev_class, port->dev, MKDEV(PP_MAJOR,
>> > port->number), NULL, "parport%d", port->number);
>>
>> Meine Kernel erzeugen so etwas nicht. So etwas pflege ich (wenn der
>
> Doch, Deine Kernel erzeugen sowas auch.
>
>> Eintrag nicht sowieso seit vielen Jahren existiert) von Hand
>> anzulegen, meistens mit dem Programm "MAKEDEV", notfalls mit "mknod".
>
> Nein, das obige kannst Du nicht per mknod anlegen - das ist eine
> interne Datenstruktur des Kernels, die lediglich durch den
> Geräte-Knoten eine Schnittstelle für Anwendungen zugeordnet bekommt.
Device-Major PP_MAJOR und Device-Minor port->number kommuniziert werden
kann und dass sein Vorschlag für einen damit verbundenen Deviceknoten
parport"port->number" ist. Der Kernel würde jetzt udev anweisen, einen
Deviceknoten mit eben diesem Namen und diesem Major/Minor zu erstellen.
udev kann das nun tun oder ignorieren.
Oder es gibt schon einen Deviceknoten mit exakt dem Major/Minor. Wie der
heißt, ist eigentlich auch egal, er wird trotzdem funktionieren.
>> > Ähh - was ist jetzt _darunter_ zu verstehen? Was soll da einen
>> > "(immerwährende[r]) Eintrag" darstellen?
>> > (Wie kann in einem tmpfs ein Eintrag überhaupt "immerwährend"
>> > sein?)
>>
>> "/dev/" ist nicht zwingend als "tmpfs" angelegt. Bei meinen
>
> Noch nicht, jedenfalls. Aber es wird wohl nicht mehr lange dauern, das
> "devtmpfs" mountet der Kernel schon selber, wenn er so eingerichtet
> ist.
Anführungsstrichen, weil es sich um ein Pseudodateisystem wie /proc oder
/sys handelt.)
>> > Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
>> > einen solchen transient angelegten Geräte-Knoten wieder,
>>
>> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind,
>> insbesondere "udev" und "tmpfs".
>
> Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind Deine
> /dev- Einträge doch eher _nicht_ transient, sondern von _Dir_
> angelegt.
virtuell.
Gruß
Henning
Helmut Hullen
Mar 22, 2012, 3:21:00 AM3/22/12
to
Hallo, Sieghard,
Du meintest am 21.03.12:
>>> Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
>>> einen solchen transient angelegten Geräte-Knoten wieder,
>> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind,
>> insbesondere "udev" und "tmpfs".
> Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind Deine
> /dev- Einträge doch eher _nicht_ transient, sondern von _Dir_
> angelegt.
Und die werden (wenn z.B. "udev" werkelt) überschrieben/überdeckt, weil
dann das "tmpfs" /dev drübergemountet wird.
Du meintest am 21.03.12:
>>> Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
>>> einen solchen transient angelegten Geräte-Knoten wieder,
>> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind,
>> insbesondere "udev" und "tmpfs".
> Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind Deine
> /dev- Einträge doch eher _nicht_ transient, sondern von _Dir_
> angelegt.
dann das "tmpfs" /dev drübergemountet wird.
Helmut Hullen
Mar 22, 2012, 3:26:00 AM3/22/12
to
Hallo, Henning,
Du meintest am 19.03.12:
>> Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich
>> habe hier mehr als 30 Festplatten für solche Basteleien. Und dann
>> will ich nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der
>> u.a. steht, dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse
>> "/dev/sdq" und die 32-GByte-CFcard heisse "/dev/sdw".
> Mir scheint, Du hast die Funktionsweise von udev bis heute nicht
> verstanden. Der _Kernel_ wird die Blockdevices immer bei sda anfangen
> durchzunummerieren. Wenn Du keine 23 Blockdevices _gleichzeitig_ in
> Betrieb hast, wird niemals ein sdw auftauchen.
Irgendwann werde ich das noch mal mit einigen USB-Sticks testen. Kern
dieses speziellen Problems ist ja, was mit den bisherigen Namen
passiert, wenn das von "udev" dahin eingetragene Gerät wieder
abgestöpselt wird und irgendwann später ein anderes Gerät angestöpselt
wird. Bei Laptops o.ä. wird das mögliche Problem faktisch irgendwann
durch Neustart nebenher gelöst.
Du meintest am 19.03.12:
>> Ja - ich wechsle des öfteren mal Festplatten gegen andere aus; ich
>> habe hier mehr als 30 Festplatten für solche Basteleien. Und dann
>> will ich nicht auch noch eine Umsetz-Tabelle benutzen müssen, in der
>> u.a. steht, dass "udev" meint, die 4,3-GByte-SCSI-Platte heisse
>> "/dev/sdq" und die 32-GByte-CFcard heisse "/dev/sdw".
> Mir scheint, Du hast die Funktionsweise von udev bis heute nicht
> verstanden. Der _Kernel_ wird die Blockdevices immer bei sda anfangen
> durchzunummerieren. Wenn Du keine 23 Blockdevices _gleichzeitig_ in
> Betrieb hast, wird niemals ein sdw auftauchen.
dieses speziellen Problems ist ja, was mit den bisherigen Namen
passiert, wenn das von "udev" dahin eingetragene Gerät wieder
abgestöpselt wird und irgendwann später ein anderes Gerät angestöpselt
wird. Bei Laptops o.ä. wird das mögliche Problem faktisch irgendwann
durch Neustart nebenher gelöst.
Henning Paul
Mar 22, 2012, 6:27:46 AM3/22/12
to
Helmut Hullen wrote:
> Irgendwann werde ich das noch mal mit einigen USB-Sticks testen. Kern
> dieses speziellen Problems ist ja, was mit den bisherigen Namen
> passiert, wenn das von "udev" dahin eingetragene Gerät wieder
> abgestöpselt wird und irgendwann später ein anderes Gerät angestöpselt
> wird.
Dann wird der Bezeichner recyclet.
> Irgendwann werde ich das noch mal mit einigen USB-Sticks testen. Kern
> dieses speziellen Problems ist ja, was mit den bisherigen Namen
> passiert, wenn das von "udev" dahin eingetragene Gerät wieder
> abgestöpselt wird und irgendwann später ein anderes Gerät angestöpselt
> wird.
Gruß
Henning
Sieghard Schicktanz
Mar 22, 2012, 4:28:06 PM3/22/12
to
Hallo Helmut,
Du schriebst am 22 Mar 2012 08:21:00 +0100:
> >>> Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
> >>> einen solchen transient angelegten Geräte-Knoten wieder,
>
> >> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind,
> >> insbesondere "udev" und "tmpfs".
>
> > Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind Deine
> > /dev- Einträge doch eher _nicht_ transient, sondern von _Dir_
> > angelegt.
>
> Und die werden (wenn z.B. "udev" werkelt) überschrieben/überdeckt, weil
> dann das "tmpfs" /dev drübergemountet wird.
Ja, wenn Du das machst - aber nach Deinen Worten machst Du das doch
garnicht.
Entschließ' Dich halt mal, über was für Voraussetzungen Du diskutieren
willst, damit man auch ein Thema hat.
Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
_nicht_ transient und werden von udev auch nicht gelöscht, wenn sie schon
vorhanden waren.
Wenn Du das aber für udev mit einem (dev)tmpfs übermountest und dort die
entsprechenden Einträge angelegt werden, dann können die Geräte damit
trotzdem ganz genauso angesprochen werden wie zuvor - das ist ein etwas
anderes Verhalten als das für "normale" Dateien auf einer Platte, die nach
dem Übermounten nicht mehr zugänglich sind. Geräteknoten sind eben keine
normalen Dateien, sondern eher Zugriffsstrukturen für Kernelschnittstellen.
Du schriebst am 22 Mar 2012 08:21:00 +0100:
> >>> Dann machst Du wohl etwas falsch. Üblicherweise löscht der Kernel
> >>> einen solchen transient angelegten Geräte-Knoten wieder,
>
> >> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind,
> >> insbesondere "udev" und "tmpfs".
>
> > Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind Deine
> > /dev- Einträge doch eher _nicht_ transient, sondern von _Dir_
> > angelegt.
>
> Und die werden (wenn z.B. "udev" werkelt) überschrieben/überdeckt, weil
> dann das "tmpfs" /dev drübergemountet wird.
garnicht.
Entschließ' Dich halt mal, über was für Voraussetzungen Du diskutieren
willst, damit man auch ein Thema hat.
Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
_nicht_ transient und werden von udev auch nicht gelöscht, wenn sie schon
vorhanden waren.
Wenn Du das aber für udev mit einem (dev)tmpfs übermountest und dort die
entsprechenden Einträge angelegt werden, dann können die Geräte damit
trotzdem ganz genauso angesprochen werden wie zuvor - das ist ein etwas
anderes Verhalten als das für "normale" Dateien auf einer Platte, die nach
dem Übermounten nicht mehr zugänglich sind. Geräteknoten sind eben keine
normalen Dateien, sondern eher Zugriffsstrukturen für Kernelschnittstellen.
Helmut Hullen
Mar 23, 2012, 3:24:00 AM3/23/12
to
Hallo, Sieghard,
Du meintest am 22.03.12:
>>>> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind,
>>>> insbesondere "udev" und "tmpfs".
>>
>>> Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind
>>> Deine /dev- Einträge doch eher _nicht_ transient, sondern von _Dir_
>>> angelegt.
>> Und die werden (wenn z.B. "udev" werkelt) überschrieben/überdeckt,
>> weil dann das "tmpfs" /dev drübergemountet wird.
> Ja, wenn Du das machst - aber nach Deinen Worten machst Du das doch
> garnicht.
Eben - die sind bei meinem System dauerhaft.
> Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
> _nicht_ transient und werden von udev auch nicht gelöscht, wenn sie
> schon vorhanden waren.
"udev" mountet sein tmpfs-"/dev" drüber. Die dauerhaften Einträge sind
also noch immer vorhanden, aber sie sind nicht mehr benutzbar, weil sie
vom tmpfs-"/dev" überdeckt werden.
> Wenn Du das aber für udev mit einem (dev)tmpfs übermountest
Das macht "udev", ohne mich zu fragen.
> und dort die entsprechenden Einträge angelegt werden,
"udev" legt dort nur dann Einträge an, wenn es "irgendwie" die
zugehörigen Geräte gefunden hat.
Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten später
einschalte, dann bekommt "udev" davon nichts mit. Anders als mein
übliches System ohne "udev".
> dann können die Geräte damit trotzdem ganz genauso angesprochen werden
> wie zuvor - das ist ein etwas anderes Verhalten als das für "normale"
> Dateien auf einer Platte, die nach dem Übermounten nicht mehr
> zugänglich sind.
Was "udev" nicht wahrnimmt, wird von "udev" (natürlich) nicht angelegt.
Du meintest am 22.03.12:
>>>> Wenn viele weitere Nebenbedingungen ebenfalls erfüllt sind,
>>>> insbesondere "udev" und "tmpfs".
>>
>>> Bist Du Dir da wirklich völlig sicher? Nach Deinen Worten sind
>>> Deine /dev- Einträge doch eher _nicht_ transient, sondern von _Dir_
>>> angelegt.
>> Und die werden (wenn z.B. "udev" werkelt) überschrieben/überdeckt,
>> weil dann das "tmpfs" /dev drübergemountet wird.
> Ja, wenn Du das machst - aber nach Deinen Worten machst Du das doch
> garnicht.
> Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
> _nicht_ transient und werden von udev auch nicht gelöscht, wenn sie
> schon vorhanden waren.
also noch immer vorhanden, aber sie sind nicht mehr benutzbar, weil sie
vom tmpfs-"/dev" überdeckt werden.
> Wenn Du das aber für udev mit einem (dev)tmpfs übermountest
> und dort die entsprechenden Einträge angelegt werden,
zugehörigen Geräte gefunden hat.
Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten später
einschalte, dann bekommt "udev" davon nichts mit. Anders als mein
übliches System ohne "udev".
> dann können die Geräte damit trotzdem ganz genauso angesprochen werden
> wie zuvor - das ist ein etwas anderes Verhalten als das für "normale"
> Dateien auf einer Platte, die nach dem Übermounten nicht mehr
> zugänglich sind.
Henning Paul
Mar 23, 2012, 4:36:14 AM3/23/12
to
Helmut Hullen wrote:
>> Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
>> _nicht_ transient und werden von udev auch nicht gelöscht, wenn sie
>> schon vorhanden waren.
>
> "udev" mountet sein tmpfs-"/dev" drüber. Die dauerhaften Einträge sind
> also noch immer vorhanden, aber sie sind nicht mehr benutzbar, weil
> sie vom tmpfs-"/dev" überdeckt werden.
>
>> Wenn Du das aber für udev mit einem (dev)tmpfs übermountest
>
> Das macht "udev", ohne mich zu fragen.
Nein. Ein tmpfs käme aus der fstab, das devtmpfs wird in der
>> Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
>> _nicht_ transient und werden von udev auch nicht gelöscht, wenn sie
>> schon vorhanden waren.
>
> "udev" mountet sein tmpfs-"/dev" drüber. Die dauerhaften Einträge sind
> also noch immer vorhanden, aber sie sind nicht mehr benutzbar, weil
> sie vom tmpfs-"/dev" überdeckt werden.
>
>> Wenn Du das aber für udev mit einem (dev)tmpfs übermountest
>
> Das macht "udev", ohne mich zu fragen.
Kernelkonfig festgelegt. udev kann auch mit einem "stinknormalen" /dev-
Verzeichnis im root-Dateisystem umgehen. Es ist nur schöner, wenn man
nach einem Reboot mit einer "sauberen" Grundlage anfangen kann.
>> und dort die entsprechenden Einträge angelegt werden,
>
> "udev" legt dort nur dann Einträge an, wenn es "irgendwie" die
> zugehörigen Geräte gefunden hat.
Deviceknoten!) angelegt worden ist.
> Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
> Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten später
> einschalte, dann bekommt "udev" davon nichts mit. Anders als mein
> übliches System ohne "udev".
Hostadapter? Auf dem "udev"-System tut sich im dmesg-Output nichts nach
dem Einschalten der Devices? Dann kann nämlich auch gar nichts
passieren. WIMRE war das immer der Normalfall, dass zum Neuerkennen von
SCSI-Devices ein manueller Busrescan ausgelöst werden muss (und ich
kenne es auch nicht anders aus meinen U(2)W-SCSI-Zeiten). Kann natürlich
auch sein, das jüngere SCSI-HA beim Einsatz eines passenden Treibers an
den Kernel signalisieren können, dass Devices hinzugekommen sind.
Gruß
Henning
Helmut Hullen
Mar 23, 2012, 5:40:00 AM3/23/12
to
Hallo, Henning,
Du meintest am 23.03.12:
>> Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
>> Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten
>> später einschalte, dann bekommt "udev" davon nichts mit. Anders als
>> mein übliches System ohne "udev".
> Und in den beiden verwendest Du denselben Kernel und denselben
> Hostadapter?
Hardware: identisch.
Kernel: natürlich unterschiedlich, schon weil ich bei meinem Kernel
(ohne "udev") die Option
# CONFIG_DEVTMPFS_MOUNT is not set
eingestellt habe.
> Auf dem "udev"-System tut sich im dmesg-Output nichts
> nach dem Einschalten der Devices?
Nichts.
> Dann kann nämlich auch gar nichts
> passieren. WIMRE war das immer der Normalfall, dass zum Neuerkennen
> von SCSI-Devices ein manueller Busrescan ausgelöst werden muss (und
> ich kenne es auch nicht anders aus meinen U(2)W-SCSI-Zeiten).
Ja - scheint ("im Prinzip") immer noch so zu sein. Bei meinem System
ohne "udev" funktioniert das bestens, bei meinen beiden Versuchen mit
Knoppix sowie Artistx hat der Aufruf des entsprechenden Scripts (hier:
"scanscsi", bei einigen anderen Distributionen z.B. "scan_scsi") nichts
geändert.
> Kann natürlich auch sein, das jüngere SCSI-HA beim Einsatz eines
> passenden Treibers an den Kernel signalisieren können, dass Devices
> hinzugekommen sind.
Mag sein - hier werkelt ein Adaptec AIC-7892A. Und der wird bei allen
Versuchen brav erkannt.
Du meintest am 23.03.12:
>> Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
>> Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten
>> später einschalte, dann bekommt "udev" davon nichts mit. Anders als
>> mein übliches System ohne "udev".
> Und in den beiden verwendest Du denselben Kernel und denselben
> Hostadapter?
Kernel: natürlich unterschiedlich, schon weil ich bei meinem Kernel
(ohne "udev") die Option
# CONFIG_DEVTMPFS_MOUNT is not set
> Auf dem "udev"-System tut sich im dmesg-Output nichts
> nach dem Einschalten der Devices?
> Dann kann nämlich auch gar nichts
> passieren. WIMRE war das immer der Normalfall, dass zum Neuerkennen
> von SCSI-Devices ein manueller Busrescan ausgelöst werden muss (und
> ich kenne es auch nicht anders aus meinen U(2)W-SCSI-Zeiten).
ohne "udev" funktioniert das bestens, bei meinen beiden Versuchen mit
Knoppix sowie Artistx hat der Aufruf des entsprechenden Scripts (hier:
"scanscsi", bei einigen anderen Distributionen z.B. "scan_scsi") nichts
geändert.
> Kann natürlich auch sein, das jüngere SCSI-HA beim Einsatz eines
> passenden Treibers an den Kernel signalisieren können, dass Devices
> hinzugekommen sind.
Versuchen brav erkannt.
Michael Baeuerle
Mar 23, 2012, 6:21:57 AM3/23/12
to
Henning Paul wrote:
des Hosts via AER (Asynchronous Event Reporting) moeglich. Das gibt es
schon seit SCSI2 (damals hiess es noch AEN) und ist u.a. auch fuer
diesen Zweck vorgesehen. Zitat aus der Spec:
|
| The asynchronous event notification protocol may be used to notify
| processor devices that a system resource has become available.
> WIMRE war das immer der Normalfall, dass zum Neuerkennen von
> SCSI-Devices ein manueller Busrescan ausgelöst werden muss (und ich
> kenne es auch nicht anders aus meinen U(2)W-SCSI-Zeiten).
Ja, die Zahl der Geraete die AER unterstuetzen duerfte sehr
ueberschaubar sein. Ein kompletter Bus-Scan muss aber nicht sein wenn
man die Adresse weiss, bei Linux kann man ja schon ewig SCSI devices
einzeln an- und abmelden.
> Kann natürlich
> auch sein, das jüngere SCSI-HA beim Einsatz eines passenden Treibers an
> den Kernel signalisieren können, dass Devices hinzugekommen sind.
Das reicht nicht. Zuerst muss der HA ja selbst erfahren, dass Devices
hinzugekommen sind. Wenn die ihm das nicht via AER sagen, kriegt er das
nicht mit.
Die Krueckenloesung ohne AER waere pauschal alle paar Sekunden einen
kompletten Bus-Scan zu machen. Das ist aber ein Performancekiller erster
Guete. Speziell wenn man alle LUNs abfragt und den Timeout auf die
empfohlenen 250ms setzt dauert das eine mittlere Ewigkeit (und der Bus
ist auch noch jedesmal 250ms lang blockiert wenn niemand antwortet).
Micha
> Helmut Hullen wrote:
> >
> > Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
> > Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten später
> > einschalte, dann bekommt "udev" davon nichts mit. Anders als mein
> > übliches System ohne "udev".
>
> Und in den beiden verwendest Du denselben Kernel und denselben
> Hostadapter? Auf dem "udev"-System tut sich im dmesg-Output nichts nach
> dem Einschalten der Devices? Dann kann nämlich auch gar nichts
> passieren.
Doch es koennte, zumindest auf dem Papier waere eine Benachrichtigung
> >
> > Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
> > Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten später
> > einschalte, dann bekommt "udev" davon nichts mit. Anders als mein
> > übliches System ohne "udev".
>
> Und in den beiden verwendest Du denselben Kernel und denselben
> Hostadapter? Auf dem "udev"-System tut sich im dmesg-Output nichts nach
> dem Einschalten der Devices? Dann kann nämlich auch gar nichts
> passieren.
des Hosts via AER (Asynchronous Event Reporting) moeglich. Das gibt es
schon seit SCSI2 (damals hiess es noch AEN) und ist u.a. auch fuer
diesen Zweck vorgesehen. Zitat aus der Spec:
|
| The asynchronous event notification protocol may be used to notify
| processor devices that a system resource has become available.
> WIMRE war das immer der Normalfall, dass zum Neuerkennen von
> SCSI-Devices ein manueller Busrescan ausgelöst werden muss (und ich
> kenne es auch nicht anders aus meinen U(2)W-SCSI-Zeiten).
ueberschaubar sein. Ein kompletter Bus-Scan muss aber nicht sein wenn
man die Adresse weiss, bei Linux kann man ja schon ewig SCSI devices
einzeln an- und abmelden.
> Kann natürlich
> auch sein, das jüngere SCSI-HA beim Einsatz eines passenden Treibers an
> den Kernel signalisieren können, dass Devices hinzugekommen sind.
hinzugekommen sind. Wenn die ihm das nicht via AER sagen, kriegt er das
nicht mit.
Die Krueckenloesung ohne AER waere pauschal alle paar Sekunden einen
kompletten Bus-Scan zu machen. Das ist aber ein Performancekiller erster
Guete. Speziell wenn man alle LUNs abfragt und den Timeout auf die
empfohlenen 250ms setzt dauert das eine mittlere Ewigkeit (und der Bus
ist auch noch jedesmal 250ms lang blockiert wenn niemand antwortet).
Micha
Sieghard Schicktanz
Mar 23, 2012, 4:51:39 PM3/23/12
to
Hallo Helmut,
Du schriebst am 23 Mar 2012 08:24:00 +0100:
> > Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
> > _nicht_ transient und werden von udev auch nicht gelöscht, wenn sie
> > schon vorhanden waren.
>
> "udev" mountet sein tmpfs-"/dev" drüber. Die dauerhaften Einträge sind
udev mountet nix drüber - _wenn_ da was drübergemountet wird, dann macht
das das Start-Skript oder gleich der Kernel selber, wenn er so konfiguriert
ist. Aber letzteres hast Du ja abgestellt.
(Ich hatte hier vor kurzem das Problem, daß nach einem Update das Start-
Skript ein _devtmpfs_ verlangt hat, ich das aber im Kernel abgestellt
hatte. udev hat daraufhin versucht, ins plattenresidente /dev zu schreiben,
was aber wegen read-only-mount nicht ging. Folge war Panikanfall beim
Kernel...)
> > Wenn Du das aber für udev mit einem (dev)tmpfs übermountest
>
> Das macht "udev", ohne mich zu fragen.
Nein, das macht wahrscheinlich das Start-Skript von udev oder eins, das
vorher läuft.
> "udev" legt dort nur dann Einträge an, wenn es "irgendwie" die
> zugehörigen Geräte gefunden hat.
>
> Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
> Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten später
> einschalte, dann bekommt "udev" davon nichts mit. Anders als mein
Ja, dann hat udev davon eben nicht mitgekriegt. D.h. der Treiber hat kein
Ereignis für udev ausgelöst.
> übliches System ohne "udev".
Dann benutzt der Treiber eben "einfach" den passenden schon existierenden
Geräteknoten, so vorhanden.
> Was "udev" nicht wahrnimmt, wird von "udev" (natürlich) nicht angelegt.
Richtig. Geht aber anderen genauso... ;->
Du schriebst am 23 Mar 2012 08:24:00 +0100:
> > Jedenfalls sind Einträge in einem plattenresidenten /dev-Verzeichnis
> > _nicht_ transient und werden von udev auch nicht gelöscht, wenn sie
> > schon vorhanden waren.
>
> "udev" mountet sein tmpfs-"/dev" drüber. Die dauerhaften Einträge sind
das das Start-Skript oder gleich der Kernel selber, wenn er so konfiguriert
ist. Aber letzteres hast Du ja abgestellt.
(Ich hatte hier vor kurzem das Problem, daß nach einem Update das Start-
Skript ein _devtmpfs_ verlangt hat, ich das aber im Kernel abgestellt
hatte. udev hat daraufhin versucht, ins plattenresidente /dev zu schreiben,
was aber wegen read-only-mount nicht ging. Folge war Panikanfall beim
Kernel...)
> > Wenn Du das aber für udev mit einem (dev)tmpfs übermountest
>
> Das macht "udev", ohne mich zu fragen.
vorher läuft.
> "udev" legt dort nur dann Einträge an, wenn es "irgendwie" die
> zugehörigen Geräte gefunden hat.
>
> Unlängst habe ich das ausprobiert: wenn ich "udev" laufen lasse, den
> Rechner erst mal ohne SCSI-Platten starte und die SCSI-Platten später
> einschalte, dann bekommt "udev" davon nichts mit. Anders als mein
Ereignis für udev ausgelöst.
> übliches System ohne "udev".
Geräteknoten, so vorhanden.
> Was "udev" nicht wahrnimmt, wird von "udev" (natürlich) nicht angelegt.
Helmut Hullen
Mar 24, 2012, 2:24:00 AM3/24/12
to
Hallo, Sieghard,
Du meintest am 23.03.12:
>> "udev" mountet sein tmpfs-"/dev" drüber. Die dauerhaften Einträge
>> sind
> udev mountet nix drüber - _wenn_ da was drübergemountet wird, dann
> macht das das Start-Skript oder gleich der Kernel selber, wenn er so
> konfiguriert ist. Aber letzteres hast Du ja abgestellt.
> (Ich hatte hier vor kurzem das Problem, daß nach einem Update das
> Start- Skript ein _devtmpfs_ verlangt hat, ich das aber im Kernel
> abgestellt hatte. udev hat daraufhin versucht, ins plattenresidente
> /dev zu schreiben, was aber wegen read-only-mount nicht ging. Folge
> war Panikanfall beim Kernel...)
Ok - diese Variante hatte ich noch nicht getestet.
Aber in der Gegend dieses Problems müsste ich gewesen sein, bei meiner
Kernel-Konfiguration steht nicht ohne Grund, dass "DEVTMPFS" gesetzt
ist, nur "DEVTMPFS_MOUNT" nicht.
Du meintest am 23.03.12:
>> "udev" mountet sein tmpfs-"/dev" drüber. Die dauerhaften Einträge
>> sind
> udev mountet nix drüber - _wenn_ da was drübergemountet wird, dann
> macht das das Start-Skript oder gleich der Kernel selber, wenn er so
> konfiguriert ist. Aber letzteres hast Du ja abgestellt.
> (Ich hatte hier vor kurzem das Problem, daß nach einem Update das
> Start- Skript ein _devtmpfs_ verlangt hat, ich das aber im Kernel
> abgestellt hatte. udev hat daraufhin versucht, ins plattenresidente
> /dev zu schreiben, was aber wegen read-only-mount nicht ging. Folge
> war Panikanfall beim Kernel...)
Aber in der Gegend dieses Problems müsste ich gewesen sein, bei meiner
Kernel-Konfiguration steht nicht ohne Grund, dass "DEVTMPFS" gesetzt
ist, nur "DEVTMPFS_MOUNT" nicht.
0 new messages