mdev hotplug mit fester Zuordnung auf einen Device-Namen

[rgrr]

Hallo zusammen,

folgendes Problem:

• ich habe eine USB-Festplatte an der FB hängen,
• diese Festplatte legt sich nach kurzer Zeit schlafen (hdparm -B 1 /dev/sda),
• schläft die Platte nur kurz, so kommt sie nach ein paar Sekunden wieder hoch und alles ist in Ordnung
• schläft die Platte über einen langen Zeitraum (ein paar Stunden) und man spricht sie wieder an, so läuft sie hoch, erzeugt aber scheinbar ein hotplug-Event -> die Platte bekommt ein neues Device zugewiesen

Nun meine Fragen:

• wo muss ich im mdev hotplugging drehen, um das Event zu unterdrücken?
• wie debugge ich mdev hotplugging am einfachsten?
• gibt es irgendwo eine Doku der gesetzten Environment-Variablen, die während des hotpluggings gesetzt sind?

Danke & Gruss

Hardy

[olistudent]

Man kann bei mdev einem Device eine feste Zuordnung geben. Das geht über die uuid und da war auch ein Beispiel mit drin!?

MfG Oliver

[rgrr]

...Das geht über die uuid und da war auch ein Beispiel mit drin!?

Danke für den Hinweis, Oliver.

Durch Deine Hilfe bin ich jetzt zu dem Schluss gekommen, dass ich an /etc/fstab noch ein

UUID=ced77156-baa6-478d-9b3f-e9167b97803f /var/media/ftp/uStora1 ext3 noatime,nodiratime 0 1

anhängen muss. Kann ich das temporär machen, ohne im freetz rumzubasteln (z.B. per mount tmpfs o.ä.)?

Hardy

[matze1985]

mount -o bind ist dein stichwort, hält aber nur bis zum nächsten reboot.

[rgrr]

mount -o bind ist dein stichwort...

Danke matze! Wie behält man das alles in einem Kopf?

Hardy

[rgrr]

...Das geht über die uuid und da war auch ein Beispiel mit drin!?

Noch mal zu dem 'Beispiel': meinst Du das in der fstab?

Falls ja: das ist fehlerhaft, da es dort nicht /media/export heissen sollte, sondern /var/media/export.

Jedenfalls bei mir schlägt der 'mkdir -p /media/export' fehl, da /media nicht existiert. 'mkdir /var/media/export' funktioniert aber.

Kann man nachvollziehen, indem man unter /var einen Link xxx in die Leere erzeugt und dann ein 'mkdir -p /var/xxx/yyy/zzz' versucht (schlägt fehl).

Hardy



PS: jetzt muss ich das nur noch mit der fsmod_custom hinbekommen, so dass ich meinen Mountpoint persistent habe. Kann mir da vielleicht jemand eine Starthilfe geben?

[cando]

Bei Linux ist es

/media/...

bei Fritz ist das unter

/var/media/...

Wahrscheinlich wegen den Flash speicher / SquashFS

[matze1985]

Was willst du denn mit der fwmod_custom machen? Was willst du dort verändern lassen?

[rgrr]

Was willst du denn mit der fwmod_custom machen?...

Ich möchte in der fwmod_custom drinstehen haben, dass meine fstab immer um den Eintrag für meine Festplatte mit UUID-mount ergänzt wird.

Da es hier extrem wenige Beispiele für die fwmod_custom gibt würde mich mal interessieren, was es

• da für Konventionen gibt (z.B. mit sed/echo Dateien ändern/ergänzen)
• wie ist fwmod_custom im Makefile integriert?:
  
  • wird nach einer Änderung in fwmod_custom das image neu gebaut?
  • wann genau im build-Prozess wird die fwmod_custom ausgeführt?

Für ein paar Beispiele wäre ich dankbar, für die weiteren Fragen würde mir eine kleine Starthilfe genügen, wo ich graben muss.

Danke & Gruss

Hardy

[rgrr]

Man kann bei mdev einem Device eine feste Zuordnung geben...

Hallo zusammen,

meine fstab enthält den entsprechenden UUID-Eintrag. So richtig froh bin ich über das Verhalten aber immer noch nicht.

Kleine Zusammenfassung:

