Unable to handle kernel paging request at virtual address...

[doodie]

Hi,

seit ein paar Wochen betreibe ich einen FTP-Server (Debian Woody), bei dem häufig Neue Benutzer erstellt, andere gelöscht und viele scriptgesteuert (Perl) aktualisiert werden. Dazu verwende ich diese Shell-Befehle:

Code: Select all

useradd
userdel
usermod

Seit dem bekomme ich immer wieder Fehlermeldungen wie

Code: Select all

usermod: [username] not found in /etc/passwd
usermod: [username] not found in /etc/shadow

Das habe ich dann mit vipw erledigt, indem ich den Benutzer gelöscht und manuell nochmal angelegt habe. Bevor ich die Lösung mit vipw gefunden habe, dachte ich, dass der nscd-Cache möglicherweise nicht richtig geleert wird und da am Wochenende auf dem Server wenig los ist, habe ich ihn einfach mal neu gestartet (shutdown -r now). Leider ist der Server nicht mehr hochgefahren und musste per Reset-Knopf nochmal neu gestartet werden - in der /var/log/kernel.log stand folgendes drin:

Code: Select all

Nov 27 18:59:48 ftp kernel: Unable to handle kernel paging request at virtual address 723a8150
Nov 27 18:59:48 ftp kernel: printing eip:
Nov 27 18:59:48 ftp kernel: c0145697
Nov 27 18:59:48 ftp kernel: *pde = 00000000
Nov 27 18:59:48 ftp kernel: Oops: 0000
Nov 27 18:59:48 ftp kernel: CPU: 0
Nov 27 18:59:48 ftp kernel: EIP: 0010:[remove_inode_dquot_ref+63/124] Not tainted
Nov 27 18:59:48 ftp kernel: EFLAGS: 00010202
Nov 27 18:59:48 ftp kernel: eax: 00000002 ebx: 723a8120 ecx: d6116d90 edx: d6116e74
Nov 27 18:59:48 ftp kernel: esi: f507df4c edi: f6ec1800 ebp: f507df4c esp: f507df18
Nov 27 18:59:48 ftp kernel: ds: 0018 es: 0018 ss: 0018
Nov 27 18:59:48 ftp kernel: Process quotaoff (pid: 11336, stackpage=f507d000)
Nov 27 18:59:48 ftp kernel: Stack: d6116d98 f6ec1884 c01420e1 d6116d90 00000000 f507df4c 00000000 f6ec1884
Nov 27 18:59:48 ftp kernel: 00000000 f6ec1800 f6ec1860 f6ec1868 00000009 f5c788a0 f23a8de0 c0146725
Nov 27 18:59:48 ftp kernel: f6ec1800 00000000 00006000 00000200 00000000 f507dfa4 f6ec189c 00006000
Nov 27 18:59:48 ftp kernel: Call Trace: [remove_dquot_ref+109/300] [quota_off+137/224] [sys_quotactl+508/787] [sys_munmap+52/
60] [system_call+51/56]
Nov 27 18:59:48 ftp kernel:
Nov 27 18:59:48 ftp kernel: Code: 8b 43 30 83 f8 01 75 27 74 0e 50 68 60 83 2c c0 e8 a4 00 fd
Nov 27 18:59:48 ftp kernel: Kernel logging (proc) stopped.
Nov 27 18:59:48 ftp kernel: Kernel log daemon terminating.

So ganz im Allgemeinen läuft die Kiste ziemlich buggy und ich habe den Verdacht, das vielleicht mit dem Arbeitsspeicher was nicht stimmen könnte - ist das möglich? Oder die Festplatte? Weiss vielleicht jemand was mit den Eintragungen aus der kernel.log was anzufangen?

Ciao
nd

<edit>
PS: Hab' mir gerade nochmal ein paar Benutzer, die schon wieder buggy sind, via vipw genau angesehen und festgestellt, dass aus irgend einem Grund deren Zeile in der /etc/passwd und / oder /etc/shadow ziemlich zerschossen ist, weil z.B. anstatt einem Doppelpunkt ein z als Spaltentrenner reingeschrieben wurde... Misteriös...
</edit>

[kase]

Sieht mir fast etwas nach einem defekten Filesystem / einer defekten Festplatte aus, aber warte lieber noch mal auf Aussagen von welchen, die sich mit so Sachen etwas besser auskennen.

Zumindest die korrupten Files und das mehrfache Auftauchen von "inode" und "ref" im Panic sieht IMHO etwas danach aus.

