On Sunday 09 February 2003 03:54 am, vatbier wrote: > Mandrake Linux 9.0 here: > I installed alsa-utils from CD1 with MCC:Software Install: > in /var/log/syslog these error messages appeared (SEE BELOW): > > "XT3-fs error (device ide0(3,2)): ext3_new_block: Allocating block in > system zone - block = 294914" > > Then I rebooted (because I wanted to boot in runlevel 3 to see > whether I could play sound..., not relevant here). > Error bootmessages appeared (SEE BELOW FOR MORE DETAILS): > > "fsck: /dev/hda2 contains a file system with errors, check forced"... > fsck: /dev/hda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > failed to check filesytem. Do you want to repair the errors? Y/N > (beware, you can lose data) > > I pressed Yes: > a lot of inodes were fixed or cleared > ABOUT 22345 MESSAGES APPEARED (SEE BELOW) > "/dev/hda2: ****file system was modified ****" > > I was in runlevel 3: tried a few commands but those weren't recognized. > > Booted into KDE: > about 25 windows appeared that said: > "could not find mime type application/octet stream" > or "could not find mime type application/x-executable" > or "could not find mime type application/x-desktop" > or "could not find mime type application/x-shellscript" > Each window has to be pressed twice to get rid of. > There are some Konqueror windows open from the former session, > I can use them to browse the internet or my file system. > I can not start programs from the menu, in my file system a lot of > files have now file type mime. > FINALLY I FOUND OUT THAT A LOT OF FILES WERE GONE, FROM > DIFFERENT DIRECTORIES. > I also have a Konsole window open: except for basic commands no command > is recognized. > I searched Google, found nothing useful, search function of > [EMAIL PROTECTED] mailing list didn't work. > Is there an easy way to repair my system or do I have to reinstall > everything?? > I have a backup from 3 weeks ago, but that won't bring back the lost > files from /bin, /user/sbin,etc. > UPDATE: I searched Google for "ext3_new_block: Allocating block in > system zone": I found the ext3-user mailing-list and read and learned a bit > about file system corruption. > I tested my memory with memtest86 but no errors were detected, I read > that this is not conclusive. > I probably will reinstall Mandrake Linux 9.0. > But how can I figure out what has caused the corruption: > Memory, hard disk, IDE cable, IDE controller, UDMA, CPU, cooling,...? > And how can I best recover from this: reinstall complete distribution and > then apply backups? How can I figure out which files have been modified or > disappeared? > > I also remember that in the same session KNode newsreader crashed when I > tried to read a newsmessage after downloading the headers of > alt.os.linux.mandrake. It crashed several times. > > My system: > AMD AthlonXP 1600+ > Motherboard MSI K7T266 Pro2 (MS-6380 V2.0): VIA KT266A, VIA VT8233 > 512 MB memory (tested it with memtest86: no errrors detected) > Western Digital Caviar 40GB 7200RPM: UDMA is enabled I think (see below for > info from dmesg) > Mandrake Linux 9.0 (kernel 2.4.19-16mdk) > On this disk I also run: WinXP,Win98,Mandrake8.2(ext2) : no problem with > these OSes so far. > > Very frustrated after this happened, I thought linux file systems were > stable. UPDATE: No longer very frustrated, just a little; this is the first > time in six years I experience such a problem. > > vatbier > > ERROR MESSAGES AFTER INSTALLATION ALSA-UTILS: > LOOK AT LINES WITH * IN FRONT OF IT: > Jan 31 13:55:22 this rpmdrake[1711]: Extracting header of > xine-alsa-0.9.13-3mdk.i586 from /var/lib/urpmi/hdlist.Internationa > Jan 31 13:55:22 this rpmdrake[1711]: removed files/directories > (recursively) /root/tmp/headers/ > Jan 31 13:55:26 this rpmdrake[1711]: removed files/directories > (recursively) /root/tmp/headers/ > *Jan 31 13:55:53 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294914 > *Jan 31 13:55:53 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294915 > Jan 31 14:01:00 this CROND[1754]: (root) CMD (nice -n 19 run-parts > /etc/cron.hourly) > Jan 31 14:03:40 this rpmdrake[1711]: Installing package > removable://mnt/cdrom/Mandrake/RPMS//alsa-utils-0.9.0-0.6rc2mdk > Jan 31 14:03:46 this kernel: ISO 9660 Extensions: Microsoft Joliet > Level 3 > Jan 31 14:03:46 this kernel: ISO 9660 Extensions: RRIP_1991A > *Jan 31 14:03:49 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294916 > *Jan 31 14:03:49 this kernel: EXT3-fs error (device ide0(3,2)): > *ext3_new_block: Allocating block in system zone - block = 294917 > ABOUT 190 OF THESE ERROR MESSAGES APPEARED. > > BOOTING: ABOUT 22345 MESSAGES APPEARED: > Jan 31 14:29:22 this fsck: /dev/hda2 contains a file system with > errors, check forced > Jan 31 14:29:25 this /etc/hotplug/usb.agent: ... no modules for USB > product 0/0/0 > Jan 31 14:29:36 this fsck: Inode 139427 is in use, but has dtime set. > FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139428 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139429 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139430 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139431 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139432 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139433 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139434 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Special > (device/socket/fifo/symlink) file (inode 139434) has immutable > Jan 31 14:29:36 this fsck: or append-only flag set. IGNORED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139435 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139436 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139437 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139438 is in use, but has > dtime set. FIXED. > Jan 31 14:29:36 this fsck: /dev/hda2: Inode 139438 has imagic flag set. > Jan 31 14:29:36 this fsck: /dev/hda2: UNEXPECTED INCONSISTENCY; RUN > fsck MANUALLY. > Jan 31 14:29:36 this fsck: ^I(i.e., without -a or -p options) > Jan 31 14:32:25 this fsck: /dev/hda2 contains a file system with > errors, check forced. > Jan 31 14:32:25 this fsck: Pass 1: Checking inodes, blocks, and sizes > Jan 31 14:32:25 this fsck: e2fsck 1.27ea (14-Mar-2002) > Jan 31 14:32:25 this fsck: Special (device/socket/fifo/symlink) file > (inode 139434) has immutable > Jan 31 14:32:25 this fsck: or append-only flag set. Clear? yes > Jan 31 14:32:25 this fsck: Inode 139438 has imagic flag set. Clear? yes > Jan 31 14:32:25 this fsck: Inode 139439 is in use, but has dtime set. > Fix? yes > Jan 31 14:32:25 this fsck: Inode 139440 is in use, but has dtime set. > Fix? yes > ...fsck: Inode 139442 has imagic flag set. Clear? yes > ...fsck: Illegal block #0 (1342448708) in inode 139965. CLEARED. > ...fsck: Too many illegal blocks in inode 139965. > ...fsck: Duplicate/bad block(s) in inode 139841: 6 52 192 192 5 4 3 244 > ...fsck: File /tmp/kde-root/ksycoca (inode #146132, mod time Fri Jan 31 > 14:26:59 2003) > fsck: has 119 duplicate block(s), shared with 2 file(s): > fsck: ^I<filesystem metadata> > fsck: ^I... (inode #141028, mod time Sun Jan 4 10:57:48 1970) > fsck: Clone duplicate/bad blocks? yes > ...fsck: Directory inode 139841, block 7, offset 0: directory corrupted > ...fsck: Inode 144116 (/usr/share/apps/konquest) has a bad mode (0160). > fsck: Clear? yes > ...fsck: Inode 141347 (/usr/bin/mcc) has a bad mode (0145). > fsck: Clear? yes > ...fsck: Entry 'aumix' in /usr/bin (139395) has deleted/unused inode > 144586. Clear? yes > ...fsck: /dev/hda2: ***** FILE SYSTEM WAS MODIFIED ***** > > /var/log/dmesg: > > "Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > VP_IDE: IDE controller on PCI bus 00 dev 89 > VP_IDE: chipset revision 6 > VP_IDE: not 100% native mode: will probe irqs later > VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1 > ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio > hda: WDC WD400BB-32CXA0, ATA DISK drive > hdc: LITE-ON LTR-24102B, ATAPI CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63, > UDMA(100)"
OK What happened is this: With each sector of data the system generates a 57 byte CRC (Cyclic Redundancy Check) WD drives of the generation you are using do not calculate that same CRC for comparison--they store it in their big 600-byte sectors along with the 512 bytes of data. They may calculate the first in a series of writes, but not all. The result is that a channel error is not always recognized from mobo to disk, only from disk to memory No request to retransmit is generated by the disk because it is not capable of independently verifying the channel error. This is NOT new. Chipset makers have been letting WD get away with this crap for years http://kt.zork.net/kernel-traffic/kt20000214_54.html#2 Yep February 2000 Anyway WD is the only drive I know that can turn a transitory noise problem into a more or less permanent hardware problem. The drive is safe enough run at udma2 (33Mhz and 32 byte CRCs) or lower but has this very low probability of failure at udma3 or higher. But in computers a low probability of failure means that you can calculate how often to expect it. ext3 or XFS or Reiserfs or JFS are not inherently more secure than ext2... They just recover from errors caused by sudden poweroffs or static from the family cat brushing up against the computer case somewhat faster than the older non-journaling filesystems. On a larger partition this can be the difference between back up in 45 seconds or 45 minutes, so the journaling filesysem is much preferable for servers. If you cannot put a better drive in that box, a 40-pin cable could make a big difference for the safe operation, to force 33MHz or lower transfer speed. KDE constantly updates things on disk, like the position of windows on the screen, so drive reliability is critical with that application. Civileme
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
