ext3 partition problem
A month or two ago, I repartitioned my hard drive, and moved the root
partition to a slightly smaller partition and created a huge home
partition. Since I had no immediate need for the space occupied by the
old root partition, I kept it as a security to make sure I did the
transition correctly which as it turns out I didn't. I had never fixed
my lilo.conf to point to the new root partition[at least the lilo.conf
on the current / partition, I am not sure what the lilo.conf on the old
partition says]. When the big Sarge update arrived post-Woody's
release, lilo was upgraded and ran with the faulty lilo.conf.
Subsequently, a couple of days ago, I lost power. After this the
machine refused to boot. I eventually fixed lilo.conf to point to my
current / partition, and got it to boot. But I thought this was strange
since the old root partition was still a valid / partition and should
have allowed the computer to boot. To try to figure out if it was all
right, I mounted it. It mounted fine, but then very quickly died with
the attached error[from /var/log/syslog][the error appears to be the
same error I was getting when the 'puter refused to boot but I can't be
sure]. The partition that died was ext3, and kernel is 2.4.18 built
with make-kpkg with ext3 support compiled into the kernel. After this
failure, I attempted to 'ls' the contents of the directory where it was
mounted, but 'ls' just hanged. So my first question is how do I kill
the 'ls' process and/or unmount the partition without rebooting? The
'ls' process doesn't respond to 'kill -s KILL <pid of ls>'. My other
question is what caused this error in the first place so I don't repeat
the error with a partition with important information on it[I was
planning to reformat this partition eventually anyway]? The only other
relevant information that I can think of is that a couple of weeks ago,
after I had stopped using it, I defraged it with e2defrag just to see
what the defrag process was like, was this the mistake? The output from
fdisk -l for this partition is:
/dev/hda5 6120 7352 9904041 83 Linux
Aug 4 01:48:24 localhost kernel: attempt to access beyond end of device
Aug 4 01:48:24 localhost kernel: 03:05: rw=0, want=1343556380, limit=9904041
[whole bunch of lines like this]
Aug 4 01:48:25 localhost kernel: attempt to access beyond end of device
Aug 4 01:48:25 localhost kernel: 03:05: rw=0, want=1520600832, limit=9904041
Aug 4 01:48:25 localhost kernel: kjournald starting. Commit interval 5 seconds
Aug 4 01:48:25 localhost kernel: EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,5), internal journal
Aug 4 01:48:25 localhost kernel: EXT3-fs: recovery complete.
Aug 4 01:48:25 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode.
Aug 4 01:49:16 localhost kernel: attempt to access beyond end of device
Aug 4 01:49:16 localhost kernel: 03:05: rw=1, want=1343556380, limit=9904041
Aug 4 01:49:16 localhost kernel: attempt to access beyond end of device
Aug 4 01:49:16 localhost kernel: 03:05: rw=1, want=1460962200, limit=9904041
Aug 4 01:49:16 localhost kernel: attempt to access beyond end of device
Aug 4 01:49:16 localhost kernel: 03:05: rw=1, want=355344556, limit=9904041
Aug 4 01:49:16 localhost kernel: attempt to access beyond end of device
Aug 4 01:49:16 localhost kernel: 03:05: rw=1, want=1114941708, limit=9904041
Aug 4 01:49:16 localhost kernel: attempt to access beyond end of device
Aug 4 01:49:16 localhost kernel: 03:05: rw=1, want=2057663124, limit=9904041
Aug 4 01:49:16 localhost kernel: attempt to access beyond end of device
Aug 4 01:49:16 localhost kernel: 03:05: rw=1, want=171643804, limit=9904041
Aug 4 01:49:16 localhost kernel: Assertion failure in __journal_remove_journal_head() at journal.c:1730: "buffer_jbd(bh)"
Aug 4 01:49:16 localhost kernel: invalid operand: 0000
Aug 4 01:49:16 localhost kernel: CPU: 0
Aug 4 01:49:16 localhost kernel: EIP: 0010:[__journal_remove_journal_head+125/224] Tainted: P
Aug 4 01:49:16 localhost kernel: EFLAGS: 00210286
Aug 4 01:49:16 localhost kernel: eax: 0000005c ebx: d36901e0 ecx: d66d2000 edx: 00000001
Aug 4 01:49:16 localhost kernel: esi: c96618c0 edi: d3064f40 ebp: 0000000a esp: cb4a1e5c
Aug 4 01:49:16 localhost kernel: ds: 0018 es: 0018 ss: 0018
Aug 4 01:49:16 localhost kernel: Process kjournald (pid: 8350, stackpage=cb4a1000)
Aug 4 01:49:16 localhost kernel: Stack: c01e5d20 c01e656f c01e5cf1 000006c2 c01e658d c96618c0 d36901e0 c015c27c
Aug 4 01:49:16 localhost kernel: c96618c0 c96618c0 c0158947 d36901e0 c1e03050 c1e03000 c1e03000 00000000
Aug 4 01:49:16 localhost kernel: 00000000 cb4a1fd4 c96618c0 c1e03094 c1e03050 00000000 00000fbc caac2044
Aug 4 01:49:17 localhost kernel: Call Trace: [journal_unlock_journal_head+76/96] [journal_commit_transaction+2007/3543] [vgacon_cursor+375/384] [set_cursor+110/128] [poke_blanked_console+92/96]
Aug 4 01:49:17 localhost kernel: [vt_console_print+719/736] [__call_console_drivers+57/80] [schedule+704/752] [kjournald+267/416] [commit_timeout+0/16] [kernel_thread+40/64]
Aug 4 01:49:17 localhost kernel:
Aug 4 01:49:17 localhost kernel: Code: 0f 0b 83 c4 14 39 33 74 2a 68 9c 65 1e c0 68 c3 06 00 00 68
Reply to: