Re: 32bit chroot help
Thanks for the help. I really appreciate it works like a charm. Thanks, Bharath * Goswin von Brederlow ([EMAIL PROTECTED]) wrote: > Bharath Ramesh <[EMAIL PROTECTED]> writes: > > > I had recently posted in the group for suggestions on the best possible > > setup for a dual opteron compile/head node for our cluster. The solution > > for 32bit support was to install a chroot for compiling 32bit > > applications. I have a few questions on the best way to set up the 32bit > > chroot. > > > > 1) The base-config package has been dropped. Do I need to configure the > > 32bit chroot or I dont need to configure the chroot at all. > > Install sarge and dist-upgrade. > > > 2) We use nis for providing a single authentication system. From the > > documents I read I need to have a copy of my /etc/passwd, /etc/shadow > > and /etc/group in the 32bit chroot. Since I am using nis what would be > > the way to enable this. > > Setup nis inside the chroot just like outside the chroot. > > > I really appreciate the help given by all the debian developers and > > users. > > > > Thanks, > > > > Bharath > > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > --- Bharath Ramesh <[EMAIL PROTECTED]> http://people.cs.vt.edu/~bramesh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On 07/18/06 05:27:17PM +0200, Erik Mouw wrote: > On Tue, Jul 18, 2006 at 04:15:42PM +0200, Goswin von Brederlow wrote: > > Francesco Pietra <[EMAIL PROTECTED]> writes: > > The most recent FS is generaly the one with the most unfound bugs left > > and often a lot of design kinks that remain to be fixed. > > > > Something like ext2 on the other hand has all the bugs and kinks > > worked out over the years and there is very little new code that could > > go wrong. > > Ext3 should do as well. The same team that maintains ext2 also > maintains ext3. Ext3 is like ext2, but with journaling and directory > indexing. Bug fixes from ext3 get backported to ext2. > Ideally yes, but a lot of times bug fixes and other code changes don't get backported. From what I've seen very few people think "Hmm, I should check ext2 for that too" when they make a change to ext3. This isn't a knock on ext3, it's been extremely reliable in the places that I've used it and I would definitely recommend it over reiserfs any day, I'm just saying that ext2 and ext3 aren't really the same any more. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: two questions about packages
Wolfgang Mader wrote: Hello list, since a real long time, two months or so, aptitude always wants to upgrade the package libselinux from version 1.30-1 to version 1.30-1 This is not bad, I think but anoying. Has someone an idea. And another package is a bit strange. The new googleearth-package package. I installed it but this package seems to do nothing. It does not download any google-earth, installs an executable or does something else I was expecting from it. What to do which this thing. I want to try google-earth but if I execute the googleearth.bin I get the nice error: ./setup.sh: line 216: setup.data/bin/Linux/amd64/setup.gtk2: Datei oder Verzeichnis nicht gefunden ./setup.sh: line 216: setup.data/bin/Linux/amd64/setup.gtk: Datei oder Verzeichnis nicht gefunden The setup program seems to have failed on amd64 Fatal error, installer failed to run at all! So I wanted to try the package. Thank you in advance. W. Mader Hi, My german is not that good, but I think that, for googleearth, the installer is looking for xserver or something similar, and it does not fing it because you are running ./googleearthbin from root. Try it as a normal user, should work Thierry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
two questions about packages
Hello list, since a real long time, two months or so, aptitude always wants to upgrade the package libselinux from version 1.30-1 to version 1.30-1 This is not bad, I think but anoying. Has someone an idea. And another package is a bit strange. The new googleearth-package package. I installed it but this package seems to do nothing. It does not download any google-earth, installs an executable or does something else I was expecting from it. What to do which this thing. I want to try google-earth but if I execute the googleearth.bin I get the nice error: ./setup.sh: line 216: setup.data/bin/Linux/amd64/setup.gtk2: Datei oder Verzeichnis nicht gefunden ./setup.sh: line 216: setup.data/bin/Linux/amd64/setup.gtk: Datei oder Verzeichnis nicht gefunden The setup program seems to have failed on amd64 Fatal error, installer failed to run at all! So I wanted to try the package. Thank you in advance. W. Mader pgpnr5WNfybiH.pgp Description: PGP signature
Re: reiserfs/md1/failure/threads
On Tue, Jul 18, 2006 at 05:33:51PM +0200, Francesco Pietra wrote: > Not to insist any further on the relative merits of the various filesystems, > but in the general interest of maintaining amd64 (and therefore of > examinining parameters one at once, withouth mixing problems), did you notice > my e-mail of today emphasizing that after the crash my data are intact? I > wonder whether your suspicion about memory or cpu may be the point. How to > carry out a thourough memory test and identifying which slot is defective, if > any? Although Kingston ECC, one of the eight slots (1GB each) might be > defective. Well I have certainly seen a number of messages from people with opterons having memory problems over the last few months. The opteron seems to be very picky about memory quality, which makes some sense given have efficiently it uses it. It drives the memory quite hard. Simplest way I know of to test memory andd cpu, is to run a lot of large kernel compiles. Often a memory problem will cause that to segfault. Anything htat uses lots of cpu and lots of memory is usually a good test, at least if it fails spectacularly on an error, like gcc tends to do. To test the memory, remove half of it, and try the test. If it fails, replace one stick of memory with one of the other ones, until you can run the test without a problem. You could probably even run the test with 1 or 2 sticks of memory. A number of people have managed to find faulty memory on an opteron this way. Some people have come back going "I found a faulty stick of memory" after swearing that memtest86 had said all their ram was fine and they were sure their name brand ram wasn't faulty. :) memtest86 does't catch all errors. Of course with ECC memory I would have expected to see a machine check exception (MCE) if there was any single bit errors in the memory. I am still most inclined to blame reiserfs or perhaps the cpu. Of course since it was multiple errors all coming from reiserfs, with apparently nothing else seeing a problem, I really think it may simply be a reiserfs bug. I was using XFS before on early 2.6 kernels on i386, and even tually had to give up and move to ext3 since it just wasn't reliably on top of LVM on top of MD raid. The filesystem had some bad interaction with the LVM and MD raid that made it not work. It probably got fixed since, but I needed something that worked then, and ext3 worked. > What about checking the cpu? I can simply tell that I monitored the > temperature during the long calculation, with the machine in a strongly > ventilated area. Starting from 36C, the temp raised to 44C at maximum. I > don't know the correspondence with real temp ($sensors) but the difference > should tell. AMD for my 265 dual opterons indicates case temperature 49-67C > (is what I measured just case temp?). AMD also indicate as temp limits 10-35, > but I gues this should be the ambient temperatures. That temperature is fine as far as I can tell. > Also, how to check thouroghly the disks? Well there is badblocks which allows disk testing. In my experience though, modern disks tend to either work or fail. They very rarely have small problems. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tuesday 18 July 2006 19:15, Lennart Sorensen wrote: > On Tue, Jul 18, 2006 at 04:45:08PM +0200, Francesco Pietra wrote: > > On this suspicion, my relationships with reiserfs 3.6 are closed, as far > > as amd64 is concerned. > > > > That involves reinstalling amd 64 etch, I imagine. Could I start from > > raid1 installed and simply reform the file system or is it better start > > from scratch (I mean even to clarify the matter 32/64)? Perhaps it will > > be easier for me to start from scratch. Is it any suggestion about the > > install CD (to go then to a net install)? > > Well I know how I did my conversions of filesystems before, but it is > more tricky (but takes less time). > > I dropped one disk out of the raid, created a new degraded raid with it, > and made a filesystem on it, copied the data with cp -ax from the > current filesystem to the new one, then rebooted to the new filesystem > and added the old filesystem raid drive to the new raid. > > It might be simpler to just reinstall though using whatever method you > used before. You should be able to reuse the partition setup from > before, and just tell it to reassemble the raids and then pick the > filesystem and mount points again. Yes, this should be simpler for me. > > Of courses there is a small chance that you are dealing with a hardware > problem such as memory or cpu Not to insist any further on the relative merits of the various filesystems, but in the general interest of maintaining amd64 (and therefore of examinining parameters one at once, withouth mixing problems), did you notice my e-mail of today emphasizing that after the crash my data are intact? I wonder whether your suspicion about memory or cpu may be the point. How to carry out a thourough memory test and identifying which slot is defective, if any? Although Kingston ECC, one of the eight slots (1GB each) might be defective. What about checking the cpu? I can simply tell that I monitored the temperature during the long calculation, with the machine in a strongly ventilated area. Starting from 36C, the temp raised to 44C at maximum. I don't know the correspondence with real temp ($sensors) but the difference should tell. AMD for my 265 dual opterons indicates case temperature 49-67C (is what I measured just case temp?). AMD also indicate as temp limits 10-35, but I gues this should be the ambient temperatures. Also, how to check thouroghly the disks? Thanks a lot for your interest and advice francesco > or perhaps the disk (although with a raid > a disk error shouldn't behave as you are seeing). > > -- > Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tue, Jul 18, 2006 at 04:45:08PM +0200, Francesco Pietra wrote: > On this suspicion, my relationships with reiserfs 3.6 are closed, as far as > amd64 is concerned. > > That involves reinstalling amd 64 etch, I imagine. Could I start from raid1 > installed and simply reform the file system or is it better start from > scratch (I mean even to clarify the matter 32/64)? Perhaps it will be easier > for me to start from scratch. Is it any suggestion about the install CD (to > go then to a net install)? Well I know how I did my conversions of filesystems before, but it is more tricky (but takes less time). I dropped one disk out of the raid, created a new degraded raid with it, and made a filesystem on it, copied the data with cp -ax from the current filesystem to the new one, then rebooted to the new filesystem and added the old filesystem raid drive to the new raid. It might be simpler to just reinstall though using whatever method you used before. You should be able to reuse the partition setup from before, and just tell it to reassemble the raids and then pick the filesystem and mount points again. Of courses there is a small chance that you are dealing with a hardware problem such as memory or cpu or perhaps the disk (although with a raid a disk error shouldn't behave as you are seeing). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tuesday 18 July 2006 18:25, Lennart Sorensen wrote: > On Tue, Jul 18, 2006 at 07:15:33AM +0200, Francesco Pietra wrote: > > Because the matter is rather obscure to me, sent also CC to mpqc although > > it seems an exclusive problem of the OS. > > > > OS: Debian amd64 etch > > Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; > > raid1; temperature cpu low throughout. > > > > Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation > > for a large molecule, max_iterations = 40, memory = 5GB, launched as > > > > $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out > > > > all 40 iterations were completed in a couple of days, with "Optimization > > NOT converged". > > > > Restarted from the last minimum geometry, with memory = 7 GB, launched as > > > > $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee > > filename.out > > > > calculation hanged after ca 11 hours with warnings: > > > > ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in > > block 589839. Fsck? > > > > ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure > > occurred during tryong to find stat data of [7109 7110 0x0 SD] > > > > ReiserFS: warning: is_tree_node: node level 0 does not match to the > > expected one 1. > > > > and several other similar warnings. > > > > Thanks for suggestions > > Try a trusted filesystem instead. I stopped using reiserfs years ago > due to bugs in it. I wouldn't be surprised if it isn't 64bit clean > even. On this suspicion, my relationships with reiserfs 3.6 are closed, as far as amd64 is concerned. > > You either have a failing disk, or a buggy filesystem. > > Try ext3 instead. I haven't seen it fail yet. That involves reinstalling amd 64 etch, I imagine. Could I start from raid1 installed and simply reform the file system or is it better start from scratch (I mean even to clarify the matter 32/64)? Perhaps it will be easier for me to start from scratch. Is it any suggestion about the install CD (to go then to a net install)? Thank you francesco > -- > Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Texmaker fails to build on arm
On Tue, Jul 18, 2006 at 08:44:22AM -0600, Joseph Smidt wrote: > I uploaded texmaker-1.3-2 and built fine on every > architecture except arm. I am confused because texmaker-1.3-1 built > fine and is now in testing and all I thought I changed was the man-pages > and the package description. Could somebody take a look at the package > and help me find out why it is having trouble building on arm. I really > appreciate the help. Thanks. Well the log to me looks like a g++ bug, or possibly something in libqt, but probably the compiler. Too bad you can't tell which g++ version was installed at the time of the compile on each architecture's buildd. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tue, Jul 18, 2006 at 07:15:33AM +0200, Francesco Pietra wrote: > Because the matter is rather obscure to me, sent also CC to mpqc although it > seems an exclusive problem of the OS. > > OS: Debian amd64 etch > Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; raid1; > temperature cpu low throughout. > > Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation > for a large molecule, max_iterations = 40, memory = 5GB, launched as > > $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out > > all 40 iterations were completed in a couple of days, with "Optimization NOT > converged". > > Restarted from the last minimum geometry, with memory = 7 GB, launched as > > $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee > filename.out > > calculation hanged after ca 11 hours with warnings: > > ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in block > 589839. Fsck? > > ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure > occurred during tryong to find stat data of [7109 7110 0x0 SD] > > ReiserFS: warning: is_tree_node: node level 0 does not match to the expected > one 1. > > and several other similar warnings. > > Thanks for suggestions Try a trusted filesystem instead. I stopped using reiserfs years ago due to bugs in it. I wouldn't be surprised if it isn't 64bit clean even. You either have a failing disk, or a buggy filesystem. Try ext3 instead. I haven't seen it fail yet. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tue, Jul 18, 2006 at 04:15:42PM +0200, Goswin von Brederlow wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > The most recent FS is generaly the one with the most unfound bugs left > and often a lot of design kinks that remain to be fixed. > > Something like ext2 on the other hand has all the bugs and kinks > worked out over the years and there is very little new code that could > go wrong. Ext3 should do as well. The same team that maintains ext2 also maintains ext3. Ext3 is like ext2, but with journaling and directory indexing. Bug fixes from ext3 get backported to ext2. Very likely there will be an ext4 filesystem that starts with the same functionality as ext3, but will get extents and 64 bit block addressing (and problably other neat features on the go). Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tuesday 18 July 2006 16:15, Goswin von Brederlow wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > When installing the OS I thought that the most recent fs (reiserfs 3.6) > > were the most secure. Actually I have reiserfs on i386 (no raid) with no > > problem. Anyway, probably a warning against reiserfs on the installation > > disk or manual would avoid much troubles to users and advicers. > > > > Thanks a lot > > francesco pietra > > The most recent FS is generaly the one with the most unfound bugs left > and often a lot of design kinks that remain to be fixed. > > Something like ext2 on the other hand has all the bugs and kinks > worked out over the years and there is very little new code that could > go wrong. I was aware of this principle. However, principles are never absolute. Reiserfs 3.6 was offered at the Debian installation without warnings and I took it for good (I had also a long positive experience with reiserfs on i386, to my excuse). But the matter with amd64 may be more complex than it appears from the filesystems: I got a kernel (the last one from Debian) dump twice (reported here) while computing with mpqc, and it had nothing to do with hackers. In both cases the kernel was recovered with a reinstall, which did not take anything from repositories. I am also still wondering why I get /lib32 while I am installing a few things that supposedly require only /lib64. I got the naive impression that Debian amd64 is not mature for running mpqc. Luckily, the last useful computation can be easily recovered (until the HD allows so). Yours francesco pietra > > MfG > Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
I followed with interest high-level discussions on the filesystem problems for amd64 by Peter Yorke, Michael Marchand, Jo Shields, and Erik Mouw. However, at low level, I would be much obliged for suggestions about what to do with my system, where crash relateted to resiserfs 3.6 occurred while my data are intact. I suppose that scanning disks for possible defetcts, and recovering everything should be possible. How at best? thank you francesco Added info below On Tuesday 18 July 2006 10:09, Goswin von Brederlow wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > Because the matter is rather obscure to me, sent also CC to mpqc although > > it seems an exclusive problem of the OS. > > > > OS: Debian amd64 etch > > Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; > > raid1; temperature cpu low throughout. > > > > Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation > > for a large molecule, max_iterations = 40, memory = 5GB, launched as > > > > $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out > > > > all 40 iterations were completed in a couple of days, with "Optimization > > NOT converged". > > > > Restarted from the last minimum geometry, with memory = 7 GB, launched as > > > > $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee > > filename.out > > > > calculation hanged after ca 11 hours with warnings: > > > > ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in > > block 589839. Fsck? > > > > ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure > > occurred during tryong to find stat data of [7109 7110 0x0 SD] > > > > ReiserFS: warning: is_tree_node: node level 0 does not match to the > > expected one 1. > > > > and several other similar warnings. > > > > Thanks for suggestions > > > > francesco > > If you checkd the disks, cables, controler and parity of the raid Is any software command to partly fulfill your suggestions? > then > the only suggestion I can make is don't use reiserfs. When installing the OS I thought that the most recent fs (reiserfs 3.6) were the most secure. Actually I have reiserfs on i386 (no raid) with no problem. Anyway, probably a warning against reiserfs on the installation disk or manual would avoid much troubles to users and advicers. ADDED INFO: the system starts normally and I can read the out file from the mpqc calculation. I can recover the last geometry to restart the calculation. Does this mean that the hardware is OK and it was only a failure of reiserfs 3.6? thanks again francesco Thanks a lot francesco pietra > > MfG > Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
Francesco Pietra <[EMAIL PROTECTED]> writes: > When installing the OS I thought that the most recent fs (reiserfs 3.6) were > the most secure. Actually I have reiserfs on i386 (no raid) with no problem. > Anyway, probably a warning against reiserfs on the installation disk or > manual would avoid much troubles to users and advicers. > > Thanks a lot > francesco pietra The most recent FS is generaly the one with the most unfound bugs left and often a lot of design kinks that remain to be fixed. Something like ext2 on the other hand has all the bugs and kinks worked out over the years and there is very little new code that could go wrong. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recent sid amd64 rpath oddity?
Simon Huggins <[EMAIL PROTECTED]> writes: > Hi, > > On the 3rd May I built libxfce4util and generated > libxfce4util2_4.3.90.1-1_amd64.deb. This is in the archive exactly as I > built it. It has a couple of lintian failures that I missed and have since > been fixed in our SVN. > > Upstream have released recently and whilst checking these packages more > thoroughly I've fixed up the lintian errors but I've also built the new > package and I noticed that it's defining an rpath. So I rooted around and > tried to work out why but couldn't really work it out. Upstream's > libtool and autotools looked recent to me. If I relibtoolize though > this does go away. > > Out of curiousity I rebuilt the previous package i.e. 4.3.90.1-1 again from > the same source files as before but with current sid and this time it fails > with two extra lintian warnings: > W: libxfce4util2: binary-or-shlib-defines-rpath > ./usr/lib/libxfce4util.so.2.1.0 /usr/lib > W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/sbin/xfce4-kiosk-query > /usr/lib > > If I rebuild the same package on i386 current sid then I don't get the rpath > installed. > > I guess I have several questions: > - how can the same source package over a few months build > differently in this way? > - am I really going to have to relibtoolize every xfce package > before I upload or make them do it themselves? :-/ > - how evil is an rpath on /usr/lib anyway? > > I'd welcome any testers on amd64 or not and on recent sid or not to narrow > this down. Or any clues as to how on earth this can happen. > > If you do want to relibtoolize then install xfce4-dev-ools and run > xdt-autogen in the package dirrectory. Your package, or more likely libtool, has different ideas about what amd64 system library dirs are to what debian has. Other distributions use /usr/lib64 and debian has /usr/lib. That confuses libtool into adding a rpath. The fix is to force libtool to never ever use rpath. If you can't get libtool to leave well enough alone then use 'chrpath -d'. With rpath your package will afaik break when the library moves, e.g. to /usr/lib64 for biarch systems as we use at my workplace, or the multiarch /usr/lib/x86_64-linux-gnu directory. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
Erik Mouw <[EMAIL PROTECTED]> writes: > On Tue, Jul 18, 2006 at 12:01:31PM +0100, Jo Shields wrote: >> Reiser is lasting up better, but reiserfsck segfaults when it >> sees /home > > That means that the filesystem has errors. Reiserfsck is able to detect > them, but because nobody has seen those errors before it will segfault > on them. That also means that the reiserfs filesystem driver in the > kernel will happily screw the filesystem further up without notice. > Back up your data *NOW* before it's too late. That is such a joke and just shows how poor a quality the reiserfs code is. A segfault is always a bug in the software. You can't expect input, especialy in a repair program, to conform to any syntax. If the input data were always correct you wouldn't need checking and repairing. And there I was considering testing reiserfs due to fast resize operation yesterday. Now I'm happy that I didn't try. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apparent crashes persist.
On Thu, Jul 13, 2006 at 07:21:06AM -0400, [EMAIL PROTECTED] wrote: > On Wed, Jul 12, 2006 at 09:43:55PM -0500, Jaime Ochoa Malag?n wrote: > > An importat thing about havig ssh acces is the problem is not wqith > > the machine is with your applications, try vesa X driver... > > > > You could have only a unstable X... > > I'm currently running the vesa X driver. Previously I had the problem > with the nvidia X drivers. > > The problem shows up as dead mouse pointer. Which maked X pretty > useless. But if the system is in a state where it might expect keyboard > input, it continues to react to the keyboard. I can continue to enter a > URL into firefox (though it won't load a new one when I press enter), > and the tab key allows me to change panes in firefox -- tab between ads, > images, and so forth. However, the ctrl-alt-F* keys no longer work. > > In fact, the specificity of the problem suggests that it is probably not > a RAM problem at all. But it doesn't rule out other hardware, such as > maybe the mouse itself, or the USB controller the mouse plugs into. And it doesn't seem to be a problem with 64-bit cleanlines or with leftovers from tortuous upgrades. I installed 32-bit etch on a spare partition, with the same failures. It might be hardware, but probably not RAM. It might be a device-driver for one of the new nvidia chips on the AMD-64 motherboard (the reason why I'm using etch instead of stable). Still no idea how to track this down. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
A few other solutions I had with reiser Was seeing consistent sleepycat database corruption together with the type of log messages you described on MD softraids about 6 months ago I ended up dumping the reiser for xfs and upgrading the kernel from 2.6.8 to 2.6.12 For reasons of performance/stability/realiability, some of these systems needed 3ware raid controllers which required kernel upgrades to 2.6.16 I would have liked to have stayed with reiser, but it just didn't seem to behave well in the Debian amd64 OS Today I have over 100 happy Debian amd64 servers running 2.6.12/16 with xfs on soft and hard raid configurations Peter Peter Yorke Sr. Linux Server Engineer -- Thumb typed from a tiny keyboard. - Original Message - From: Jo Shields <[EMAIL PROTECTED]> To: Erik Mouw <[EMAIL PROTECTED]> Cc: Francesco Pietra <[EMAIL PROTECTED]>; debian-amd64@lists.debian.org ; [EMAIL PROTECTED] <[EMAIL PROTECTED]> Sent: Tue Jul 18 05:37:20 2006 Subject: Re: reiserfs/md1/failure/threads Erik Mouw wrote: > On Tue, Jul 18, 2006 at 12:01:31PM +0100, Jo Shields wrote: > >> Mickael Marchand wrote: >> >>> check your memory (yes it's going to be long, but that's almost always >>> the reason of reiserfs failures) >>> I am stressing hard reiserfs on various amd64/em64t boxes, no pbl so >>> far. >>> every box I found corrupting filesystems were having : >>> 1 - bad hard drives that a low scan confirmed >>> or 2 - bad memory that a real long memtest could detect >>> >>> Cheers, >>> Mik >>> >>> >> I'll add to this - I've seen corruption with all filesystems on my >> office desktop (which has screwed memory, but they refuse to fix it). >> EXT3 gave up on journalling & just started writing junk, costing me my >> /home. >> > > Ext2/ext3 complains about errors, but you normally don't see that > because it's hidden in the system log files. It's a good thing to mount > partitions with the "errors=remount-ro" option. If anything goes wrong, > the kernel will mount the partition read-only. Reboot+fsck will save > your data. > > >> Reiser is lasting up better, but reiserfsck segfaults when it >> sees /home >> > > That means that the filesystem has errors. Reiserfsck is able to detect > them, but because nobody has seen those errors before it will segfault > on them. That also means that the reiserfs filesystem driver in the > kernel will happily screw the filesystem further up without notice. > Back up your data *NOW* before it's too late. > Meh. I stopped using my desktop for real work a while back, since it locks up under load. If I ask nicely, they take my machine away for a week, sit on it, then give it back to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
Erik Mouw wrote: On Tue, Jul 18, 2006 at 12:01:31PM +0100, Jo Shields wrote: Mickael Marchand wrote: check your memory (yes it's going to be long, but that's almost always the reason of reiserfs failures) I am stressing hard reiserfs on various amd64/em64t boxes, no pbl so far. every box I found corrupting filesystems were having : 1 - bad hard drives that a low scan confirmed or 2 - bad memory that a real long memtest could detect Cheers, Mik I'll add to this - I've seen corruption with all filesystems on my office desktop (which has screwed memory, but they refuse to fix it). EXT3 gave up on journalling & just started writing junk, costing me my /home. Ext2/ext3 complains about errors, but you normally don't see that because it's hidden in the system log files. It's a good thing to mount partitions with the "errors=remount-ro" option. If anything goes wrong, the kernel will mount the partition read-only. Reboot+fsck will save your data. Reiser is lasting up better, but reiserfsck segfaults when it sees /home That means that the filesystem has errors. Reiserfsck is able to detect them, but because nobody has seen those errors before it will segfault on them. That also means that the reiserfs filesystem driver in the kernel will happily screw the filesystem further up without notice. Back up your data *NOW* before it's too late. Meh. I stopped using my desktop for real work a while back, since it locks up under load. If I ask nicely, they take my machine away for a week, sit on it, then give it back to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tue, Jul 18, 2006 at 12:01:31PM +0100, Jo Shields wrote: > Mickael Marchand wrote: > >check your memory (yes it's going to be long, but that's almost always > >the reason of reiserfs failures) > >I am stressing hard reiserfs on various amd64/em64t boxes, no pbl so > >far. > >every box I found corrupting filesystems were having : > >1 - bad hard drives that a low scan confirmed > >or 2 - bad memory that a real long memtest could detect > > > >Cheers, > >Mik > > > > I'll add to this - I've seen corruption with all filesystems on my > office desktop (which has screwed memory, but they refuse to fix it). > EXT3 gave up on journalling & just started writing junk, costing me my > /home. Ext2/ext3 complains about errors, but you normally don't see that because it's hidden in the system log files. It's a good thing to mount partitions with the "errors=remount-ro" option. If anything goes wrong, the kernel will mount the partition read-only. Reboot+fsck will save your data. > Reiser is lasting up better, but reiserfsck segfaults when it > sees /home That means that the filesystem has errors. Reiserfsck is able to detect them, but because nobody has seen those errors before it will segfault on them. That also means that the reiserfs filesystem driver in the kernel will happily screw the filesystem further up without notice. Back up your data *NOW* before it's too late. Reiserfs is much more vulnerable to disk errors cause it lacks redundancy: - There is only one superblock. If you loose it (bad block, for example) you *could* repair it with reiserfsck, but for that you need to know the hash type, which depends on the fileystem version, and the only place where that is documented is the superblock. If you guess it wrong, your data will be lost. - File connectivity is represented by a btree (b+tree, IIRC). If you loose some of the nodes high up in the tree, you can recover files, but where they belong in the tree is everybody's guess. Another interesting way to screw up reiserfs is to have an image of another reiserfs on a reiserfs partition. Reiserfsck will happily link the contents of that image into the containing partition damaging the partition beyond repair. Due to its traditional Unix disk layout, ext[23] doesn't have the problems reiserfs has. And ext2/ext3 is the only filesystem that has a regression test suite for its fsck, so errors in earlier e2fsck revision will not pop up again in later revisions. Sure, reiser4 will solve some of the problems I mentioned above, but it doesn't look like it will go into the kernel real soon now. See http://wiki.kernelnewbies.org/WhyReiser4IsNotIn , or tune in to the linux-kernel mailing list for the current reiser4 flamewar. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
Mickael Marchand wrote: check your memory (yes it's going to be long, but that's almost always the reason of reiserfs failures) I am stressing hard reiserfs on various amd64/em64t boxes, no pbl so far. every box I found corrupting filesystems were having : 1 - bad hard drives that a low scan confirmed or 2 - bad memory that a real long memtest could detect Cheers, Mik I'll add to this - I've seen corruption with all filesystems on my office desktop (which has screwed memory, but they refuse to fix it). EXT3 gave up on journalling & just started writing junk, costing me my /home. Reiser is lasting up better, but reiserfsck segfaults when it sees /home -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
check your memory (yes it's going to be long, but that's almost always the reason of reiserfs failures) I am stressing hard reiserfs on various amd64/em64t boxes, no pbl so far. every box I found corrupting filesystems were having : 1 - bad hard drives that a low scan confirmed or 2 - bad memory that a real long memtest could detect Cheers, Mik On Tue, Jul 18, 2006 at 07:15:33AM +0200, Francesco Pietra wrote: > Because the matter is rather obscure to me, sent also CC to mpqc although it > seems an exclusive problem of the OS. > > OS: Debian amd64 etch > Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; raid1; > temperature cpu low throughout. > > Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation > for a large molecule, max_iterations = 40, memory = 5GB, launched as > > $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out > > all 40 iterations were completed in a couple of days, with "Optimization NOT > converged". > > Restarted from the last minimum geometry, with memory = 7 GB, launched as > > $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee > filename.out > > calculation hanged after ca 11 hours with warnings: > > ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in block > 589839. Fsck? > > ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure > occurred during tryong to find stat data of [7109 7110 0x0 SD] > > ReiserFS: warning: is_tree_node: node level 0 does not match to the expected > one 1. > > and several other similar warnings. > > Thanks for suggestions > > francesco > > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
Added info below On Tuesday 18 July 2006 10:09, Goswin von Brederlow wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > Because the matter is rather obscure to me, sent also CC to mpqc although > > it seems an exclusive problem of the OS. > > > > OS: Debian amd64 etch > > Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; > > raid1; temperature cpu low throughout. > > > > Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation > > for a large molecule, max_iterations = 40, memory = 5GB, launched as > > > > $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out > > > > all 40 iterations were completed in a couple of days, with "Optimization > > NOT converged". > > > > Restarted from the last minimum geometry, with memory = 7 GB, launched as > > > > $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee > > filename.out > > > > calculation hanged after ca 11 hours with warnings: > > > > ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in > > block 589839. Fsck? > > > > ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure > > occurred during tryong to find stat data of [7109 7110 0x0 SD] > > > > ReiserFS: warning: is_tree_node: node level 0 does not match to the > > expected one 1. > > > > and several other similar warnings. > > > > Thanks for suggestions > > > > francesco > > If you checkd the disks, cables, controler and parity of the raid Is any software command to partly fulfill your suggestions? > then > the only suggestion I can make is don't use reiserfs. When installing the OS I thought that the most recent fs (reiserfs 3.6) were the most secure. Actually I have reiserfs on i386 (no raid) with no problem. Anyway, probably a warning against reiserfs on the installation disk or manual would avoid much troubles to users and advicers. ADDED INFO: the system starts normally and I can read the out file from the mpqc calculation. I can recover the last geometry to restart the calculation. Does this mean that the hardware is OK and it was only a failure of reiserfs 3.6? thanks again francesco Thanks a lot francesco pietra > > MfG > Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiserfs/md1/failure/threads
On Tuesday 18 July 2006 10:09, Goswin von Brederlow wrote: > Francesco Pietra <[EMAIL PROTECTED]> writes: > > Because the matter is rather obscure to me, sent also CC to mpqc although > > it seems an exclusive problem of the OS. > > > > OS: Debian amd64 etch > > Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; > > raid1; temperature cpu low throughout. > > > > Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation > > for a large molecule, max_iterations = 40, memory = 5GB, launched as > > > > $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out > > > > all 40 iterations were completed in a couple of days, with "Optimization > > NOT converged". > > > > Restarted from the last minimum geometry, with memory = 7 GB, launched as > > > > $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee > > filename.out > > > > calculation hanged after ca 11 hours with warnings: > > > > ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in > > block 589839. Fsck? > > > > ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure > > occurred during tryong to find stat data of [7109 7110 0x0 SD] > > > > ReiserFS: warning: is_tree_node: node level 0 does not match to the > > expected one 1. > > > > and several other similar warnings. > > > > Thanks for suggestions > > > > francesco > > If you checkd the disks, cables, controler and parity of the raid Is any software command to partly fulfill your suggestions? > then > the only suggestion I can make is don't use reiserfs. When installing the OS I thought that the most recent fs (reiserfs 3.6) were the most secure. Actually I have reiserfs on i386 (no raid) with no problem. Anyway, probably a warning against reiserfs on the installation disk or manual would avoid much troubles to users and advicers. Thanks a lot francesco pietra > > MfG > Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No sound on etch when using video players
Gudjon I. Gudjonsson wrote: Hi I might be off topic but I have had the problem with my sound card that /dev/dsp is not created at boot time. I need to create it myself mknod /dev/dsp c 14 3 chgrp audio /dev/dsp chmod 660 /dev/dsp then I can use realplayer and skype. Hope it helps and a solution would be very much appreciated:) /Gudjon or "modprobe snd-pcm-oss" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Recent sid amd64 rpath oddity?
Hi, On the 3rd May I built libxfce4util and generated libxfce4util2_4.3.90.1-1_amd64.deb. This is in the archive exactly as I built it. It has a couple of lintian failures that I missed and have since been fixed in our SVN. Upstream have released recently and whilst checking these packages more thoroughly I've fixed up the lintian errors but I've also built the new package and I noticed that it's defining an rpath. So I rooted around and tried to work out why but couldn't really work it out. Upstream's libtool and autotools looked recent to me. If I relibtoolize though this does go away. Out of curiousity I rebuilt the previous package i.e. 4.3.90.1-1 again from the same source files as before but with current sid and this time it fails with two extra lintian warnings: W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/lib/libxfce4util.so.2.1.0 /usr/lib W: libxfce4util2: binary-or-shlib-defines-rpath ./usr/sbin/xfce4-kiosk-query /usr/lib If I rebuild the same package on i386 current sid then I don't get the rpath installed. I guess I have several questions: - how can the same source package over a few months build differently in this way? - am I really going to have to relibtoolize every xfce package before I upload or make them do it themselves? :-/ - how evil is an rpath on /usr/lib anyway? I'd welcome any testers on amd64 or not and on recent sid or not to narrow this down. Or any clues as to how on earth this can happen. If you do want to relibtoolize then install xfce4-dev-ools and run xdt-autogen in the package dirrectory. Thanks. Simon. heh, good sigmonster. -- oOoOo Open source is about letting go of complete control. Accept oOoOo oOoOo the fact that other people are wonderful resources tooOoOo oOoOo fixing problems, and let them help you. - Linus Torvalds oOoOo htag.pl 0.0.22 ::: http://www.earth.li/~huggie/ signature.asc Description: Digital signature
Re: reiserfs/md1/failure/threads
Francesco Pietra <[EMAIL PROTECTED]> writes: > Because the matter is rather obscure to me, sent also CC to mpqc although it > seems an exclusive problem of the OS. > > OS: Debian amd64 etch > Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; raid1; > temperature cpu low throughout. > > Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation > for a large molecule, max_iterations = 40, memory = 5GB, launched as > > $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out > > all 40 iterations were completed in a couple of days, with "Optimization NOT > converged". > > Restarted from the last minimum geometry, with memory = 7 GB, launched as > > $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee > filename.out > > calculation hanged after ca 11 hours with warnings: > > ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in block > 589839. Fsck? > > ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure > occurred during tryong to find stat data of [7109 7110 0x0 SD] > > ReiserFS: warning: is_tree_node: node level 0 does not match to the expected > one 1. > > and several other similar warnings. > > Thanks for suggestions > > francesco If you checkd the disks, cables, controler and parity of the raid then the only suggestion I can make is don't use reiserfs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No sound on etch when using video players
Hi I might be off topic but I have had the problem with my sound card that /dev/dsp is not created at boot time. I need to create it myself mknod /dev/dsp c 14 3 chgrp audio /dev/dsp chmod 660 /dev/dsp then I can use realplayer and skype. Hope it helps and a solution would be very much appreciated:) /Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No sound on etch when using video players
Sam Varghese wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jul 14, 2006 at 09:46:27AM +0100 Jo Shields said: Sam Varghese wrote: On Thu, Jul 13, 2006 at 03:55:44PM -0400 Lennart Sorensen said: On Thu, Jul 13, 2006 at 08:47:29AM +1000, Sam Varghese wrote: Yes, the sound daemon is running. And the gstreamer packs are installed. The user is already a member of the audio group (which I presume is what you mean). Same situation. Sound with CDs, not with videos or DVDs. Is mixer volume for PCM set high enough and unmuted? Playing audio CDs use one of the line in volume settings after all, not PCM. That's fine as well. It's just a mystery to me. And very frustrating as well. Thanks for the tip anyway. If you have a digital output switch mixer, mute/unmute it e.g. http://apebox.org/modules/images//Miscelaneous%20Junk/digitalout.png I've looked long and hard for an equaliser similar to this but can't find one. What's the name of the app in the link you provided? Thanks, Sam It's probably xfce4-mixer, but you'll find the same functionality in alsamixer or alsamixergui too -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 32bit chroot help
Bharath Ramesh <[EMAIL PROTECTED]> writes: > I had recently posted in the group for suggestions on the best possible > setup for a dual opteron compile/head node for our cluster. The solution > for 32bit support was to install a chroot for compiling 32bit > applications. I have a few questions on the best way to set up the 32bit > chroot. > > 1) The base-config package has been dropped. Do I need to configure the > 32bit chroot or I dont need to configure the chroot at all. Install sarge and dist-upgrade. > 2) We use nis for providing a single authentication system. From the > documents I read I need to have a copy of my /etc/passwd, /etc/shadow > and /etc/group in the 32bit chroot. Since I am using nis what would be > the way to enable this. Setup nis inside the chroot just like outside the chroot. > I really appreciate the help given by all the debian developers and > users. > > Thanks, > > Bharath MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 stable release signature problems?
Jo Shields <[EMAIL PROTECTED]> writes: > Török Edvin wrote: >> Hi, >> >> Today I got this error while running `aptitude update`: >> >> W: GPG error: http://amd64.debian.net stable Release: The following >> signatures were invalid: BADSIG E415B2B4B5F5BBED Debian AMD64 Archive >> Key >> >> >> The Release file for testing and sid are fine. What is going on, did >> the release file get corrupt? >> FYI: I am using sid, but I kept stable in my sources.list, now that >> there are key problems, I've deleted it from sources.list. But still, >> why this error? >> >> Thanks, >> Edwin > > AMD64 Stable is not an official Debian project, and is not signed with > official Debian keys. Doh, it is BADSIG. That means the signature in Release.gpg does not match the Release file. Doesn't matter who signed it or if the key is known, it is just broken. Ganneff, can you check this and comment? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reiserfs/md1/failure/threads
Because the matter is rather obscure to me, sent also CC to mpqc although it seems an exclusive problem of the OS. OS: Debian amd64 etch Hardw: Tyan S2895 K8WE; two 265 dual opteron; 8GB ram Kingston ECC; raid1; temperature cpu low throughout. Process: mpqc 2.3.1 calc b3lyp geom optimization MCsearch OO calculation for a large molecule, max_iterations = 40, memory = 5GB, launched as $mpqc -messagegrp ":(n=4)" filename.in | tee filename.out all 40 iterations were completed in a couple of days, with "Optimization NOT converged". Restarted from the last minimum geometry, with memory = 7 GB, launched as $ mpqc -threadgrp ":(num_threads=4)" filename.in | tee filename.out calculation hanged after ca 11 hours with warnings: ReiserFS: md1: warning: vs-5150: searchby key: invalid format found in block 589839. Fsck? ReiserFS: md1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred during tryong to find stat data of [7109 7110 0x0 SD] ReiserFS: warning: is_tree_node: node level 0 does not match to the expected one 1. and several other similar warnings. Thanks for suggestions francesco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
