A long long time ago, I can still remember... My computer hosed itself
(power out as I recall), and then when it was coming back up and running
e2fsck, the power went out again - perhaps not the exact situation, but
suffice to say, init ended up running e2fsck on my drive, and filling
/lost+found/ with lots of garbage, most of which I needed.
I managed to easily clean it out, with one exception. And a friend
recently suggested posting it to this list. Can anyone here
explain what on earth is going on, and how to get rid of it?
Incidentally, it's been around since a custom-compiled 2.3.x (where x > 40
I believe), and has been impervious to my fixing ever since.
Also, I'm not subscribed, so please, any replies CC'ed to
[email protected], I'd appreciate it.
Here's the problem(s) (or at least, the symptoms):
sentry21@Petra:1:/lost+found$ ls -l
total 0
lr----S--- 1 52 12337 0 Nov 1 2022 #3147 ->
sentry21@Petra:0:/lost+found$ file \#3147/
#3147/: directory
sentry21@Petra:0:/lost+found$ rm -rf \#3147/
rm: cannot unlink `#3147': Permission denied
sentry21@Petra:1:/lost+found$ sudo rm -rf \#3147/
rm: cannot unlink `#3147': Operation not permitted
sentry21@Petra:1:/lost+found$ sudo chown sentry21.sentry21 \#3147/
chown: changing ownership of `#3147': Operation not permitted
sentry21@Petra:1:/lost+found$ cd \#3147/
sentry21@Petra:0:/lost+found/#3147$ ls
#3147@
sentry21@Petra:0:/lost+found/#3147$ cd \#3147/
sentry21@Petra:0:/lost+found/#3147/#3147$ ls
#3147@
sentry21@Petra:0:/lost+found/#3147/#3147$ cd
\#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/
sentry21@Petra:0:/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147$ ls
#3147@
sentry21@Petra:0:/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147$ pwd
/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147
sentry21@Petra:0:/lost+found/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147/#3147$ file \#3147/
#3147/: directory
Weird, ne? I -did- manage to make it -not rwxrwxrwx, suid, sgid, sticky,
and every other bloody FS flag you can stick on a directory (and lots you
can't), but it's still impervious to my sk|llz. It's not hurting anything,
but cron whines about it every day.
Thanks.
--Dan
> On Thu, 26 Jul 2001 [email protected] wrote:
> [SNIPPED...]
> >
> > Here's the problem(s) (or at least, the symptoms):
> >
> > sentry21@Petra:1:/lost+found$ ls -l
> > total 0
> > lr----S--- 1 52 12337 0 Nov 1 2022 #3147 ->
> >
>
> Did you try..
> # rm -r lost+found
> # mklost+found
>
> Without knowing how to use the ext2fs tools, and not wanting to
> risk more damage, I tried this and it worked when I had such a
> crash-induced problem.
sentry21@Petra:1:/$ sudo rm -rf lost+found/
rm: cannot unlink `lost+found/#3147': Operation not permitted
rm: cannot remove directory `lost+found': Directory not empty
Dang.
--Dan
On Thu, 26 Jul 2001 [email protected] wrote:
[SNIPPED...]
>
> Here's the problem(s) (or at least, the symptoms):
>
> sentry21@Petra:1:/lost+found$ ls -l
> total 0
> lr----S--- 1 52 12337 0 Nov 1 2022 #3147 ->
>
Did you try..
# rm -r lost+found
# mklost+found
Without knowing how to use the ext2fs tools, and not wanting to
risk more damage, I tried this and it worked when I had such a
crash-induced problem.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
> sentry21@Petra:1:/$ sudo rm -rf lost+found/
> rm: cannot unlink `lost+found/#3147': Operation not permitted
> rm: cannot remove directory `lost+found': Directory not empty
>
>
> Dang.
Perhaps:
debugfs -w <your root filesystem>
unlink /lost+found/#3147
On Thu, Jul 26, 2001 at 11:04:48AM -0400, [email protected] wrote:
> sentry21@Petra:1:/$ sudo rm -rf lost+found/
> rm: cannot unlink `lost+found/#3147': Operation not permitted
> rm: cannot remove directory `lost+found': Directory not empty
Have you tried "chattr -i \#3147" and then "rm -rf \#3147"?
--
Sven Vermeulen - Key-ID CDBA2FDB
LUG: http://www.lugwv.be - http://www.keyserver.net
> > sentry21@Petra:1:/$ sudo rm -rf lost+found/
> > rm: cannot unlink `lost+found/#3147': Operation not permitted
> > rm: cannot remove directory `lost+found': Directory not empty
>
> Perhaps:
>
> debugfs -w <your root filesystem>
> unlink /lost+found/#3147
root@Petra:0:~# debugfs -w /
debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
/: Is a directory while opening filesystem
debugfs: ^D
root@Petra:0:~# debugfs -w /dev/hda5
debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
debugfs: unlink /lost+found/#3147
debugfs: ^D
root@Petra:0:~# cd /lost+found/
root@Petra:0:/lost+found# ls -l
total 0
lr----S--- 1 52 12337 0 Nov 1 2022 #3147 ->
root@Petra:0:/lost+found#
Apparantly I wasn't joking when I said 'immortal'.
--Dan
On Thursday 26 July 2001 16:37, [email protected] wrote:
> sentry21@Petra:1:/lost+found$ cd \#3147/
>
> sentry21@Petra:0:/lost+found/#3147$ ls
> #3147@
It's linked to itself.
--
Daniel
> > root@Petra:0:~# debugfs -w /
> > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > /: Is a directory while opening filesystem
> > debugfs: ^D
> >
> > root@Petra:0:~# debugfs -w /dev/hda5
> > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > debugfs: unlink /lost+found/#3147
> > debugfs: ^D
> ^^^^^^^^
> How about 'Q' so debugfs gets to write the modifications to the
> drive?
root@Petra:0:/lost+found# debugfs -w /dev/hda5
debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
debugfs: unlink /lost+found/#3147
unlink_file_by_name: No free space in the directory
This is getting weirder and weirder.
--Dan
On Thu, 26 Jul 2001 [email protected] wrote:
> > > sentry21@Petra:1:/$ sudo rm -rf lost+found/
> > > rm: cannot unlink `lost+found/#3147': Operation not permitted
> > > rm: cannot remove directory `lost+found': Directory not empty
> >
> > Perhaps:
> >
> > debugfs -w <your root filesystem>
> > unlink /lost+found/#3147
>
> root@Petra:0:~# debugfs -w /
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> /: Is a directory while opening filesystem
> debugfs: ^D
>
> root@Petra:0:~# debugfs -w /dev/hda5
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> debugfs: unlink /lost+found/#3147
> debugfs: ^D
^^^^^^^^
>
How about 'Q' so debugfs gets to write the modifications to the
drive?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
Try lsattr ./#3147 and see if the i attribute is set. If so, then (as root) do
chattr -i ./#3147 and try again to remove it.
Wayne
[email protected] on 07/26/2001 10:04:48 AM
To: "Richard B. Johnson" <[email protected]>
cc: [email protected] (bcc: Wayne Brown/Corporate/Altec)
Subject: Re: Weird ext2fs immortal directory bug
> On Thu, 26 Jul 2001 [email protected] wrote:
> [SNIPPED...]
> >
> > Here's the problem(s) (or at least, the symptoms):
> >
> > sentry21@Petra:1:/lost+found$ ls -l
> > total 0
> > lr----S--- 1 52 12337 0 Nov 1 2022 #3147 ->
> >
>
> Did you try..
> # rm -r lost+found
> # mklost+found
>
> Without knowing how to use the ext2fs tools, and not wanting to
> risk more damage, I tried this and it worked when I had such a
> crash-induced problem.
sentry21@Petra:1:/$ sudo rm -rf lost+found/
rm: cannot unlink `lost+found/#3147': Operation not permitted
rm: cannot remove directory `lost+found': Directory not empty
Dang.
--Dan
On Thu, 26 Jul 2001 [email protected] wrote:
> > > root@Petra:0:~# debugfs -w /
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > /: Is a directory while opening filesystem
> > > debugfs: ^D
> > >
> > > root@Petra:0:~# debugfs -w /dev/hda5
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > debugfs: unlink /lost+found/#3147
> > > debugfs: ^D
> > ^^^^^^^^
> > How about 'Q' so debugfs gets to write the modifications to the
> > drive?
>
> root@Petra:0:/lost+found# debugfs -w /dev/hda5
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> debugfs: unlink /lost+found/#3147
> unlink_file_by_name: No free space in the directory
>
>
> This is getting weirder and weirder.
>
Okay, the file is a link, linked to /lost+found. So, using debugfs,
just remove the directory:
# debugfs -w /dev/hda5
debugfs: rmdir /lost+found
My debugfs is too old, so the above command replies with "Unimplemented".
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
<[email protected]> said:
> > > root@Petra:0:~# debugfs -w /
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > /: Is a directory while opening filesystem
> > > debugfs: ^D
> > >
> > > root@Petra:0:~# debugfs -w /dev/hda5
> > > debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> > > debugfs: unlink /lost+found/#3147
> > > debugfs: ^D
> > ^^^^^^^^
> > How about 'Q' so debugfs gets to write the modifications to the
> > drive?
>
> root@Petra:0:/lost+found# debugfs -w /dev/hda5
> debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> debugfs: unlink /lost+found/#3147
> unlink_file_by_name: No free space in the directory
What machine is that? e2fsprogs-1.22 had some similar weird effects on
SPARC with kernel 2.4.x, 1.20 works fine AFAICS.
You can try nuking the directory (clear_inode or such) and have fsck(8)
pick up the resulting fallout.
--
Dr. Horst H. von Brand Usuario #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Dan writes:
> sentry21@Petra:1:/lost+found$ sudo rm -rf \#3147/
> rm: cannot unlink `#3147': Operation not permitted
>
> Weird, ne? I -did- manage to make it -not rwxrwxrwx, suid, sgid, sticky,
> and every other bloody FS flag you can stick on a directory (and lots you
> can't), but it's still impervious to my sk|llz. It's not hurting anything,
> but cron whines about it every day.
Run "debugfs -w /dev/hdX", and then:
debugfs> mi <3147>
# set Mode to 0
# set Deletion time to something other than 0
# set Link count to 0
# set Block count to 0
# set File flags to 0
debugfs> freei <3147>
debugfs> q
e2fsck -f /dev/hdX
Cheers, Andreas
--
Andreas Dilger Turbolinux filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Thu, 26 Jul 2001 [email protected] wrote:
>
>
> Try lsattr ./#3147 and see if the i attribute is set. If so, then
> (as root) do
> chattr -i ./#3147 and try again to remove it.
>
> Wayne
If you try that from a shell, it may fail because '#' means
"ignore everything thereafter", so you are trying to do muck
with the directory. I think:
chattr -i ./\#3147 had ought to do it.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
In order to avoid flooding the list and everyone else with replies to all
the e-mails I've recieved, I'm going to put them all in one. Hope this
doesn't cause anyone problems.
One of the suggestions -did- work, but I thought I should post replies to
the rest of the suggestions where possible, so that people know what
worked and what didn't.
Here's the summary:
----
>From Daniel Phillips <[email protected]>:
> > sentry21@Petra:1:/lost+found$ cd \#3147/
> >
> > sentry21@Petra:0:/lost+found/#3147$ ls
> > #3147@
>
> It's linked to itself.
Yes, it's a directory as well as a symlink to itself. It, quite frankly,
should not exist. Go figure.
----
>From Christopher Allen Wing <[email protected]>:
> You can remove it using the 'debugfs' program. The safest way to do this
> is to boot your machine to single user mode, and then do:
>
> mount -o remount,rw /
> sync
> debugfs -w /dev/device_that_/_is_mounted_on
>
> then at the debugfs: prompt
>
> cd /lost+found
> rm #3147
> close
> quit
>
>
> Then:
> sync
> reboot
>
> and it should be gone.
This worked admirably, my thanks.
----
>From [email protected]:
> Try lsattr ./#3147 and see if the i attribute is set. If so, then (as
> root) do chattr -i ./#3147 and try again to remove it.
I tried this, after doing 'chattr -AacdijsSu ./#3147' (which did not
help), and tried removing after both, which did not work.
----
>From Richard B. Johnson <[email protected]>:
> Okay, the file is a link, linked to /lost+found. So, using debugfs,
> just remove the directory:
> # debugfs -w /dev/hda5
> debugfs: rmdir /lost+found
>
> My debugfs is too old, so the above command replies with "Unimplemented".
As did mine - the version in Debian Unstable, which I assume is the latest
(debugfs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09).
----
>From Horst von Brand <[email protected]>:
> What machine is that? e2fsprogs-1.22 had some similar weird effects on
> SPARC with kernel 2.4.x, 1.20 works fine AFAICS.
i386, pretty standard boring stuff.
> You can try nuking the directory (clear_inode or such) and have fsck(8)
> pick up the resulting fallout.
This was going to be my next step, if the suggestion that worked hadn't.
----
>From Andreas Dilger <[email protected]>:
> Run "debugfs -w /dev/hdX", and then:
>
> debugfs> mi <3147>
> # set Mode to 0
> # set Deletion time to something other than 0
> # set Link count to 0
> # set Block count to 0
> # set File flags to 0
> debugfs> freei <3147>
> debugfs> q
>
> e2fsck -f /dev/hdX
e2fsck complained about the file not being attached, and attached it to
lost+found - basically, the exact same thing that happened in the first
place. Go figure. Suffice to say, this also did not work.
----
>From Richard B. Johnson <[email protected]>:
> If you try that from a shell, it may fail because '#' means
> "ignore everything thereafter", so you are trying to do muck
> with the directory. I think:
>
> chattr -i ./\#3147 had ought to do it.
bash (and likely others) will figure out that #filename is a directory if
the # is part of a string blah#blah, and will only treat it as a comment
if there is a space in front of it.
----
Thank you all for your help and efforts in solving this extremely peculiar
bug. I still have no idea why it happened, but now that it's gone, cron
should rest happily at night.
Cheers.
--Dan
I am assuming that the problem here was that fsck restored a lost inode to
lost+found, but the inode had been corrupted and had the immutable bit
set.
It should be pointed out that there is currently no way to modify ext2
attributes for symlinks or device files, because ext2 attributes are
implemented via an ext2-specific ioctl(). You can't open() symlinks to
even attempt an ioctl, and ioctl on a device file goes directly to the
device, skipping ext2's ioctl method.
So, in the long term do we need some sort of lchflags() system call to
operate on names?
At the very least, ext2 fsck should complain about ext2 attributes set for
symlinks or device files... I have had this same problem myself many times
on machines with bad SCSI termination- I end up with unremovable device
files thanks to a bogus immutable bit and have to use debugfs to get rid
of them.
-Chris Wing
[email protected]
On Thu, 26 Jul 2001 [email protected] wrote:
> In order to avoid flooding the list and everyone else with replies to all
> the e-mails I've recieved, I'm going to put them all in one. Hope this
> doesn't cause anyone problems.
> I am assuming that the problem here was that fsck restored a lost inode to
> lost+found, but the inode had been corrupted and had the immutable bit
> set.
Which would actually be an fsck bug, since such an inode isnt legal and cant
be fixed by normal means
Chris Wing writes:
> I am assuming that the problem here was that fsck restored a lost inode to
> lost+found, but the inode had been corrupted and had the immutable bit
> set.
>
> At the very least, ext2 fsck should complain about ext2 attributes set for
> symlinks or device files... I have had this same problem myself many times
> on machines with bad SCSI termination- I end up with unremovable device
> files thanks to a bogus immutable bit and have to use debugfs to get rid
> of them.
It should actually assume that such inodes are corrupt, and either just
delete them at e2fsck time, or at least clear the "bad" parts of the inode
before sticking it in lost+found.
Cheers, Andreas
PS - I CC'd Ted on this, as he can probably fix this a lot faster than I
(I may be able to fix it during another OLS presentation today or
tomorrow).
--
Andreas Dilger Turbolinux filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Thu, 26 Jul 2001, Andreas Dilger wrote:
> It should actually assume that such inodes are corrupt, and either just
> delete them at e2fsck time, or at least clear the "bad" parts of the inode
> before sticking it in lost+found.
I had this happen to me once before. I did something bad, and when I
started my machine up again, I got a couple of files in lost+found. I
couldn't delete two of them.
I posted my trouble here, and I got many of the same hints I've seen given
this time around.
What just made me think, is you just said that e2fsck should clean up this
problem before putting it in lost+found. That is probally a good idea.
But it was also half way to my solution. e2fsck did know there was
something wrong with the inodes, but since it marked the disk clean the
first time it was run it wouldn't bother looking over the disk upon
farther reboots. I wasn't comfortable with figuring out how to use
debugfs, so I just left the 2 bad files there. Until I did something
else silly and another fsck was forced. Upon being run the second time
e2fsck did notice something out of order and fixed up the files so I could
delete them.
So yes, e2fsck probally should have noticed the problem the first time
through and not written a funky file to lost+found. But this might be a
possible solution for the orginal poster of the message. Just force a
check right now and see if it gets fixed.
-Chris
--
Two penguins were walking on an iceberg. The first penguin said to the
second, "you look like you are wearing a tuxedo." The second penguin
said, "I might be..." --David Lynch, Twin Peaks
Chris Wing writes:
> At the very least, ext2 fsck should complain about ext2 attributes set for
> symlinks or device files... I have had this same problem myself many times
> on machines with bad SCSI termination- I end up with unremovable device
> files thanks to a bogus immutable bit and have to use debugfs to get rid
> of them.
I checked, and at least recent versions of e2fsck complain/fix immutable
flags on device files, fifos, and sockets. The below check disallows
immutable or append-only flags on symlinks (on the grounds that it is not
possible to set these legally).
Now what I need to do is also add an e2fsck test case for this...
Cheers, Andreas
===========================================================================
--- 1.56/e2fsck/pass1.c Thu Jul 19 14:31:24 2001
+++ edited/e2fsck/pass1.c Thu Jul 26 16:18:59 2001
@@ -559,6 +563,7 @@
check_size(ctx, &pctx);
ctx->fs_blockdev_count++;
} else if (LINUX_S_ISLNK (inode.i_mode)) {
+ check_immutable(ctx, &pctx);
ctx->fs_symlinks_count++;
if (!inode.i_blocks) {
if (inode.i_size_high ||
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
It should probably not allow things to be both a directory and a symlink
as well. I asked the original poster and he indicated the permissions
were "all on" when he first discovered the file. Clearly that's not
a combination fsck should let pass.
Gerhard
On Thu, 26 Jul 2001, Andreas Dilger wrote:
> Chris Wing writes:
> > I am assuming that the problem here was that fsck restored a lost inode to
> > lost+found, but the inode had been corrupted and had the immutable bit
> > set.
> >
> > At the very least, ext2 fsck should complain about ext2 attributes set for
> > symlinks or device files... I have had this same problem myself many times
> > on machines with bad SCSI termination- I end up with unremovable device
> > files thanks to a bogus immutable bit and have to use debugfs to get rid
> > of them.
>
> It should actually assume that such inodes are corrupt, and either just
> delete them at e2fsck time, or at least clear the "bad" parts of the inode
> before sticking it in lost+found.
>
> Cheers, Andreas
>
> PS - I CC'd Ted on this, as he can probably fix this a lot faster than I
> (I may be able to fix it during another OLS presentation today or
> tomorrow).
> --
> Andreas Dilger Turbolinux filesystem development
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.