similar to: recovery notice on every reboot, errors writing to fs

Hey folks, I searched the list archives and found this : echo "AUTOFSCK_TIMEOUT=5" > /etc/sysconfig/autofsck echo "AUTOFSCK_DEF_CHECK=yes" >> /etc/sysconfig/autofsck http://lists.centos.org/pipermail/centos/2006-November/029837.html http://lists.centos.org/pipermail/centos/2009-September/thread.html#81934 Will this do all disks? I want to do a reboot of a couple

Hello, I looked through the archives a bit and could not find anything relevant, if you know otherwise please point me in the right direction. I have a ~3T ext3 filesystem on linux software raid that had been behaving corectly for sometime. Not to long ago it gave the following error after trying to mount it: mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many

Hi, I accidentally issued "mkswap" on a used ext3 fs partition (~30G) :-/ I have analyzed the behaviour of mkswap using two test files and it appears to only change "some" bytes: --8<-- --- swap2.xxd 2005-07-04 21:00:10.157261360 +0200 +++ swap1.xxd 2005-07-04 21:00:01.894517488 +0200 @@ -62,7 +62,7 @@ 00003d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................

Hey! I have some RHEL6 hypervisors and the VMs are in raw qemu image files in a local raid array linux raid + lvm + ext3. When a kernel update is installed a reboot is necessary, usually it has been more than 180 days since the last reboot and the file system is fsck'd and this takes 2-3 hours. I am curious to know if there is any documentation that addresses the pro's and con's of

Hi :) Yes, _I known_ that is a devel glibc version but all of my others daemon works fine, eventual will be rebuild, and all works fine, but not openssh - compiling without errors, but when I try run.. [root at link /root]# /usr/sbin/opensshd BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed! [root at link /root]# [root

Hey all.. I had a bad IDE controller that hosed my EXT3 filesystems. A resulting fsck damaged pat of the filesystem and the root inode is gone (on my main drive AND the backup drive). I immediately DD'd the main drive over to an identical drive that I have been working on. But every time.. a fsck destroys all the data (moves everything to lost+found) and nothing that I've found

Hi, I just converted all my hard disk filesystems from ext2 to ext3. This worked perfectly fine for all non-root fs, but I am having trouble converting the root fs, too. Here's what I did: 1. rebuilt my kernel (2.4.20, x86) with ext3 support linked in statically - no module. 2. Added a journal file to my root fs using 'tune2fs -j'. 3. Added 'rootfstype=ext3' to the

Hi, can anyone give me an example of when an fsck would repair something that the ext3 driver would not? with full "data=journal" journaling, would fsck ever need to be run if all the partitions were ext3? the ext3 mini-howto refers to "certain rare hardware failure cases (e.g. hard drive failures)" that would require a filesystem check, but doesn't go into details.

I have a damaged Ext3 filesystem which fsck has not been able to recover. If I try to mount it, I get a message like this in dmesg: EXT3-fs error (device sda1): ext3_free_blocks_sb: bit already cleared for block 2370866 If I try fsck on it, I get a series of messages like this: Inode bitmap for group 0 is not in group. (block 0) Relocate<y>? Up to group 95. Some say

I have many systems running current ext3 code. Some of them have hardware problems that lead to frequent reboots, and the journal recovery has worked excellently. However, on the periodic forced fsck on supposedly recovered and clean filesystems, I've many times seen fsck report that i_blocks is too large in one or more inodes. I suspect that i_blocks is somehow escaping proper restoration

Getting this oops on one of our production servers pretty much hangs the server. Do we have a corrupted Journal? how would ewe rebuild it? Any idea how to recover from it? Assertion failure in journal_bmap() at journal.c:636: "ret != 0" invalid operand: 0000 CPU: 0 EIP: 0010:[journal_bmap+70/96] Not tainted EIP: 0010:[<c016b646>] Not tainted EFLAGS: 00010282

Hi, We've got some units in client's vehicles which are running Fedora core 1. We've can log into them over ssh remotely there is no console attached to them. I suspect one of them has some filesystem corruption, and I'd like to both force a fsck at next reboot (which I think I can do with shutdown -F) but I'd also like to make this fsck not require any human intervention.

For some time now I have been puzzled as to why certain portions of my system boot were quite slow -- but only after journal recoveries. I was fearing that there was some ugly interaction between the recovery and the use of the journal shortly afterward but alas that is not the case. So just in case anybody else is seeing this problem and decides to try to hunt it down, let me save you some

Hello, a system here stopped because it had a hardware problem. We rebooted it and have now the following problem: The data disk /dev/hde1 is formatted as ext3. Obviously one of the inodes is bad and we get a lot of lines: Truncating prphaned inode 8863987 (uid=0, gid=0, mode=0100644, size=742) when running fsck. These lines have always the same values (inode, mode, ... are equal) and ar enow

Hi all, I have a bunch of mail servers running postfix (external smtp), qmail (LDA) and courier IMAP/POP. Frequently, Ext3 filesystem goes into read-only mode forcing recovery using fsck. Below are the errors we have seen so far on these systems and those systems config. The ext3 errors are common in many cases. 1. Red Hat Enterprise Linux Server release 5.2 (Tikanga) 2.6.18-92.1.10.el5

Hello all. I am currently using ext3 0.0.5d with great success. I am a bit conflicted about what to tell the system regarding my root filesystem however. I have my root filesystem configured and working as an ext3 filesystem, but it is/was not without some fraught. Using RedHat 7.0, if you simply create your journal on the root file- system, figure out it's inode number, issue a lilo -R

On 2015-01-07, Gordon Messmer <gordon.messmer at gmail.com> wrote: > > Of course, the other possibility is simply that you've formatted your > own filesystems, and they have a maximum mount count or a check > interval. If Les is having to run fsck manually, as he wrote in his OP, then this is unlikely to be the cause of the issues he described in that post. There must be

I have worked quite a bit with CentOS 4.x with SAN, multipathing, LVM etc. The way I mount my file systems is using a script that is called during startup that runs fsck, imports the physical volumes, and volume groups, activates the logical volumes, creates the mount point if needed then mounts the volume, I mainly made it for software iSCSI due to the iscsi stack loading after the system mount

Hi - I've been asked to turn on autofsck on ext3 filesystems for CentOS 4 and 5 servers on reboot after a crash by adding AUTOFSCK_TIMEOUT=5 AUTOFSCK_DEF_CHECK=yes to the file /etc/sysconfig/autofsck Is this necessary for ext3 filesystems? Is this a safe thing to do for a ext3 filesystems? I haven't used autofsck since the ext2 days. -- Agile --

Dear ext3 hackers, I'm running a RH 7.2 system with kernel 2.4.18 an a ext3 fs. Yesterday night this machine, which is being tested with a Proxy server (Squid), was accidentally power off (electrical outage). Now, when the system is booted, I have a ext2 'read only' fs; fsck doesn't find any kind of problem (automatic or manually executed: fsck -t ext3 /dev/sdb1). The only fstab