[tally]

War denn die Kiste zu Beginn stabil, sprich hast Du einen vernünftigen BurnIn-Test laufen lassen, z.B. mit parallelen Kernel-Compiles, bevor Du sie produktiv eingesetzt hast? Ansonsten kann es eigentlich alles sein: defekter CPU-Lüfter, RAM, HD usw.

tally

[tally]

Ach ja, wenn die Hardware einigermaßen aktuell ist und Du keinen direkten Zugriff auf die Hardware haben solltest, kannst Du ja mal mit lm_sensors und den smartmontools schauen, ob Du etwas auffälliges siehst.

BTW, das Subject halte ich nicht für besonders glücklich, keine Disti läuft auf kaputter Hardware stabil.

tally

[doodie]

Hi!

@kase:
ACK - ein paar Sachen bzgl. FS stehen da drin... Aber ob das was zu bedeuten hat (bzw. was) ist halt jetzt die Frage.

@tally:
Das Subject ist zustande gekommen, nachdem ich feststellte, dass ich massig Probleme mit dem Usermanagement habe und ich im WWW diverse Informationen über Fehler in useradd etc. gefunden habe. Okay, ich werd's ändern, falls das noch geht...

Die smartmontools habe ich gerade installiert und einen Test mit

Code: Select all

smartctl -s on -t long /dev/hda >smartctl.log

gestartet. Ich hoffe, er schreibt mir das Testergebnis irgendwie in die Datei rein, falls meine SSH-Verbindung zwischendurch gekillt wird. So gegen 18 Uhr ist er fertig, sagt er mir...

Auf die Hardware habe ich leider keinen Zugriff, aber (einigermaßen) aktuell sein sollte sie schon.

> BurnIn-Test laufen lassen, z.B. mit parallelen Kernel-Compiles

Wa??? Da muss ich passen... Aber ich denke für die Zukunft werde ich mir ein paar Tests einfallen lassen, bevor ich mit so'ner Kiste produktiv an den Start gehe. Die Probleme hatte ich von Anfang an, wurden nur in den letzten Tagen häufiger.

Ich hoffe mal, dass die Festplatte in Ordnung ist, sonst bekomme ich die Kriese, weil

a) ca. 40 GB Daten drauf sind und die erstmal gesichert sein wollen

b) ich bei einem Festplattentausch wohl das komplette System neu installieren darf und der Server wohl ein paar Stunden bis Tage offline sein wird - das zu argumentieren ist halt für mich etwas schwierig...

Bin ja im Grunde selbst schuld, wenn's soweit kommt. Also ich melde mich wieder hier an dieser Stelle sobald der Test geschafft ist oder ich irgendwelche anderen Ergebnisse habe. Bis dahin dankeschön und

ciao
nd

[tally]

@doodie

Ã?h, das habe ich nicht explizit geschrieben aber das sollte doch eigentlich klar sein: wenn Du wichtige Daten auf dem System und kein Backup hast, dann ist jetzt definitiv nicht der richtige Zeitpunkt für Tests. Dann heißt es als allererstes Daten sichern. Mit jeder Aktivität riskierst Du das Dateien verändert werden bzw. Daten teilweise oder ganz verloren gehen.

Mit den smartmontools hättest Du Dir eigentlich nur das Errorlog der HD ansehen sollen.

tally

[doodie]

Hi tally,

na klar - passt scho'... Bei dem Server ist es nicht sooo dringend alle Daten zu sichern, bevor ich einen Befehl eintippe. Jetzt mal so auf die Schnelle 40 Gig übers Netz zu schieben ist halt auch eine Zeit- / Kostenfrage... Bevor ich bewusst wirklich kritische Aktionen starte, überleg' ich's mir nochmal mit der Dasi.

Also

Code: Select all

smartctl -a /dev/hda

gibt mir (nachdem ich noch schnell einen kurzen Selbsttest gestartet habe):

Code: Select all

smartctl version 5.26 Copyright (C) 2002-3 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     SAMSUNG SV1203N
Serial Number:    S01CJ10X643436
Firmware Version: TQ100-24
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 0
Local Time is:    Sun Nov 28 17:58:37 2004 CET

==> WARNING: Contact developers at smartmontools-support@lists.sourceforge.net; may need -F samsung[2] enabled.


SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity was
					never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		 (5400) seconds.