• die Platte wird beim Hochfahren korrekt erkannt und gemountet
• ich schicke die Platte schalfen per 'hdparm -B 127 /dev/sda' (spindown)
• schläft die Platte nur kurz, wacht sie auch wieder schön auf (spinup)
• schläft die Platte über einen längeren Zeitraum (über Nacht), so wird sie beim Aufwecken nicht mehr als /dev/sda1 erkannt, sondern über Hotplug als /dev/sdb1 neu eingehängt

Hier mal der Zustand nach einem langen Schlaf aber vor dem Aufwecken:

/var/mod/root # mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
mdev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw)
devshm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
proc on /proc type proc (rw,nosuid,nodev,noexec)
tmpfs on /var type tmpfs (rw)
/dev/mtdblock5 on /data type jffs2 (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /var/media/export type ext3 (rw,noatime,nodiratime,data=ordered)
/dev/loop0 on /var/plugin-mediasrv type squashfs (ro)
/dev/loop1 on /var/plugin-mini type squashfs (ro)
/dev/loop2 on /var/plugin-ntfs type squashfs (ro)
/dev/loop3 on /var/plugin-samba type squashfs (ro)
/var/mod/root # cat /proc/partitions 
major minor  #blocks  name

  31     0      14851 mtdblock0
  31     1        893 mtdblock1
  31     2        128 mtdblock2
  31     3        256 mtdblock3
  31     4        256 mtdblock4
  31     5       6400 mtdblock5
   7     0        200 loop0
   7     1        424 loop1
   7     2        120 loop2
   7     3        364 loop3
   8     0  244198584 sda
   8     1  244196001 sda1

Dann wecke ich die Platte auf und bekomme folgendes:

/var/mod/root # cd ~rsync
/var/media/export/rsync # ls -ls
ls: ./linux: Input/output error
ls: ./hardy: No such file or directory
ls: ./maren: No such file or directory
ls: ./rsyncd.conf: No such file or directory
ls: ./rsyncd.secrets: No such file or directory
ls: ./rsyncd.log: No such file or directory
 608 -rwxr-xr-x    1 root     root       617796 Dec 11 22:28 rsync
/var/media/export/rsync # cat /dev/debug
/proc/tffs: info request: success
musb_host_rx 1498: AVM CRC Error fix: count=1 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=2 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=3 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=4 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=5 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=6 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=7 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=8 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=9 RXCSR 2204 (0/4096)bytes received
musb_host_rx 1498: AVM CRC Error fix: count=10 RXCSR 2204 (0/4096)bytes received
end_request: I/O error, dev sda, sector 304087191
EXT3-fs error (device sda1): ext3_get_inode_loc: 
scsi 0:0:0:0: rejecting I/O to dead device
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
scsi 0:0:0:0: rejecting I/O to dead device
EXT3-fs error (device sda1): ext3_find_entry: 
scsi 0:0:0:0: rejecting I/O to dead device
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
scsi 0:0:0:0: rejecting I/O to dead device
EXT3-fs error (device sda1): ext3_find_entry: 
scsi 0:0:0:0: rejecting I/O to dead device
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
scsi 0:0:0:0: rejecting I/O to dead device
EXT3-fs error (device sda1): ext3_find_entry: 
scsi 0:0:0:0: rejecting I/O to dead device
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
scsi 0:0:0:0: rejecting I/O to dead device
EXT3-fs error (device sda1): ext3_find_entry: 
scsi 0:0:0:0: rejecting I/O to dead device
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
scsi 0:0:0:0: rejecting I/O to dead device
EXT3-fs error (device sda1): ext3_find_entry: 
scsi 0:0:0:0: rejecting I/O to dead device
Buffer I/O error on device sda1, logical block 0
lost page write due to I/O error on sda1
cat: read error: Broken pipe

Aua! Der syslog sagt:

Feb  6 20:40:02 fritz local0.info usbcontrol[1757]: remove 1-1.1.1  
Feb  6 20:40:02 fritz local0.info usbcontrol[1757]: 1-1.1.1 transparent scsi mass storage device
Feb  6 20:40:02 fritz user.warn kernel: unable to read inode block - inode=9502880, block=38010891reading directory #9428993 offset 0reading directory #9428993 offset 0reading directory #9428993 offset 0
Feb  6 20:40:02 fritz user.info kernel: reading directory #9428993 offset 0reading directory #9428993 offset 0
Feb  6 20:40:02 fritz local0.info mdevmodule[1748]: remove module chain sg sd_mod
Feb  6 20:40:09 fritz local0.info usbcontrol[1790]: add 1-1.1.1 05e3 USB Storage
Feb  6 20:40:09 fritz local0.info usbcontrol[1790]: 1-1.1.1 transparent scsi mass storage device
Feb  6 20:40:17 fritz local0.info partition[1869]: starting e2fsck on '/dev/sdb1'
Feb  6 20:40:18 fritz local0.info partition[1869]: fritz.box: recovering journal fritz.box: clean, 601334/15269888 files, 17854936/61049000 blocks
Feb  6 20:40:18 fritz local0.info partition[1869]: mounted 'UUID=ced77156-baa6-478d-9b3f-e9167b97803f' to a user configured mountpoint
Feb  6 20:40:19 fritz local0.info partition[1869]: starting 'S80.rsync.sh'...

Und weiterhin sieht der Zustand so aus:

/var/mod/root # mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
mdev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw)
devshm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
proc on /proc type proc (rw,nosuid,nodev,noexec)
tmpfs on /var type tmpfs (rw)
/dev/mtdblock5 on /data type jffs2 (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /var/media/export type ext3 (rw,noatime,nodiratime,data=ordered)
/dev/loop0 on /var/plugin-mediasrv type squashfs (ro)
/dev/loop1 on /var/plugin-mini type squashfs (ro)
/dev/loop2 on /var/plugin-ntfs type squashfs (ro)
/dev/loop3 on /var/plugin-samba type squashfs (ro)
/dev/sdb1 on /var/media/export type ext3 (rw,noatime,nodiratime,data=ordered)
/var/mod/root # cat /proc/partitions 
major minor  #blocks  name

  31     0      14851 mtdblock0
  31     1        893 mtdblock1
  31     2        128 mtdblock2
  31     3        256 mtdblock3
  31     4        256 mtdblock4
  31     5       6400 mtdblock5
   7     0        200 loop0
   7     1        424 loop1
   7     2        120 loop2
   7     3        364 loop3
   8    16  244198584 sdb
   8    17  244196001 sdb1

Die Platte hat sich also wohl halb abgemeldet und dann beim Hochfahren ein weiteres Mal eingehängt.

Hat das Phänomen schon mal jemand gehabt und weiss vielleicht Abhilfe?

Danke & Gruss

Hardy

[matze1985]

hey,

die fwmod_custom wird beim jedem make ausgeführt und zwar ziemlich am Ende kurz bevor die FW wiedergepackt wird, also nachdem alle anderen Änderungen von Freetz vollzogen wurden.

Wie der Anfange der fwmod_custom schon zeigt:

#!/bin/bash

# Custom firmware modifications

# Directories:
#  ./firmware	- untared firmware
#  ./filesystem	- unpacked filesystem squashfs
#  ./kernel	- unpacked kernel & hidden kernel squashfs
all() {

Wird diese aus dem Verziechnis build/modified aufgerufen und das entsprechende Unterverzeichnis in das du musst ist ./filesystem. Um die fstab zu erweitern könnte man also sowas schreiben:

#!/bin/bash

# Custom firmware modifications

# Directories:
#  ./firmware	- untared firmware
#  ./filesystem	- unpacked filesystem squashfs
#  ./kernel	- unpacked kernel & hidden kernel squashfs

all() {
	echo "FWMOD_CUSTOM  ################################"
	echo "Customizing fstab"
	
	echo "UUID=ced77156-baa6-478d-9b3f-e9167b97803f /var/media/ftp/uStora1 ext3 noatime,nodiratime 0 1"  >> ./filesystem/etc/fstab

	echo "FWMOD_CUSTOM  ################################"
}

Wie du also siehst musst du alle deine Befehle in den all() { ... } Bereich schreiben, ich habe jetzt nur Sachen kopiert, anpassen musst du sie, da ich die fstab nicht benutze.
Ich übernehme also keine Haftung, dass soll nur zeigen wie die fwmod_custom funktioniert!

edit: Die Ausgaben wie echo "FWMOD_CUSTOM ################################" mache ich nur damit ich sehe wann und ob sie Ausgeführt werden, musst du nicht.

[rgrr]

...die fwmod_custom wird beim jedem make ausgeführt und zwar ziemlich am Ende kurz bevor die FW wiedergepackt wird, also nachdem alle anderen Änderungen von Freetz vollzogen wurden...

Hai matze,

Danke für die Erläuterungen. Demnach brauche ich also keine Bedenken zu haben, dass meine fwmod_custom zweimal auf die fstab angewendet wird? Oder sollte ich doch vorher mit einem grep prüfen, ob mein Eintrag in der fstab schon existiert?

Danke & Gruss

Hardy


PS: jetzt brauche ich nur noch was zu dem eigentlichen Problem des doppelten mounts

[matze1985]

ne da brauchst du keine Angst haben.

[rgrr]

Hallo zusammen,

jetzt habe ich zur Problematik einen Link gefunden: http://www.nslu2-linux.org/wiki/FAQ/...agateFreeAgent

Auf der FB finde ich auch unter /sys/class/scsi_disk/0:0:0:0/ ein allow_restart.

Wenn ich ins Verzeichnis wechsel und ein 'echo 1>allow_restart' mache, scheint alles ok. Allerdings bringt der 'cat allow_restart' eine 0.

Weiss jemand Rat, ob das von Bedeutung ist? (ich habe den Parameter jetzt auf alle Fälle gesetzt und meine Platte schlafen geschickt. Mal gucken, was morgen ist...)

Hardy

[matze1985]

versuche mal ein

echo "1" > allow_restart

Bei mir zeigt dann ein cat auch die 1 an.

[rgrr]

versuche mal ein

echo "1" > allow_restart

...

Hi matze,

vielen Dank für den Tipp! Nach längerem Nachdenken bin ich auch darauf gekommen, warum das so ist ("echo 1|hexdump -C" liefert nämlich das erwartete): durch das "echo 1>datei" habe ich eine Leerzeile an stdout geschickt.

Man lernt halt nie aus...

Hardy


PS: jetzt warte ich auf alle Fälle, was die Platte nach dem nächsten Langschlaf macht...

[RalfFriedl]

Man braucht nicht unbedingt die Anführungszeichen, er reicht auch ein Abstand zwischen 1 und >

echo 1 > datei
echo 1> datei

Im ersten Fall (mit Leerzeichen) wird "1\n" in die Datei geschrieben. Im zweiten Fall wird nur "\n" (Zeilenumbruch) in die Datei geschrieben.

In keinem Fall sollte der Zeilenumbruch/Leerzeile auf stdout herauskommen (es sei denn, "datei" bezieht sich auf stdout).

[Silent-Tears]

Können wir uns auf die Anführungszeichen einigen? Obiges geht vielleicht, führt auch zum Ziel, wie eben viele Wege nach Rom führen, allerdings sollte man sich da auf eine Methode festlegen, denke ich und da die Fehlerunanfälligste wählen.
Dies wäre dann meines Erachtens

echo "1" > filename

LG

[rgrr]

...In keinem Fall sollte der Zeilenumbruch/Leerzeile auf stdout herauskommen (es sei denn, "datei" bezieht sich auf stdout).

Sorry, da war ich wohl ein wenig unvollständig, soll heissen: der Zeilenumbruch geht nach stdout (1>) und stdout wird umgeleitet in "datei".

Hardy


PS: aber lustig ist die Syntax da schon. Wo steht nämlich, dass in "datei" umgeleitet wird? Dass der Linefeed nach stdout geht, steht ja da, aber mehr eigentlich nicht...

[RalfFriedl]

Was ist da lustig, bzw. was steht wo nicht?

echo > datei
echo 1> datei

Die beiden Konstruktionen mit ">" bzw. "1>" haben beide genau die gleiche Wirkung. Deswegen ist es nicht üblich "1>" zu schreiben, sondern die kürzere Form ">". Dagegen sieht man häufiger "2>", weil in diesem Fall die 2 notwendig ist.

Das Linefeed kommt vom "echo"-Befehl und die Umleitung sorgt dafür, daß es in der Datei landet.