Nem lehet a /sbin-be beléni ?!

Linux-kezdő

Üdv!

Tegnap amikor be akartam lépni a /sbin könyvtárba ezt írta ki és nem lépett bele:
Nov 9 08:49:14 server kernel: Modules linked in: usbserial parport_pc lp parport af_packet floppy edd freq_table thermal processor fan button battery ac ipt_limit ipt_MASQUERADE iptable_nat ipt_LOG ipt_multiport ipt_state ip_conntrack iptable_filter ip_tables ipv6 evdev joydev sg st sr_mod ehci_hcd uhci_hcd ohci1394 ieee1394 sk98lin dm_mod r8169 usbcore raid1 reiserfs ata_piix libata sd_mod scsi_mod

Akkor nem tudtam mikor írta ki pontosan de ma kétszer próbáltam belépni és kidobta ezt a logot a képernyőre. Eddig nem találtam semmit erről a neten. Találkoztatok már ezzel? Mit tehetek?

Szerk.: ha 'ls -l /sbin' parancsot ütök akkor szintén ez a helyzet.

Megint szerk.: a /bin-el ugyan ez a helyzet.

Megsérült a file rendszer???

  • 791 megtekintés

( budacsik | 2006. 11. 09., cs – 09:15 )

Nov 9 08:56:08 server kernel: <1>Unable to handle kernel NULL pointer dereference at 0000000000000078 RIP:
Nov 9 08:56:08 server kernel: {vfs_getattr+75}
Nov 9 08:56:08 server kernel: PML4 67419067 PGD 6757c067 PMD 0
Nov 9 08:56:08 server kernel: Oops: 0000 [29]
Nov 9 08:56:08 server kernel: CPU 0
Nov 9 08:56:08 server kernel: Modules linked in: usbserial parport_pc lp parport af_packet floppy edd freq_table thermal processor fan button battery ac ipt_limit ipt_MASQUERADE iptable_nat ipt_LOG ipt_multiport ipt_state ip_conntrack iptable_filter ip_tables ipv6 evdev joydev sg st sr_mod ehci_hcd uhci_hcd ohci1394 ieee1394 sk98lin dm_mod r8169 usbcore raid1 reiserfs ata_piix libata sd_mod scsi_mod
Nov 9 08:56:08 server kernel: Pid: 12211, comm: mc Tainted: G U (2.6.8-24-default )
Nov 9 08:56:08 server kernel: RIP: 0010:[] {vfs_getattr+75}
Nov 9 08:56:08 server kernel: RSP: 0018:00000100656a7e38 EFLAGS: 00010246
Nov 9 08:56:08 server kernel: RAX: 0000000000000000 RBX: 000001007f2ab790 RCX: 0000000000000000
Nov 9 08:56:08 server kernel: RDX: 0000000000000000 RSI: 000001007f2ab790 RDI: 000001007ff98080
Nov 9 08:56:08 server kernel: RBP: 000001007bbf2340 R08: 000000000000000b R09: 0000000000000000
Nov 9 08:56:08 server kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 00000100656a7ef8
Nov 9 08:56:08 server kernel: R13: 000001007ff98080 R14: 00000000005c87b0 R15: 0000000000000000
Nov 9 08:56:08 server kernel: FS: 0000002a9649f600(0000) GS:ffffffff804c6480(0000) knlGS:0000000000000000
Nov 9 08:56:08 server kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 9 08:56:08 server kernel: CR2: 0000000000000078 CR3: 0000000000101000 CR4: 00000000000006e0
Nov 9 08:56:08 server kernel: Process mc (pid: 12211, threadinfo 00000100656a6000, task 0000010067e997b0)
Nov 9 08:56:08 server kernel: Stack: 00000100656a7ef8 0000000000000000 00000100656a7ef8 00000000ffffffff
Nov 9 08:56:08 server kernel: 0000007fbfffdf60 ffffffff801785ad 000001007f2ab790 000001007ff98080
Nov 9 08:56:08 server kernel: 000000000000b798 0000000000001000
Nov 9 08:56:08 server kernel: Call Trace:{vfs_lstat+61} {sys_newlstat+31}
Nov 9 08:56:08 server kernel: {system_call+126}
Nov 9 08:56:08 server kernel:
Nov 9 08:56:08 server kernel: Code: 48 8b 40 78 48 85 c0 74 0d 4c 89 e2 48 89 de 4c 89 ef ff d0
Nov 9 08:56:08 server kernel: RIP {vfs_getattr+75} RSP <00000100656a7e38>
Nov 9 08:56:08 server kernel: CR2: 0000000000000078

Itt az egész ha valakinek így ismerősebb. Ahogy olvasgatok ez egy OOPS hiba amiről egyenlőre nem sok fogalmam van de azt látom, hogy bizonyos eseteknem nem vészes, de Egy oops akkor okozhat pánikot, ha a rendszer egy életfontosságú része semmisül meg.

Én a helyedben arról a gépről sürgősen elkezdenék adatot menteni, mielőtt bármi mást tennék. Nagyon fontos, hogy a gép újraindítása nélkül...

Így ránézésre elég súlyosan sérült az a rendszer, és könnyen lehet, hogy hdd hiba miatt. Persze az is lehet, hogy csak szoftveresen halt meg szegényke, de jobb félni szerintem.

Csaba

( LGee | 2006. 11. 09., cs – 09:27 )

> Eddig nem találtam semmit erről a neten.

Ezt nezted? Ugy latom, ez a 2.6-os kernelben fordul csak elo.

Lehet hardverhiba is! Legalabb egy memtest ajanlott, de johet a tobbi is (fsck, cpuburn...)

Ha jol latom, ez egy SUSE, igaz?
Esetleg erdemes lenne nekik is elkuldeni az uzenetet, vagy egy SLES levlistan megkerdezni.

( budacsik | 2006. 11. 09., cs – 10:23 )

Érdekes:
Amikor elkezdtem menteni egy Raid storage-ra az adatokat Samban keresztül, mert ... mindegy, egyszercsak meghalt a szerver. Nem reagált semmire. Odamentem és bill-ről se lehetett felizgatni. Pár perc töprengés vizsgálódás után kénytelen voltam resetelni. Azóta minden szép és jó. A kérédéses könyvtárakba is bele tudok menni, semmi hibát nem tapasztalok, minden megy. Kiérti ... ?!

Én a helyedben nagyon résen lennék. Nekem volt hasonlóm, ha jól emlékszem két alkalommal, és egy idő után egyre sűrűbben jöttek a zavarok, amiket újraindítás után nem lehetett visszanyomozni. A végén a komplett gép elszállt, és a mai napig nem sikerült megtudnom, hogy alaplap/táp/hdd volt e a hiba forrása? Az igaz, hogy ezek az esetek nem szerveren, hanem desktop gépeken voltak.

Üdv:

Csaba