Problem beim Sichern per smbmount (mit rsync) von Windowsfreigabe auf Linux (Debian Lenny)
Hi,
wie so oft habe ich mal wieder ein Problem, bei dem ich nicht weiter weiß ...
Mein Netz:
Ein Windowsserver (auf dem meine Nutzdaten liegen)
Ein Linux-Rechner, welcher Dateien sichern soll (per rsync von der Windowsfreigabe)
Mein eigentliches Script (nur als nebeninfo), aber problem kommt jedoch auch bei einem einfachen cp -r
meine fstab:
Nun,
immer passiert es, dass der Rechner einige Minuten im Netzwerk nicht mehr erreichbar ist (per ping) ssh bringt ab (ist ja klar ..) und der Vorgang abbricht, ab und zu startet sich der Rechner neu ...
Beim hochfahren habe ich keine Probleme (ist bisher nie hängen geblieben oder ähnliches)
Der Rechner war einige Zeit nicht in Benutzung ...
Habe leider keine Ahnung, wo ich bei der Fehlersuche anfangen soll ...
Zur Hardware:
P4, 2GB RAM (DDR), 250Gb systemplatte IDE, 500er Datenplatte (Sata), Onboard 100M-Bit, PCI nic: G-Bit
Meine bisherigen Versuche:
1. Die gesteckte G-Bit Netzwerkkarte ausgebaut (und die onboard benutzt)
2. alle angeschlossenen Geräte, welche man nicht benötigt abgeschlossen
3. Mehrfache versuche (mit rsync)
4. versucht aus den logs schlau zu werden ...
auf der Console wurde zwischendurch einmal das hier ausgegeben:
Hier noch die /var/log/syslog (von dem Zeitpunkt):
Die Festplatte habe ich gestern schon getestet, sie scheint keine Fehler zu haben ... (mit dem WD tool)
RAM hatte ich vor ca. 2 Wochen bei einem anderen test getestet, ohne probleme werde es aber zur Sicherheit noch im Ausschlussverfahren mit je einem RAM Riegel testen ...
Mit Linux kenne ich mich leider nicht so gut aus, sonst hätte ich das Problem wahrscheinlich schon gelöst ...
Fällt euch noch etwas ein, was ich testen kann?! --> denke ehrlich gesagt, dass es an dem mount.cifs liegt ... aber denke, dass es auf anderen System wahrscheinlich funktioniert ...
bin für jede Idee dankbar ;)
//edit:
Einmal Nur das erste RAM modul in DIMM-0 getestet, einmal nur das 2. modul in DIMM-2
funktioniert genau so wenig
wie so oft habe ich mal wieder ein Problem, bei dem ich nicht weiter weiß ...
Mein Netz:
Ein Windowsserver (auf dem meine Nutzdaten liegen)
Ein Linux-Rechner, welcher Dateien sichern soll (per rsync von der Windowsfreigabe)
Mein eigentliches Script (nur als nebeninfo), aber problem kommt jedoch auch bei einem einfachen cp -r
rsync -a --delete "/media/orca2/altes_raid/Eigene Dateien" /media/backup/500_1/eigene_dateien/current
cp -al /media/backup/500_1/eigene_dateien/current /media/backup/500_1/eigene_dateien/date +%F_%H:%M
meine fstab:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 errors=remount-ro 0 1
/dev/hda5 none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
/dev/sda1 /media/backup/500_1 ext3 rw 0 0
/dev/sdb1 /media/backup/160er ext3 rw 0 0
//192.168.0.200/altes_raid /media/orca2/altes_raid smbfs username=aaron,password=mein_pw 0 0
Nun,
immer passiert es, dass der Rechner einige Minuten im Netzwerk nicht mehr erreichbar ist (per ping) ssh bringt ab (ist ja klar ..) und der Vorgang abbricht, ab und zu startet sich der Rechner neu ...
Beim hochfahren habe ich keine Probleme (ist bisher nie hängen geblieben oder ähnliches)
Der Rechner war einige Zeit nicht in Benutzung ...
Habe leider keine Ahnung, wo ich bei der Fehlersuche anfangen soll ...
Zur Hardware:
P4, 2GB RAM (DDR), 250Gb systemplatte IDE, 500er Datenplatte (Sata), Onboard 100M-Bit, PCI nic: G-Bit
Meine bisherigen Versuche:
1. Die gesteckte G-Bit Netzwerkkarte ausgebaut (und die onboard benutzt)
2. alle angeschlossenen Geräte, welche man nicht benötigt abgeschlossen
3. Mehrfache versuche (mit rsync)
4. versucht aus den logs schlau zu werden ...
auf der Console wurde zwischendurch einmal das hier ausgegeben:
orca3:~/backupscripts# ./eigene_dateien
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] Process bash (pid: 2700, ti=f7d24000 task=f77804e0 task.ti=f7d24000)
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] Stack: 164020f6 6de6c0c0 167f0c00 000001f7 b2d00000 7d39bc08 c7bc80f7 fd2088f6
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] 000001f6 1665e700 008b28c0 00000000 b2d00000 000cb408 00000100 c7bc8000
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] 100073f6 166a0c00 b2e000c0 10007308 00000000 00000000 008b2d00 7d39bc00
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] Call Trace:
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] =======================
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] Code: 00 00 00 00 8b 52 24 83 ea 24 8b 42 24 0f 18 00 90 8d 42 24 3b 44 24 24 75 e3 8b 54 24 18 f0 fe 42 28 8b 4c 24 10 b8 00 00 00 00 <83> 79 08 00 0f 49 44 24 14 89 44 24 14 83 c4 6c 5b 5e 5f 5d c3
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.713364] EIP: [<c0168d19>] try_to_unmap+0x43c/0x451 SS:ESP 0068:f7d25f0f
Message from syslogd@orca3 at Oct 28 20:21:46 ...
kernel:[ 752.709491] Oops: 0000 [#1] SMP
Hier noch die /var/log/syslog (von dem Zeitpunkt):
Oct 28 20:10:30 orca3 kernel: [ 22.898696] eth1: no IPv6 routers present
Oct 28 20:17:01 orca3 /USR/SBIN/CRON[2657]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 28 20:21:46 orca3 kernel: [ 752.705351] BUG: unable to handle kernel paging request at b2d00008
Oct 28 20:21:46 orca3 kernel: [ 752.709400] IP: [<c0168d19>] try_to_unmap+0x43c/0x451
Oct 28 20:21:46 orca3 kernel: [ 752.709484] *pde = 00000000
Oct 28 20:21:46 orca3 kernel: [ 752.709491] Oops: 0000 [#1] SMP
Oct 28 20:21:46 orca3 kernel: [ 752.709595] Modules linked in: nls_utf8 cifs nls_base ipv6 sbp2 loop serio_raw psmouse pcspkr i2c_i801 rng_core i2c_core snd_hda_intel button snd_pcm snd_timer snd soundcore snd_page_alloc intel_agp agpgart evdev joydev ext3 jbd mbcache sg sr_mod sd_mod cdrom ide_disk ata_piix ata_generic 8139too libata scsi_mod dock usbhid hid ff_memless floppy 8139cp mii ohci1394 ieee1394 ehci_hcd ide_pci_generic piix ide_core uhci_hcd usbcore thermal processor fan thermal_sys [last unloaded: scsi_wait_scan]
Oct 28 20:21:46 orca3 kernel: [ 752.713364]
Oct 28 20:21:46 orca3 kernel: [ 752.713364] Pid: 2700, comm: bash Not tainted (2.6.26-2-686 #1)
Oct 28 20:21:46 orca3 kernel: [ 752.713364] EIP: 0060:[<c0168d19>] EFLAGS: 00010202 CPU: 0
Oct 28 20:21:46 orca3 kernel: [ 752.713364] EIP is at try_to_unmap+0x43c/0x451
Oct 28 20:21:46 orca3 kernel: [ 752.713364] EAX: 00000000 EBX: f6f36cb4 ECX: b2d00000 EDX: c7bc80f7
Oct 28 20:21:46 orca3 kernel: [ 752.713364] ESI: 7ff43067 EDI: c1ffe860 EBP: c16de6cc ESP: f7d25f0f
Oct 28 20:21:46 orca3 kernel: [ 752.713364] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Oct 28 20:21:46 orca3 kernel: [ 752.713364] Process bash (pid: 2700, ti=f7d24000 task=f77804e0 task.ti=f7d24000)
Oct 28 20:21:46 orca3 kernel: [ 752.713364] Stack: 164020f6 6de6c0c0 167f0c00 000001f7 b2d00000 7d39bc08 c7bc80f7 fd2088f6
Oct 28 20:21:46 orca3 kernel: [ 752.713364] 000001f6 1665e700 008b28c0 00000000 b2d00000 000cb408 00000100 c7bc8000
Oct 28 20:21:46 orca3 kernel: [ 752.713364] 100073f6 166a0c00 b2e000c0 10007308 00000000 00000000 008b2d00 7d39bc00
Oct 28 20:21:46 orca3 kernel: [ 752.713364] Call Trace:
Oct 28 20:21:46 orca3 kernel: [ 752.713364] =======================
Oct 28 20:21:46 orca3 kernel: [ 752.713364] Code: 00 00 00 00 8b 52 24 83 ea 24 8b 42 24 0f 18 00 90 8d 42 24 3b 44 24 24 75 e3 8b 54 24 18 f0 fe 42 28 8b 4c 24 10 b8 00 00 00 00 <83> 79 08 00 0f 49 44 24 14 89 44 24 14 83 c4 6c 5b 5e 5f 5d c3
Oct 28 20:21:46 orca3 kernel: [ 752.713364] EIP: [<c0168d19>] try_to_unmap+0x43c/0x451 SS:ESP 0068:f7d25f0f
Oct 28 20:21:46 orca3 kernel: [ 752.717351] ---[ end trace a5a5fbe154da9b87 ]---
Oct 28 20:22:37 orca3 kernel: imklog 3.18.6, log source = /proc/kmsg started.
Die Festplatte habe ich gestern schon getestet, sie scheint keine Fehler zu haben ... (mit dem WD tool)
RAM hatte ich vor ca. 2 Wochen bei einem anderen test getestet, ohne probleme werde es aber zur Sicherheit noch im Ausschlussverfahren mit je einem RAM Riegel testen ...
Mit Linux kenne ich mich leider nicht so gut aus, sonst hätte ich das Problem wahrscheinlich schon gelöst ...
Fällt euch noch etwas ein, was ich testen kann?! --> denke ehrlich gesagt, dass es an dem mount.cifs liegt ... aber denke, dass es auf anderen System wahrscheinlich funktioniert ...
bin für jede Idee dankbar ;)
//edit:
Einmal Nur das erste RAM modul in DIMM-0 getestet, einmal nur das 2. modul in DIMM-2
funktioniert genau so wenig
Please also mark the comments that contributed to the solution of the article
Content-ID: 154016
Url: https://administrator.de/contentid/154016
Printed on: September 7, 2024 at 11:09 o'clock
5 Comments
Latest comment