| Summary: | perl-5.8.0-r12 fails to install | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andrei Ivanov <andrei.ivanov> |
| Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | bakirov, bugs.gentoo.org, chris, christian.strauf, chutzpah, jon, Jonathan.M.Hanson, leif, markknecht, matt, ogunden, perl, steel300, storri, wheio, zoogie |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | ls -lRa /var/tmp/portage/perl-5.8.0-r12/ | bzip2 -9 > perl_ls-lra.bz2 | ||
|
Description
Andrei Ivanov
2003-07-21 13:14:53 UTC
This appears to be a portage problem, outside the scope of the perl ebuild. Can you include your emerge --info, please? *** Bug 25210 has been marked as a duplicate of this bug. *** Is there any progress on this bug ? I can't update anything that depends on perl :( Portage 2.0.48-r7 (default-x86-1.4, gcc-3.3, glibc-2.3.2-r1) ================================================================= System uname: 2.6.0-test1-ac1 i686 AMD Athlon(tm) Processor GENTOO_MIRRORS=" ftp://ftp.tu-clausthal.de/pub/linux/gentoo http://ftp.easynet.nl/mirror/gentoo ftp://ftp.easynet.nl/mirror/gentoo ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 3dnow avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses pdflib png quicktime spell truetype xml2 xmms xv zlib alsa gdbm berkdb slang readline arts svga java guile X sdl gpm tcpd pam libwww ssl perl python imlib oggvorbis gtk qt kde motif opengl aalib acl acpi apache2 -apm curl dga esd gd gnome gnomedb gtk2 gtkhtml imap innodb lcms ldap libgda maildir mozilla mozsvg moznoirc moznocompose -mysql -nls nptl odbc oss pic -postgres samba sasl slp -sse tiff xml" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -ffast-math -fforce-addr -falign-functions=4" CXXFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -ffast-math -fforce-addr -falign-functions=4" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage/" FEATURES="sandbox ccache" what if you re-emerge perl ? I've tried... resynced and re-emerged, everytime the same error. It appears something is being done in the background. This occurs immediately following a listdir() of that directory, and a lstat call to a filename that was returned. Try again, then try with 48-r5, and then if it is still occuring please post an ls -lRa /var/tmp/portage/perl-5.8.0-r12/ | bzip2 -9 > perl_ls-lra.bz2 I am getting a similar error merging the perl-5.8.0-r12
Here's the output:
Traceback (most recent call last):
File "/usr/bin/emerge", line 1993, in ?
mydepgraph.merge(mydepgraph.altlist())
File "/usr/bin/emerge", line 1226, in merge
retval=portage.doebuild(y,"merge",myroot,edebug)
File "/usr/lib/python2.2/site-packages/portage.py", line 1768, in doebuild
return merge(settings["CATEGORY"],settings["PF"],settings["D"],settings["BUILDDIR"]+"/build-info",myroot,myebuild=settings["EBUILD"])
File "/usr/lib/python2.2/site-packages/portage.py", line 1877, in merge
return mylink.merge(pkgloc,infloc,myroot,myebuild)
File "/usr/lib/python2.2/site-packages/portage.py", line 4692, in merge
return self.treewalk(mergeroot,myroot,inforoot,myebuild)
File "/usr/lib/python2.2/site-packages/portage.py", line 4379, in treewalk
if self.mergeme(srcroot,destroot,outfile,secondhand,"",cfgfiledict,mymtime): File "/usr/lib/python2.2/site-packages/portage.py", line 4603, in mergeme
if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime):
File "/usr/lib/python2.2/site-packages/portage.py", line 4603, in mergeme
if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime):
File "/usr/lib/python2.2/site-packages/portage.py", line 4603, in mergeme
if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime):
File "/usr/lib/python2.2/site-packages/portage.py", line 4603, in mergeme
if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime):
File "/usr/lib/python2.2/site-packages/portage.py", line 4519, in mergeme
mystat=os.lstat(mysrc)
OSError: [Errno 2] No such file or directory: '/var/tmp/portage/perl-5.8.0-r12/image/usr/share/man/man3/Hash::Util.tmp'
Created attachment 15135 [details]
ls -lRa /var/tmp/portage/perl-5.8.0-r12/ | bzip2 -9 > perl_ls-lra.bz2
I got an error when i did what you suggested
I am using portage 2.0.48-r7
ls -lRa /var/tmp/portage/perl-5.8.0-r12/ | bzip2 -9 > perl_ls-lra.bz2
ls: /var/tmp/portage/perl-5.8.0-r12/image/usr/share/man/man3/Hash::Util.tmp: No
such file or directory
Here's my emerge --info Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.6.0-test2 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GENTOO_MIRRORS="ftp://cs.ubishops.ca/pub/gentoo http://adelie.polymtl.ca/ ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /opt/tomcat/conf /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 3dnow apm avi crypt encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xv zlib alsa gdbm berkdb slang readline arts tetex bonobo tcltk java postgres X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla apache2 doc emacs gtk2 sse usb xml -oss -cups -svga -xmms" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -msse2 -msse -mmmx -O3 -pipe" CXXFLAGS="-march=pentium4 -msse2 -msse -mmmx -O3 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.ca.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" I think I have some sort of file system oddity (ext3 with 2.6.0-test2-mm1) cd /var/tmp/portage/perl-5.8.0-r12//image/usr/share/man/man3/ hate:/var/tmp/portage/perl-5.8.0-r12/image/usr/share/man/man3# ls -al ls: Hash::Util.tmp: No such file or directory total 36 drwxr-xr-x 2 root root 32768 Jul 28 21:16 . drwxr-xr-x 3 root root 4096 Jul 28 21:16 .. Something is happening with Hash::Util.tmp.. I've forced an fsck on the filesystem, it found a couple of errors, rebooted, re-emerged perl and the same thing happens. Maybe I should try with a 2.4 kernel. I get the same error with 2.6.0-test2, so its not only a test1 issue. Also running 48-r5 as spanky had earlier suggested. Linux tribeca.formanonline.com 2.6.0-test2 #3 Mon Jul 28 14:19:44 CDT 2003 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux tribeca root # emerge info Portage 2.0.48-r5 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1,2.3.1-r4) ================================================================= System uname: 2.6.0-test2 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://gentoo.oregonstate.edu/" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss 3dnow apm avi crypt encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml gdbm berkdb slang readline tetex bonobo svga java guile sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gtk motif opengl mozilla gphoto2 cdr X alsa cups -gnome qt mysql -kde pda -arts ipv6 gtk2" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium4 -pipe" CXXFLAGS="-O3 -march=pentium4 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" *** Bug 25426 has been marked as a duplicate of this bug. *** I'm yet another person getting this error. I initally tried an upgrade, I got the python errors, and had to unmerge both -r8 and -r12. I tried emerging perl again, and it errored out in the same spot. I am currently running 2.5.73mm1 as well, so yet another dev kernel but not 2.6. For me, the file var/tmp/portage/perl-5.8.0-r12/image/man/man3/Hash:Util.tmp cannot be removed - the file system returns errors that this file does not exist. Forcing an fsck on reboot allowed me to delete the file, but emerge perl fails again with the same error in the same spot. The Hash::Util.tmp is, once again, a "ghost file" and I had to reboot AND fsck to remove it. Added myself as a cc to this bug - feel free to email me if you need me to test anything. I managed to get it to emerge by suspending the emerge jsut after it created the files in the man3 dir, moving all files in var/tmp/portage/perl-5.8.0-r12/image/man/man3/ to a temp dir (except Hash::Util.tmp) deleting the dir and renaming the new dir to man3, then resuming the emerge. I get the same stuff. here is my info: (running a 3.0Ghz P4 w/hyperthreading enabled. 512M dual channel) [ ribo$io :: ~ ] emerge info Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.6.0-test2-mm1 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linu x/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share /config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 3dnow apm avi crypt cups encode foomaticdb gif jpeg libg++ libwww mad m ikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline svga java sdl gpm tcpd pam ssl perl python imlib ogg vorbis gtk qt motif opengl mozilla cdr -arts -esd xosd X gtk2 gnome alsa oss mys ql -kde" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe -mmmx -msse" CXXFLAGS="-march=pentium3 -O3 -pipe -mmmx -msse" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j3" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" In an attempt to get my stuff working, I tried to install perl-5.8.1_rc2.ebuild (on portage). It has the same error. breaking at:
>>> /usr/share/man/man3/ExtUtils::MM_Win95.3pm.gz
>>> /usr/share/man/man3/Filter::Util::Call.3pm.gz
Traceback (most recent call last):
File "/usr/bin/emerge", line 1993, in ?
with:
OSError: [Errno 2] No such file or directory: '/var/tmp/portage/perl-5.8.1_rc2/image/usr/share/man/man3/FileHandle.tmp'
I've booted in 2.4.22-pre3-ac1 and re-emerged perl and it worked just fine. I think it might be a bug in the 2.5 and 2.6 kernel's ext3 support which is triggered by emerge or something... Its HTREE support in EXT3 filesystems from late 2.5 and now 2.6 kernels. Unmount the FS and run on it: # tune2fs -O ^dir_index /dev/_my_partition_ . Sounds like a kernel bug to me then, perhaps this should be reported to the lkml? Especially since we now know what is causing it. I did some time back. Problem is to get a test case that you can simulate it with. I did not have the time back then (still do not really) to do it, so not much they could do. Btw, if anybody have time to try and see if they can recreate it with touching/ deleting files, please feel free. I really do not know when I will get to this. Did a quick go at seeing if I could create a test case. Note that This
is not related to portage, as doing a make install outside portage have
the same result (as long as the destination is on a HTREE enabled partition).
Somewhere the temp file is added as a directory, or it gets
into the directory hash ? (not sure as I have not tried to
figure out what the HTREE code does):
------------------------------------------------
nosferatu perl-5.8.0 # ls /space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/
ls: /space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp: No such file or directory
AnyDBM_File.3pm Exporter::Heavy.3pm Locale::Country.3pm Sys::Syslog.3pm
Attribute::Handlers.3pm ExtUtils::Command.3pm Locale::Currency.3pm Term::ANSIColor.3pm
....
------------------------------------------------
Here is a strace (cannot really see anything of use. Also,
the first bit is not of real use):
------------------------------------------------
nosferatu perl-5.8.0 # grep Hash trace.log | grep Util [pid 5112] open("lib/Hash/Util.pm", O_RDONLY|O_LARGEFILE) = 3
[pid 5112] stat64("lib/Hash/Util.pm", {st_mode=S_IFREG|0444, st_size=3939, ...}) = 0
[pid 5112] read(3, "package Hash::Util;\n\nrequire 5.0"..., 4096) = 3939
[pid 6215] open("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/lib/perl5/5.8.0/Hash/Util.pm", O_RDONLY|O_LARGEFILE) = 4
[pid 6215] read(3, "package Hash::Util;\n\nrequire 5.0"..., 4096) = 3939
[pid 6215] read(4, "package Hash::Util;\n\nrequire 5.0"..., 4096) = 3939
[pid 6226] open("lib/Hash/Util.pm", O_RDONLY|O_LARGEFILE) = 3
[pid 6226] stat64("lib/Hash/Util.pm", {st_mode=S_IFREG|0444, st_size=3939, ...}) = 0
[pid 6226] read(3, "package Hash::Util;\n\nrequire 5.0"..., 4096) = 3939
[pid 6256] stat64("lib/Hash/Util.pm", {st_mode=S_IFREG|0444, st_size=3939, ...}) = 0
[pid 6256] stat64("lib/Hash/Util.t", {st_mode=S_IFREG|0555, st_size=6729, ...}) = 0
[pid 6256] stat64("lib/Hash/Util.pod", 0x811e540) = -1 ENOENT (No such file or directory)
[pid 6256] open("lib/Hash/Util.pm", O_RDONLY|O_LARGEFILE) = 3
[pid 6256] stat64("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp", 0x811e540) = -1 ENOENT (No such file or directory)
[pid 6256] open("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
[pid 6256] read(3, "package Hash::Util;\n\nrequire 5.0"..., 4096) = 3939
[pid 6256] stat64("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp", {st_mode=S_IFREG|0644, st_size=6435, ...}) = 0
[pid 6256] stat64("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.3pm", 0x811e540) = -1 ENOENT (No such file or directory)
[pid 6256] link("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp", "/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.3pm") = 0
[pid 6256] stat64("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp", {st_mode=S_IFREG|0644, st_size=6435, ...}) = 0
[pid 6256] lstat64("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp", {st_mode=S_IFREG|0644, st_size=6435, ...}) = 0
[pid 6256] unlink("/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.tmp") = 0
/space/var/tmp/portage/perl-5.8.0-r12/image//usr/share/man/man3/Hash::Util.3pm
nosferatu perl-5.8.0 #
------------------------------------------------
Nice oops when I tried to unmount the partition (yes, it
is tainted, as I use the nvidia module, but yes, it does
do the same without):
------------------------------------------------
Unable to handle kernel paging request at virtual address 6b6b6cdf
printing eip:
c0195a9f
*pde = 00000000
Oops: 0000 [#1]
CPU: 1
EIP: 0060:[<c0195a9f>] Tainted: PF
EFLAGS: 00210206
EIP is at ext3_get_inode_block+0x2d/0x105
eax: 6b6b6b6b ebx: 00000000 ecx: 00000000 edx: 6b6b6b6b
esi: ee0c724c edi: f2aa9114 ebp: 6b6b6b6b esp: e00f1dd8
ds: 007b es: 007b ss: 0068
Process umount (pid: 6511, threadinfo=e00f0000 task=ea3f52e0)
Stack: 00000000 00000000 ebabb49c 00000000 00001000 00000000 ee0c724c f2aa9114
e00f1e78 c0195b9f 6b6b6b6b 6b6b6b6b e00f1e78 00000000 e1b90bd4 c01a10f7
e1b90bd4 e1b90bd4 00000000 ee0c724c f2aa9114 e00f1e78 c019668d ef6fe194
Call Trace:
[<c0195b9f>] ext3_get_inode_loc+0x28/0x265
[<c01a10f7>] journal_get_write_access+0x43/0x51
[<c019668d>] ext3_reserve_inode_write+0x39/0xcc
[<c0199b29>] ext3_orphan_del+0xd7/0x215
[<c01a03e1>] journal_start+0xab/0xd2
[<c0192e1d>] ext3_delete_inode+0x6e/0x106
[<c0192daf>] ext3_delete_inode+0x0/0x106
[<c01733d3>] generic_delete_inode+0x77/0x13c
[<c017219a>] destroy_inode+0x35/0x50
[<c0173687>] iput+0x62/0x7c
[<c016ff91>] dput+0x11a/0x248
[<c0170630>] prune_dcache+0x1c3/0x23c
[<c0170ae7>] shrink_dcache_parent+0x1c/0x23
[<c015ef07>] generic_shutdown_super+0x2b/0x1e4
[<c015fd61>] kill_block_super+0x1d/0x48
[<c015ed23>] deactivate_super+0x6b/0xe8
[<c0175d9e>] sys_umount+0x3f/0x90
[<c0175e06>] sys_oldumount+0x17/0x1b
[<c010aaa5>] sysenter_past_esp+0x52/0x71
Code: 8b 9d 74 01 00 00 3b 53 50 72 07 8b 43 2c 3b 10 76 32 89 54
<3>Slab corruption: start=d9ac38e4, expend=d9ac3acf, problemat=d9ac3958
Last user: [<c019af3f>](ext3_destroy_inode+0x1d/0x21)
Data: ********************************************************************************************************************08 79 37 EB ***********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************A5
Next: 71 F0 2C .3F AF 19 C0 71 F0 2C .********************
slab error in check_poison_obj(): cache `ext3_inode_cache': object was modified after freeing
Call Trace:
[<c01416f4>] check_poison_obj+0x161/0x1a1
[<c01418be>] slab_destroy+0x18a/0x192
[<c0142e4d>] free_block+0x235/0x31f
[<c0143ef6>] drain_array+0x9c/0xfb
[<c0144057>] reap_timer_fnc+0x0/0x2ad
[<c0144114>] reap_timer_fnc+0xbd/0x2ad
[<f9b442dd>] __nvsym00795+0x31/0x50 [nvidia]
[<c0144057>] reap_timer_fnc+0x0/0x2ad
[<c012a5c7>] run_timer_softirq+0xe5/0x1c2
[<c011d590>] rebalance_tick+0x47/0xd2
[<c0126146>] do_softirq+0xca/0xcc
[<c01181e4>] smp_apic_timer_interrupt+0xdd/0x145
[<c010b4e6>] apic_timer_interrupt+0x1a/0x20
[<c01087ee>] default_idle+0x0/0x2c
[<c0108817>] default_idle+0x29/0x2c
[<c0108887>] cpu_idle+0x3a/0x3c
[<c0122b2f>] printk+0x165/0x1c4
there was a bug in test2-mm1 -> test2-mm3 that's fixed in test2-mm3-1 and test2-mm4 with ext3. It may be related. can somone test on either of tese releases? Pat Erley I'm running test2-mm4 right now, i'll try re-emerging perl it works with 2.6.0-test-mm4, problem's gone you can probably close the bug now ;) Scratch that, i tried it on the wrong system, had forgotten which system had an ext3 /var and which didn't. I tried it on another system where /var is on an ext3 partition and it still had the problem. Sorry about that. Just wanted to confirm that ran into this bug, used tune2fs to turn off htree. emerged perl and turned htree back on. Still just working around it, and I do not know when it will come back to bite us. Will try to compile Perl on my debian box tomorrow and see if it is a Gentoo specific occurrence. If you are getting that kernel OOPS this patch against 2.6-test3 should fix it
-----------------------
===== fs/ext3/namei.c 1.44 vs edited =====
--- 1.44/fs/ext3/namei.c Sun Jun 29 23:49:04 2003
+++ edited/fs/ext3/namei.c Tue Aug 19 03:28:52 2003
@@ -1304,7 +1304,8 @@
data1 = bh2->b_data;
/* The 0th block becomes the root, move the dirents out */
- de = (struct ext3_dir_entry_2 *) &root->info;
+ de = &root->dotdot;
+ de = (struct ext3_dir_entry_2 *) ((char *)de + de->rec_len);
len = ((char *) root) + blocksize - (char *) de;
memcpy (data1, de, len);
de = (struct ext3_dir_entry_2 *) data1;
@@ -2006,9 +2007,9 @@
* recovery. */
inode->i_size = 0;
ext3_orphan_add(handle, inode);
+ inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
ext3_mark_inode_dirty(handle, inode);
dir->i_nlink--;
- inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
ext3_update_dx_flag(dir);
ext3_mark_inode_dirty(handle, dir);
@@ -2060,8 +2061,8 @@
inode->i_nlink--;
if (!inode->i_nlink)
ext3_orphan_add(handle, inode);
- ext3_mark_inode_dirty(handle, inode);
inode->i_ctime = dir->i_ctime;
+ ext3_mark_inode_dirty(handle, inode);
retval = 0;
end_unlink:
@@ -2220,7 +2221,6 @@
goto end_rename;
} else {
BUFFER_TRACE(new_bh, "get write access");
- BUFFER_TRACE(new_bh, "get_write_access");
ext3_journal_get_write_access(handle, new_bh);
new_de->inode = le32_to_cpu(old_inode->i_ino);
if (EXT3_HAS_INCOMPAT_FEATURE(new_dir->i_sb,
Just curious, where did you get this patch from? I know *just enough* C to *feel* like this doesn't do anything harmful, but I'm far from a kernel hacker. Can anyone explain what this does or where it came from? Thanks! It was posted on linux-kernel mailing list... Martin, I assume I can close this as you seem to have got past this with that kernel patch? Has anyone else tried the patch? Did it fail/work/... ? Ok... I recompiled perl on 2.6.0-test4-mm4 and it worked fine... I think this bug can be closed... Closing bug as we seem to have this resolved... *** Bug 38629 has been marked as a duplicate of this bug. *** *** Bug 38917 has been marked as a duplicate of this bug. *** *** Bug 40156 has been marked as a duplicate of this bug. *** Occurs on 2.4.22-gentoo-r5, too. works fine in 2.4.20-gentoo-r7. not working in 2.4.22-gentoo-r5 here either. I saw this in 2.4.22-gentoo-r5. I backed up to 2.4.22-entoo-r2 and the problem went away. What's the process for getting a 'resolved' bug reopend? This bug (40156) is neither fixed nor resolved in my eyes. Even if I mount the partition as ext2 I get the same error. There's got to be some other reason for this behaviour than HSTREE. Christian Same here with gentoo-2.4.22-r5 with ext3. Me too, 2.4.22-gentoo-r5 and ext3 fs. *** Bug 40237 has been marked as a duplicate of this bug. *** Count me in as getting the same bug: !!! ERROR: There appears to be FILE SYSTEM CORRUPTION. A file that is listed !!! as existing is not capable of being stat'd. If you are using an !!! experimental kernel, please boot into a stable one, force an fsck, !!! and ensure your filesystem is in a sane state. 'shutdown -Fr now' !!! File: /usr/tmp/portage/perl-5.8.2-r1/image/usr/share/man/man3/Hash::Util.tmp !!! Error: [Errno 2] No such file or directory: '/usr/tmp/portage/perl-5.8.2-r1/image/usr/share/man/man3/Hash::Util.tmp' asgard portage # uname -a Linux asgard.cs.uct.ac.za 2.4.22-gentoo-r4 #3 Thu Jan 29 15:33:21 SAST 2004 i686 AMD Athlon(tm) processor AuthenticAMD GNU/Linux asgard portage # emerge info Portage 2.0.50_pre12 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9, 2.4.22-gentoo-r4) ================================================================= System uname: 2.4.22-gentoo-r4 i686 AMD Athlon(tm) processor Gentoo Base System version 1.4.3.10p1 Autoconf: sys-devel/autoconf-2.58 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-tbird -Os -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-tbird -Os -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp.is.co.za/linux/distributions/gentoo http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://ftp.leg.uct.ac.za/gentoo-portage" USE="3dnow X alsa apm avi bonobo crypt cups curl doc encode esd evo foomaticdb gd gdbm gif gnome gpm gtk gtk2 gtkhtml guile imlib java jpeg libg++ libwww mad mikmod mmx motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python quicktime readline ruby ruby18 sdl slang spell ssl svg svga tcltk tcpd tetex truetype usb x86 xml xml2 xmms xv zlib" I can confirm that I am also experiencing this problem on 2.4.22-gentoo-r5. I am unable to emerge perl-5.8.0-r12.(message telling me about file system corruption). Reassigning to kernel people *** Bug 40384 has been marked as a duplicate of this bug. *** Can confirm also happening under gentoo-2.4.22-r3, both perl-5.8.0-r12 and perl-5.8.2-r1. I have this problem too, with kernel 2.4.22-gentoo-r5 and perl-5.8.2-r1 http://bugs.gentoo.org/show_bug.cgi?id=40237 So if it is a Kernel bug as it seems to be, why does it only show when emerging Perl? And why does disabling HTREE support make the bug not show up? *** Bug 40743 has been marked as a duplicate of this bug. *** I now see this problem with 2.4.22-r2 also. I think the problem seems to be getting worse not better. So.. this bug combined with 35259 make the gentoo-sources-2.4.22* kinda unreliable and unusable on an ext3 filesystem. I tried (as Martin Schlemmer suggested) # tune2fs -O ^dir_index /dev/_my_partition_ and than "emerge perl" finished OK. Thanks, Martin! OK, I also tried tune2fs -O ^dir_index /dev/vg/var and perl emerged without any problems! :) Thank you very much for hint! In my case the var directory is just part of /. (/dev/hda7) Should I be doing: tune2fs -O ^dir_index /dev/hda7/var or tune2fs -O ^dir_index /dev/hda7 ???? Thanks. In order to turn on using hashed-btrees to speed up lookups in larged directories (-O) you need to use tune2fs to enable it. The option is executed as below. The flag is capital O as in oscar and not the number zero. tune2fs -O ^dir_index /dev/hda7 I am still unclear as to whether I need to do anything. I won't have physical access to the box this popped up on until next month and I'm swamped at the moment so unmounting /var for a tune2fs would be a bit of a pain. Will this lead to any other problems; i.e., is there any urgency to take action to get rid of the offending Hash::Util.tmp? Advice would be appreciated. Hmmm ... don't everyone reply at once. Seriously, since I may not be able to get to the box this cropped up on for a few weeks I'm curious whether this might cause cascading filesystem errors or somesuch or whether I can just not worry about it until later. I'm not a filesystems guy so you'll have to excuse my ignorance if this is a stupid question. Thanks! maybe this could help: this doesn't seem to occur with vanilla-sources. I have vanilla-sources on my notebook and didn't notice any problem. However, now I was trying to upgrade another machine which uses gentoo-sources and the problem appeared. The tune2fs command worked for me. Prior to that, Perl 5.8.2-r1 errored out thinking I had a corrupt filesystem. My kernel gentoo-sources-2.4.22-r4. Seems to be fixed in gentoo-sources-2.4.25. emerge of perl with dir_index enabled was successfull for me. Could someone else verify? Yep, works for me on two x86 boxes running 2.4.25. (I turned dir_index back on). A newer kernel fixed this then? I am seeing multiple solutions here. Either tune2fs or a newer kernel is the fix. > A newer kernel fixed this then? I am seeing multiple solutions here. Either
> tune2fs or a newer kernel is the fix.
That's pretty much correct. It would be slightly more correct to say that
tune2fs provides a simple workaround (but presumably slows things down), and
2.4.25 has the fix.
|