Offline data collection
capabilities: 			 (0x1b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					No Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					No General Purpose Logging support.
Short self-test routine 
recommended polling time: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 (  90) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0007   253   253   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   253   253   000    Old_age   Always       -       0
  5 Reallocated_Sector_Ct   0x0033   253   253   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0024   253   253   000    Old_age   Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       4828
 10 Spin_Retry_Count        0x0013   253   253   049    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   253   253   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   133   133   000    Old_age   Always       -       35
195 Hardware_ECC_Recovered  0x000a   100   100   000    Old_age   Always       -       8536321
196 Reallocated_Event_Count 0x0012   253   253   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0033   253   253   010    Pre-fail  Always       -       0
198 Offline_Uncorrectable   0x0031   253   253   010    Pre-fail  Offline      -       0
199 UDMA_CRC_Error_Count    0x000b   253   253   051    Pre-fail  Always       -       0
200 Multi_Zone_Error_Rate   0x000b   100   100   051    Pre-fail  Always       -       0
201 Soft_Read_Error_Rate    0x000b   100   100   051    Pre-fail  Always       -       0

SMART Error Log Version: 1
Warning: ATA error count 4608 inconsistent with error log pointer 5

ATA Error Count: 4608 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Timestamp = decimal seconds since the previous disk power-on.
Note: timestamp "wraps" after 2^32 msec = 49.710 days.

Error 4608 occurred at disk power-on lifetime: 39 hours
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 00 00 4f c2 e0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Timestamp  Command/Feature_Name
  -- -- -- -- -- -- -- --   ---------  --------------------
  b0 da 00 00 4f c2 e0 00   81983.625  SMART RETURN STATUS
  20 00 08 fb 7e 1b eb 00   81983.625  READ SECTOR(S)
  20 00 f8 03 7e 1b eb 00   81983.563  READ SECTOR(S)
  ec 00 00 02 7e 1b e0 00   81983.563  IDENTIFY DEVICE
  20 00 08 fb 7d 1b eb 00   81983.563  READ SECTOR(S)

Error 4607 occurred at disk power-on lifetime: 18 hours
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 00 01 4f c2 a0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Timestamp  Command/Feature_Name
  -- -- -- -- -- -- -- --   ---------  --------------------
  b0 d9 00 01 4f c2 a0 00       8.313  SMART DISABLE OPERATIONS
  ec 00 ff 01 00 00 a0 00       8.313  IDENTIFY DEVICE
  10 00 ff 01 00 00 a0 00       8.313  RECALIBRATE [OBS-4]
  91 00 ff 01 00 00 af 00       8.313  INITIALIZE DEVICE PARAMETERS [OBS-6]
  ec 00 ff 01 00 00 a0 00       8.313  IDENTIFY DEVICE

Error 4606 occurred at disk power-on lifetime: 18 hours
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 00 01 4f c2 a0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Timestamp  Command/Feature_Name
  -- -- -- -- -- -- -- --   ---------  --------------------
  b0 d9 00 01 4f c2 a0 00       8.313  SMART DISABLE OPERATIONS
  ec 00 ff 01 00 00 a0 00       8.313  IDENTIFY DEVICE
  10 00 ff 01 00 00 a0 00       8.313  RECALIBRATE [OBS-4]
  91 00 ff 01 00 00 af 00       8.313  INITIALIZE DEVICE PARAMETERS [OBS-6]
  ec 00 ff 01 00 00 a0 00       8.313  IDENTIFY DEVICE

Error 4605 occurred at disk power-on lifetime: 18 hours
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 00 01 4f c2 a0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Timestamp  Command/Feature_Name
  -- -- -- -- -- -- -- --   ---------  --------------------
  b0 d9 00 01 4f c2 a0 00       8.500  SMART DISABLE OPERATIONS
  ec 00 ff 01 00 00 a0 00       8.500  IDENTIFY DEVICE
  10 00 ff 01 00 00 a0 00       8.500  RECALIBRATE [OBS-4]
  91 00 ff 01 00 00 af 00       8.500  INITIALIZE DEVICE PARAMETERS [OBS-6]
  ec 00 ff 01 00 00 a0 00       8.438  IDENTIFY DEVICE

Error 4604 occurred at disk power-on lifetime: 18 hours
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 00 01 4f c2 a0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Timestamp  Command/Feature_Name
  -- -- -- -- -- -- -- --   ---------  --------------------
  b0 d9 00 01 4f c2 a0 00   70983.500  SMART DISABLE OPERATIONS
  ec 00 ff 01 00 00 a0 00   70983.500  IDENTIFY DEVICE
  10 00 ff 01 00 00 a0 00   70983.500  RECALIBRATE [OBS-4]
  91 00 ff 01 00 00 af 00   70983.500  INITIALIZE DEVICE PARAMETERS [OBS-6]
  ec 00 ff 01 00 00 a0 00   70983.500  IDENTIFY DEVICE

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%        40         -

Zugegeben, das sagt mir auch nicht sooo viel, sieht aber für meine Begriffe recht gut aus!?

Ciao
nd

PS: Okay, dass in smartctl.log nicht viel drin stehen wird, hab' ich jetzt auch gerafft Kann es sein, dass mein erster long-Test gar nicht gestartet wurde? Der steht nämlich nicht in der Liste am Ende der Ausgabe...

[tally]

@doodie

Du wirst schon wissen was Du tust.

Die HD scheint wohl i.O. zu sein. Wenn Du einen kleinen Streßtest haben willst, kannst Du den hier probieren. Das Boardmitglied Walsleben kann damit seinen Rooti ziemlich schnell zum Absturz bringen. Die Zeile macht einen rekursiven ls auf / und übergibt das Ergebnis direkt an bzip2 zum packen. Je nach Prozessanzahl erzeugt es eine ganz nette Last und läuft auch ins swap. Die Schleifenzahl liegt standardmäßig auf 3 und Du kannst sie nach Deinem Gefühl erhöhen. Verfolgen kannst Du alles mit top.

Code: Select all

typeset -i i=0 ; while [ $((i++)) -lt 3 ] ; do ls -laR / 2>&1 | bzip2 -qf9 - > lslaR$i.bz2 & done

Ob Du diesen Test risikierst mußt Du selbst entscheiden und verantworten ;-)

tally

[doodie]

Hi tally,

wissen was man tut ist meistens irgendwo relativ (btw wissen was frau tut häufig auch ). Also ich traue mich mal und starte erstmal die 3...

...

Was denn, schon fertig? Das war zu schnell. 50...

...

Der Server ist seinen Preis wert :-D 99...

...
...

Hmmmm... top:

Code: Select all

Mem:    900080K total,   862408K used,    37672K free,    28632K buffers

Hmmmm... 500...

...
...
...
...
...
...

Hoppla:

Code: Select all

bzip2: Caught a SIGSEGV or SIGBUS whilst compressing.

   Possible causes are (most likely first):
   (1) This computer has unreliable memory or cache hardware
       (a surprisingly common problem; try a different machine.)
   (2) A bug in the compiler used to create this executable
       (unlikely, if you didn't compile bzip2 yourself.)
   (3) A real bug in bzip2 -- I hope this should never be the case.
   The user's manual, Section 4.3, has more info on (1) and (2).

   If you suspect this is a bug in bzip2, or are unsure about (1)
   or (2), feel free to report it to me at: jseward@acm.org.
   Section 4.3 of the user's manual describes the info a useful
   bug report should have.  If the manual is available on your
   system, please try and read it before mailing me.  If you don't
   have the manual or can't be bothered to read it, mail me anyway.

Und was später:

Code: Select all

bzip2/libbzip2: internal error number 1007.
This is a bug in bzip2/libbzip2, 1.0.2, 30-Dec-2001.
Please report it to me at: jseward@acm.org.  If this happened
when you were using some program which uses libbzip2 as a
component, you should also report this bug to the author(s)
of that program.  Please make an effort to report this bug;
timely and accurate bug reports eventually lead to higher
quality software.  Thanks.  Julian Seward, 30 December 2001.

[52] 23800

*** A special note about internal error number 1007 ***

Experience suggests that a common cause of i.e. 1007
is unreliable memory or other hardware.  The 1007 assertion
just happens to cross-check the results of huge numbers of
memory reads/writes, and so acts (unintendedly) as a stress
test of your memory system.

I suggest the following: try compressing the file again,
possibly monitoring progress in detail with the -vv flag.

* If the error cannot be reproduced, and/or happens at different
  points in compression, you may have a flaky memory system.
  Try a memory-test program.  I have used Memtest86
  (www.memtest86.com).  At the time of writing it is free (GPLd).
  Memtest86 tests memory much more thorougly than your BIOSs
  power-on test, and may find failures that the BIOS doesn't.

* If the error can be repeatably reproduced, this is a bug in
  bzip2, and I would very much like to hear about it.  Please
  let me know, and, ideally, save a copy of the file causing the
  problem -- without which I will be unable to investigate it.

Liegt das jetzt an bzip2 oder der Maschine??? Mein Verdacht auf defekten Arbeitsspeicher verhärtet sich langsam. Test mit 500 läuft noch...

Ciao
nd

<edit>
Hmmmm... Zum Thema Swap (jetzt so ca. bei 285):

Code: Select all

Mem:    900080K total,   892840K used,     7240K free,    19520K buffers
Swap:        0K total,        0K used,        0K free,     8884K cached

</edit>

[tally]

Ist bestimmt ein Hardwareproblem. Aber wo das Problem genau liegt ist dann meistens sehr schwer zu lokalisieren und vor allem sehr zeitaufwendig. Defektes RAM, überhitztes RAM, defekter/verschmutzter CPU-Lüfter, allgemein zu hohe Umgebungstemperatur usw. Auf jeden Fall keine schöne Sache.

tally

[tally]

Code: Select all

Mem:    900080K total,   892840K used,     7240K free,    19520K buffers
Swap:        0K total,        0K used,        0K free,     8884K cached

Hast Du gar keinen swap aktiviert?

tally

[doodie]

Hi tally,

ok, also die 500 hat er jetzt gestartet und auf zwei SSH Konsolen läuft top - aber nicht wirklich. Mit einer dritten Konsole versuche ich mich gerade anzumelden, aber irgendwie dauert das ewig (warum nur? ). Die Frage ist jetzt, ob der Server komplett steht, oder sich nochmal wieder erholt - Ping geht jedenfalls noch und SSH hat auch noch keine Konsole wegen unterbrochener Verbindung gekillt...

Also wenn Du auch von einem Hardware-Problem überzeugt bist, will ich es jetzt mal mit einem Arbeitsspeicher-Test probieren. Nun ist es ja so, dass memtest86 beim Booten läuft!? Ich habe das Tool noch nie ausprobiert, bin aber etwas skeptisch, weil da der lilo mit im Spiel ist, und da habe ich mir bei root-Servern mit Recovery-System schonmal die Finger verbrannt.
Wie funktioniert das mit memtest86? Wie komme ich an das Testergebnis, wenn das Tool beim Booten läuft? Gar nicht? Und wie verträgt sich das Tool mit Rechnern von 1&1 oder Server4Free und deren Recovery-Systemen?

Oder gibt es vielleicht noch eine alternative Möglichkeit den Arbeitsspeicher zur Laufzeit (also nach dem Booten) zu testen? Auch wenn das nicht DER 100%ige Test ist, der jeden Staubkrümel auf der Oberfläche des RAM-Bausteins bemängelt - wenn ich nur irgendeine Fehlermeldung bekomme, die eindeutig beweist, dass der Arbeitsspeicher einen Schuss hat, kann ich den Support des Rechenzentrums bemühen...

Auf jeden Fall Dir ein dickes DANKESCHÃ?N für Deine Mühe!

Ciao
nd

[doodie]

Ooops... Da war noch was: Ich habe zum Installieren der Kiste das Script von roothell.org benutzt und dabei auch eine Swap-Partition eingerichtet, wenn ich mich nicht irre... Aber leider kann ich das gerade nicht prüfen, weil ich immer noch nicht wieder auf die Shell komme...

Ciao
nd

<edit>
Also die Kiste reagiert immer noch nicht. Ich muss jetzt mal eben nach Karlsruhe rüberdüsen, bin aber gegen 0 Uhr wieder im Lande und sehe dann auf jeden Fall nochmal nach dem Stand der Dinge...
</edit>

[tally]

@doodie

Ohne swap könnte es ziemlich lange dauern, bis Deine Kiste für Dich wieder verfügbar ist.

Zu memtest86 kann ich Dir nichts sagen, habe ich noch nie benutzt. Mir reichen eigentlich solche Meldungen von bzip2 oder ein "signal 11" beim Kernel-Compile.

tally

[doodie]

Hi tally,

ja, das merke ich gerade... Läuft wohl immer noch - naja, schaumermal, das kann ja nicht ewig dauern. Ich probier mal den Speicher aufgrund dieser Fehlermeldungen austauschen su lassen. Wenn die RZ-Techniker den Speicher getauscht haben und die Probleme nicht verschwunden sein sollten, poste ich hier wohl nochmal - bis dahin: Nochmals vielen Dank und

ciao
nd