(Sorry for the delay in getting back to you; I've been travelling.)
Hmm, looking at what you sent me, it looks like DFSee was being
"clever". It looks like it deliberately put something which looks
like almost exactly like a FAT12/FAT16 header, passing all of the
normal checks one might make for
FYI, this is what I've checked into the e2fsprogs git repository.
- Ted
commit 8305cdf401b05e3748b87d0b63c4fa5bad8f8eb6
Author: Theodore Ts'o <[EMAIL PROTECTED]>
Date: Sat Aug 23 22:11:01 2008 -0400
libblkid: Fix false de
probe order of the
tests around. (The patch to explicitly check for DFSee should solve
your particular issue.)
- Ted
commit ddd46b9b85c158fb51c0ba45ec11b7c032fb457f
Author: Theodore Ts'o <[EMAIL PROTECTED]>
Date: Sat Aug 23 22:27:22
n, for your comments, they have been very
helpful!
- Ted
P.S. Here's the new version of the patch which I've applied to blkid.
commit 78d89cda680498957e4ad78602751d1f905cee08
Author: Theodore Ts'o <[EMAIL PROTECTED]>
Date: Sat Aug 23
The fix for this problem was released in e2fsprogs 1.40.7, and Hardy is
shipping e2fsprogs 1.40.8. Hence this bug is fixed in the latest
shipping version of Ubuntu.
** Changed in: e2fsprogs (Ubuntu)
Status: Confirmed => Fix Released
--
e2fsck forces reboot when clearing LARGE_FILE flag
*** This bug is a duplicate of bug 257048 ***
https://bugs.launchpad.net/bugs/257048
** This bug has been marked a duplicate of bug 257048
e2fsck crashed with SIGSEGV in strlen()
--
fsck.ext3 crashed with SIGSEGV in strlen()
https://bugs.launchpad.net/bugs/257049
You received this bug not
By definition a kernel panic is a linux kernel problem and not a
userspace bug. There should be nothing that a user program can do that
should be able to trigger a kernel panic, without a kernel bug. In this
case, the bug isn't even in any ext3 filesystem code, but rather a
kernel soft lockup whi
On Mon, Aug 25, 2008 at 11:22:43PM -, boga wrote:
> So I guess your latest idea is correct: if a boot sector looks like
> FAT12/16 and contains "JFS " or "HPFS " at 0x36 then it is not
> FAT. However are you sure about memcmp(ms->ms_magic, "JFS ", 8) and
> memcmp(ms->ms_magic, "HPFS ", 8) ? Th
What kind of applications are these? 32-bit or 64-bit?Could this
be as simple as not installing the 32-bit version of this shared
library? What does ldd on an affected application return? The output
of "objdump -x /usr/bin/" would also be useful.
Does it show up in Intrepid, or only i
No, this is deliberate, and it's always been this way. The UUID
generator follows the algorithm set forth in RFC 4122:
4.1.5. Clock Sequence
For UUID version 1, the clock sequence is used to help avoid
duplicates that could arise when the clock is set backwards in time
or if the node
Please send the output of dumpe2fs -h on the filesystem before and after
running e2fsck -f. Tihs is normally due to buggy initscripts and an
incorrect system clock when the filesystems are mounted and/or checked.
The debian bug has been closed because it has been fixed under debian
when their in
Another possibility is to use the Karmic kernel but keep a Jaunty
userspace. I haven't tried this myself, but I suspect it is highly
likely to work.
As far as people complaining --- please note that (a) Ubuntu has not
made this the default, and (b) when I talked to the Canonical kernel
team, the
P.S. There is a known ext4 file system corruption bug which is fixed in
the 2.6.30 mainline kernel and in 2.6.29.5. It was found after the
stable kernel series stopped updating for 2.6.28, but I do carry a fix
for it in my for-stable-2.6.28 branch of the ext4 git tree, located
here:
git
On Fri, Jun 19, 2009 at 04:49:19PM -, Derek wrote:
> >git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> > for-stable-2.6.28
> >
> > http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=shortlog;h=for-stable-2.6.28
> >
> > (This is where it's handy to have a
On Thu, Jun 04, 2009 at 04:26:20AM -, Hyperfitz wrote:
> Wow, this is constructive. For the record, there is nothing wrong with my
> file system. There is, however, something wrong with the check that happens
> at boot. It is not user error, sorry if you think otherwise--doesn't change
> the fa
Hyperfitz,
Can you open a new bug report, please?*Please* don't assume that
just because you have the same symptoms as someone else, that it is the
same bug.
If two people went to the doctor, both complaining of a headache, one
might just have the flu, and another might have brain cancer. I
Thanks for reporting this documentation bug. I've checked in a fix for
the man pages of mke2fs (and e2fsck, and dumpe2fs, and resize2fs, and
debugfs, et. al.), and it will be fixed in e2fsprogs 1.41.6.
--
man pages for mkfs.ex4
https://bugs.launchpad.net/bugs/381854
You received this bug notifi
On Sat, May 30, 2009 at 04:28:53PM -, Hyperfitz wrote:
>
> Sure, if I have this problem again I will do all of this stuff that you ask.
> But the name of the thread is "filesystem check fails on boot, but
> filesystem isn't bad." This is a problem that it seems that not only I have
> had. I th
Jose, please open a separate bug, as this is an entirely different
problem. (I really hate Ubuntu bugs that have a generic description,
because it seems to generate "Ubuntu Launchpad Syndrome" --- a problem
which seems to cause users to search for bugs, see something that looks
vaguely similar, a
Public bug reported:
Binary package hint: e2fsprogs
I have found a SERIOUS regression in e2fsprogs 1.41.5, which causes
e2fsck to undo updates to the block group descriptors when replaying a
journal for a filesystem which was not cleanly unmounted. Fortunately,
most Ubuntu users with a single e
** Attachment added: "Commit 27a407d which fixes this bug"
http://launchpadlibrarian.net/27181055/0001-e2fsck-Fix-journal-replay-bug-which-reverts-changes-.patch
--
e2fsck will corrupt filesystems when replaying journal
https://bugs.launchpad.net/bugs/380727
You received this bug notificatio
Here is a test case which shows the problem. Without the patch,
"e2fsck -f journal-test.img" will show multiple filesystem
inconsistencies. This filesystem image was created by running the
command "for i in `seq 1 1`; do echo $i; touch $i ; sleep 0.10;
done" in one window, and then forcing
Since I have a reproducible test case, I figure it can serve as the
"second user" confirming the bug. :-)
Please get this patch (or e2fsprogs 1.41.6 as soon as it becomes available)
packaged and published to Ubuntu users as soon as possible. I suspect that
most recent user who glommed on to L
This was fixed in e2fsprogs 1.41.2, so it is fixed in Ubuntu Intrepid
and Jaunty.
** Changed in: e2fsprogs (Ubuntu)
Status: Triaged => Fix Released
--
Spelling mistake in e2fsck man page.
https://bugs.launchpad.net/bugs/275272
You received this bug notification because you are a member o
Hi,
Is there an update for when the patch we supplied will be applied?
Many thanks!!
--
LSB 4.0 support
https://bugs.launchpad.net/bugs/370066
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lis
Apparently Launchpad isn't able to pull status from Debian... and this
bug has already been fixed for Debian, so I'm going to close it here.
** Changed in: e2fsprogs (Debian)
Importance: Unknown => Undecided
** Changed in: e2fsprogs (Debian)
Remote watch: Debian Bug tracker #506279 => None
Fixed in Karmic as of 1.41.5-1.
** Changed in: e2fsprogs (Ubuntu)
Status: Triaged => Fix Released
--
e2fsprogs should have info. on homepage field
https://bugs.launchpad.net/bugs/300188
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
This was fixed in Debian as of 1.41.4-2, and has been fixed in upstream
as of 1.41.5
** Changed in: e2fsprogs (Debian)
Status: New => Fix Released
--
e2fsprogs should have info. on homepage field
https://bugs.launchpad.net/bugs/300188
You received this bug notification because you are a m
Sorry for not checking in sooner, I've been swamped with upstream issues
with ext4, and this is pretty clearly an Ubuntu specific bug. Maybe
later this weekend I'll have time to try to figure out which ones of the
Ubuntu-backported patches is responsible for the problem.
However, I wanted to rep
We might have a break in this bug. For those people who can reliably
reproduce the problem, are you using ecryptfs, possibly extensively?
Roland Drier has reported a potential lockdep report that might explain
why some of us have had extreme problems reproducing the problem; namely
we might not b
On Mon, Jul 06, 2009 at 01:11:40AM -, Abraham Smith wrote:
> Ted,
> I've NOT been using ecryptfs, but I was using NFS and rsync-over-ssh on ext4
> extensively during my lockups.
NFS client or server? If NFS server, were you exporting an ext4
filesystem?
On Mon, Jul 06, 2009 at 02:57:32AM -, Feistybird wrote:
> Hi Ted,
>
> > even though at this point we've got a huge number of Fedora 11 users
> using ext4 w/o any problems.)
>
> Fedora 11 uses linux kernel 2.6.29.4, but Ubuntu 9.04 uses kernel 2.6.28
> by default.
>
> I don't have any ext4 so
Phil,
The only suggestion I can make at this point is to use a mainline
kernel. This seems to be some kind of interaction between Ubuntu
"Sauce" patches and the ext4 code. People have reported success with
stock 2.6.28, stock 2.6.29 and a bleeding-edge 2.6.30-rcX kernels.
There have been attempt
Sergey,
There's an easy workaround. Just add a line with the text "usb_storage"
to the file /etc/modules, and then rebuild the initrd file. Running
the command /sbin/update-initramfs -k -u" where you
need to replace with your current kernel version number
will do the trick. So will installi
@Tim:
I would be delighted if commit e7c9e3e9 fixes this bug. However, this
fix was added after 2.6.29 was released (it was pushed to Linus between
during the 2.6.29..2.6.29-rc1 merge window), and Ubuntu users have
reported that using the 2.6.29 stock kernel was enough to avoid the rm
-rf hang p
Saïvann,
Thank you very much for doing the bisect and confirming Carey's results.
The problem with this is that the commit that you figured as causing the
problem, dbf8b1c4, is identical to commit 82eb4869, which appeared in
2.6.28.7, and commit 920313a7, which appeared in 2.6.29-rc1, and so was
i
As an idea; for people who can reproduce it easily, preferably one of
you who have been doing this on a relatively small (20-40GB filesystem),
maybe you would be willing to do the following?
(a) Load up the filesystem with the test set of files that, when deleted, will
product the hang.
(b) Run
If they are not visible via /proc/partitions, there's no hope that blkid
will see them.Looks like a kernel problem. You might want to submit
the output of dmesg, and hopefully that will clarify what is going on.
--
usb HD detected by lsusb but not blkid.
https://bugs.launchpad.net/bugs/34440
Rocko,
Thanks for your kernel panic log. This doesn't prove anything, but 14
seconds before the oops involving ext4_delete_inode, there was a
recursive fault in the X server, which was apparently running the Nvidia
proproietary driver.
So I hate to ask this but (a) how many other people who have
Saïvann,
Thanks for your willingness to work on this.
>However the good news is that I'm ready to take a lot more time on this. If it
>requires me to
>git bisect again the whole jaunty kernel and to apply commit dbf8b1c4 each
>time I test one
>commit, I'm ready to do it. If you can only guide m
In some cases, this syslog warning can be emitted at a very high rate,
potentially causing /var/log to fill up. So I would strongly encourage
Ubuntu to consider back-porting two very simple commits into the Jaunty
kernel as an interim measure: 2842c3b54 and 6b82f3cb2 in the mainline
kernel.
*
For people who are seeing this --- try booting the kernel with the
"mem=" command line option and see if this makes a difference. For
example if you have 4 gigs of memory, try using "mem=1G"; if you have a
gig of memory, try using "mem=512M". Does this change how big the file
needs to be before
Something else to try; I would suggest using "dstat" with the -D option
(i.e, dstat -D sda,sdb) or iostat 1 (although I find dstat to be a bit
more user friendly) to measure I/O transfer rates. I would recommend
using "dd if=/dev/zero of=/media/disk/test.img bs=32k" to measure the
transfer rates,
Ulrich --- if you have time to try to do more tests, may I gently
suggest that you start a new Launchpad bug?Drop a pointer from in
this launchpad bug number to the new one, but let's do all of the
experimentation on a new launchpad bug. There are a couple of reasons
for this:
(1) Launchpad
Night64:
No, you're using usb-storage device driver for both the pendrive and the
ipod.The messages that you quoted as coming from the ipod just means
that the usb-storage module had gotten unloaded, and when it was loaded
as a module, it prints those lines to the kernel log. The fact that
t
On Wed, May 20, 2009 at 08:48:34PM -, Night64 wrote:
> Thanks for the info, Ts'o. But your comment about libusual caught my eye. In
> Ubuntu 9.04 this module still shows up, right?
>
> [81601.434729] usbcore: registered new interface driver libusual
Oops, sorry, that's what I get for not chec
@Volodymyr M. Lisivka,
You can opine all you want, but the problem is that POSIX does not
specify anything about "hidden transactions", and certainly does not
make any guarantees like this. As I said, most modern file systems are
doing delayed allocation for speed reasons, so you can expect this
@Michael,
The trick is being able to determine which applications are being too
aggressive with writing files. Section 5 in the laptop-mode's FAQ:
http://samwel.tk/laptop_mode/faq has some good tips about how to detect
which applications are writing indiscriminately to the disk. However,
some a
@Michael,
The trick is being able to determine which applications are being too
aggressive with writing files. Section 5 in the laptop-mode's FAQ:
http://samwel.tk/laptop_mode/faq has some good tips about how to detect
which applications are writing indiscriminately to the disk. However,
some a
@Brian,
We can't hold off one rename but not other file system activities. What
you can do is simply not save files to disk in your editor, until you
are ready to save them all --- or, you can extend the commit time to
longer than 5 seconds; laptop mode extends the commit time to be 30
seconds, i
@Brian,
One other thought... emacs (and all other competently implemented
editors) will use fsync() and *should* use fsync because for networked
filesystems, fsync() may be the only way that the editor will know
whether or not a file will be written to stable storage. For example,
if AFS returns
@Volodymyr,
If you or someone else is going to run a statistical analysis, it's
better to wait until after the patches queued for 2.6.30 make it into an
Ubuntu kernel. Also, you should when you did your test, did you check
to see about file lossagem, or just that the filesystem was self-
consist
@Volodymyr,
Oh, about your scenario --- the hiberate scripts *should* be doing a
sync before putting your laptop to sleep, so you shouldn't be losing any
files if the problem is failing to wake up after a hibernate. (Me, I'm
still paranoid about whether the hibernation scripts work correctly, so
>I wouldn't say linux users are used
>to crashed all the time, but on an alpha
>with new proprietary drivers,
>kernel panics aren't THAT rare until worked out.
@Michael,
I use bleeding edge kernels all the time -- including 2.6.X-rc1 kernels,
right after the merge window has closed and all sort
@Peter
For git, you should add to your ~/.gitconfig file:
[core]
fsyncobjectfiles = true
@Colin,
For Aptitude/dpkg, there really should be a call to sync before the
program exits, if it has installed or upgraded new packages. I can't
speak to subversion because I don't know how the .
@Raine,
Well, if the applications were written correctly, there wouldn't be any
data loss problems. I suppose we could thank the unreliable proprietary
binary drivers that were causing all of these crashes, so we could find
out about the buggy application code. :-)
It is a twist saying that bu
So a couple of things, since this has gone totally out of control.
First of all, ZFS also has delayed allocation (also called "allocate on
flush"). That means it will suffer similar issues if you crash without
doing an f*sync(), and the page cache hasn't been flushed out yet.
Solaris partisans w
Whatever allows you to skip an fsck check by hitting "escape" is not any
program in e2fsprogs.
It's either part of upstart or the init scripts, but not e2fsprogs.
--
Skipping routine drive check very slow
https://bugs.launchpad.net/bugs/292323
You received this bug notification because you are a
Ubuntu probably also needs installer support...
--
make ext4 as the primary filesystem for GNU/Linux
https://bugs.launchpad.net/bugs/293465
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ub
I'm not sure what you mean by "compatibility problems with the upcoming
ext4 filesystem". You will get better performance if you remake the
filesystem as ext4 from the beginning as opposed to converting an
existing ext3 filesystem to ext4, but the latter certainly works.
Also, note that that use
This is an xfsprogs problem, not an e2fsprogs problem.
** Also affects: xfsprogs (Ubuntu)
Importance: Undecided
Status: New
** Changed in: e2fsprogs (Ubuntu)
Status: New => Invalid
--
fsck dies on boot with XFS USB drive
https://bugs.launchpad.net/bugs/276045
You received this
I can't tell for sure if you are complaining about the "ext3 recovery flag is
clear, but journal has data." message (which is just a filesystem corruption),
or the corrupted display with the "Project-Id-Version: e2fsprogs
Report-Msgid-Bugs-To: FULL NAME <[EMAIL PROTECTED]>" text. Was that really
Please also send the output of the "blkid" command, as well as "ls -l
/dev/disk/by-uuid".
Thanks!
--
see attach file
https://bugs.launchpad.net/bugs/246958
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubu
lsdel hasn't worked since ext3 was introduced. Journaling requirements
forced us to clear the i_blocks array, and this made lsdel non-
operative. It's theoretically possible to change the kernel's unlink
algorithm to avoid needing to zap the i_blocks array for most deleted
inodes, but no one has
Note that debian has e2fsprogs 1.41.0-1 in Unstable; it was uploaded
last night, at the same time e2fsprogs 1.41 as released. I am running
Ubuntu Hardy, and I have built Ubuntu packages from released tarball.
In fact, it's what I'm using right now. :-)
If people really care I probably could make
Yep, I just checked e2fsprogs_1.40.8-2ubuntu2.diff.gz, and sure enough,
whoever packaged up e2fsprogs for Ubuntu simply snipped off the
dietlibc-dev from the Build-deps line in the control file.
Unfortunately there isn't a dietlibc-dev [!ubuntu] syntax for the rules
file, so I guess Ubuntu package
The dietlibc-dev dependency can be safely removed. The rules files has
a provision where if dietlibc is present, it is used to make
e2fsck.static somewhat smaller in size --- from 1036k to 816k, for a
savings of over 20%. But it is strictly optional, and perhaps a relic
from the days when people
PS, I'll note the original bug that started this chain was started
because libvolume_id gave the wrong answer, erroneously reporting an
ext3 filesystem as FAT. I've tried working with the vol_id folks
before, and they are not interested in patches to make libvolume_id give
more correct answers, be
Note that libvolume_id BREAKS ext4 support. For that reason the
e2fsprogs patch HAS NOT BEEN ACCEPTED IN MAINLINE.
I am telling people who are using ubuntu to back out the changes in
mount that switch it to use volume_id, as they are problematic for ext4,
and recompile mount if they want to use e
When I have submitted patches in the past, to fix problems such as the one that
kicked off this thread (an ext3 filesystem erroneously getting reported as a
FAT filesystem), it was rejected by the libvolume_id maintainer.
I've been very busy trying to get ext4 production ready, and decided I didn
I very much doubt this was a problem with e2fsprogs, but rather with the
RAID setup. If e2fsck was doing a full check after doing a journal
replay, it's probably because the kernel had detected a filesystem
consistency problem, and had set the "filesystem has an error" flag.
The symptoms describe
Note that it there is a space between "-l" and "/dev/disk/by-uuid" in
the requested command, "ls -l /dev/disk/by-uuid". Or, "ls", space,
"-l", space, "/dev/disk/by-uuid."
Also, you mistyped your password twice wiht the "sudo blkid" command, so
we never got to see the output.
You also didn't answ
Steve,
I have two concerns with your suggestion. First, are we sure that in
the future, no Ubuntu or Debian buildd will do something stupid and
think that because it has loaded dietlibc-dev, it doesn't need to load
libc6-dev? Secondly, and probably more seriously, this means that I
will hav
So indeed, there is no filesystem with the UUID b4553c87-85ef-4c03-8e0f-
c23600f62c5. Did you install another Linux system or another instance
of Ubuntu on this system? It looks like your /etc/fstab file is simply
incorrect, or out of date.
This then is not a e2fsprogs bug, but either an issue
Ah, OK, so the problem seems to be one UUID identification. OK, so
this could be a blkid problem --- or the filesystem could just be
corrupted enough that the UUID isn't identifying. We need to see the
output of "sudo /sbin/blkid", and "ls -l /dev/disk/by-uuid", please.
** Changed in: e2fsprog
OK, so blkid is correctly identifying the filesystem. How about the
output of this command:
"sudo /sbin/fsck -C3 -R -A -N -V -a"
The -N means to not actually do anything, and -V will print the commands
that fsck would have executed. So you should see something like this
# fsck -C3 -R -A -N -
That's not a bug; that's mke2fs working as designed. Using -t ext3
simply selects a base set of options, as documented in the mke2fs and
mke2fs man pages. BTW, "mke2fs -t ext3 -O extents" and "mke2fs -t
ext4dev" are NOT the same thing.
** Changed in: e2fsprogs (Ubuntu)
Status: New =>
OK, so that means that blkid is able to detect device correctly. I'm going to
guess that the USB device wasn't visible at the time that
/etc/rcS.d/S30checkfs.sh is run. If you can, add to /etc/init.d/checkfs.sh
the following:
logsave -a /var/log/checkfs.debug blkid
logsave -a /var/log/checkfs
The blkid library keeps old entries in /etc/blkid.tab even if the
devices disappear, in the off-chance that it might be useful later. So
the entries in /dev/sdc[12] are no big deal. The big indicator is the
log from /proc/partitions; that indicates that /dev/sdb1 simply doesn't
exist at the time
OK, so if the sleep 15 works, then the problem is that the system isn't
waiting until all of the USB buses and devices are enumerated until
continuing. This is nominally the job of /etc/init.d/udev, which is
run out of /etc/rcS.d as /etc/rcS.d/S10udev. This init script runs
"/sbin/udevadm trigg
Non-contiguous means that the data blocks are not stored contiguously on
disk. Yes, that means "fragmented". Keep in mind that a certain amount
of fragmentation isn't going to hurt performance. If a file is badly
fragmented, yes, that can hurt performance (at least until we all switch
to solid s
I am at a loss to see how the message:
/dev/thunk/testext4: 5452/65536 files (0.0% non-contiguous),
12692/262144 blocks
could possibly be interpreted as an error message. It's been like this
for over 15 years and no one has ever been confused about what it means
until now. What would you sugge
Patch in e2fsprogs git tree, but probably won't hit Ubuntu (per private
communication with Steve Langasek) until an upstream release is cut
(i.e., when e2fsprogs 1.41.2 is released). And we've already missed the
freeze window for Intrepid, so this probably won't get fixed until
Intrepid+1
The
OK, can you send create a sparse e2image dump file of the filesystem,
using e2image -r? i.e:
e2image -r /dev/sdb /var/tmp/sdb.e2i
You might also want to make a copy of the file, and try running e2fsck
on the file. If the USB drive is going bad, it could be that writes
aren't reliably making it
Why are you trying to run fsck from a terminal window in the first
place?
And it would have warned you that you were doing something dangerous:
% sudo fsck
[sudo] password for tytso:
fsck 1.41.0 (10-Jul-2008)
e2fsck 1.41.0 (10-Jul-2008)
/dev/mapper/thunk-root is mounted.
WARNING!!! Running e
Sure sounds like a hardware problem to me. I'm not sure how you've
concluded that it's not a hardware problem
--
Dapper lvm over software raid kills ext3
https://bugs.launchpad.net/bugs/247318
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed t
In your first message, you said only one server has the problem. In
your most recent message, you said "all servers have the same problem".
Would you like to clarify exactly what is going on...?
--
Dapper lvm over software raid kills ext3
https://bugs.launchpad.net/bugs/247318
You received this
Sorry, but it would be much more helpful if you could be extremely
precise with your statements; maybe it's an language problem, but some
of your statements, especially your parenthetical comments, are very
hard for me to parse as valid english and then make semantic sense out
of them. For example
If the problem doesn't show up when you stop using LVM, it's highly
unlikely to be an e2fsprogs bug!
--
Data corruption with ext3 in striped logical volume
https://bugs.launchpad.net/bugs/100126
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
This isn't an e2fsprogs bug; the message "Checking Drive Press Esc. to
Cancel" isn't printed by e2fsprogs.
--
Fsck Check Doesn't Remove All Text After Finished
https://bugs.launchpad.net/bugs/219867
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Is this a multiboot system? This may very well be related to Launchpad
Bug #106209.
Can you send your /etc/fstab, and the output of the command "sudo
blkid"?
thanks!!
--
fsck.ext3: Unable to resolve 'UUID=cfa4b09b-82db-4bef-8c86-a226e17d9649'
https://bugs.launchpad.net/bugs/233885
You receive
On Mon, Aug 11, 2008 at 04:28:56PM -, fdk007 wrote:
> I think fsck is the same how chkdsk under windows.
> It go to remove errors form your Harddisc.
Fsck does roughly the same thing as chkdsk, which is to say it will
fix filesystem corruptions. However, it can not be used on a mounted
files
This looks like a duplicate of #257048. Mind if I close it? (fsck.ext3
and e2fsck are the same binary).
--
fsck.ext3 crashed with SIGSEGV in strlen()
https://bugs.launchpad.net/bugs/257049
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Can you send the output of "dumpe2fs -h /dev/sdc3"?
Thanks!!
--
e2fsck crashed with SIGSEGV in strlen()
https://bugs.launchpad.net/bugs/257048
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@list
There seems to be a fundamental misconception here that running fsck
"cleans up" or "clears" the filesystem. In general, this is not true.
Fsck detects filesystem corruptions, and if it finds them, it fixes
them. If it does not find any problems it's not going to "clean up"
the filesystem in any
This sounds like a different problem, right? You've already blown away
the original contents of the disk, so it's going to be impossible for us
to try to reproduce what was going on on the Ubuntu e2fpsrogs version
1.40.8.
As for the "device or resource is busy", that means something else has
the
On Wed, Aug 13, 2008 at 07:38:25PM -, ingo wrote:
> If said in my first post, that the file system was created by QNAP
> TS-209 NAS. It is an ext3 file system, but with some patches from
> QNAP applied (as far as I know to speed up RAID1).
Actually, it looks like it's an ext4 filesystem --- o
On Wed, Aug 13, 2008 at 09:21:20PM -, ingo wrote:
> Many thanks Ted,
>
> So I now know where to go and I discard the unusable partitition. But I
> will get my NAS back and repaired soon (I hope) and then be able to
> create a 'virgin QNAP ext3' and check with Lenny or even Intrepid
> whether i
On Thu, Aug 14, 2008 at 11:00:44AM -, ingo wrote:
>
> 1. partly image of current sda3 (dd if=/dev/sdc3 of=qnap-sdc3.img bs=4k
> count=200) -> attached!
So I just tried downgrading to e2fsprogs 1.40.8-2ubuntu2 (and all of
its associated libraries), and I can't reproduce the crash. What I
get
On Thu, Aug 14, 2008 at 02:48:08PM -, ingo wrote:
> one more information:
>
> when trying to mount /dev/sdc3 I get following message:
>
> mount -t ext3 /dev/sdc3 /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/sdc3,
>missing codepage or helper program, or other error
>
1 - 100 of 596 matches
Mail list logo
