Bug#681820: e2fsprogs: Problems in German translation
On Mon, Jul 16, 2012 at 10:02:42PM +0200, Helge Kreutzmann wrote: By chance I saw a slight error in the German output e2fsprogs programms. I grabed the latest de.po and startet reviewing it; unfortunately it is quite huge and I only managed to to about 1/3 up to now. I found various issues, from spelling errors, inconsistent translations to (unfortunately) mistranslations. Due to the latter I like to explore if there are chances to do an upload despite the freeze and ask for a freeze exception. If the answer is yes (and ideally the upstream maintainer is repsonsive) then I could try to review a few more strings for the targeted upload date. Helge, Many thanks for your effort! In my experience Philipp is very responsive as the upstream Translation Project translator for e2fsprogs. Ideally, if agrees with your updates, he could upload a fixed de.po for e2fsprogs to the Translation project, and I would be very happy to get it into an updated e2fsprogs upload for Debian. We would have to reques a freeze exception, but if the only change is translation and man page typo's, I'm pretty sure it wouldn't cause any issues, since it wouldn't effect the udeb's used by the d-i team. Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677624: multiarch-support should be priority: required
Package: multiarch-support Version: 2.13-33 Forwarding per Russ's observation that multiple required library packages are depending on multiarch-support, which causes Lintian to complain. Given that it is a transitional package, this shouldn't be a big deal, since it's less than 200k installed (and all of that package documentation overhead) Thanks, - Ted ---BeginMessage--- Theodore Ts'o ty...@mit.edu writes: If a required package (such as e2fslibs, which is required by e2fsprogs) provides multiarch support, then Lintian requires that the package have a dependency on the package multiarch-support[1]. However, this causes debcheck to complain because you now have a required package depending on a package, multiarch-support, which is only at standard priority[2] [1] http://lintian.debian.org/tags/missing-pre-dependency-on-multiarch-support.html [2] http://qa.debian.org/debcheck.php?dist=unstablepackage=e2fsprogs What is the right thing to do to resolve this mutually irreconcilable set of complaints from either Lintian or debcheck? multiarch-support should be priority: required. It's already a dependency of several other priority: required packages, such as libselinux1 and zlib1g. That implies that in the interim you should ignore debcheck. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa05kxv0@windlord.stanford.edu ---End Message---
Bug#674453: e2fsck(8): Unnecessary escape of tabs in the manual
tags 674453 +pending thanks Patch applied, thanks. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674694: resize2fs(8): Unnecessary escape before a tab in the manual
tags 674694 +pending thanks Patch applied, except that 1 k and 2 k blocksize looks horrible; I much prefer 1k and 2k blocksize. So I reverted that part of the patch. It may be the preferred style for SI units, but these are the same jokers who suggest the use of ridiculous terms like tibibytes (a term I reject, since while they may get to define what a metre is, they don't have the authority or responsibility to define what a byte means --- and if they did, they'd probably insist on ten bits in a byte :-). In any case, in the computer world we very regularly do *not* put a space between the number and units: i.e., 640k memory. Best regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670100: e2fsprogs: Please don't use blocksize of 1024 in usage-type 'small'
On Mon, Apr 23, 2012 at 03:22:52PM +0300, Touko Korpela wrote: Finally, the only file system where someone is likely to be creating that is this small in this day and age is the /boot filesystem --- and there, even if the drive using 512-byte emulation, performance isn't an issue since no one is executing out of /boot, or even modifying it very often. Yes, /boot is my primary worry. Yes, and the performance hit only really happens when you need to do a read-modify-write cycle. And /boot doesn't get modified very often --- only when you update a kernel, and even when you do, it's mostly large files which will generally be contiguous. So the performance hit is barely measurable. A thing to consider is that dumb SSDs and USB sticks/memory cards are more common than smart SSDs. (a) dumb SSD's still had to work well on Windows XP, and hardware designs are conservative, so it's not clear to me this is really a huge issue. And (b) USB sticks/memory cards are again primarily used for file interchange, where performance is not a big thing. (It's really random 4k writes where the read-modify-write cycles really hurt. For big files, we where we issue a large contiguous write transaction, you only do the read-modify-write cycle for the first and last 4k block and that's not a big deal. And maybe some wants to resize such small filesystem bigger but resizing can't change blocksize larger. ... and how often do you start with a file system *that* small? Still I think that at least filesystems that are larger than about 50-100MB in size default blocksize should be 4096. You're certainly entitled to your opinion. One of the reasons why this policy is not hard coded, but can be easily modified via /etc/mke2fs.conf is so that sysadmins can make changes for what is most appropriate for their systems. Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670100: e2fsprogs: Please don't use blocksize of 1024 in usage-type 'small'
On Mon, Apr 23, 2012 at 06:51:28PM +0300, Touko Korpela wrote: USB sticks and other flash media are optimised for FAT (using big blocks). Most of my information comes from LWN article Optimizing Linux with cheap flash drives https://lwn.net/Articles/428584/ I don't know if linear reads during boot are affected but other usage is much slower when reads/writes aren't aligned. Fdisk has already fixed its default partition layout. Read that article more closely. Flash page sizes are well beyond 4k; with modern flash they are 32k and 64k. Hence, any read *smaller* than the page size (32k or 64k) will take the same amount of time as a page read. It's not going matter whether it is 512-byte aligned or 4k aligned. And if you do a nice big contiguous read (i.e., reading in a 4MB kernel image), it might make a small amount of difference, but only at the beginning and the end of the file, which might result in a performance hit of just under 0.2% --- i.e., reading in a 4MB kernel, which might take 1.100 millseconds, might end up taking 1.102 millseconds instead. Good luck measuring that. For writes, to get optimal speeds, you need to be doing 4MB aligned writes. Will there be a difference between 512 byte and 4k random writes? It depends on the SSD. For good SSD's it won't matter at all. For bad ones, there may be some difference, but the big breakpoint happens with 4MB writes (or whatever the erase block size happens to be --- for newer devices, they might be 8MB at this point). And again, for /boot, it's really not going to matter. Heck, on my systems /boot is generally well larger than 512MB anyway (but that's because I'm a kernel developer :-). - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670100: e2fsprogs: Please don't use blocksize of 1024 in usage-type 'small'
On Mon, Apr 23, 2012 at 01:17:34AM +0300, Touko Korpela wrote: Package: e2fsprogs Version: 1.42.2-2 Severity: normal I noticed that mke2fs has a default blocksize of 1024 bytes when it uses filesystem type 'small' (3-512MB) from mke2fs.conf. It's a bad thing for performance (more so now when 4K sector HDDs and SDDs are common). Also space savings are quite small. You can always override the blocksize if you feel strongly about this. The performance problem is only true on very new disks --- and it's rare that someone would be formatted a file system so small on such disks. I'll also note that many SDD's can handle 512 byte mis-aligned blocks (i.e., Windows XP formatting) just fine. It doesn't make any difference at all on Intel SSD's, for example. Secondly, mke2fs will use 4k blocks if the drive requires it (i.e., for Advanced Format disks with 4k sectors). So the problem you're worried about only occurs for Advanced Format drives with 512e emulation. Finally, the only file system where someone is likely to be creating that is this small in this day and age is the /boot filesystem --- and there, even if the drive using 512-byte emulation, performance isn't an issue since no one is executing out of /boot, or even modifying it very often. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669730: e2fsprogs: Bigalloc is not documented
Hi Touko, Note that bigalloc is still somewhat under development; there are number of bugs that are still in the kernel code, so at this point I can't really recommend non-developers use it in production yet... (Some of the bugs weren't evident at the time of the 1.42 release, or I would have added more cautions in the e2fsprogs release notes.) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666460: define 'check' clearer
On Mon, Apr 02, 2012 at 06:34:39AM +0800, jida...@jidanni.org wrote: My main motivation is that for years uses see checking messages at boot. On a dentist's bill at least checking is separate from treating. So somehow the user should be more informed about what is going on. Else he wonders if all that Windows defragmentation is somehow unnecessary on Linux, and for years his disks have passed with flying colors... When if fact the dentist is doing more than just looking. This is no different from Windows when it runs the CHKDSK program; it says that it's checking the disk, but it's really checking and repairing it. And none of this has anything to do with defragmentation; it has to do with dealing with potentially corrupted file systems after hardware failures/hiccups --- or if a USB thumb drive is forcibly removed in the middle of a write operation, and the flash translation's metadata is corrupted. I really have no idea. I just wish =Checking... done=== messages were more honest. I just don't like my dentist to say he only checked when he in fact plans to check and maybe alter. This message has nothing to do with the fsck man page or the util-linux package. that's really a matter of the system startup scripts. But I'll note that the term checking has a very long history, going back decandes for Linux, Unix, as well as in MS-DOS / Windows --- so it's not even Linux / Unix. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666460: define 'check' clearer
On Sat, Mar 31, 2012 at 06:39:35AM +0800, jida...@jidanni.org wrote: Package: util-linux Version: 2.20.1-4 Severity: wishlist File: /usr/share/man/man8/fsck.8.gz X-debbugs-cc: ty...@mit.edu The man page should say by 'check' we mean that nothing will be altered on the disk except updating the mount tally. Anything more invasive we call 'repair'. Or something like that. It is not clear. One just guesses. The man page currently says: Fsck is used to check and optionally repair one or more Linux file systems That's not technically correct since in actual practice is fsck with no options will repair the file system. This becomes clear if you read the definitions of the -y, -n, and -a/-p options. So probably the best thing to do is delete the word optionally in the above statement. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666725: secure passwords more predictable than expected
severity 666725 normal thanks On Sun, Apr 01, 2012 at 12:50:58PM +0200, Thomas Arendsen Hein wrote: When using pwgen -s 1 50 to generate 50 one-char passwords, only lowercase letters are used. When using pwgen -s 2 50 to generate 50 two-char passwords, exactly one lowercase letter and one number is used. Three-char and longer passwords are not affected by this major security issue. Thanks for reporting this, and I agree it's a bug, but if you're using one or two letter passwords (or heck, anything under 5 characters), you're totally insecure anyway. Whether someone has to brute force 26 possible passwords versus 62 possible passwords is not a major security issue. :-) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666460: define 'check' clearer
One of the reasons why the fsck page is a little vague is that it's a front end progam which executes a file system specific checker program. These programs are not necessarily consistent in how they operate. The way e2fsck, which is the file system checker used for ext2, ext3, and ext4 (and so /sbin/fsck.ext2, /sbin/fsck.ext3, and /sbin/fsck.ext4, are either sym links or hard links to /sbin/e2fsck) works is that without any options, it is interactive; it will require access to a tty, and before it actually makes any changes, it will *ask* the user whether it wants to correct a particular file system corruption if it comes a cross scuh a corruption. The options -n, and -y will make e2fsck automatically answer no, or yes to questions, so it can be used non-interactively --- i.e., it doesn't need access to a valid tty for input, which is the case for boot scripts. The -p/-a option for e2fsck is called preen mode, which will answer yes automatically for safe questions, and will exit with an error, causing the boot script to abort the boot, for dangerous questions that requires a system administrator's personal attention to minimize the chances of data loss. Other file system consistency checkers are sometimes a little different, although most of them handle the -y, -n, and -a/-p as described in the fsck man page since that's what the boot scripts use. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665885: e2fsprogs: libcomerr2.shlibs should point at e2fsprogs-udeb for udebs
tags 665885 +pending
thanks
On Tue, Mar 27, 2012 at 06:41:42PM +0200, Julien Cristau wrote:
Is this what you are looking for?
% more debian/libcomerr2/DEBIAN/shlibs
libcom_err 2 libcomerr2 (= 1.33-3)
udeb: libcom_err 2 e2fsprogs-udeb (= 1.33-3)
Yep, that looks like what I'd expect. Thanks.
Great, just checking since I wasn't familiar with that udeb-specific
syntax in the shlibs file.
I've applied the following patch that will be in the e2fsprogs 1.42.2
release.
- Ted
commit 38c5e731157116b7cd350e2e3c05e64340307a2c
Author: Theodore Ts'o ty...@mit.edu
Date: Tue Mar 27 11:48:18 2012 -0700
debian: add pointer to e2fsprogs-udeb to libcomerr2.shlibs
The udeb for btrfs-tools need libcom_err.so.2, which is packaged as a
part of e2fsprogs-udeb since we don't have a separate libcomerr2 udeb.
So we need to make sure the shlibs file has an explicit pointer to
handle this case.
Addresses-Debian-Bug: #665885
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/debian/rules b/debian/rules
index 82a1576..1f6e7b4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -618,7 +618,7 @@ endif
dh_compress
dh_makeshlibs -Ne2fsprogs-udeb -Nlibblkid1-udeb -Nlibuuid1-udeb
- dh_makeshlibs -plibcomerr${COMERR_SOVERSION} \
+ dh_makeshlibs --add-udeb=e2fsprogs-udeb -plibcomerr${COMERR_SOVERSION} \
-V 'libcomerr2 (= 1.33-3)'
ifneq ($(UTIL_LINUX_NG),yes)
dh_makeshlibs -plibblkid${BLKID_SOVERSION} -V 'libblkid1 (= 1.39-1)'
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665427: Fix roff syntax and typo in mke2fs.conf.5 and tune2fs.8
tags 665427 +pending thanks On Fri, Mar 23, 2012 at 10:27:11PM -0400, David Prévot wrote: We noticed some tiny errors in the mke2fs.conf.5 and tune2fs.8 manpages while translating them in French (for the manpages-fr-extra package), please find attach a patch to address these issues. Thanks, applied. BTW, we would be pleased if you could consider shipping the translated manpages directly in your package, or even better, help us to integrate them upstream. The major concern that I have with including the translated manpages is the synchronization problem that this implies. By definition the translated man pages will always be out of sync, whenever I make change; I can forsee this leading to endless bug reports, for which I am not really able to act upon. Also, how do the man pages get updated? Do I have to ask? Will someone be checking the e2fsprogs git repository on a regular basis to find man page changes? It just seems that including translated man pages is a support nightmare. The other question I have is if I include the French man pages in the e2fsprogs package, then what if I start having to include German, Spanish, Polish, Turkish, etc. Wouldn't this massively bloat the e2fsprogs package? And if I have to create an e2fsprogs-fr-manpages, and a e2fsrpogs-es-manpages, etc., again this start looking like a huge amount of work just to give me more bug reports that I'm not capable of handling (since I don't speak French.) Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665885: e2fsprogs: libcomerr2.shlibs should point at e2fsprogs-udeb for udebs
On Mon, Mar 26, 2012 at 09:53:56PM +0200, Julien Cristau wrote: Package: e2fsprogs Version: 1.42.1-2 Severity: important Tags: d-i (x-debbugs-cc to debian-boot and the btrfs-tools maintainer) btrfs-tools-udeb's btrfsctl and mkfs.btrfs seem to be linked against libcom_err.so.2, and the package ends up with a dependency on libcomerr2, which isn't an udeb. Since libcom_err seems to be included in e2fsprogs-udeb, I guess this means the shlibs file should be adjusted to point there. See the --add-udeb option to dh_makeshlibs. Is this what you are looking for? % more debian/libcomerr2/DEBIAN/shlibs libcom_err 2 libcomerr2 (= 1.33-3) udeb: libcom_err 2 e2fsprogs-udeb (= 1.33-3) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663237: e2fsprogs: [patch] Make resize2fs shrinking use much less CPU
On Fri, Mar 09, 2012 at 08:11:05PM +0200, Sami Liedes wrote:
Shrinking a filesystem is currently very CPU intensive. On a 100G ext4
filesystem filled to 50% full by making copies of /usr/share/doc to
$MNTPOINT/doc{1,2,3,...}, running resize2fs on a fairly slow (~5400
rpm) disk and a fast Core i7 processor
Thanks for looking into this!
I also noted that resize2fs does not call ext2fs_open2() with
EXT2_FLAG_64BITS set; is there a reason for that? Adding that flag
change causes a minor speedup by eliminating
ext2fs_test_generic_bitmap() from the call chain.
Yeah, resize2fs hasn't had work done on it to support 64-bit file
systems, which is why it hasn't been changed to set that flag. That
flag only means that it was compiled with the new 64-bit capable
header files, though, so it's safe to set that flag. We just hadn't
gotten around to it.
After these optimizations, the wall time taken to resize the same
filesystem has decreased from 96m27s to 39m49s:
Cool!!
A tentative (or proof of concept) patch is attached. Some concerns
that I have:
1. How should internal errors, like functions returning EINVAL when
that ostensibly cannot be due to invalid filesystem, be handled?
Currently ext2fs_new_inode() just propagates the error further:
+ if (err != ENOENT)
+ return err; /* Internal error? */
In general, errors get propagated upwords, although if a function can
recover in some way, or wishes to translate the error from ENOENT to
some new com_err defined code, so that the user gets a more specific
error message (i.e, Configuration file not found instead of just
file not found), it can do that.
2. My additions in blkmap64_ba.c rely on the availability of
stdint.h and intptr_t (to detect when a pointer is 8-byte
aligned). Perhaps that should be done in another way if C89
compatibility is a concern?
You could just cast the pointer to an unsigned long before you mask it
with 0x07 in the highly unlikely case that the pointer is wider
than an unsigned long, it won't matter since you really want to look
at the low three bits anyway.
3. 64-bit scans might be slower on a system with native register size
64 bits. I doubt they will be slower than the code used to be,
though.
Probably; it's easy enough to test on a 32-bit x86 binary.
4. What is bitmap-cluster_bits and how should it be handled? in
ba_find_first_zero(); similar code in
ext2fs_find_first_zero_generic_bmap():
+ /* FIXME what is this? */
+ if (bitmap-cluster_bits)
+ return EINVAL;
It's something which is only used for bigalloc file systems, where
it indicates the cluster size. With this feature, instead of the
block allocation bitmap indicate block numbers being free, it
indicates cluster numbers being free, where a cluster is a power of
two number of blocks. It's not something you need to worry about in
this context, because resize2fs doesn't support bigalloc file systems
yet, and it doesn't make much difference in terms of how the libext2fs
library functions work.
5. Is returning ENOENT the preferred way of indicating not found?
How is this supposed to integrate in the com_err framework?
What is it that is not being found? A bit in the bitmap? In that
case I'd probably define a new com_err error code.
I'd be happy to update the patch to fix any remaining issues, unless
you think there's another, cleaner solution to the slowness.
It would be really great if you could break things into small logical
patches, and send them to the linux-ext4 list for review.
Thanks,
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654457: Please enabled hardened build flags
On Mon, Feb 20, 2012 at 09:28:49PM +0100, Simon Ruderich wrote: dpkg-buildflags /dev/null Dash, which is (now) the default shell for scripts on Debian, doesn't support that - and it's used by the buildds I think. I guess you have bash as your /bin/sh which accepts that syntax. The following works fine: dpkg-buildflags /dev/null 21 And fixes the hardening flags for me. OK, I'll try this and see how that works out. But you don't need to check if dpkg-buildflags is available. You could use the method I suggested in the last message and call dpkg-buildflags unconditionally - if it doesn't exist no output is added to the *FLAGS variables. I believe I do need to do the check, because if the *FLAGS are set (even if they are set to the empty string), they will override what dpkg-buildpackage sets on Ubuntu obsolete systems (per corporate security dictats, I'm forced to run Ubuntu 10.04 LTS on my laptop). That's why if dpkg-buildflags isn't available, I'm explicitly setting CFLAGS and LDFLAGS to what was the default on older versions of dpkg. Btw. I think there's one problem with the current debian/rules: If dpkg-buildflags is found and used then -Wl,-Bsymbolic-functions is missing from LDFLAGS, I'm not sure if this was intended. Yes, that was the default from Ubuntu 10.04. But if dpkg-buildflags is going to supply something else, we'll use whatever the distro defaults are. If I understand things correctly, even Debian obsolete^H^H^H^H^H^H^H stable supports dpkg-buildflags so this is really only something needed to support Ubuntu LTS. Sometime after Ubuntu LTS 12.04 I'll stop worrying about this, but for right now, I'm forced to use Ubuntu LTS, so I'm trying to support it. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654457: Please enabled hardened build flags
On Mon, Feb 20, 2012 at 09:28:49PM +0100, Simon Ruderich wrote:
On Sun, Feb 19, 2012 at 10:39:40PM -0500, Ted Ts'o wrote:
I don't understand, but it looks like the hardening flags are being
passed, but either (a) they are't correct, or (b) they seemingly have
no effect. Can you help me? What have I missed?
The hardening flags in the build log you posted are correct - and
have an effect in your local build.
OK, so, this is considered an acceptable result?
ty...@tytso-glaptop.cam.corp.google.com {/kbuild/debian/e2fsprogs-1.42.1}
530% hardening-check debian/BUILD-STD/e2fsck/e2fsck
debian/BUILD-STD/e2fsck/e2fsck:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: no not found!
i.e., it's ok for the purposes of the hardening effort for the
executable to not be PIE, and not to have immediate binding enabled?
Thanks,
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654457: Please enabled hardened build flags
On Sun, Feb 19, 2012 at 04:39:38PM +0100, Simon Ruderich wrote:
Dear Maintainer,
It looks like the hardening flags weren't applied in 1.42.1-1.
For example:
$ hardening-check /sbin/fsck.ext4
/sbin/fsck.ext4:
Position Independent Executable: no, normal executable!
Stack protected: no, not found!
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: no, not found!
Immediate binding: no not found!
I'm not sure why the if construct doesn't work correctly, but the
original patch from Moritz should also work if dpkg-buildflags
doesn't exist (the flags are empty in that case).
I don't understand, but it looks like the hardening flags are being
passed, but either (a) they are't correct, or (b) they seemingly have
no effect. Can you help me? What have I missed?
Thanks,
- Ted
ty...@tytso-glaptop.cam.corp.google.com {/kbuild/debian/e2fsprogs-1.42.1}
528% /bin/rm debian/BUILD-STD/e2fsck/pass1.o
ty...@tytso-glaptop.cam.corp.google.com {/kbuild/debian/e2fsprogs-1.42.1}
529% make -C debian/BUILD-STD/e2fsck V=1
make: Entering directory
`/kbuild/debian/e2fsprogs-1.42.1/debian/BUILD-STD/e2fsck'
gcc -c -I. -I../lib -I/kbuild/debian/e2fsprogs-1.42.1/lib -D_FORTIFY_SOURCE=2
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
-Werror=format-security -D__NO_STRING_INLINES
/kbuild/debian/e2fsprogs-1.42.1/e2fsck/pass1.c -o pass1.o
gcc -Wl,-z,relro -Wl,-rpath-link,../lib -rdynamic -o e2fsck crc32.o dict.o
unix.o e2fsck.o super.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o
journal.o badblocks.o util.o dirinfo.o dx_dirinfo.o ehandler.o problem.o
message.o quota.o recovery.o region.o revoke.o ea_refcount.o rehash.o profile.o
prof_err.o sigcatcher.o ../lib/libquota.a ../lib/libext2fs.so
../lib/libcom_err.so -lblkid-luuid ../lib/libe2p.so
make: Leaving directory
`/kbuild/debian/e2fsprogs-1.42.1/debian/BUILD-STD/e2fsck'
ty...@tytso-glaptop.cam.corp.google.com {/kbuild/debian/e2fsprogs-1.42.1}
530% hardening-check debian/BUILD-STD/e2fsck/e2fsck
debian/BUILD-STD/e2fsck/e2fsck:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: no not found!
ty...@tytso-glaptop.cam.corp.google.com {/kbuild/debian/e2fsprogs-1.42.1}
531% dpkg-buildflags
CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -Werror=format-security
FFLAGS=-g -O2
LDFLAGS=-Wl,-z,relro
ty...@tytso-glaptop.cam.corp.google.com {/kbuild/debian/e2fsprogs-1.42.1}
532% gcc --version
gcc (Debian 4.6.2-14) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654457: Please enabled hardened build flags
tags 654457 +pending thanks Thanks for sending a proposed patch! I had to slightly modify it so it deals with the case where we are building on an ancient distro that doesn't yet have dpkg-buildflags (since I support building this on systems such as Ubuntu 10.04 LTS and Debian stable). I've checked in a fix and it will be in e2fsprogs 1.41.1. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654206: [PATCH] ext4: Report max_batch_time option correctly
On Mon, Jan 02, 2012 at 02:13:02PM +, Ben Hutchings wrote: Currently the value reported for max_batch_time is really the value of min_batch_time. Reported-by: Russell Coker russ...@coker.com.au Signed-off-by: Ben Hutchings b...@decadent.org.uk Applied, thanks. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634401: extundelete: FTBFS: extundelete.cc:963:47: error: invalid use of incomplete type 'struct opaque_ext2_group_desc'
On Tue, Jan 03, 2012 at 11:54:46AM -0600, Eric Sandeen wrote: I just investigated on this FTBFS issue. The problem is that extundelete doesn't compile against e2fslibs-dev versions =1.42. Therefore extundelete was just removed from Debian/testing, so if this bug can't be resolved then extundelete sadly can't be shipped with the upcoming Debian stable release. The extundelete program also needs to be changed to support 64-bit file systems. The responsible change in e2fslibs-dev is this one (libext2fs: make fs-group_desc opaque): http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=commit;h=efe0b401465a3ee836180614b5b435acbb84fc27 The commit message talks about EXT2FS_OLD_32_COMPAT which should provide compiling of Old-style applications who don't want to change their source code. Sadly EXT2FS_OLD_32_COMPAT wasn't implemented in this commit nor in a following one. Hm, none of that was in my original commit or message, I think Ted added that text on commit, but didn't modify the patch at all. Yeah, somehow that change got lost. I'm not sure what happened. There are other problems though, I think, in parse_inode_block() for example, things in there have changed as well... this tool seems to be getting a little to grubby in the ext internals. I think maybe it should be making use of ext2fs_swap_inode() instead. The issue was brought up on the mailinglist of extundelete a few weeks ago, but there wasn't a reaction from upstream since then. Eric and Theodore - any ideas what's the best way to resolve this issue in the meanwhile? I'll look at trying to add the backwards compatibility support back into a future version of e2fsprogs, but really, extundelete should be updated to use the accessor functions and updated to support 64-bit file systems. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Wed, Dec 21, 2011 at 02:32:58PM +0100, Goswin von Brederlow wrote: If we want to improve fsck time then the best thing to do would be to consider a different default value for the -i option of mke2fs. This advice is not applicable for ext4, since it will not read unused portions of the inode table. There have been a number of improvements in the ext4 file system format which means that in general fsck times for ext4 are around 7-12 times faster than the equivalent ext3 file system. As an aside mke2fs -t ext4 includes huge_file, dir_nlink, and extra_isize while mke4fs doesn't. This difference seems wrong to me. Urgs. +1. I've never heard of mke4fs --- who thought up that abortion? mke2fs -t ext4 and mkfs.ext4 will both do the right thing, as far as creating file systems that have the correct ext4 file system features for a file system designed to be mounted using the ext4 file system driver in modern Linux kernels. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649689: e2fsprogs: FTBFS on hurd-i386
On Sun, Nov 27, 2011 at 10:27:48PM -0500, Ted Ts'o wrote: Additionally, the call to msync() is made conditional on HAVE_MSYNC instead of MS_SYNC by a test in configure.in for that function. On GNU/Hurd msync() is only a stub, so with this test a potential run-time error is avoided. Wait a second --- do you mean that msync() doesn't exist, but it exists but is a no-op? If it's the latter (is only a stub), then adding a check for HAVE_MSYNC won't help, because configure will check for the stub, find it, and come to the wrong conclusion. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649689: e2fsprogs: FTBFS on hurd-i386
On Mon, Nov 28, 2011 at 07:37:53PM +0100, Svante Signell wrote: Checking for HAVE_MSYNC helps because configure finds the stub and decides it is not usable, see below. Um, how does configure find the stub if you're just doing an AC_CHECK_FUNCS(... msync ...) That just checks if a function can link against msync() and not fail. It's not going to cause configure to go peering deeply into header files. Are you proposing that we use some specific autoconf macro? If so, which macro? Your patch just uses AC_CHECK_FUNCS, which doesn't have any kind of hueristic magic or artificial intelligence capabilities as far as I know - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649689: e2fsprogs: FTBFS on hurd-i386
tags 649689 +pending -patch
thanks
On Wed, Nov 23, 2011 at 09:44:34AM +0100, Svante Signell wrote:
The attached patch fixes the FTBFS problems for GNU/Hurd due to the lack
of a PATH_MAX definition. Instead of fixed length strings dynamic
allocation is used.
I fixed this problem a different way. See below.
Additionally, the call to msync() is made conditional on HAVE_MSYNC
instead of MS_SYNC by a test in configure.in for that function. On
GNU/Hurd msync() is only a stub, so with this test a potential run-time
error is avoided.
I'll take care of this too --- but in the future I'd appreciate if you
submitted separate patches for separate fixes.
Thanks, regards
- Ted
commit 4cd2d4ca4128456b82e927b1efd2dd023100934e
Author: Theodore Ts'o ty...@mit.edu
Date: Sun Nov 27 20:31:36 2011 -0500
libquota: remove use of PATH_MAX and replace it with QUOTA_NAME_LEN
PATH_MAX is not portable (for example, it doesn't exist on the Hurd).
So replace it with a new define, which defines the maximum length of
the base quota name. As it turns out, this is substantially smaller
than PATH_MAX.
Also move the definitions relating to quotaio.c from mkquota.h to
quotaio.h, as a cleanup.
Addresses-Debian-Bug: #649689
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/lib/quota/mkquota.h b/lib/quota/mkquota.h
index 4fbaedd..a5fa74b 100644
--- a/lib/quota/mkquota.h
+++ b/lib/quota/mkquota.h
@@ -60,9 +60,4 @@ int quota_is_on(ext2_filsys fs, int type);
int quota_file_exists(ext2_filsys fs, int qtype, int fmt);
void quota_set_sb_inum(ext2_filsys fs, ext2_ino_t ino, int qtype);
-/* In quotaio.c */
-const char *quota_get_qf_name(int type, int fmt, char *buf);
-const char *quota_get_qf_path(const char *mntpt, int qtype, int fmt,
- char *path_buf, size_t path_buf_size);
-
#endif /* __QUOTA_QUOTAIO_H__ */
diff --git a/lib/quota/quotaio.c b/lib/quota/quotaio.c
index d0b5b9d..3f434ca 100644
--- a/lib/quota/quotaio.c
+++ b/lib/quota/quotaio.c
@@ -56,7 +56,7 @@ const char *quota_get_qf_name(int type, int fmt, char *buf)
{
if (!buf)
return NULL;
- snprintf(buf, PATH_MAX, %s.%s,
+ snprintf(buf, QUOTA_NAME_LEN, %s.%s,
basenames[fmt], extensions[type]);
return buf;
@@ -66,7 +66,7 @@ const char *quota_get_qf_path(const char *mntpt, int qtype,
int fmt,
char *path_buf, size_t path_buf_size)
{
struct stat qf_stat;
- char qf_name[PATH_MAX] = {0};
+ char qf_name[QUOTA_NAME_LEN];
if (!mntpt || !path_buf || !path_buf_size)
return NULL;
diff --git a/lib/quota/quotaio.h b/lib/quota/quotaio.h
index f8cc1f1..91a1ff2 100644
--- a/lib/quota/quotaio.h
+++ b/lib/quota/quotaio.h
@@ -159,4 +159,12 @@ const char *type2name(int type);
void update_grace_times(struct dquot *q);
+/* size for the buffer returned by quota_get_qf_name(); must be greater
+ than maxlen of extensions[] and fmtnames[] (plus 2) found in quotaio.c */
+#define QUOTA_NAME_LEN 16
+
+const char *quota_get_qf_name(int type, int fmt, char *buf);
+const char *quota_get_qf_path(const char *mntpt, int qtype, int fmt,
+ char *path_buf, size_t path_buf_size);
+
#endif /* GUARD_QUOTAIO_H */
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644989: Still not fixed
On Wed, Nov 16, 2011 at 10:24:23AM +0600, Roman Mamedov wrote:
Hello,
I have just tried the version from Squeeze (1.41.12-4stable1), and it does
work properly
Yes, that's not surprising. The 1.41 version doesn't try to use the
new-style resize2fs ioctl. The fundamental issue is what error code
should be returned when an ioctl doesn't exist. Note:
% file /tmp/bad-ioctl-32 /tmp/bad-ioctl-64
/tmp/bad-ioctl-32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.26, not stripped
/tmp/bad-ioctl-64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
% /tmp/bad-ioctl-64 file
ENOTTY is 25
EINVAL is 22
ioctl 0xDEAD1 returns 25 (Inappropriate ioctl for device)
% /tmp/bad-ioctl-32 file
ENOTTY is 25
EINVAL is 22
ioctl 0xDEAD1 returns 22 (Invalid argument)
The issue is the kernel is returning a different error code when you
are using a 32-bit binary with a 64-bit kernel, which you are doing on
your MIPS system. So this is a mips-specific bug, and arguably its a
kernel-level problem. We can work around it by checking for EINVAL,
but that's unfortunate since EINVAL can mean other things ---
including its canonical Invalid argument.
- Ted
/*
* bad-ioctl.c - try calling a non-existent ioctl, and see what happens
*/
#include stdio.h
#include string.h
#include unistd.h
#include stdlib.h
#include errno.h
#include fcntl.h
#include sys/ioctl.h
int main(int argc, char **argv)
{
int fd;
fd = open(argv[1], O_RDONLY, 0);
if (fd 0) {
perror(open);
exit(1);
}
printf(ENOTTY is %d\n, ENOTTY);
printf(EINVAL is %d\n, EINVAL);
if (ioctl(fd, (unsigned) 0xDEAD1, 0) 0) {
int err = errno;
fprintf(stderr, ioctl 0xDEAD1 returns %d (%s)\n,
err, strerror(err));
exit(1);
}
return 0;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644989: Still not fixed
On Wed, Nov 16, 2011 at 02:29:37AM +0600, Roman Mamedov wrote: reopen 644989 ! thanks Hello, With e2fsprogs 1.42~WIP-2011-10-16-1 and Linux hoshi 3.1.0-libre-lemote-rm2-mfgpt #2 Fri Nov 11 03:07:23 YEKT 2011 mips64 GNU/Linux Are you using a 32-bit or 64-bit userspace with this 64-bit kernel? Because I can't replicate the problem, and in fact everyone else was complaining when we were checking for EINVAL instead of ENOTTY (which is what should be returned). # /vdb/resize2fs /dev/vdc resize2fs 1.42-WIP (16-Oct-2011) Filesystem at /dev/vdc is mounted on /vdc; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 20 Performing an on-line resize of /dev/vdc to 5242880 (1k) blocks. The filesystem on /dev/vdc is now 5242880 blocks long. p Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647039: e2fsprogs: e4defrag does not work with LVM device nodes
On Mon, Oct 31, 2011 at 12:16:35AM +0100, Laurent Grawet wrote: Then I would like to know whether chattr +e on files and dirs when coming from ext3 is enough to trigger online defragmentation in order to migrate those files to extent format ? The chattr +e will migrate older files to use the extent format; it will, however, not defragment the files. This matters primarily for very large files which are tens of megabytes or larger. And if the file system's free space wasn't fragmented, the difference will be marginal even in that case. And if the file system free space is heavily fragmented (say, if you were running it at 80-90% full for long periods of time), e4defrag isn't smart enough to handle this case, so the only real solution to recover the lost performance is to do a backup, reformat, and restore operation. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647245: e2fsprogs: 2GiB volume can't be formated on 32bit ports.
tag 647245 +pending thanks On Tue, Nov 01, 2011 at 01:23:09AM +0100, Samuel Thibault wrote: Samuel Thibault, le Tue 01 Nov 2011 01:16:58 +0100, a écrit : Package: e2fsprogs Version: 1.42~WIP-2011-10-16-1 Severity: important Actually that might even warrant a serious severity, as nowadays you can't do much with a 2GiB volume. It only applies to 2GB files. If it's on a disk device, it works fine. (Or otherwise a lot more people would have been screaming. :-) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644792: e2fsprogs [filefrag]: filefrag gets stuck if -v option not specified
tags 644792 +pending thanks On Sun, Oct 09, 2011 at 02:26:20AM -0400, Chris Lawrence wrote: filefrag seems to get stuck (if -v is not specified) repeatedly calling the FS_IOC_FIEMAP ioctl in the do..while loop. I suspect this may have to do with the fix for #631498. It looks like the changes from Ibragimov Rinat were only partially applied, which means that count is still set to 0 when -v is not specified. Applying the first part of his patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631498#17 appears to fix the problem. Oops, thanks for noticing this. You were absolutely right on what happened. I've applied the missing patch hunk. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644584: e2fsprogs: fsck.ext4 failed to run at boot time. causing boot failure
retitle 644425 undefined symbol in /sbin/e2fsck caused by missing dependency priority 644584 important merge 644425 644584 thanks On Fri, Oct 07, 2011 at 03:28:32PM +0800, Yafan Zhao wrote: Package: e2fsprogs Version: 1.42~WIP-2011-10-05-1 Severity: grave Justification: renders package unusable Dear Maintainer, After upgrade e2fsprogs and e2fslibs to e2fslibs_1.42~WIP-2011-10-05-1 and e2fsprogs_1.42~WIP-2011-10-05-1, system failed to boot. It is clear that the problem is within fsck.ext4, which failed to check file system and the file system was mounted read-only. In rescue mode (using init=/bin/bash in grub option), when running fsck.ext4, the following error message was printed: fsck.ext4 undefined symbol : ste_com_err_gettext Downgraing e2fslibs and e2fsprogs to e2fslibs_1.41.12-4stable1 and e2fsprogs_1.41.12-4stable1 solved the problem. Upgraded libcom_err to a 1.42~WIP-2011-10-05-1 would have also fixed the problem. The issue was a missing dependency that I will be addressing in the next version (coming soon!), which will get this fixed. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644502: e2fsprogs: FTBFS on hurd-i386 (and kfreebsd-any)
tags 644502 +pending
thanks
On Thu, Oct 06, 2011 at 02:37:41PM +0200, Svante Signell wrote:
The patch inlined below fixes the remaining FTBFS problems for
GNU/Hurd.
It probably fixes the build problems for GNU/kFreeBSD too. The QIF_*
stuff is only used for quota_v2 and kfree seems to have version quota_v1
as their quota.h does not have these defined. For kfreebsd-* quota.h is
at ufs/ not sys/ so the test below also applies to this architecture.
From the latest build log quotactl is found, and that function is
defined in quota.h.
Thanks, I already have the following checked into the git tree to
address that problem (which I had noticed by checking the buildd logs).
I'm waiting for clarification from the mips folks about how to address
the remaining MIPS build failure before uploading a new updated package...
It's good to know that this fixes the last remaining problem with
Hurd. BTW, could you confirm that on a hurd system the mke2fs.conf
file which is included has a default inode_size of 128 bytes, to
address #629355? Thanks!!
- Ted
commit b5ba6f5b9da9d4e3d6f52ef9470ec12a161b1a7f
Author: Theodore Ts'o ty...@mit.edu
Date: Wed Oct 5 13:26:59 2011 -0400
libquota: remove flag argument to commit_dquot()
The flag parameter wasn't being used, and using it meant that we had
to define the COMMIT_* flags, which relied on the QIF_* flags being
present. Removing this allows for increased portability.
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/lib/quota/mkquota.c b/lib/quota/mkquota.c
index 35cac66..5440003 100644
--- a/lib/quota/mkquota.c
+++ b/lib/quota/mkquota.c
@@ -127,7 +127,7 @@ static void write_dquots(dict_t *dict, struct quota_handle
*qh)
if (dq) {
dq-dq_h = qh;
update_grace_times(dq);
- qh-qh_ops-commit_dquot(dq, COMMIT_ALL);
+ qh-qh_ops-commit_dquot(dq);
}
}
}
diff --git a/lib/quota/quotaio.h b/lib/quota/quotaio.h
index 333a59f..282b543 100644
--- a/lib/quota/quotaio.h
+++ b/lib/quota/quotaio.h
@@ -101,13 +101,6 @@ struct dquot {
struct util_dqblk dq_dqb; /* Parsed data of dquot */
};
-/* Flags for commit function (have effect only when quota in kernel is
- * turned on) */
-#define COMMIT_USAGE QIF_USAGE
-#define COMMIT_LIMITS QIF_LIMITS
-#define COMMIT_TIMES QIF_TIMES
-#define COMMIT_ALL (COMMIT_USAGE | COMMIT_LIMITS | COMMIT_TIMES)
-
/* Structure of quotafile operations */
struct quotafile_ops {
/* Check whether quotafile is in our format */
@@ -123,7 +116,7 @@ struct quotafile_ops {
/* Read dquot into memory */
struct dquot *(*read_dquot) (struct quota_handle *h, qid_t id);
/* Write given dquot to disk */
- int (*commit_dquot) (struct dquot *dquot, int flag);
+ int (*commit_dquot) (struct dquot *dquot);
/* Scan quotafile and call callback on every structure */
int (*scan_dquots) (struct quota_handle *h,
int (*process_dquot) (struct dquot *dquot,
diff --git a/lib/quota/quotaio_v2.c b/lib/quota/quotaio_v2.c
index 35512c0..7c9e4f7 100644
--- a/lib/quota/quotaio_v2.c
+++ b/lib/quota/quotaio_v2.c
@@ -25,7 +25,7 @@ static int v2_init_io(struct quota_handle *h);
static int v2_new_io(struct quota_handle *h);
static int v2_write_info(struct quota_handle *h);
static struct dquot *v2_read_dquot(struct quota_handle *h, qid_t id);
-static int v2_commit_dquot(struct dquot *dquot, int flags);
+static int v2_commit_dquot(struct dquot *dquot);
static int v2_scan_dquots(struct quota_handle *h,
int (*process_dquot) (struct dquot *dquot,
char *dqname));
@@ -285,7 +285,7 @@ static struct dquot *v2_read_dquot(struct quota_handle *h,
qid_t id)
* became fake one and user has no blocks.
* User can process use 'errno' to detect errstr.
*/
-static int v2_commit_dquot(struct dquot *dquot, int flags)
+static int v2_commit_dquot(struct dquot *dquot)
{
struct util_dqblk *b = dquot-dq_dqb;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644425: e2fsprogs: undefined symbol in fsck.ext4
On Wed, Oct 05, 2011 at 08:59:38PM +0200, Maarten De Munck wrote: Package: e2fsprogs Version: 1.42~WIP-2011-10-05-1 Severity: important fsck.ext4 fails with error: fsck.ext4: symbol lookup error: fsck.ext4: undefined symbol: set_com_err_gettext. Since this happens on the root fsck at boot, the system is left in maintenance mode. The error dos not occur with e2fsprogs 1.42~WIP-2011-09-25-1 in combination with libcomerr2 1.42~WIP-2011-07-02-01 (tested). The error is solved by upgrading libcomerr2 to version 1.42~WIP-2011-10-05-1, so I suppose this should be changed in the package requirements (tested). Yes, this is a dependency problem; we need to bump the requirement to libcomerr2 be 1.42~WIP-2011-10-05-1. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451388: resize2fs: Invalid argument While trying to add group #38
On Sun, Oct 02, 2011 at 11:48:44PM -0400, Daniel Kahn Gillmor wrote: Any chance the resize2fs was a 32-bit binary by any chance? yes, indeed. this is a ppc64 kernel and a 32-bit powerpc everything-else. Stupid question. Can you tell me what the sizeof(unsigned long) is on ppc64 and ppc32? I think that might be the problem... Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451388: resize2fs: Invalid argument While trying to add group #38
On Mon, Oct 03, 2011 at 12:46:52PM -0400, Daniel Kahn Gillmor wrote: On Mon, 3 Oct 2011 12:04:19 -0400, Ted Ts'o ty...@mit.edu wrote: Stupid question. Can you tell me what the sizeof(unsigned long) is on ppc64 and ppc32? I think that might be the problem... 0 abc@tut:~/src/test$ gcc -o test test.c -m32 ./test 4 0 abc@tut:~/src/test$ gcc -o test test.c -m64 ./test 8 0 abc@tut:~/src/test$ Yep, that's the problem. We're not taking that into account for the EXT4_IOC_GROUP_EXTENT ioctl, which would explain why we're then getting the last group not full error. Hmm... by any chance was there a will only finish group ( blocks, ddd new) warning message in the dmesg, before that last group not full error? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451388: resize2fs: Invalid argument While trying to add group #38
On Mon, Oct 03, 2011 at 01:34:57PM -0400, Daniel Kahn Gillmor wrote:
Does this bug need to be reassigned to the kernel or is it in
e2fsprogs? Do you have a patch you want me to try? (it'd be much
easier for me to try a patched e2fsprogs than a patched kernel on
remote hardware)
Actually looking at this some more, I think it might actually be an
e2fsprogs bug. Can you try out the following patch? It applies
against the 1.42-WIP-1001 release of e2fsprogs. Or grab the next
branch from git://github.com/tytso/e2fsprogs.git.
- Ted
commit 200569608fc6e33f6546c17999f14fb5dbb0b9b5
Author: Theodore Ts'o ty...@mit.edu
Date: Mon Oct 3 20:35:19 2011 -0400
resize2fs: fix on-line resizing
On-line resizing has been broken in the 1.42 series for two reasons:
(a) the call to the new EXT4_IOC_RESIZE_FS ioctl checked for ENOTTY to
indicate that the ioctl does not exist, when in fact EINVAL is what is
returned if the ioctl doesn't exist. (b) resize2fs was passing in a
pointer to a 64-bit value, when the ioctl expected a 32-bit value.
This was OK on little-endian systems, but it wouldn't work at all on
big-endian systems.
Fix both problems.
Addresses-Debian-Bug: #451388
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/resize/online.c b/resize/online.c
index e1d05b7..bbe684a 100644
--- a/resize/online.c
+++ b/resize/online.c
@@ -19,6 +19,8 @@
extern char *program_name;
+#define MAX_32_NUM unsigned long long) 1) 32) - 1)
+
errcode_t online_resize_fs(ext2_filsys fs, const char *mtpt,
blk64_t *new_size, int flags EXT2FS_ATTR((unused)))
{
@@ -31,7 +33,7 @@ errcode_t online_resize_fs(ext2_filsys fs, const char *mtpt,
errcode_t retval;
double percent;
dgrp_t i;
- blk64_t size;
+ blk_t size;
int fd, overhead;
int use_old_ioctl = 1;
@@ -69,10 +71,8 @@ errcode_t online_resize_fs(ext2_filsys fs, const char *mtpt,
exit(1);
}
- size=ext2fs_blocks_count(sb);
-
if (ioctl(fd, EXT4_IOC_RESIZE_FS, new_size)) {
- if (errno != ENOTTY) {
+ if (errno != EINVAL) {
if (errno == EPERM)
com_err(program_name, 0,
_(Permission denied to resize filesystem));
@@ -87,6 +87,14 @@ errcode_t online_resize_fs(ext2_filsys fs, const char *mtpt,
return 0;
}
+ if ((ext2fs_blocks_count(sb) MAX_32_NUM) ||
+ (*new_size MAX_32_NUM)) {
+ com_err(program_name, 0,
+ _(Kernel does not resizing a file system this large));
+ exit(1);
+ }
+ size = ext2fs_blocks_count(sb);
+
if (ioctl(fd, EXT2_IOC_GROUP_EXTEND, size)) {
if (errno == EPERM)
com_err(program_name, 0,
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451388: resize2fs: Invalid argument While trying to add group #38
On Sun, Oct 02, 2011 at 05:00:51PM -0400, Daniel Kahn Gillmor wrote: Performing an on-line resize of /dev/mapper/vg_tut0-usr to 1572864 (4k) blocks. resize2fs: Invalid argument While trying to add group #38 1 tut:~# let me know if there is more information i can provide. Could you check /var/log/dmesg* log files to see if the kernel printed any explanatory messages around the time when you attempted to run resize2fs? That might shed some light as to what was going on. Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451388: resize2fs: Invalid argument While trying to add group #38
On Sun, Oct 02, 2011 at 10:30:47PM -0400, Daniel Kahn Gillmor wrote:
On 10/02/2011 09:41 PM, Theodore Tso wrote:
Oh interesting…. I'm not sure whether this is a kernel bug or a resize2fs
bug.
What version of the kernel are you using? And what architecture? x86_64?
i386?
This is a powerpc G5, running debian's powerpc64 3.0
(linux-image-3.0.0-1-powerpc64, version 3.0.0-3)
Any chance the resize2fs was a 32-bit binary by any chance?
This message:
Oct 2 16:43:39 tut kernel: [ 168.613200] ioctl32(resize2fs:2469):
Unknown cmd fd(4) cmd(80286608){t:'f';sz:40} arg(ffcfc210) on /usr
is very interesting and suggests the problem is in the 32-64 bit
compatibility code in the kernel, and explains why most other people
aren't seeing it.
Is this failure something that happens reliably, in that on this
machine, online resizing isn't working pretty much for any file
system?
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546388: e2fsprogs: Odd filesystem labels confuse blkid
reassign 546388 util-linux thanks Sigh, one more time, with feeling The blkid library is now the responsibility of the util-linux package. I *think* this issue is already addressed in the revmaped version of blkid found in util-linux, but I'm not 100% sure, so I'm reassigning it to the util-linux package for its maintainers to confirm whether it should be closed as already fixed. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634883: e2fsprogs: Please explain in mke2fs.conf(5) what enabled means
tags 634883 +pending thanks On Wed, Jul 20, 2011 at 09:23:51PM +0200, Helge Kreutzmann wrote: The man page explains the various options and several times says if enabled (e.g. for enable_periodic_fsck). From the shipped file I assume that enabled means a numeric 1 and disabled a numeric 0? Yes, that's correct. Thanks for pointing out the man page was less than clear here. I've fixed this for the next release. - Ted commit 900ea6129541ab9319986c4960ee7335c13830c8 Author: Theodore Ts'o ty...@mit.edu Date: Fri Sep 30 18:32:44 2011 -0400 mke2fs.conf.5: clarify the man page regarding boolean relations Explain more clearly how boolean relations in the mke2fs.conf file are parsed, and which config parameters are in fact boolean relations. Addresses-Debian-Bug: #634883 Signed-off-by: Theodore Ts'o ty...@mit.edu diff --git a/misc/mke2fs.conf.5.in b/misc/mke2fs.conf.5.in index b2c7a57..636a0f1 100644 --- a/misc/mke2fs.conf.5.in +++ b/misc/mke2fs.conf.5.in @@ -59,6 +59,11 @@ apply: \en (for the newline character), \et (for the tab character), \eb (for the backspace character), and \e\e (for the backslash character). .P +Some relations expect a boolean value. The parser is quite liberal on +recognizing ``yes'', '`y'', ``true'', ``t'', ``1'', ``on'', etc. as a +boolean true value, and ``no'', ``n'', ``false'', ``nil'', ``0'', +``off'' as a boolean false value. +.P The following stanzas are used in the .I mke2fs.conf file. They will be described in more detail in future sections of this @@ -108,8 +113,8 @@ to .BR mke2fs (8). .TP .I enable_periodic_fsck -This relation specifies whether periodic filesystem checks should be -enforced at boot time. If enabled, checks will be forced every +This boolean relation specifies whether periodic filesystem checks should be +enforced at boot time. If set to true, checks will be forced every 180 days, or after a random number of mounts. These values may be changed later via the .B -i @@ -119,7 +124,7 @@ command-line options to .BR tune2fs (8). .TP .I force_undo -This relation, if set to a boolean value of true, forces +This boolean relation, if set to a value of true, forces .B mke2fs to always try to create an undo file, even if the undo file might be huge and it might extend the time to create the filesystem image @@ -341,7 +346,7 @@ This relation specifies the default blocksize if the user does not specify a blocksize on the command line. .TP .I lazy_itable_init -This relation is a boolean which specifies whether the inode table should +This boolean relation specifies whether the inode table should be lazily initialized. It only has meaning if the uninit_bg feature is enabled. If lazy_itable_init is true and the uninit_bg feature is enabled, the inode table will @@ -392,7 +397,7 @@ by on a per-filesystem type basis. .TP .I discard -This relation is a boolean which specifies whether the +This boolean relation specifies whether the .BR mke2fs (8) should attempt to discard device prior to filesystem creation. .TP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631498: e2fsprogs: filefrag should report adjacent extents as one
tag 631498 +pending thanks On Fri, Jun 24, 2011 at 04:02:23PM +0400, Ibragimov Rinat wrote: When filefrag uses FIEMAP ioctl its logic differs for ordinary and verbose (-v) modes. ext4 returns extent on every 32768 block so on large files it is possible that `filefrag large-file' tells about 4 extents while `filefrag -v large-file' finds only one. Also when I tried to use generic_block_fiemap function to add FIEMAP for reiserfs, every block was reported as a new extent resulting in thousands extents for continuous files. I think filefrag should merge adjacent extents even when -v is not specified. Thanks for reporting this bug. I agree, and I've applied a fix for the next release of e2fsprogs. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520985: [nieh...@web.de: typo: e2fsck abgebrochhen]
Hi, since you are the last translator for the German e2fsprogs.pot file, I'm forwarding this to you. Note that there will be a new e2fsprogs.pot published soon, for the upcoming e2fsprogs 1.42 release. If you could include this fix in the next de.po update for e2fsprogs, I would greatly appreciate it. Thanks!! - Ted ---BeginMessage--- Package: e2fsprogs Version: 1.41.3-1 Severity: minor Tags: l10n fsck.ext3 has a typo in the german translation: , | crystalline:/home/niehaus# fsck.ext3 -fn /dev/sda1 | e2fsck 1.41.3 (12-Oct-2008) | Durchgang 1: Prüfe Inodes, Blocks, und Größen I press Strg-C to interrupt it: ^C | USB-BACKUP: e2fsck abgebrochhen. ` Should be: e2fsck abgebrochen. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages e2fsprogs depends on: ii e2fslibs 1.41.3-1 ext2 filesystem libraries ii libblkid1 1.41.3-1 block device id library ii libc6 2.7-18 GNU C Library: Shared libraries ii libcomerr21.41.3-1 common error description library ii libss21.41.3-1 command-line interface parsing lib ii libuuid1 1.41.3-1 universally unique id library e2fsprogs recommends no packages. Versions of packages e2fsprogs suggests: pn e2fsck-static none (no description available) ii gpart 0.1h-4.1 Guess PC disk partition table, fin pn partednone (no description available) -- no debconf information ---End Message---
Bug#620659: [glo...@debian.org: e2fsprogs: strange French translation in resize2fs]
Hi, since you're the last translator for the French translation file for e2fsprogs.pot, I'm forwarding this to you. Note that there will shortly be a new e2fsprogs.pot file published for the upcoming 1.42 release. If you could consider this bug report and fix translation if appropriate in the next fr.po update for e2fsprogs, I would greatly appreciate it. Many thanks!! - Ted ---BeginMessage--- Package: e2fsprogs Version: 1.41.12-2 Severity: minor Tags: l10n Hello, When resizing a filesystem using resize2fs, the French message reads: En train de retailler le système de fichiers sur [...] retailler doesn't look right... especially when the fs is growing! (re-)tailler is always shrinking in French. redimensionner is neutral w.r.t. the kind of resizing, and would be better here. Cheers, -- Stéphane -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages e2fsprogs depends on: ii e2fslibs 1.41.12-2 ext2/ext3/ext4 file system librari ii libblkid1 2.17.2-9.1 block device id library ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libcomerr21.41.12-2 common error description library ii libss21.41.12-2 command-line interface parsing lib ii libuuid1 2.17.2-9.1 Universally Unique ID library ii util-linux2.17.2-9.1 Miscellaneous system utilities e2fsprogs recommends no packages. Versions of packages e2fsprogs suggests: pn e2fsck-static none (no description available) pn gpart none (no description available) pn partednone (no description available) -- no debconf information ---End Message---
Bug#627535: e2fsprogs: FTBFS with DEB_BUILD_OPTIONS=noopt nostrip
tags 627535 +pending thanks On Sat, May 21, 2011 at 09:23:42PM +0300, Sami Liedes wrote: Package: e2fsprogs Version: 1.41.12-4 Severity: normal e2fsprogs fails to build if DEB_BUILD_OPTIONS contains nostrip Thanks for reporting this. I've fixed it in my sources and it will be in the next release. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642193: 'man e2fsck' typo: exacly
tag 642193 +pending thanks On Tue, Sep 20, 2011 at 01:33:38AM -0400, A. Costa wrote: Found a typo in '/usr/share/man/man8/e2fsck.8.gz', see attached '.diff'. Thanks for reporting this! I've fixed it in my sources and it will be in the next release. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614082: e2fsprogs: fsck.ext4 fails with 'Memory allocation failed' message
retitle 614082 e2fsck dies with an OOM on bad triple-indirect block in a dir inode thanks On Sat, Feb 19, 2011 at 06:09:38PM +0300, George Shuklin wrote: Error storing directory block information (inode=169246423, block=0, num=3966024): Memory allocation failed Apologies for not looking at this sooner. I had assumed this was the standard user was trying to check a too-big file system with an 32-bit userspace problem, and then I got busy and it dropped off the end of my inbox. In fact it's a much more interesting problem. What happened was that you got unlucky and trash got written into your inode table. One of the inodes that got overwritten had the directory bit set, and the extents flag was _not_ set. So the i_blocks field was interpreted as a series of blocks. Many of those i_blocks entries were garbage, and were cleared, but the triple indirect block could be interpreted as a valid block number, so we started iterating over all of the double indirection blocks. To make sure that the directory doesn't have holes in it, e2fsck then started allocating entries to keep track of all of this via ext2fs_add_dir_block2(), and this is what caused the memory overflow. To fix this what we need to do is to notice when an inode looks insane, and ask the user if they are willing to just nuke it, as opposed to trying to fix all of the individual things that are wrong with it. The way to work around this problem should it occur again is to note the inode number, and then zap it using debugfs: debugfs -w /dev/md1 debugfs: clri 169246423 debugfs: quit Then e2fsck should be able to complete its work. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629883: e2fsprogs: FTBFS: parse.c:56:20: error: 'errno' undeclared (first use in this function)
tag 629883 +pending thanks I recently was able to reproduce this. It looks like some shellutil program used by configure has a 4k line length problem. The problem doesn't show up on Ubuntu 10.04/x86_64, and it doesn't show up in my sid/i386 chroot (which is what I normally upload to the ftp archives) and apparently it doesn't show up in the official x86_64/buildd's But it did show up in your (Didier's) test builds, and it recently popped for me as well when I created a sid/x86_64 chroot to do some unrelated development/test work. The problem is that there is this line in MCONFIG.in: DEFS = @DEFS@ which gets pulled into all of the make files. @DEFS@ is about 4200 bytes. This resulted in a corrupted line in the generated MCONFIG file, and hence in all of the Makefiles. This caused all of the autoconf-generated declarations (e.g., -DHAVE_ERRNO_H, et. al) to get lost, and that's what caused the 'errno' undeclared compilation error. Why the problem doesn't show up the 32-bit sid environment, but only the 64-bit sid environment (and as a regression to boot since Ubuntu 10.04 doesn't exhibit this bug) is an interesting one, but I'll leave that for another day or another developer to figure out. I've worked around the problem in e2fsprogs by using a config.h file instead of passing all of the defines on the command-line -- a better solution anyway. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632169: Please transition e2fsprogs for multiarch
On Thu, Jun 30, 2011 at 09:17:58AM +0100, Steve Langasek wrote: Please find attached a patch to e2fsprogs to transition it to use of the multiarch library paths as described at http://wiki.debian.org/Multiarch/Implementation. This patch has been applied and is being used successfully in Ubuntu 11.04, and should be safe to apply in Debian now that multiarch has been bootstrapped there. Note, your patches appear cause the following Lintian error: E: libcomerr2-dbg: binary-with-bad-dynamic-table usr/lib/x86_64-linux-gnu/debug/lib/x86_64-linux-gnu/libcom_err.so.2.1 N: N:This appears to be an ELF file but objdump -T cannot parse it. If it is N:external debugging symbols for another file, it should be installed N:under /usr/lib/debug. N: N:Severity: serious, Certainty: possible N: N:Check: binaries, Type: binary, udeb N: This is caused by files showing up in /usr/lib/x86_64-linux-gnu/debug/lib/x86_64-linux-gnu/libcom_err.so.2.1 instead of /usr/lib/debug/lib/x86_64-linux-gnu/libcom_err.so.2.1 The multiarch proposal seems to be vague on some of these details. And I'm really worred about whether tools like gdb, perf, and other tools that expect to find the debugging files will find them if /usr/lib/triplet/debug is used instead of /usr/lib/debug. My current thinking is to *not* enable move these files from /usr/lib/debug, since from my testing both gdb and lintian don't know about this change (for now). Pkgconfig seems to know about /usr/lib/triplet/pkgconfig, and lintian doesn't complain, I'll move the .pc files for now. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632169: Please transition e2fsprogs for multiarch
Hi Steve, On Thu, Jun 30, 2011 at 09:17:58AM +0100, Steve Langasek wrote: Please find attached a patch to e2fsprogs to transition it to use of the multiarch library paths as described at http://wiki.debian.org/Multiarch/Implementation. This patch has been applied and is being used successfully in Ubuntu 11.04, and should be safe to apply in Debian now that multiarch has been bootstrapped there. If you have time to validate the changes I made to e2fsprogs to support multiarch, I would greatly appreciate it. I couldn't just use your patch because I need to support Ubuntu 10.04 (and Debian Stable) as well as Debian Unstable systems. You can get and build my latest e2fsprogs tree as follows: git clone git://github.com/tytso/e2fsprogs.git cd e2fsprogs git checkout -b next origin/next ./debian/rules fakeroot dpkg-buildpackage The above should work on Ubuntu LTS, Debian Stable, Debian Unstable, as well as whatever prelease Ubuntu system you are working on. Let me know if I screwed anything up. :-) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641838: FTBFS: struct ext2_group_desc missing some members
On Fri, Sep 16, 2011 at 05:42:26PM +, Thorsten Glaser wrote: Source: e2fsprogs Version: 1.42~WIP-2011-09-16-1 Severity: serious Justification: fails to build from source (but built successfully in the past) e2fsprogs stopped building with the latest upload. Relevant build log excerpt: CC /tmp/buildd/e2fsprogs-1.42~WIP-2011-09-16/lib/ext2fs/swapfs.c /tmp/buildd/e2fsprogs-1.42~WIP-2011-09-16/lib/ext2fs/swapfs.c: In function 'ext2fs_swap_group_desc2': /tmp/buildd/e2fsprogs-1.42~WIP-2011-09-16/lib/ext2fs/swapfs.c:135: error: 'struct ext2_group_desc' has no member named 'bg_exclude_bitmap_hi' Ack, thanks, I'll get this fixed. By the way, hiding build command lines like this (as CC) is against buildd admin policy, I think. Please consider fixing that as well. Can you point me at the relevant policy, out of curiosity? Thanks, regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641838: FTBFS: struct ext2_group_desc missing some members
On Fri, Sep 16, 2011 at 07:47:46PM +, Thorsten Glaser wrote: Not really, I read it “somewhere”, while trying to familiarise myself with buildds, but didn’t bookmark this specially (as it matches what I think is right), see http://lists.debian.org/debian-68k/2011/09/msg00035.html Is there a reliable way that the debian/rules file can determine that it's running in a buildd? The reason for this is that when you're monitoring the build when it's happening in a window, make V=1 is darned annoying although I'll agree it's useful when you're trying to debug what's going on after a buildd failure. After all, we're talking about the difference of this: CC ../../e2fsck/pass1.c and this: gcc -c -I../lib -I../../lib -DLOCALEDIR=\/usr/share/locale\ -DROOT_SYSCONFDIR=\/etc\ -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DHAVE_DLOPEN=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DENABLE_HTREE=1 -DCONFIG_TESTIO_DEBUG=1 -DTLS=__thread -DUSE_UUIDD=1 -DPACKAGE=\e2fsprogs\ -DVERSION=\0.14.1\ -DHAVE_LONG_LONG=1 -DHAVE_LONG_DOUBLE=1 -DHAVE_WCHAR_T=1 -DHAVE_WINT_T=1 -DHAVE_INTTYPES_H_WITH_UINTMAX=1 -DHAVE_STDINT_H_WITH_UINTMAX=1 -DHAVE_INTMAX_T=1 -DHAVE_POSIX_PRINTF=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DINTDIV0_RAISES_SIGFPE=1 -DHAVE_UNSIGNED_LONG_LONG=1 -DHAVE_UINTMAX_T=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDINT_H=1 -DHAVE_ARGZ_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_ASPRINTF=1 -DHAVE_FWPRINTF=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETUID=1 -DHAVE_MEMPCPY=1 -DHAVE_MUNMAP=1 -DHAVE_PUTENV=1 -DHAVE_SETENV=1 -DHAVE_SETLOCALE=1 -DHAVE_SNPRINTF=1 -DHAVE_STPCPY=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRTOUL=1 -DHAVE_TSEARCH=1 -DHAVE_WCSLEN=1 -DHAVE___ARGZ_COUNT=1 -DHAVE___ARGZ_STRINGIFY=1 -DHAVE___ARGZ_NEXT=1 -DHAVE___FSETLOCKING=1 -DHAVE_DECL__SNPRINTF=0 -DHAVE_DECL__SNWPRINTF=0 -DHAVE_DECL_FEOF_UNLOCKED=1 -DHAVE_DECL_FGETS_UNLOCKED=0 -DHAVE_DECL_GETC_UNLOCKED=1 -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LANGINFO_CODESET=1 -DHAVE_LC_MESSAGES=1 -DENABLE_NLS=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -DHAVE_DIRENT_H=1 -DHAVE_ERRNO_H=1 -DHAVE_EXECINFO_H=1 -DHAVE_GETOPT_H=1 -DHAVE_MALLOC_H=1 -DHAVE_MNTENT_H=1 -DHAVE_PATHS_H=1 -DHAVE_SEMAPHORE_H=1 -DHAVE_SETJMP_H=1 -DHAVE_SIGNAL_H=1 -DHAVE_STDARG_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_TERMIO_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_LINUX_FALLOC_H=1 -DHAVE_LINUX_FD_H=1 -DHAVE_LINUX_MAJOR_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PRCTL_H=1 -DHAVE_SYS_QUEUE_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_SYSCALL_H=1 -DHAVE_SYS_SYSMACROS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UN_H=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_NET_IF_H=1 -DHAVE_VPRINTF=1 -DHAVE_RECLEN_DIRENT=1 -DHAVE_TYPE_SSIZE_T=1 -DHAVE_LSEEK64_PROTOTYPE=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_INTTYPES_H=1 -DHAVE_INTPTR_T=1 -DHAVE_GETRUSAGE=1 -DHAVE_LLSEEK=1 -DHAVE_LSEEK64=1 -DHAVE_OPEN64=1 -DHAVE_FSTAT64=1 -DHAVE_FTRUNCATE64=1 -DHAVE_STRTOULL=1 -DHAVE_STRCASECMP=1 -DHAVE_SRANDOM=1 -DHAVE_JRAND48=1 -DHAVE_FCHOWN=1 -DHAVE_MALLINFO=1 -DHAVE_FDATASYNC=1 -DHAVE_STRNLEN=1 -DHAVE_STRPTIME=1 -DHAVE_STRDUP=1 -DHAVE_SYSCONF=1 -DHAVE_PATHCONF=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_MEMALIGN=1 -DHAVE_VALLOC=1 -DHAVE___SECURE_GETENV=1 -DHAVE_PRCTL=1 -DHAVE_MMAP=1 -DHAVE_UTIME=1 -DHAVE_SETRESUID=1 -DHAVE_SETRESGID=1 -DHAVE_USLEEP=1 -DHAVE_NANOSLEEP=1 -DHAVE_GETDTABLESIZE=1 -DHAVE_GETRLIMIT=1 -DHAVE_SYNC_FILE_RANGE=1 -DHAVE_POSIX_FADVISE=1 -DHAVE_FALLOCATE=1 -DHAVE_FALLOCATE64=1 -DHAVE_BLKID_PROBE_GET_TOPOLOGY=1 -DHAVE_MBSTOWCS=1 -DHAVE_BACKTRACE=1 -DHAVE_SEM_INIT=1 -DHAVE_EXT2_IOCTLS=1 -g -DRESOURCE_TRACK -I. ../../e2fsck/e2fsck.c -o e2fsck.o Multiplied by several thousand lines. :-( - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636418: e2fslibs: New version breaks dump (source and binary)
tags 636418 +pending thanks On Wed, Aug 03, 2011 at 12:07:29AM +0100, Mark Wooding wrote: Package: e2fslibs Version: 1.42~WIP-2011-07-02-1 Severity: important With this version of e2fslibs, dump 0.4b44-1 is a total loss: it fails with SIGFPE during pass IV. Thanks for reporting this! I made a change to struct fs which caused dump to have heartburn. That's an ABI change which shouldn't have happen. (But this is why I do WIP releases. :-) I've fixed the binary ABI compatibility, and also added back the support for the fragments macros (which ext2/3/4 will never support, but which whoever originally hacked dump/restore so that it worked with ext2/3/4 instead of the BSD FFS) so that dump can build against the 1.42 version of e2fsprogs. Note however that dump is doing some very sketchy things, and quite frankly I'm suprised it works with ext4 file systems --- or at least appears to work. :-P Someone should really do some verification to make sure it is really working with ext4. I can guarantee it won't work on file systems 16TB's, because of how it's accessing blocks_count variable: #define sblock fs #define fs_fsizeblocksize #define fs_bsizeblocksize #define fs_size super-s_blocks_count You will never find a more wretched hive of scum and villainy. ;-) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641667: /lib/libe2p.so.2: [patch] e2fsprogs/libe2p: tune2fs never recognizes MNTOPT_* mount options
On Thu, Sep 15, 2011 at 04:07:07AM +0200, Israel G. Lugo wrote: There's an off-by-one bug in lib/e2p/mntopts.c:e2p_string2mntopt(), both in the Debian 1.41.12 version, and the current upstream 1.41.14 version. It's failing to properly recognize any MNTOPT_* options, which means I can't for example do the following: # tune2fs -o MNTOPT_10 /dev/sda2 tune2fs 1.41.12 (17-May-2010) Invalid mount option set: MNTOPT_10 MNTOPT_10 corresponds to the discard mount option; this particular example is from an embedded system running Debian 6.0.2 armv5tel. Thanks for the fix. I am the upstream for e2fsprogs, so I'll make sure it gets into a future release. As far as getting this backported into 1.41.12-4stable1, it's a pain in the tuckus to get patches backported into stable, especially when the package is used by the installer, and I'm not sure the stable release maintainers would consider this bug important enough to be worthy of a backport. After all, I don't think the stable kernel understands EXT4_DEFM_DISCARD anyway, does it? Why don't you just compile a newer version of e2fsprogs for stable? We may never get it into stable release, but it should work just fine there. After all, there's a reason Debian Stable is known as Debian Obsolete. :-) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629883: e2fsprogs: FTBFS: parse.c:56:20: error: 'errno' undeclared (first use in this function)
fixed 629883 e2fsprogs/1.41.12-4stable1 thanks On Thu, Jun 09, 2011 at 10:20:22AM +0200, Didier Raboud wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: CC /«BUILDDIR»/e2fsprogs-1.41.12/lib/ss/parse.c /«BUILDDIR»/e2fsprogs-1.41.12/lib/ss/parse.c: In function 'ss_parse': /«BUILDDIR»/e2fsprogs-1.41.12/lib/ss/parse.c:56:20: error: 'errno' undeclared (first use in this function) /«BUILDDIR»/e2fsprogs-1.41.12/lib/ss/parse.c:56:20: note: each undeclared identifier is reported only once for each function it appears in I have no idea how or why this failed, but (a) I always only upload 32-bit i386 packages, and so the original 1.41.12 deb was built using the autobuilder, (b) we definitely are #including errno.h in parse.c., (c) I uploaded a 32-bit binaries for 1.41.12-4stable1, and according to: http://packages.debian.org/squeeze/libss2 it looks pretty clear that amd64 (as far as all other architectures) built w/o problems. So I'm going to declare this problem fixed in 1.41.12-4stable1. I'm pretty sure it was fine in 1.41.12-4 (since as I said the amd64 debs were originally built using the Debian pbuilder systems; I only upload i386 binaries), but it's not worth trying to debug how or why it failed when you tried to do the rebuild. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
My basic impression is that the use of data=journalled can help reduce the risk (slightly) of serious corruption to some kinds of databases when the application does not provide appropriate syncs or journalling on its own (IE: such as text-based Wiki database files). Yes, although if the application has index files that have to be updated at the same time, there is no guarantee that the changes that survive after a system failure (either a crash or a power fail), unless the application is doing proper application-level journalling or some other structured. To sum up, the only additional guarantee data=journal offers against data=ordered is a total ordering of all IO operations. That is, if you do a sequence of data and metadata operations, then you are guaranteed that after a crash you will see the filesystem in a state corresponding exactly to your sequence terminated at some (arbitrary) point. Data writes are disassembled into page-sized page-aligned sequence of writes for purpose of this model... data=journal can also make the fsync() operation faster, since it will involver fewer seeks (although it will require a greater write bandwidth). Depending on the write bandwidth, you really need to benchmark things to be sure, though. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
On Mon, Jun 27, 2011 at 05:30:11PM +0200, Lukas Czerner wrote: I've found some. So although data=journal users are minority, there are some. That being said I agree with you we should do something about it - either state that we want to fully support data=journal - and then we should really do better with testing it or deprecate it and remove it (which would save us some complications in the code). I would be slightly in favor of removing it (code simplicity, less options to configure for admin, less options to test for us, some users I've come across actually were not quite sure why they are using it - they just thought it looks safer). Hmm... FYI, I hope to be able to bring on line automated testing for ext4 later this summer (there's a testing person at Google is has signed up to work on setting this up as his 20% project). The test matrix that I have him included data=journal, so we will be getting better testing in the near future. At least historically, data=journalling was the *simpler* case, and was the first thing supported by ext4. (data=ordered required revoke handling which didn't land for six months or so). So I'm not really that convinced that removing really buys us that much code simplification. That being siad, it is true that data=journalled isn't necessarily faster. For heavy disk-bound workloads, it can be slower. So I can imagine adding some documentation that warns people not to use data=journal unless they really know what they are doing, but at least personally, I'm a bit reluctant to dispense with a bug report like this by saying, oh, that feature should be deprecated. Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
On Thu, Jun 23, 2011 at 01:32:48PM -0500, Moffett, Kyle D wrote: Ted, since this new iteration has no customer data, passwords, keys, or any other private data, I'm going to try to get approval to release an exact EC2 image of this system for you to test with, including the fake data volume that I triggered the problem on. That would be great! Approximately how big are the images involved? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628536: Heads up: update for e2fsprogs intended for stable-proposed-updates
On Sat, Jun 18, 2011 at 11:38:07AM +0200, Philipp Kern wrote: To the normal ftp-master queue with stable as its distribution target in the .changes (i.e. the changelog dist bit). But proposed-updates works equally well. OK, uploaded. Please let me know if there were any issues/problems. I need to run to the gate for my next flight, so I won't be able to respond until late tonight, though. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628536: Heads up: update for e2fsprogs intended for stable-proposed-updates
On Sat, Jun 18, 2011 at 12:36:01AM +0200, Philipp Kern wrote: We cannot use the unstable version verbatim for technical reasons. So I'd like to ask you to add a changelog entry with Upload to proposed-updates. and a version like 1.41.12-4+squeeze1. It needs to be built in a stable chroot and you'd need to specify the stable version with -v1.41.12-2 to debuild/ dpkg-buildpackage so that the right changelog entries are included in the .changes. I.e. please go ahead. What I uploaded into unstable *was* built with a stable chroot, but sure, I can re-upload it with the appropriate version number and changelog entry. I assume it should be dupload'ed to the proposed-updates queue, correct? The deadline for the next point release is this weekend, though. I apologize for the delay in responding; we're tying up the lose ends for the point release currently and this was one of them, which was lingering around because we generally don't like touching core stuff with extensive changes. Understood. OK, I'm flying back from Portland (Usenix ATC) to Boston tomorrow morning, so I'll prepare the packages while I'm in the air. I may not have a chance to upload them until late Saturday night or Sunday mid-day, although I will try to do it sooner if I can. (I just want to make some allowances for Murphy's law while I'm in transit...) I hope that will be enough time? Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612522: e2fsprogs: [l10n-fr] : various errors in the translation (typo, etc.)
tags 612522 +pending thanks On Wed, Feb 09, 2011 at 02:34:36PM -0500, Ted Ts'o wrote: I've forwarded your suggestions to the maintainer of the French language e2fsprogs.pot at the Translation Project. Thanks!! The maintainer of the French language translation file has updated fr.po per your suggestions. This will be reflected in a future release of e2fsprogs. Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
On Tue, Apr 05, 2011 at 10:30:11AM -0500, Moffett, Kyle D wrote: Couple of questions which might give me some clues: (a) was this a natively formatted ext4 file system, or a ext3 file system which was later converted to ext4? All the filesystems were formatted like this using Debian e2fstools as of 9 months ago: Rats. OK, so the indirect block journal credit bug fix won't help this bug. mke2fs -t ext4 -E lazy_itable_init=1 -L db:mail /dev/mapper/db-mail tune2fs -i 0 -c 1 -e remount-ro -o acl,user_xattr,journal_data /dev/mapper/db-mail Ooooh could the lazy_itable_init have anything to do with it? Shouldn't be, since 2.6.32 doesn't have the lazy inode init support. That support didn't show up until 2.6.37. I've switched the relevant filesystems back to data=journal mode, so if you want to send me a patch for 2.6.32 that I can apply to a Debian kernel I will keep that kernel around and if I see it happen again I'll check if the patch fixes it. Given that this was a freshly created file system with mke2fs -t ext4, I doubt the patch would help. Well, the base image is essentially a somewhat basic Debian squeeze for EC2 with our SSH public keys and a couple generic customizations applied. It does not have Postfix installed or configured, so there would be some work involved. Well, if you can share that image in AWS with the ssh keys stripped out it would save me a bunch of time. I assume it's not setup to automatically set ssh keys and pass them back to AWS like the generic images can? I also didn't see any problems with the system at all until the queue got backed up with ~100-120 stuck emails. After Postfix tried and failed to deliver a bunch of emails I would get the OOPS. Yeah, what I'd probably try to do is install postfix and then send a few hundred messages to foo...@example.com and see if I can repro the OOPS. Thanks for investigating! - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
On Mon, Apr 04, 2011 at 09:24:28AM -0500, Moffett, Kyle D wrote: Unfortunately it was not a trivial process to install Debian squeeze onto an EC2 instance; it took a couple ugly Perl scripts, a patched Debian-Installer, and several manual post-install-but-before-reboot steps (like fixing up GRUB 0.99). One of these days I may get time to update all that to the official wheezy release and submit bug reports. Sigh, I was whoping someone was maintaining semi-official EC2 images for Debian, much like alestic has been maintaining for Ubuntu. (Hmm, actually, he has EC2 images for Lenny and Etch, but unfortunately not for squeeze. Sigh) It's probably easier for me to halt email delivery and clone the working instance and try to reproduce from there. If I recall, the (easily undone) workaround was to remount from data=journal to data=ordered on a couple filesystems. It may take a day or two to get this done, though. Couple of questions which might give me some clues: (a) was this a natively formatted ext4 file system, or a ext3 file system which was later converted to ext4? (b) How big are the files/directories involved? In particular, how big is the Postfix mail queue directory, and it is an extent-based directory? (what does lsattr on the mail queue directory report) As far as file sizes, does it matter how big the e-mail messages are, and are there any other database files that postgress might be touching at the time that you get the OOPS? I have found a bug in ext4 where we were underestimating how many journal credits were needed when modifying direct/indirect-mapped files (which would be seen on ext4 if you had a ext3 file system that was converted to start using extents; but old, pre-existing directories wouldn't be converted), which is why I'm asking the question about whether this was an ext2/ext3 file system which was converted to use ext4. I have a patch to fix it, but backporting it into a kernel which will work with EC2 is not something I've done before. Can anyone point me at a web page that gives me the quick cheat sheet? If it comes down to it I also have a base image (from squeeze as of 9 months ago) that could be made public after updating with new SSH keys. If we can reproduce the problem on that base image it would be really great! I have an Amazon AWS account; contact me when you have an image you want to share, if you want to share it just with my AWS account id, instead of sharing it publically... - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable kernel BUG at fs/jbd2/commit.c:534 from Postfix on ext4
Hi Kyle, Sorry for not following up sooner. Are you still able to reproduce this failure? If I set up an identical Debian stable instance on EC-2, am I likely to reproduce it myself? Do you have a package list or EC2 base image I can use as a starting point? Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615592: e2fsprogs: autodetect stride and stripe-width (and perhaps even block size) on RAID devices
On Sun, Feb 27, 2011 at 04:52:46PM +0100, Christoph Anton Mitterer wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: wishlist AFAIU this is not yet done: It would be nice, if mke2fs could provide an auto-detect mode or something like this for setting sitrde and stripe-with. This should be possible by using device topology information and the information exported by DM/MD. At least for Linux Software RAID but maybe also for (supportding) hardware RAIDs. This is done as of mke2fs 1.41.10. Perhaps it can also make sense to set (upper) limits on the block size, or at least give warnings if the block size is bigger than the RAID chunck size. Given the block size is typically 4k (and can be no more than the page size of the architecture on which it runs), and the RAID chunk size is many times that (i.e., 32k, 64k, or more) , I don't think this is a problem or did you mean something other than block size? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614611: e2fsprogs: ext4_mb_generate_buddy erros on suspend/resume
On Tue, Feb 22, 2011 at 10:15:23PM +0530, Ritesh Raj Sarraf wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: normal I think I have started seeing this message very recently (maybe with the 2.6.37 kernel). [ 307.168035] EXT4-fs (dm-0): error count: 9 [ 307.168046] EXT4-fs (dm-0): initial error at 1296155431: ext4_mb_generate_buddy:726 [ 307.168054] EXT4-fs (dm-0): last error at 1296155431: ext4_reserve_inode_write:5589 There hasn't been a data corruption that I'm aware of. I did check for similar reports but most I found were reported to have resizing as the common element. In my case, there's no resize done. Yeah, it has nothing to do with resizing. The problem is that you need a newer e2fsprogs than what is shipping with Debian stable if you want to use the newer kernel. And I've held off on getting a newer version of e2fsprogs into testing because I need to backport some fixes into the very stale version of e2fsprogs 1.41.12 that has been frozen during the stablization period for Sqeeze. There is a version of e2fsprogs 1.41.14 in experimental which you can use. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613737: e2fsprogs: Programming error? block #33600 claimed for no reason in process_bad_block.
On Wed, Feb 16, 2011 at 11:17:58PM +0100, Johannes Rohr wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: normal I have run a full read-write surface scan on an ext4 partition on an external USB hard drive (e2fsck -ccfy /dev/sdb6), which lasted for about 20 hours. After that, e2fsck emits the following error message: First of all, can you map the blocks to specific inodes: debugfs /dev/sdb6 debugfs: icheck 33600 33637 then when you get the inode numbers, can you try using the debugfs stat command and show me the output. i.e., if the inode number is 12345, enter the command: debugfs: stat 12345 Also, if you retry the e2fsck with the -cc, can you reproduce the problem? Finally, if you retry the e2fsck command without the -cc can you reproduce this? (i.e., e2fsck -fy /dev/sdb6). If no, can you try it with the -cc again (e2fsck -ccfy /dev/sdb6). - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612522: e2fsprogs: [l10n-fr] : various errors in the translation (typo, etc.)
forwarded 612522 thanks I've forwarded your suggestions to the maintainer of the French language e2fsprogs.pot at the Translation Project. Thanks!! Thanks for taking the time in making these corrections available. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599079: /usr/sbin/filefrag: random perfection reported
On Mon, Oct 04, 2010 at 03:38:01PM +0200, Mike Hommey wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: normal File: /usr/sbin/filefrag Filefrag never reports the same perfection, on top of the value being entirely wrong: # filefrag /mnt/gnome.raw /mnt/gnome.raw: 3569 extents found, perfection would be -6071752 extent Hmm this works for me. What kernel version are you using, and what file system type (ext2/ext3/ext4) are you using? Can you also send me the output of dumpe2fs -h /dev/XXX for your file system? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605009: serious performance regression with ext4
On Mon, Nov 29, 2010 at 02:16:02PM +0100, Raphael Hertzog wrote: It means we don't need to keep it in RAM since we're not going to read/modifiy it again in the near future. Thus the writeback can be started right now since delaying it will not save us anything. At least that's the way I understand the situation. Yes, that's correct. The fadvise() will do two things; it will start the writeback, and also make these memory pages be the most likely to be discarded. This last might or might not be a good thing. If you are installing a large number of packages, discarding will avoid more useful things from being discard, and might help the interactive feel of the machine while the install is going on in the background. OTOH, if you are only installing one package, it might cause some file that will be needed by the postinstall script to be pushed out of the page cache prematurely. So the fadvise() does the same thing as SYNC_FILE_RANGE_WRITE, which is to say, start an asynchronous writeback of the pages in the file. It will not do a SYNC_FILE_RANGE_WAIT_BEFORE, which assures that the writebacks are complete before attempting to start doing the fdatasync(). Put another way: if this works now, is it likely to continue to work? Well, it will always work (the code is unlikely to introduce failures), but the resulting behaviour is entirely up to the kernel to decide. So there's no guaranty that the optimization will last. Exactly. I think the real question is whether you want to also give the hint that the pages for that particular file should be first in line to be discarded from the page cache. On the other hand, the whole point of posix_fadvise() is to give hints to the kernel so that he can decide on the best course of action. So I hope the interpretation above is one the main motivation behind that hint. The main motivation is to make the pages easily discardable; the fact that it happens to start writeback is really a side effect. So for backup programs, including rsync when it is being used for backups, using POSIX_FADV_DONTNEED is definitely a good idea. Whether or not it is a good idea for dpkg really depends on whether you think the files are going to be used soon after they are written --- either because the user has just installed the new toy and wants to play with it (i.e., apt-get install tuxracer; tuxracer) or because of a post-install script. On the other hand, if the user was just updating a random set of progams that aren't actually going to be used right away (i.e., apt-get update; apt-get upgrade), in that case the POSIX_FADV_DONTNEED would probably be a good thing. The reason why I suggested using sync_file_range() is because it is very specifically directed at forcing the writeback to happen, which is not quite the same thrust as posix_fadvise(). Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605009: serious performance regression with ext4
On Mon, Nov 29, 2010 at 02:58:16PM +, Ian Jackson wrote: This is the standard way that ordinary files for which reliability was important have been updated on Unix for decades. fsync is for files which need synchronisation with things external to the computer (or at least, external to the volume) - eg, email at final dot. This is simply not true. And I'm speaking as someone who has been doing Unix/Linux kernel development since the BSD 4.3 days. (Well, BSD 4.3+Tahoe days, to be precise.) fsync() has always been the only guarantee that files would be on disk. In fact the way BSD worked, there was no guarantee that rename() would provide any kind of file synchronization primitive; that's actually something new. No, in the old days, if you really cared about a file, you would fsync() it. Period. End of paragraph. It was just that in those days, the main things people cared about where either source/text files (so the editors of the day would do the right thing) or e-mail (and no, just for the final delivery; for all MTA's). The problem that caused people to get this wrong idea was because (a) back then Unix machines tended to be more reliable, because they were run by professionals in machine rooms, very often with UPS's. Also, (b) people weren't loading craptastic video drivers with buggy proprietary kernel modules; they may have used proprietary drivers, but kernels weren't changing all the time, and there was a lot more careful testing of drivers before they were unloosed onto the world. Finally (c), ext3 had as an accident of how it provided protection against old file blocks showing up newly allocated files (something which BSD 4.3 did __not__ protect against, by the way), had the behaviour that renaming over a file __usually__ (but not always) provided atomic guarantees. (c) was especially unfortunate, because it never applied to all Linux file systems, just to ext3, and because the fact that it did this was also responsible for disastrous desktop performance when you had the combination of large number of streaming writes (i.e., bittorrent, video ripping/copying, etc.) going on in the background combined with foreground GUI applications that were fsync-happy() --- i.e., firefox. Lots of users have complained about the desktop performance problem, but the reality is we can't really solve that without also taking away the magic that made (c) happen. Whether you solve it by using data=writeback and stick with ext3, or switch to ext4, or switch to XFS, or switch to btrfs --- all of these will solve the desktop performance problem, but they also leave you vulnerable to file loss in the case of system crashes and applications that don't use fsync()/fdatasync(). Hence the fact that all file system developers, whether they were btrfs developers or XFS developers or ext4 developers, made the joke at the file system developers summit two years ago, that what the application programmers really wanted was O_PONY, with the magic pixie dust. Unfortunately: http://www.linuxformat.com/files/nopony.jpg - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605009: serious performance regression with ext4
On Mon, Nov 29, 2010 at 09:21:44AM -0600, Jonathan Nieder wrote: That explanation helps a lot. Thanks, both. (Guillem, I like your patch very much then. Most files being unpacked in a dpkg run aren't going to be read back again soon. Perhaps some other kernels will also interpret it as a hint to start writeback.) Most files won't, but consider a postinstall script which needs to scan/index a documentation file, or simply run one or more binaries that was just installed. I can definitely imagine situations where using POSIX_FADV_DONTNEED could actually hurt performance. Is it enough to worry about? Hard to say; for a very long dpkg run, the files might end up getting pushed out of memory anyway. But if you are only installing one package, and you are doing this on a particularly slow disk, using POSIX_FADV_DONTNEED could actually hurt in a measurable way. If you are only installing a one or a few packages, and/or you can somehow divine the user's intention that they will very shortly use the file --- for example, if dpkg is being launched via packagekit to install some font or codec, then using POSIX_FADV_DONTNEED is probably the wrong answer. So at the very least I'd recommend having command line options to enable/disable use of posix_fadvise(). Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605009: serious performance regression with ext4
I did some experimenting, and I figured out what was going on. You're
right, (c) doesn't quite work, because delayed allocation meant that
the writeout didn't take place until the fsync() for each file
happened. I didn't see this at first; my apologies.
However, this *does* work:
extract(a);
sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE);
extract(b.dpkg-new);
sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WRITE);
extract(c.dpkg-new);
sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WRITE);
sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
fdatasync(a);
fdatasync(b.dpkg-new);
fdatasync(c.dpkg-new);
rename(b.dpkg-new, b);
rename(c.dpkg-new, c);
This assumes that files b and c existed beforehand, but a is a new file.
What's going on here? sync_file_range() is a Linux specific system
call that has been around for a while. It allows program to control
when writeback happens in a very low-level fashion. The first set of
sync_file_range() system calls causes the system to start writing back
each file once it has finished being extracted. It doesn't actually
wait for the write to finish; it just starts the writeback.
The second series of sync_file_range() calls, with the operation
SYNC_FILE_RANGE_WAIT_BEFORE, will block until the previously initiated
writeback has completed. This basically ensures that the delayed
allocation has been resolved; that is, the data blocks have been
allocated and written, and the inode updated (in memory), but not
necessarily pushed out to disk.
The fdatasync() call will actually force the inode to disk. In the
case of the ext4 file system, the first fdatasync() will actually push
all of the inodes to disk, and all of the subsequent fdatasync() calls
are in fact no-ops (assuming that files 'a', 'b', and 'c' are all on
the same file system). But what it means is that it minimizes the
number of (heavyweight) jbd2 commits to a minimum.
It uses a linux-specific system call --- sync_file_range --- but the
result should be faster performance across the board for all file
systems. So I don't consider this an ext4-specific hack, although it
probably does makes things faster for ext4 more than any other file
system.
I've attached the program I used to test and prove this mechanism, as
well as the kernel tracepoint script I used to debug why (c) wasn't
working, which might be of interest to folks on debian-kernel.
Basically it's a demonstration of how cool ftrace is. :-)
But using this program on a file system composed of a 5400rpm laptop
drive running LVM and LUKS, I get:
mass-sync-tester -d:dpkg current: time: 0.83/ 0.01/ 0.00
versus
mass-sync-tester -n:dpkg fixed: time: 0.07/ 0.00/ 0.01
- Ted
/*
* Mass sync tester
*/
#define _GNU_SOURCE
#include stdio.h
#include unistd.h
#include stdlib.h
#include sys/types.h
#include sys/time.h
#include sys/stat.h
#include fcntl.h
#include sys/resource.h
#include getopt.h
#include errno.h
#include string.h
void write_file(const char *name, int sync, int sync_range)
{
int fd, i, ret;
char buf[1024];
fd = open(name, O_WRONLY|O_TRUNC|O_CREAT, 0666);
if (fd 0) {
fprintf(stderr, open(%s) in write_file: %s\n,
name, strerror(errno));
exit(1);
}
memset(buf, 0, sizeof(buf));
for (i=0; i 16; i++) {
ret = write(fd, buf, sizeof(buf));
if (ret 0) {
fprintf(stderr, writing %s: %s\n,
name, strerror(errno));
exit(1);
}
}
if (sync) {
ret = fsync(fd);
if (ret 0) {
fprintf(stderr, fsyncing %s in write_file: %s\n,
name, strerror(errno));
exit(1);
}
}
if (sync_range) {
ret = sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WRITE);
if (ret 0) {
fprintf(stderr, sync_file_range %s in write_file: %s\n,
name, strerror(errno));
exit(1);
}
}
ret = close(fd);
if (ret 0) {
fprintf(stderr, closing %s in write_file: %s\n,
name, strerror(errno));
exit(1);
}
}
void rename_file(const char *src, const char *dest)
{
int ret;
ret = rename(src, dest);
if (ret) {
fprintf(stderr, renaming %s to %s: %s\n, src, dest,
strerror(errno));
exit(1);
}
}
void sync_file(const char *name)
{
int fd, i, ret;
fd = open(name, O_RDONLY|O_NOATIME, 0666);
if (fd 0) {
fprintf(stderr, open(%s) in sync_file: %s\n,
name, strerror(errno));
exit(1);
}
ret = fsync(fd);
if (ret 0) {
fprintf(stderr, fsyncing %s in sync_file: %s\n,
name, strerror(errno));
exit(1);
}
ret = close(fd);
if (ret 0) {
fprintf(stderr, closing %s in sync_file: %s\n,
name, strerror(errno));
exit(1);
}
}
void datasync_file(const char *name)
{
int fd, i, ret;
fd = open(name, O_RDONLY|O_NOATIME, 0666);
if (fd 0) {
fprintf(stderr, open(%s) in datasync_file: %s\n,
name, strerror(errno));
exit(1);
}
ret = fdatasync(fd);
if (ret 0) {
fprintf(stderr,
Bug#605009: serious performance regression with ext4
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote: Just to sum up what dpkg --unpack does in 1.15.8.6: 1/ set the package status as half-installed/reinst-required 2/ extract all the new files as *.dpkg-new 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by rename(foo.dpkg-new, foo) What are you doing? 1) Suppose package contains files a, b, and c. Which are you doing? a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a); extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b); extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new, c); or b) extract a.dpkg-new ; fsync(a.dpkg-new); extract b.dpkg-new ; fsync(b.dpkg-new); extract c.dpkg-new ; fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); or c) extract(a.dpkg-new); extract(b.dpkg-new); extract(c.dpkg-new); fsync(a.dpkg-new); fsync(b.dpkg-new); fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); (c) will perform the best for most file systems, including ext4. As a further optimization, if b and c does not exist, of course it would be better to extract into b and c directly, and skip the rename, i.e.: d) extract(a.dpkg-new); extract(b); # assuming the file b does not yet exist extract(c); # assuming the file c does not yet exist fsync(a.dpkg-new); fsync(b); fsync(c); rename(a.dpkg-new, a); ... and then set the package status as unpacked. I am guessing you are doing (a) today --- am I right? (c) or (d) would be best. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583942: e2fsprogs: option -p not properly documented
On Fri, Jul 30, 2010 at 10:06:55PM -0400, Ted Ts'o wrote: On Mon, May 31, 2010 at 08:39:38PM +0200, Toni Mueller wrote: the -p option is not properly documented. Imho, every option deserves a top-level entry in a man page, and all other options seem to have it. I didn't check too thorougly, though. The -p option to *which* command in e2fsprogs? You haven't responded to my question of which command is lacking proper documentation for the -p option. If you do not respond shortly, I will close this bug report as not containing sufficient information. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591083: e2fsck.conf(5) should clarify whether ext4 fs are also controlled by it
On Sat, Jul 31, 2010 at 08:05:24PM +0200, Jan Schulz wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: minor File: /usr/share/man/man5/e2fsck.conf.5.gz This will be fixed in the 1.41.13 version of e2fsck. Thanks for pointing it out. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555456: Update to e2fsck bonehead problem: reproducible case found
On Wed, Nov 17, 2010 at 12:19:14AM -0800, J.P. Larocque wrote:
Hi Ted and Micah,
I ran into the problem in e2fsck that prints:
WARNING: PROGRAMMING BUG IN E2FSCK!
OR SOME BONEHEAD (YOU) IS CHECKING A MOUNTED (LIVE) FILESYSTEM.
inode_link_info[X] is Y, inode.i_links_count is Z. They should be the same!
I've sent a full transcript, e2image file with which the problem can
be reproduced, and background information to 555...@bugs.debian.org,
which you can access at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555456. (I'm
sending this message separately to spare you both from the 2.1MiB
attachment.)
Hope it helps. Thanks!
Thanks for sending me the test case. I've been able to find a fix for
this which will be going into e2fsprogs 1.41.13.
- Ted
commit 992016c5afde0f77a9ff10c4fc5be02f83eb055c
Author: Theodore Ts'o ty...@mit.edu
Date: Fri Nov 26 19:09:43 2010 -0500
e2fsck: Fix inode nlink accounting that could cause PROGRAMMING BUG errors
This fixes two possible causes for the error message:
WARNING: PROGRAMMING BUG IN E2FSCK!
OR SOME BONEHEAD (YOU) IS CHECKING A MOUNTED (LIVE) FILESYSTEM.
inode_link_info[X] is Y, inode.i_links_count is Z. They should be the same!
One cause which can trigger this message is when an inode has an
illegal link count 65500 --- for example, 65535. This was the case
in the Debian Bug report #555456.
Another cause which could trigger this message is if an ext4 directory
previously had more than 65000 subdirectories (thus causing
i_link_count to be set to 1), but then some of the subdirectories were
deleted, such that i_link_count should now be the actual number of
subdirectories.
Addresses-Debian-Bug: #555456
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/e2fsck/pass4.c b/e2fsck/pass4.c
index d9706ce..515cb84 100644
--- a/e2fsck/pass4.c
+++ b/e2fsck/pass4.c
@@ -121,6 +121,8 @@ void e2fsck_pass4(e2fsck_t ctx)
/* Protect loop from wrap-around if s_inodes_count maxed */
for (i=1; i = fs-super-s_inodes_count i 0; i++) {
+ int isdir = ext2fs_test_inode_bitmap(ctx-inode_dir_map, i);
+
if (ctx-flags E2F_FLAG_SIGNAL_MASK)
goto errout;
if ((i % fs-super-s_inodes_per_group) == 0) {
@@ -153,14 +155,14 @@ void e2fsck_pass4(e2fsck_t ctx)
ext2fs_icount_fetch(ctx-inode_count, i,
link_counted);
}
- if (ext2fs_test_inode_bitmap(ctx-inode_dir_map, i)
- (link_counted EXT2_LINK_MAX))
+ if (isdir (link_counted EXT2_LINK_MAX))
link_counted = 1;
if (link_counted != link_count) {
e2fsck_read_inode(ctx, i, inode, pass4);
pctx.ino = i;
pctx.inode = inode;
- if (link_count != inode-i_links_count) {
+ if ((link_count != inode-i_links_count) !isdir
+ (inode-i_links_count = EXT2_LINK_MAX)) {
pctx.num = link_count;
fix_problem(ctx,
PR_4_INCONSISTENT_COUNT, pctx);
@@ -168,10 +170,10 @@ void e2fsck_pass4(e2fsck_t ctx)
pctx.num = link_counted;
/* i_link_count was previously exceeded, but no longer
* is, fix this but don't consider it an error */
- if ((LINUX_S_ISDIR(inode-i_mode) link_counted 1
+ if ((isdir link_counted 1
(inode-i_flags EXT2_INDEX_FL)
link_count == 1 !(ctx-options E2F_OPT_NO)) ||
-(fix_problem(ctx, PR_4_BAD_REF_COUNT, pctx))) {
+ fix_problem(ctx, PR_4_BAD_REF_COUNT, pctx)) {
inode-i_links_count = link_counted;
e2fsck_write_inode(ctx, i, inode, pass4);
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604629: Patch to allow cross build with xdeb
On Tue, Nov 23, 2010 at 08:33:36AM +, Peter Pearse wrote: The patch below enables the package to cross build using xdeb --- +-DEPSTATIC_LIBBLKID = @DEPSTATIC_LIBBLKID@ $(STATIC_LIBUUID) ++# Why add the non static string here? ++# - causes the cross build to fail ++# DEPSTATIC_LIBBLKID = @DEPSTATIC_LIBBLKID@ $(STATIC_LIBUUID) ++DEPSTATIC_LIBBLKID = @DEPSTATIC_LIBBLKID@ That's not the right fix. The right fix is to change MCONFIG.in so the line reads: DEPSTATIC_LIBBLKID = @DEPSTATIC_LIBBLKID@ $(DEPSTATIC_LIBUUID) Thanks for pointing out the problem. I'll fix this appropriately for e2fsprogs 1.41.13. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598260: e2fsprogs: resize inode not valid
On Tue, Sep 28, 2010 at 03:24:51PM +0300, Dmitry Baryshev wrote: Hi. $ fsck /dev/sdb5 fsck from util-linux-ng 2.17.2 e2fsck 1.41.12 (17-May-2010) fsck.ext3: Group descriptors look bad... trying backup blocks... /dev/sdb5: clean, 11/1310720 files, 123484/5242338 blocks $ fsck -f /dev/sdb5 shows tons of questions, I'm attaching a photo OK, that's really wierd. Would you be willing to send me compressed raw e2image of your filesystem so I can figure out what's going on? See the man page for e2image(8), and the section RAW IMAGE FILES. For what's likely to be going on, the directory names won't matter, so if you are concerned about the file names in your directories (not I care or would go prying to see them anyway), feel free to use the -s option to scramble the file names if that would make you more comfortable. Since the file will be fairly big, if you can send me private e-mail with the URL to download them, that would be great. If you don't have access to facilities to allow you to do that, let me know and I can set up some kind of anonymous FTP upload facility. Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598260: e2fsprogs: resize inode not valid
On Tue, Sep 28, 2010 at 12:02:01AM +0300, Krasu wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: important I'm getting Resize inode not valid all the time during boot. It fails to check the root filesystem, which is ext3, and shows a prompt to ebter root password or continue. /dev/sdb5 on / type ext3 (rw,errors=remount-ro) If I login into shell and run fsck manually (without any option), it doesn't ask any questions, just fixes something automatically (something like group descriptors look bad, trying to backup blocks). Then I press Ctrl+D, shell exits, and machine reboots. After that I don't see error messages, machine boots successfully. After second reboot I see error message again, and I should redo all steps again to fix it. Can you please try to capture the output of running fsck manually, so I can see what it has printed. You can use the script command, or just redirect standard output to a file and run e2fsck with the -y option, etc. Just so I can see everything fsck is printing. What happens if you run e2fsck -f /dev/XXX a second time. Do you see any errors with the second run of e2fsck? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593620: e2fsprogs: e2fsck returns exit code 32 though allow_cancellation = true
On Sun, Sep 26, 2010 at 03:02:18PM +0400, SIO wrote: Yes, looks like you are right. I've done that test, and e2fsck returned 0. Will look into init scripts then Do you have a preference as to whether I reassign bug #59632 to initscripts, or we should close it and you can reopen another bug with initscripts or whatever happens to be the proper package once you've done more investigation? Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594004: resize2fs(8) does not clearly specify size units
tags 594004 +pending thanks On Mon, Aug 23, 2010 at 01:09:46AM +0100, Ben Hutchings wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: important resize2fs(8) says: Optionally, the size parameter may be suffixed by one of the following the units designators: 's', 'K', 'M', or 'G', for 512 byte sectors, kilobytes, megabytes, or gigabytes, respectively. In contrast to hard disk specifications, the suffixes are interpreted as base-2 multiples, not base-10 multiples. This could lead to data loss when shrinking a filesystem and then separately shrinking the partition, if the partitioning tool is not filesystem-aware. The manual page should state explicitly that the suffixes are interpreted as base-2 multiples. Priority *important*?!? OK, I'll check in the following patch. - Ted commit 63feaa13ab1011b40d59011e6ffdc1a07d3423ac Author: Theodore Ts'o ty...@mit.edu Date: Sat Sep 25 20:23:33 2010 -0400 resize2fs.8: Make it clear that power-of-2 units are meant by kilobytes It's sad that this needs to be made clear Addresses-Debian-Bug: #594004 Signed-off-by: Theodore Ts'o ty...@mit.edu diff --git a/resize/resize2fs.8.in b/resize/resize2fs.8.in index 09770e1..214d43c 100644 --- a/resize/resize2fs.8.in +++ b/resize/resize2fs.8.in @@ -51,6 +51,14 @@ If .I size parameter is not specified, it will default to the size of the partition. .PP +Note: when kilobytes is used above, I mean +.IR real , +power-of-2 kilobytes, (i.e., 1024 bytes), which some politically correct +folks insist should be the stupid-sounding ``kibibytes''. The same +holds true for megabytes, also sometimes known as ``mebibytes'', or +gigabytes, as the amazingly silly ``gibibytes''. Makes you want to +gibber, doesn't it? +.PP The .B resize2fs program does not manipulate the size of partitions. If you wish to enlarge -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594004: resize2fs(8) does not clearly specify size units
On Sun, Sep 26, 2010 at 01:45:02AM +0100, Ben Hutchings wrote: Priority *important*?!? [...] Because of the potential for data loss in case of confusion. Umm, how? If the size specified is bigger than the device size, resize2fs will stop and warn the user. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587531: e2fsprogs: e2fsck/tune2fs work badly with lvm snapshot of fs with external journal
tag 587531 +pending thanks I've checked the following patch into the e2fsprogs source tree, which will be in 1.41.13. - Ted commit 8718359b4057bf2b998f4ac6125e33f20efe60cb Author: Theodore Ts'o ty...@mit.edu Date: Sat Sep 25 21:14:06 2010 -0400 e2fsck: Open the external journal in exclusive mode This prevents accidentally replaying and resetting the journal while it is mounted, due to an accidental attempt to run e2fsck on an LVM snapshot of a file system with an external journal. Addresses-Debian-Bug: #587531 Signed-off-by: Theodore Ts'o ty...@mit.edu diff --git a/e2fsck/journal.c b/e2fsck/journal.c index 64a0fd6..b741eb9 100644 --- a/e2fsck/journal.c +++ b/e2fsck/journal.c @@ -368,7 +368,8 @@ static errcode_t e2fsck_get_journal(e2fsck_t ctx, journal_t **ret_journal) #ifndef USE_INODE_IO if (ext_journal) #endif - retval = io_ptr-open(journal_name, IO_FLAG_RW, + retval = io_ptr-open(journal_name, + IO_FLAG_RW | IO_FLAG_EXCLUSIVE, ctx-journal_io); if (retval) goto errout; -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593620: e2fsprogs: e2fsck returns exit code 32 though allow_cancellation = true
On Thu, Aug 19, 2010 at 09:11:39PM +0400, SIO wrote:
Here is my /etc/e2fsck.conf:
[options]
allow_cancellation = true
Though cancellation is allowed, when I hit ^c during check of my root
partition
at system boot, it is remounted as read-only. File system is not flagged as
containing errors, check is triggered by mounts count.
Steps to reproduce:
1. Add mentioned option to /etc/e2fsck.conf
2. Set mount count greater than max-mount-count for your fs: tune2fs -C 100
/dev/sda1
3. Reboot
4. Hit ^c during filesystem check
Can you try testing this by running e2fsck /dev/sda1 by hand, typing
^C, and then checking the exit value? i.e:
tytso.r...@tytso-glaptop {/home/tytso}
2087# /tmp/sbin/e2fsck.static /dev/funarg/kbuild
e2fsck 1.41.12 (17-May-2010)
/dev/funarg/kbuild has been mounted 35 times without being checked, check
forced.
Pass 1: Checking inodes, blocks, and sizes
^C/dev/funarg/kbuild: e2fsck canceled.
tytso.r...@tytso-glaptop {/home/tytso}
2088# echo $?
0
I've tried replicating this with the e2fsck.static from the package
e2fsck-static_1.41.12-2_amd64.deb, and with the allow_cancellation
option set, I'm not able to replicate the problem. That is, when I
interrupt e2fsck, the exit code is properly zero.
I'm wondering if the problem is because of the fact that you are
interrupting the init script, which is then somehow exiting with a
non-zero status. If that's true, then it's not something that's under
the control of e2fsprogs. Hence my request for you to test this
without having the boot scripts involved. If it works w/o the boot
scripts, then the problem will be in the init scripts.
Best regards,
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580236: /sbin/tune2fs: manpage does not mention LABEL=volume_name as device name
tag +580236 pending thanks On Tue, May 04, 2010 at 06:47:06PM +0200, Michael Schmitt wrote: as specifying the device with its label does work too. A short sentence about that could be added too. This will be fixed in the next release of e2fsprogs. Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594004: resize2fs(8) does not clearly specify size units
On Sun, Sep 26, 2010 at 02:35:14AM +0100, Ben Hutchings wrote: But if you're shrinking, you have to resize the filesystem and then the partition. And the partitioning tool is not so likely to know the size of the filesystem. And what partitioning tool uses marketing gigabytes as opposed to real gigabytes? This is all stupid anyway, since people who do this are more than likely to screw up and get it wrong by typo'ing a number. Tools like gparted are integrated with the filesystem resizers, and this is never an issue. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583942: e2fsprogs: option -p not properly documented
On Mon, May 31, 2010 at 08:39:38PM +0200, Toni Mueller wrote: the -p option is not properly documented. Imho, every option deserves a top-level entry in a man page, and all other options seem to have it. I didn't check too thorougly, though. The -p option to *which* command in e2fsprogs? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589345: e2fsprogs: Linux 2.6 kernel supports online resizing of ext4
tags 589345 +pending thanks On Fri, Jul 16, 2010 at 08:54:49PM +0100, Francis Russell wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: minor The resize2fs manpage says As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 only. I resized a mounted ext4 partion the other day on a 2.6.34.1 kernel and I'm sure I've done it before May 2010 which seems to be date-stamp on the man-page. This should probably be updated. Thanks for pointing this out. Ext4 has always supported on-line resize, but when the man page was updated to add and ext4 in the first sentence, I failed to update the later sentence regarding online resizing. I've checked in the simple and obvious fix. It will be in the next release of e2fsprogs. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588726: e2fsprogs: Outdated description: /sbin/fsck has moved to util-linux
tags 588726 +pending thanks On Sun, Jul 11, 2010 at 05:36:47PM +0200, Nicolas Boulenguez wrote: Package: e2fsprogs Version: 1.41.12-2 Severity: minor Tags: patch Here is a trivial patch for this cosmetic change. Thanks for pointing this out. It will be fixed in the next release of e2fsprogs. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
