Bug#661071: e2fsprogs is compiled without optimizations and without debug info
On Feb 23, 2012, at 6:48 PM, Sami Liedes wrote: Package: e2fsprogs Version: 1.42.1-1 Severity: normal When investigating why e2resizing a 100G filesystem to 75G takes several hours of *CPU* time on a Core i7 computer (in the Scanning inode table phase -- you might get a bug report about that later if turning optimizations on doesn't help very much), I ran into the following: The e2fsprogs-dbg package doesn't actually seem to include any debug information, *except* for e2fsck.static, which I'm at loss to explain, since I don't see any -g switches passed to gcc in my build logs for any gcc invokation when building e2fsprogs. Moreover, almost everything in the package is compiled without optimizations. Yes, the bug was caused by the use of which isn't supported by dash. I'll upload a fix for that shortly. My apologies for not notching this before the 1.41.1-1 release. In the meantime you can workaround this by forcing the use of bash as your build shell instead of the default of dash. -- Ted (By the way, the e2fsck.static debug info file is in wrong place, /usr/lib/debug/e2fsck.static instead of /usr/lib/debug/sbin/e2fsck.static, which causes it to not be found by various tools...) After figuring out how to un-hide the relevant information cleverly hidden from build logs by modifying debian/rules to pass --enable-verbose-makecmds to configure, a few things jump out from the build logs. You can get the entire build log from [1]; here's just some excerpts with line numbers. To summarize: * I think nothing is being built with -g * I think that only the BF version, whatever that is (bootfloppies?), is being built with -Os; all others are being built without any optimization flags at all * The debug info file for e2fsck.static is installed in a wrong directory [1] http://users.tkk.fi/sliedes/e2fsprogs_1.42.1-1_amd64.build Sami 20 dpkg-source: info: building e2fsprogs in e2fsprogs_1.42.1-1.dsc 21 debian/rules build 22 /bin/sh: 1: Syntax error: Bad fd number 23 /bin/sh: 1: Syntax error: Bad fd number 24 /bin/sh: 1: Syntax error: Bad fd number That's scary... 29 cd /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/debian/BUILD-STD AWK=/usr/bin/awk \ 30 /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/configure --disable-e2initrd-helper --enable-elf-shlibs --enable-quota --infodir=/usr/share/info --enable-verbose-makecmds --disable-fsck --disable-libblkid --disable-libuuid --disable-uuidd --enable-symlink-install --with-multiarch=x86_64-linux-gnu \ 31 CFLAGS= -D__NO_STRING_INLINES CPPFLAGS= LDFLAGS= Note the curious CFLAGS passed. No -O, no -g. 1104 /bin/sh: 1: Syntax error: Bad fd number 1105 /bin/sh: 1: Syntax error: Bad fd number 1106 /bin/sh: 1: Syntax error: Bad fd number [...] 1110 cd /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/debian/BUILD-BF AWK=/usr/bin/awk \ /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/configure --disable-e2initrd-helper --enable-elf-shlibs --enable-quota --infodir=/usr/share/info --enable-verbose-makecmds --disable-fsck --disable-libblkid --disable-libuuid --disable-uuidd --disable-nls --disable-imager --disable-testio-debug --disable-uuidd --disable-tls --disable-debugfs \ 1112 CFLAGS= -D__NO_STRING_INLINES -Os -fomit-frame-pointer CPPFLAGS= LDFLAGS= Scary syntax errors again. This time CFLAGS contains -Os, but no -g. 1983 /bin/sh: 1: Syntax error: Bad fd number 1984 /bin/sh: 1: Syntax error: Bad fd number [...] 1988 if type diet /dev/null 21 ; then \ 1989 cd /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/debian/BUILD-STATIC AWK=/usr/bin/awk \ 1990 /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/configure --disable-nls --disable-imager --disable-uuidd --disable-tls --enable-verbose-makecmds \ 1991 --with-diet-libc CFLAGS= -D__NO_STRING_INLINES; \ 1992 else \ 1993 cd /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/debian/BUILD-STATIC AWK=/usr/bin/awk \ 1994 /home/sliedes/scratch/rec/e/e2fsprogs-1.42.1/configure --disable-nls --disable-imager --disable-uuidd --disable-tls --enable-verbose-makecmds \ 1995 CFLAGS= -D__NO_STRING_INLINES; \ 1996 fi -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable')
Bug#661071: [patch] Re: e2fsprogs is compiled without optimizations and without debug info
On Feb 23, 2012, at 7:40 PM, Sami Liedes wrote: tags 661071 patch thanks On Fri, Feb 24, 2012 at 01:48:54AM +0200, Sami Liedes wrote: 20 dpkg-source: info: building e2fsprogs in e2fsprogs_1.42.1-1.dsc 21 debian/rules build 22 /bin/sh: 1: Syntax error: Bad fd number 23 /bin/sh: 1: Syntax error: Bad fd number 24 /bin/sh: 1: Syntax error: Bad fd number And here's a patch to fix this; it's caused by a bashism in debian/rules and is the root cause for this entire bug. I actually have a fix checked into the e2fsprogs git tree; I just somehow never got around to uploading it. (I thought I had uploaded it, but I didn't. Sigh. It's been a crazy week.) See: http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=summary I'll fix the e2fsck.static bug in the e2fsprogs-dbg package being in the wrong place, and a few other bug fixes that have come in the last few days, and get a 1.41.1-3 uploaded tomorrow. Perhaps you could also be persuaded to consider a patch that makes the build log more verbose? I've already checked in a change to do this. See commit f921eda1. -- 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
priority 647039 normal thanks On Oct 29, 2011, at 12:54 PM, Laurent Grawet wrote: Package: e2fsprogs Version: 1.42~WIP-2011-10-16-1 Severity: important Hi, e4defrag does not work with LVM device nodes. See RHEL Bug 707209. https://bugzilla.redhat.com/show_bug.cgi?id=707209 Note: e4defrag is not fully supported; indeed I was very tempted to completely remove it from the package because I don't consider it completely ready for prime time. -- 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 Oct 2, 2011, at 8:51 PM, Daniel Kahn Gillmor wrote:
Oct 2 16:43:39 tut kernel: [ 168.613177] EXT3-fs (dm-2): warning:
verify_group_input: Last group not full
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 /us
Oct 2 16:43:53 tut kernel: [ 182.925315] EXT3-fs (dm-2): warning:
verify_group_input: Last group not full
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?
Can you send me the output of:
a) file /usr/sbin/resize2fs
b) uname -a
c) strace resize2fs /dev/XXX
-- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575343: Interaction with #326647/#526398
On Apr 3, 2011, at 12:23 AM, Elliott Mitchell wrote: #326647 needs an argument for `fsck` that is passed to the back-ends that inhibits precautionary checks. A script is better suited for checking whether the system is on battery (it could be on a UPS battery instead of an internal battery)... That's not how it's implemented today; today it is implemented directly in e2fsck. Anyone insane enough to boot a system while on UPS power gets what they deserve. UPS'es are designed for tiding a machine over a brief power outage, not for booting a machine while you're on UPS. I fixed bug #326647 and closed it many years ago for the requested use case, which was laptops. The difference between this and what you wanted in Bug #575343 is that what you want requires coordination between fsck and e2fsck. That's a huge amount of complexity, which IMHO isn't warranted and isn't Two options, perhaps --retrieve-forced-check-status and --disable-preemptive-checks, then some logic to use those is that much complexity? E2fsck does not currently assume the existence of getopt_long(). Some people do like to be able to compile e2fsck with dietlibc. In addition, all of the other backend fsck programs won't know about these new options which you are proposing (many of them don't use getopt_long either). So yes, it's complexity. As mentioned before on this very same bug report, I'd hardly call the problem largely solved. Perhaps partially solved for one common usage case, but hardly largely. Any system that doesn't reboot that often (say, a server on reasonably reliable hardware without huge amounts of activity) will tend to always trigger the date-based checks. Since doing any check resets the last checked time, those will coalesce and you'll end up checking everything at once all the time. Date based checks are disabled by default, and aren't used in the common case. -- 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 Feb 17, 2011, at 3:02 AM, Johannes Rohr wrote: On Mi, Feb 16, 2011 at 05:47:45 -0500, Ted Ts'o wrote: debugfs /dev/sdb6 debugfs: icheck 33600 33637 [...] debugfs: stat 12345 1.41.12 (17-May-2010) debugfs: icheck 33600 33637 Block Inode number 33600 7 33637 7 debugfs: stat 7 7: File not found by ext2_lookup that should be: debugfs: stat 7 (The angle brackets are important. Otherwise it's looking for the file with the name '7' in the debugfs's idea of the current working directory. You can use commands like 'cd' and 'ls' in debugfs) -- Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582275: ext3 filesystem corruption on md RAID1 device
On Jun 18, 2010, at 3:12 AM, Buehl, Reiner wrote: Hi Jan, I tried for a while with alternate hardware and the original controller but the error did never happen again. I think your idea of a bug in e2fsck's handling of multiply claimed blocks is the only explanation: Maybe during a corruption long ago a number of multiply claimed blocks existed and where reduced with each reboot. Is this possible? How can this be fixed? It could be an e2fsck bug, or it could be a hardware issue. In my experience, every time I've tried digging into problems with e2fsck -fy not fixing all problems in a single pass, it's been a hardware problem. That being said, multiply claimed blocks is something that isn't exercised that much, so it's *possible* that it is an e2fsck bug. I really would need a reproducible test case before I could do anything 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#582275: ext3 filesystem corruption on md RAID1 device
On Jun 18, 2010, at 7:09 AM, Theodore Tso wrote: It could be an e2fsck bug, or it could be a hardware issue. In my experience, every time I've tried digging into problems with e2fsck -fy not fixing all problems in a single pass, it's been a hardware problem. That being said, multiply claimed blocks is something that isn't exercised that much, so it's *possible* that it is an e2fsck bug. I really would need a reproducible test case before I could do anything though. And reviewing the thread, the fact that you are reliably getting directory corruption every single time you're booting, and the reliability of the hardware has been called into question (forgive me for being a little suspicious of people trying to do reliable storage using IDE devices). -- Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583910: e2fsprogs: bogus dependency on libblkid1 due to shlibs.local
On Jun 3, 2010, at 8:53 PM, beat.n...@stagecoach-wireless.com wrote: there appears to be a package version mis-match. squeeze/ testing: e2fs(libs, progs) are version 2.17.xx and mount and util-linux are version 2.16.2-0. If you grab the e2fs(libs, progs) packages version 2.16.2-0 from stable/ lenny then it may work. Fix is already uploaded to unstable -- Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549861: ....
On Sun, Nov 15, 2009 at 10:34:33PM +0100, Eugeniy Meshcheryakov wrote:
Hello,
Thanks for reply. This option will probably fix problem with systems
with clock set to local timezone, but not for systems like FreeRunner
where clock content is lost when battery is removed. It will be good to
have option that disables mount time in the future check entirely.
Note that the file system isn't the only place that might assume that
time is correct. For example, the UUID generation algorithm derives
its uniqueness guarantees from the fact that time is correctly set.
If you don't have an accurate clock, you may have all sorts of strange
behavior as a result.
As far as the FreeRunner is concerned, it currently takes me under 8
seconds to check a 70gig SSD drive. If you put 8GB SD card into the
FreeRunner smartphone, the first check after a failed battery should
take at most a second. Hardly worth people going into hysterics and
calling this a grave bug.
If you really want to disable the future check, you can do this:
[problems]
0x31 = {
preen_ok = true
}
0x32 = {
preen_ok = true
}
I consider this a botch to work around broken hardware, 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#549861: ....
On Sun, Nov 15, 2009 at 11:02:30PM +0100, Eugeniy Meshcheryakov wrote: As far as the FreeRunner is concerned, it currently takes me under 8 seconds to check a 70gig SSD drive. If you put 8GB SD card into the FreeRunner smartphone, the first check after a failed battery should take at most a second. Hardly worth people going into hysterics and calling this a grave bug. The problem is not the check itself, but that e2fsck asks for root password to continue, and this device has no keyboard... Just to set the record straight, that's not e2fsck, but the init scripts. E2fsck never prompts for any passwords. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552934: e2fsprogs: FTBFS: install: cannot stat `/build/user-e2fsprogs_1.41.9-1-amd64-pJJNFw/e2fsprogs-1.41.9/debian /BUILD-STD/doc/libext2fs/*.html': No such file or directory
On Wed, Oct 28, 2009 at 11:50:54AM +0100, Lucas Nussbaum wrote: Source: e2fsprogs Version: 1.41.9-1 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-20091028 qa-ftbfs Justification: FTBFS on amd64 During a rebuild of all packages in sid, your package failed to build on amd64. Argh, this was caused by a gratuitous change[1] in the behavior of texi2html. [1] http://www.mail-archive.com/debian-de...@lists.debian.org/msg277902.html I'll put in a workaround to support both the old and new behavior of texi2html, since it looks like uptream likes the change things randomly. :-( - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549861: ....
On Sat, Nov 14, 2009 at 02:32:54AM +0100, Eugeniy Meshcheryakov wrote: 13 листопада 2009 о 19:43 -0500 Theodore Tso написав(-ла): (1) I'm the maintainer. (2) The bug doesn't even vaguely fit the definition of grave: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package This bug however makes some systems unusable for no good reason. And it does not look like a hard to fix bug at all. There are a number of workarounds. One is to take the kernel patch (or upgrading to 2.6.32, which will have the fix). Or you can fix your system clock to tick GMT, as opposed to localtime, which is fraught with all sorts of problems, especially around the transition in and out of summer-time/daylight savings time. Or you add the following stanza to /etc/e2fsck.conf: [options] buggy_init_scripts = 1 One could just as easily argue that the real bug is having the hardware CMOS time tick in localtime. Granted we should make the system more robust against people who incorrectly set their system clock to be bug-for-bug compatible with Microsoft, but in no way does this justify increasing the severity to grave. In fact we do have changes pending in e2fsprogs and in the kernel to make things more robust against brain-damaged configurations. See commit ba5131f6 in the e2fsprogs maint branch. Until these changes find their way into Debian packages, my recommendation is to either (a) fix your hardware clock to tick UTC time, or (b) apply the buggy_init_scripts workaround to /etc/e2fsck.conf. - 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: Processed: reassign 555456 to e2fsprogs
Hi Micah, Do you have the full e2fsck transcript (it looks like what you submitted to BTS was only a partial transcript)? Also, can you tell me something about the files which got the PROGRAMMING BUG error? It would be useful to see the pathname and inode breakdown of the inode(s) in question. For example, for inode 223806323, the following debugfs commands will give the pathname and inode: % debugfs /dev/mapper/vg_hoopoe0-backups debugfs: ncheck 223806323 debugfs: stat 223806323 debugfs: quit The other thing might be worth trying is re-running e2fsck and see what you see, via e2fsck -f /dev/mapper/vg_hoopoe0-backups. The PROGRAMMING BUG error can also result by having a hard drive returning different data when a particular inode tabke block is read at different times. So if there is something flakey in your storage device --- for example, if you have a RAID 1 setup, and the two mirrors aren't synchronized, it could be that e2fsck would read from disk #1 during pass 1, and then later when pass #4, if the disk read comes from disk #2 returns different data, you will also get the PROGRAMMING BUG error. It should also be the case after a single run of e2fsck, if all answers are answered with 'yes', that a subsequent run of e2fsck should find no problems. This, of course, is assuming that there are no e2fsck bugs and that storage device is reliable. (That is, data written to a block will be read back when the block is read, and data read from a block at time T and data read time T+n will be the same, if there are no intervening writes to that block.) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549861: ....
severity #549861 normal thanks (1) I'm the maintainer. (2) The bug doesn't even vaguely fit the definition of grave: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package You are being abusive by trying to yank up the severity of the bug. Go away. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540152: Fails on unclean umount *every time*
On Fri, Oct 30, 2009 at 12:29:03AM +0100, Michael Prokop wrote: As a developer and maintainer of a Debian based live system (mainly for sysadmins and therefore often used for rescue tasks) I'm wondering what users without (full) control over the systems they are investigating are supposed to do to avoid this situation? I'm not sure how users without full control over their systems would be rebooting them and thus running into the extra fsck? I'm not sure what you mean by your question. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551795: e2fsprogs: /sbin/fsck lost on partial upgrades
On Sun, Oct 25, 2009 at 07:37:43AM +0100, Sven Joachim wrote:
On 2009-10-24 21:06 +0200, Theodore Tso wrote:
diff --git a/debian/control.in b/debian/control.in
index 5d5142c..842d5d0 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -228,7 +228,11 @@ Description: ext2/ext3/ext4 file system libraries -
headers and static libraries
Package: e2fsprogs
Essential: yes
-Pre-Depends: ${shlibs:Depends}, ${misc:Depends}
+ifdef(`UTIL_LINUX_NG',
+``Pre-Depends: ${shlibs:Depends}, ${misc:Depends}, util-linux (
2.15~rc1-1)
^^
That seems to be a typo, surely you mean = instead of ?
Yeah, very stupid typo. Thanks for catching 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#540152: e2fsck, journal replays and timezones
On Thu, Oct 29, 2009 at 02:03:31PM +, Thorsten Glaser wrote: considering Message #64, why is localtime used by ext2fs anyway? With all times in UTC (or rather in whatever time_t is) this kind of problems certainly couln't happen at all? Ext2fs doesn't use localtime. The problem is some people, in the need to be bug-for-bug compatible with Windows, set their hardware CMOS clocks to tick localtime. This is crazy, since it means that during a DST transition, you don't know whether or not the hardware clock has been frobbed (Windows has to ask you, since it can never be sure). Worse yet, if you have two OS's that are both trying to frob the hardware CMOS times during the DST transition, it's very likely that one or the other OS will get things wrong. Unfortunately, Redmond, Washington got this wrong over two decades ago, and people who must use Windows are still paying the price. I solve the problem by simply refusing to run Windows on machines that run Linux, and making the hardware clock tick UTC time, which is the One And Only Sane Solution. In anycase, the problem isn't that ext2fs uses local time, it's that e2fsprogs requires the system clock to be *correct*; that is, the date(1) command and the time(2) system call has to return the correct time. Since Linux uses UTC, like all sane Operating systems, the problem when the hardware CMOS clock is ticking local time is setting the system clock correctly when the hardware CMOS clock is ticking some random local time (and during the DST transition, you really have no clue how to set the system clock from the hardware clock --- but the bug here is using local time and the fundamental bug is having Windows installed. :-) One of the problems that has only been recently fixed in the latest kernels is a kernel bug. When the root file system is being mounted, if you are in a European timezone and you have committed the venial sin of letting your hardware clock tick localtime, the last write time gets set incorrectly when the root file system is mounted read-only --- and it gets set mounted in the future, which means that even if the init scripts properly adjust for the local timezone so the system clock is correct when e2fsck runs, it detects a problem because the last mount time is in the future. Short of applying the local time zone adjustment in the initrd, there's no way to avoid the system clock being incorrect when the root file system is being mounted. The kernel bugfix is to avoid setting the last write time when the file system is being mounted read-only --- which is a good and proper thing to do anyway. What was happening was that when we replay the journal (after an unclean shutdown), we need to update the superblock to clear the journal replay needed bit, and this was setting the last superblock last write time. Still, this is weird. I agree on the Live CD part, although I personally take care to set the timezone on all systems to UTC, I cannot do that for other systems or for all systems at work. For the Live CD, arguably it should just set buggy_init_scripts, since it's the case that it can't know the local timezone adjustment, and simply asking fsck to be more lenient about time problems. But make no mistake, this is a case of papering over a bug. It's a bug we can't control, since it's fundamentally about Windows being installed on the disk and the hardware clock being set to tick localtime instead of UTC. But it's still a bug, and we're still papering over 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#551795: e2fsprogs: /sbin/fsck lost on partial upgrades
tags 551795 +pending
thanks
On Tue, Oct 20, 2009 at 08:32:32PM +0200, Sven Joachim wrote:
Package: e2fsprogs
Version: 1.41.9-1
Severity: serious
Recently, the /sbin/fsck binary has moved from e2fsprogs to util-linux.
While this is certainly correct in itself, e2fsprogs needs to
(pre-)depend on a version of util-linux that contains the fsck program,
otherwise it might get lost on partial upgrades breaking the system.
Looking at the util-linux changelog, 2.15~rc1-1 appears to be the first
version to ship /sbin/fsck.
Thanks for pointing this out. I've checked the following into my
source tree.
commit 06807d9fa62fe31525143b36fcff8f223e18829c
Author: Theodore Ts'o ty...@mit.edu
Date: Sat Oct 24 15:04:54 2009 -0400
debian: Add pre-depends for util-linux for util-linux-ng builds
Addresses-Debian-Bug: #551795
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/debian/control.in b/debian/control.in
index 5d5142c..842d5d0 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -228,7 +228,11 @@ Description: ext2/ext3/ext4 file system libraries -
headers and static libraries
Package: e2fsprogs
Essential: yes
-Pre-Depends: ${shlibs:Depends}, ${misc:Depends}
+ifdef(`UTIL_LINUX_NG',
+``Pre-Depends: ${shlibs:Depends}, ${misc:Depends}, util-linux ( 2.15~rc1-1)
+'',
+``Pre-Depends: ${shlibs:Depends}, ${misc:Depends}
+'')dnl
Suggests: gpart, parted, e2fsck-static
Conflicts: dump ( 0.4b4-4), quota ( 1.55-8.1), initscripts ( 2.85-4),
sysvinit ( 2.85-4)
Replaces: hurd (= 20040301-1), libblkid1 ( 1.38+1.39-WIP-2005.12.10-2),
libuuid1 ( 1.38+1.39-WIP-2005.12.10-2)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549305: Current version of e2fsprogs renders heartbeat unusable
On Fri, Oct 02, 2009 at 11:41:07AM +0200, Alessandro Polverini wrote: Package: e2fsprogs Version: 1.41.9-1 Severity: important I recently upgraded one of my clusters to latest version of e2fsprogs and it stopped working. After digging around the logs I discovered that it was because the latest version of the package does not include any more the fsck executable that heartbeat make use of. If this is a deliberate choice and not an accident I suppose that heartbeat must be patched to handle this new situation. fsck is now being provided by util-linux-ng. Both e2fsprogs and util-linux-ng are mandatory packages so it shouldn't be necessary to declare either as a package dependency. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540152: Fails on unclean umount *every time*
On Thu, Sep 24, 2009 at 12:25:00PM +0200, Marc Haber wrote: I'm in UTC+2; since there is a time difference of approximately two hours (modulo a few seconds -- it certainly took me more than five seconds to find the power cord and boot the system again), I guess that makes it clear that something somewhere is confused about timezones. This also makes it clear why Ted (being on a negative UTC offset) doesn't see this: His timestamp is always in the past, not in the future as ours. Additionally, this check is a severe nuisance for me. I frequently hack around with rescue systems and do not bother with time zones while just fixing a single file. Therefore, I expect that all times may be two hours late or fast after such an operation, and having a head- and consoleless system hang on boot just because of such an issue is a grave issue. I think that this timestamp check is too picky and should be removed completely or relaxed in a way that it does only return a non-zero exit code if the difference is more than could be explained by a timezone issue. There is an easy fix for this, which used to be installed by default on Ubuntu (but not on Debian systems, where this hasn't been a problem). This was an automatic installation of the following in /etc/e2fsck.conf: [options] buggy_init_scripts = 1 This was removed in Karmic because it was believed that all of the issues around making sure the time was properly set before the root filesystem was checked (and I suspect in some other distributions they actually set the timezone in their initrd *before* they mount the root filesystems), which also avoided the problem that I fixed in the kernel patch for ext3/4. But if you're really annoyed and you think it's too picky to make sure the time zones are set correctly in early boot, there is an easy work around. Just set buggy_init_scripts=1. This was the way things were in 9.04 and for the last few years, which I added about 2-3 years ago when I was tired about Ubuntu users (and apparently, only Ubuntu users) were complaining to me about this problem. - 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
clone 546388 -1 reassign -1 libblkid1 severity 546388 wishlist thanks On Sun, Sep 13, 2009 at 12:49:21AM +0200, Christoph Biedl wrote: Package: e2fsprogs Version: 1.41.9-1 Severity: normal Hello, appearently blkid cannot deal very well with somewhat special characters in filesystem labels. I am not sure how dangerous (read: security) this really is but at least it's annoying. Programs that parse the blkid output might return strange results if fooled by e.g. an USB stick plugged by an attacker. This is a problem that we should fix in e2fsprogs sources, but note that blkid library has been transitioned such that in Testing and Unstable, it is now being provided by the source package util-linux (util-linux-ng, aka util-linux 2.x, is taking over responsibility for the blkid and uuid libraries). So a fix in the e2fsprogs sources won't actually affect what happens in Debian, except that I'd cc Karel Zak and he'd probably take the same fix for util-linux-ng. If he gets to the problem first, I'll backport his solution to e2fsprogs' sources. There is a related problem here in how/whether special characters should be handled via backslash expansion when parsing /etc/fstab. The fsck and mount programs don't handle this in a consistent fashion but util-linux-ng is now responsible for fsck as well as mount now, so that's a util-linux-ng problem as well. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509529: e2fsprogs: e2fsck prints spurious error on low-memory system
tags 509529 +pending
thanks
On Tue, Dec 23, 2008 at 12:06:19AM +, Matt Zimmerman wrote:
Package: e2fsprogs
Version: 1.41.3-1
Severity: minor
On an armel system with 32M of RAM and no swap, attempting e2fsck on a certain
filesystem (details below) resulted in:
m...@stuff:~$ sudo e2fsck /dev/sdc1
e2fsck 1.41.3 (12-Oct-2008)
e2fsck: Group descriptors look bad... trying backup blocks...
Media was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error allocating block bitmap (1): Memory allocation failed
e2fsck: aborted
Note the Group descriptors look bad... trying backup blocks... error.
It's failing later due to an allocation failure, so it wouldn't succeed in
any case. This seemed worth reporting as the earlier error hints that there
may be an earlier allocation failure which is not recognized as such.
Thanks for reporting this bug. The following fix will be in a future
version of e2fsprogs.
- Ted
commit 82b59ca1ed0c2d6311f2e4b6e315d7ef82b62833
Author: Theodore Ts'o ty...@mit.edu
Date: Tue Sep 1 20:01:38 2009 -0400
e2fsck: Avoid scary failure messages on low-memory systems
On a very low-memory system, where ext2fs_check_desc() fails because
it can't allocate a block bitmap, catch this error and report it
immediate. This avoids something like this, which could scare and
mislead the user:
e2fsck: Group descriptors look bad... trying backup blocks...
Media was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error allocating block bitmap (1): Memory allocation failed
e2fsck: aborted
Addresses-Debian-Bug: #509529
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/e2fsck/unix.c b/e2fsck/unix.c
index e118e9a..6248958 100644
--- a/e2fsck/unix.c
+++ b/e2fsck/unix.c
@@ -926,7 +926,7 @@ static const char *my_ver_date = E2FSPROGS_DATE;
int main (int argc, char *argv[])
{
- errcode_t retval = 0, orig_retval = 0;
+ errcode_t retval = 0, retval2 = 0, orig_retval = 0;
int exit_value = FSCK_OK;
ext2_filsys fs = 0;
io_manager io_ptr;
@@ -1012,7 +1012,11 @@ restart:
!(ctx-flags E2F_FLAG_SB_SPECIFIED)
((retval == EXT2_ET_BAD_MAGIC) ||
(retval == EXT2_ET_CORRUPT_SUPERBLOCK) ||
-((retval == 0) ext2fs_check_desc(fs {
+((retval == 0) (retval2 = ext2fs_check_desc(fs) {
+ if (retval2 == ENOMEM) {
+ retval = retval2;
+ goto failure;
+ }
if (fs-flags EXT2_FLAG_NOFREE_ON_ERROR) {
ext2fs_free(fs);
fs = NULL;
@@ -1051,6 +1055,7 @@ restart:
if (features[0] || features[1] || features[2])
goto print_unsupp_features;
}
+failure:
if (retval) {
if (orig_retval)
retval = orig_retval;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540376: e2fsprogs: filefrag reports files without allocated blocks incorrectly
On Fri, Aug 14, 2009 at 07:02:28PM -0400, Theodore Tso wrote: On Fri, Aug 07, 2009 at 05:19:38PM +0200, Christoph Hellwig wrote: Package: e2fsprogs Version: 1.41.3-1 Severity: normal It seems like the filefrag doesn't report the correct results for files without any allocted blocks... A whole series of bug fixes for filefrag went into e2fsprogs just before 1.41.8 was released. I tried reproducing your tests and it works for me. So I believe this bug has been fixed in the 1.41.8-1 release of e2fsprogs. Oh, I see what is going on. In e2fsprogs 1.41.6 we added support for the FIEMAP ioctl. The bug you saw is in the FIBMAP ioctl codepath, which is still there as a fallback if filefrag is running on an older kernel. So it won't be observed in 1.41.6+ e2fsprogs, unless running on a non-FIEMAP enabled kernel. I'll get a fix for the FIBMAP code path. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540376: e2fsprogs: filefrag reports files without allocated blocks incorrectly
On Fri, Aug 07, 2009 at 05:19:38PM +0200, Christoph Hellwig wrote: Package: e2fsprogs Version: 1.41.3-1 Severity: normal It seems like the filefrag doesn't report the correct results for files without any allocted blocks... A whole series of bug fixes for filefrag went into e2fsprogs just before 1.41.8 was released. I tried reproducing your tests and it works for me. So I believe this bug has been fixed in the 1.41.8-1 release of e2fsprogs. If you could try testing the 1.41.8-1 e2fsprogs in debian unstable, I believe you will find that it is fixed there. 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#540152: Fails on unclean umount *every time*
On Sat, Aug 08, 2009 at 02:28:56PM +0200, Wouter Verhelst wrote: That was my first thought. However, I consider this unlikely, given: - The problem did not happen when I was running the system off of ext3 rather than ext4 (at least, I do not remember that to be the case). Well, the last mount time is in the future logic is the same for both ext3 and ext4; in fact it's exactly the same code, same program (e2fsck). The last mount time in the future means that the time when e2fsck was running is less than the time recorded as the last mount time in the superblock. And since your original bug report stated that: When this happens, on reboot, the system always complains that the superblock of my / filesystem (an ext4 one) has its last mount count in the future, which is an 'unexpected inconsistency' and causes it to drop to a root login, asking me to perform a manual fsck. ... I don't see how it can be anything other than a time problem at boot. Maybe I should extend the error message to print the time in the superblock and the current time, since there seem to be so many people who have problems with this, but for now, all I can tell you is to try to reproduce this, and then check the system time when it dumps you into the root shell, and to grab the last mount and last write times out of the superblock using dumpe2fs. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540152: Fails on unclean umount *every time*
The following patch will be in the next release of e2fsprogs. If
you'd like to apply it and rebuild it, it will provide the proof you
need that either your laptop RTC clock is bad or there's something
strange going on with the system time on your laptop.
- Ted
commit fe26a55ac923f4cce17c27ef51de84d2e3b6eebb
Author: Theodore Ts'o ty...@mit.edu
Date: Sat Aug 8 10:14:48 2009 -0400
e2fsck: Fix and enhance superblock dates in future problem reports
Fixed a bug where e2fsck would report that last mount time was in the
future when it was really the last write time that was in the future.
Also, since people can't seem to believe that (a) their distribution
has buggy init scripts, or (b) their CMOS/RTC clock or backup battery
is dead, print the incorrect time and the current system time.
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/e2fsck/message.c b/e2fsck/message.c
index 3f85916..77f9756 100644
--- a/e2fsck/message.c
+++ b/e2fsck/message.c
@@ -209,6 +209,24 @@ static void print_pathname(ext2_filsys fs, ext2_ino_t dir,
ext2_ino_t ino)
}
}
+static void print_time(time_t t)
+{
+ const char *time_str;
+ static int do_gmt = -1;
+
+#ifdef __dietlibc__
+ /* The diet libc doesn't respect the TZ environemnt variable */
+ if (do_gmt == -1) {
+ time_str = getenv(TZ);
+ if (!time_str)
+ time_str = ;
+ do_gmt = !strcmp(time_str, GMT0);
+ }
+#endif
+ time_str = asctime((do_gmt 0) ? gmtime(t) : localtime(t));
+ printf(%.24s, time_str);
+}
+
/*
* This function handles the '@' expansion. We allow recursive
* expansion; an @ expression can contain further '@' and '%'
@@ -244,9 +262,7 @@ static _INLINE_ void expand_inode_expression(char ch,
{
struct ext2_inode *inode;
struct ext2_inode_large *large_inode;
- const char *time_str;
time_t t;
- static int do_gmt = -1;
if (!ctx || !ctx-inode)
goto no_inode;
@@ -289,18 +305,7 @@ static _INLINE_ void expand_inode_expression(char ch,
printf(0%o, inode-i_mode);
break;
case 'M':
-#ifdef __dietlibc__
- /* The diet libc doesn't respect the TZ environemnt variable */
- if (do_gmt == -1) {
- time_str = getenv(TZ);
- if (!time_str)
- time_str = ;
- do_gmt = !strcmp(time_str, GMT0);
- }
-#endif
- t = inode-i_mtime;
- time_str = asctime((do_gmt 0) ? gmtime(t) : localtime(t));
- printf(%.24s, time_str);
+ print_time(inode-i_mtime);
break;
case 'F':
printf(%u, inode-i_faddr);
@@ -392,6 +397,8 @@ static _INLINE_ void expand_dirent_expression(ext2_filsys
fs, char ch,
static _INLINE_ void expand_percent_expression(ext2_filsys fs, char ch,
struct problem_context *ctx)
{
+ e2fsck_t e2fsck_ctx = fs ? (e2fsck_t) fs-priv_data : NULL;
+
if (!ctx)
goto no_context;
@@ -461,6 +468,12 @@ static _INLINE_ void expand_percent_expression(ext2_filsys
fs, char ch,
case 's':
printf(%s, ctx-str ? ctx-str : NULL);
break;
+ case 't':
+ print_time((time_t) ctx-num);
+ break;
+ case 'T':
+ print_time(e2fsck_ctx ? e2fsck_ctx-now : time(0));
+ break;
case 'X':
#ifdef EXT2_NO_64_TYPE
printf(0x%x, ctx-num);
diff --git a/e2fsck/problem.c b/e2fsck/problem.c
index d6b345c..fc325e9 100644
--- a/e2fsck/problem.c
+++ b/e2fsck/problem.c
@@ -334,12 +334,12 @@ static struct e2fsck_problem problem_table[] = {
/* Last mount time is in the future */
{ PR_0_FUTURE_SB_LAST_MOUNT,
- N_(@S last mount time is in the future. ),
+ N_(@S last mount time (%t,\n\tnow = %T) is in the future.\n),
PROMPT_FIX, PR_NO_OK },
/* Last write time is in the future */
{ PR_0_FUTURE_SB_LAST_WRITE,
- N_(@S last write time is in the future. ),
+ N_(@S last write time (%t,\n\tnow = %T) is in the future.\n),
PROMPT_FIX, PR_NO_OK },
{ PR_0_EXTERNAL_JOURNAL_HINT,
diff --git a/e2fsck/super.c b/e2fsck/super.c
index ef29aa5..2202967 100644
--- a/e2fsck/super.c
+++ b/e2fsck/super.c
@@ -831,7 +831,7 @@ void check_super_block(e2fsck_t ctx)
}
if (fs-super-s_wtime (__u32) ctx-now) {
pctx.num = fs-super-s_wtime;
- problem = PR_0_FUTURE_SB_LAST_MOUNT;
+ problem = PR_0_FUTURE_SB_LAST_WRITE;
if
Bug#540152: Fails on unclean umount *every time*
On Thu, Aug 06, 2009 at 10:23:55AM +0200, Wouter Verhelst wrote: Package: e2fsprogs Version: 1.41.8-2 Severity: normal File: /sbin/e2fsck Due to an incorrect assumption about user interface by the manufacturer, my laptop has its 'power almost out' LED hidden somewhere to the left, where it cannot be seen unless I turn it almost 90 degrees. Since I don't like most of the 'power manager' thingies out there (they all want to manage my CPU frequency settings and suspend state too, which I will manage myself, thank you very much), I'm not running any, which inevitably means that from time to time, the battery runs out. When this happens, on reboot, the system always complains that the superblock of my / filesystem (an ext4 one) has its last mount count in the future, which is an 'unexpected inconsistency' and causes it to drop to a root login, asking me to perform a manual fsck. Since this happens every time, I think the 'unexpected' part of the above is a bug, and an annoying one at that. E2fsck requires that the system clock be correct when it runs. I bet your trashy laptop not only has a bad design where you don't notice that you are running out of memory, but also that it doesn't have a separate CMOS to maintain your CMOS memory and time-of-day clock after your primary battery has died. As a result, when you restore power to your laptop and reboot, I suspect what is happening is that your time-of-day clock is insane at the time when e2fsck is running, and so it's deciding that it needs to do a full check of the filesystem due to it being too long since the last time the filesystem was checked, or some such. What message is e2fsck printing to explain why it thinks a full filesystem check is warranted? I'm almost 99% certain it's time-related. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540111: posstible typo in /etc/mke2fs.conf
On Wed, Aug 05, 2009 at 10:00:21PM +0200, Christoph Anton Mitterer wrote: Package: e2fsprogs Version: 1.41.8-2 Severity: normal It seems that a typo slipped into /etc/mke2fs.conf: ext4 and ext4dev use both extents but the manpage and tune2fs says extent (singular). Creating a filesystem with extents seems to activate extent anyway. Both extent and extents are accepted by e2fsprogs, for compatibility reasons. I suppose we should make the default config file consistent with the documented form of the feature found in man page, but it's only a cosmetic 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#539100: libblkid1: Broken/loose dependencies
On Wed, Jul 29, 2009 at 06:30:36AM +0200, Michael Biebl wrote: Package: libblkid1 Version: 2.16-2 Severity: serious Justification: wrong dependencies Hi, libblkdi1 has a generated dependency on libuuid1 1.40.3-1. When I compile hal 0.5.13 against libblkid-dev in a minimal chroot, this installs libblkid-dev 2.16-2 uuid-dev 1.2-1.41.8-2 libblkid1 1.41.8-2 The build fails: libtool: link: cc -g -O2 -g -Wall -O2 -Wchar-subscripts -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -Wl,--as-needed -o .libs/hald-probe-storage probe-storage.o linux_dvd_rw_utils.o util_helper.o logger.o /usr/lib/libblkid.so ../../../libhal/.libs/libhal.so ../../../partutil/.libs/libpartutil.a -ldbus-glib-1 -ldbus-1 -lpthread -lrt /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -lsmbios /usr/lib/libblkid.so: undefined reference to `uuid_unpa...@uuid_1.0' collect2: ld returned 1 exit status make[6]: *** [hald-probe-storage] Error 1 make[6]: Leaving directory `/tmp/buildd/hal-0.5.13/hald/linux/probing' libblkid1 version 2.16-2 is in experimental, and is generated from sources in util-linux-ng (aka util-linux version 2.16), and no longer from e2fsprogs. I don't think (in fact I'm pretty sure) the BTS isn't smart enough to send this report to the util-linux maintainers instead of the e2fsprogs maintainer (me). Scott, LaMont, could you subscribe to this bug, and handle it, please? As Michael pointed out in a subsequent e-mail to this bug, it's a failure in the shlibs file. The libblkid 1.x packages do not provide any symbols with the @UUID_1.0 symbol version, and so the shlibs file needs to be adjusted to point this out. 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#539100: libblkid1: Broken/loose dependencies
On Wed, Jul 29, 2009 at 09:11:30PM +0200, Michael Biebl wrote: Theodore Tso wrote: Scott, LaMont, could you subscribe to this bug, and handle it, please? As Michael pointed out in a subsequent e-mail to this bug, it's a failure in the shlibs file. The libblkid 1.x packages do not provide any symbols with the @UUID_1.0 symbol version, and so the shlibs file needs to be adjusted to point this out. Why is the shlibs.local file needed at all? If the symbols files are updated properly, that should be sufficient to generate correct dependencies. Agreed. At least for e2fsprogs, the shlibs.local file predated my adding the symbols file, and I never got around to deleting the shlibs.local file. I already talked to Scott and LaMont briefly about this. Imho the symbols files should not be updated/generated automatically, but manually, so you can actually track ABI breakages much more easily. Also, the debian revision should be stripped away (unless a symbol was added by a Debian revision specific patch), to make e.g. backports easier. Yes, I agree. I'll make the change in e2fsprogs for libraries that are still shipping as part of e2fsprogs, but it's up to Scott and LaMont to make changes to the util-linux package in experimental. Thank you for noticing this problem before it was moved to unstable and/or testing!! - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514209: initscripts: doesn't fsck /dev/disk/by-label with spaces
On Sat, Jul 25, 2009 at 05:42:01PM +0200, Marco d'Itri wrote: Thank you for your testing. It make me suspect that the file name do not really contain space, but the string '\x20' instead. This is then interpreted differently by different programs. fsck understand it to mean 'x20', while mount understand it to mean '\x20'. Neither seem to understand it to mean ' ' (space). udev outputs a string which is supposed to be used literally, I do not know why fsck tries to \-expand paths in fstab. So far it's the only program which stands out by not understanding the name, if the maintainer disagrees than I fear that this will have to be sorted out between him and the upstream udev maintainer since I am not going to modify the persistent names just for Debian. What works consistently across both fsck and mount, and what I would recommend you use instead, is something like this: LABEL=W-98\040SE /mnt vfat defaults 0 0 This works just fine for both mount and fsck. The LABEL= and UUID= is much more reliable than /dev/disk/by-label and /dev/disk/by-uuid. For example, for a newly created filesystem, /dev/disk/by-uuid and /dev/disk/by-label don't get updated until you reboot the system, which is very Windows-like. LABEL= and UUID= will reliably work as soon as you create the new filesystem. /dev/disk/by-label and /dev/disk/by-uuid are broken by design. This is why blkid has been merged into util-linux-ng, and used by default --- because it works reliably, whereas the udev pathnames do not. Note that fsck will also be shortly transfering to util-linux-ng, but until then sure, I'll investigate making sure that mount and fsck are consistent in terms of how backslashes are handled. Note that backslash support is needed in order to support actually having real spaces in pathnames, although the main reason why it was added was so that things like LABEL=W-98\040SE would work consistently accross fsck and mount --- which it does; I just tested 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#514209: initscripts: doesn't fsck /dev/disk/by-label with spaces
On Sun, Jul 26, 2009 at 10:59:15AM +0930, Arthur Marsh wrote: For the Debian bug to be closed, perhaps the manual page for fstab(5) should be changed from: Well, there still is the issue of fsck and mount potentially handling backslash-style quoting differently in various different fields; there is a bug hiding there, although it's probably lower priority given that the supported answer is to use LABEL= or UUID=. As far as the fstab manual page, it's more than just ext2/ext3/ext4 and xfs; it's any filesystem for which there is support in the blkid library for handling labels. We probably shouldn't use an explicit in fstab, since it will go out of date quite quickly. (At the time of this writing, we support LABEL= handling for the following filesystems types: ntfs, reiserfs, resierfs4, jfs, romfs, cramfs, swap, iso9660, ocfs, ocfs2, gfs, gfs2, hfsplus, btrfs). So saying that it works on most filesystems that define a label is a pretty fair 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#538052: tzc: uninstallable in unstable
On Wed, Jul 22, 2009 at 01:55:58PM -0400, Sam Hartman wrote: package: tzc severity: grave version: 2.6.15-5 Hi. tzc depends on libzephyr3 which is no longer present in unstable. This is blocking the zephyr transition, which is blocking the removal of libkrb53 from testing. I plan to schedule an NMU for 4 days from now using the delayed queue. I'll attach an NMU diff here; you can either upload before my NMU hits incoming, cancel my NMU, or do nothing and the NMU should go through. Thanks were you going to send a diff later, or were you planning on attach a diff and just forgotten to hit the include button? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535452: resize2fs fails to read mountpoint for online resize
On Thu, Jul 02, 2009 at 08:14:29PM +0200, Goswin von Brederlow wrote: OK, I see what's going on. We're freeing the mountpoint information so when we print it in an error message, the error message is getting printed as garbage. This probably doesn't qualify as a severity important level bug (a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone), so I've downgraded it to normal. major effect on the usability of resize2fs :) Does that also explain why it fails to run? Sorry, I didn't realize at first it was also causing resize2fs to fail to run. Yes, it does, and yes, with the patch it is fixed. I'll get an updated package release out quickly so that people who need online resize can get 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#535452: resize2fs fails to read mountpoint for online resize
On Thu, Jul 02, 2009 at 12:03:10PM +0200, Goswin Brederlow wrote: Package: e2fsprogs Version: 1.41.7-1 Severity: important File: /sbin/resize2fs Hi, when I try to resize a filesystem I get: % resize2fs -p /dev/s/unseen resize2fs 1.41.7 (29-June-2009) Filesystem at /dev/s/unseen is mounted on ·+; on-line resizing required old desc_blocks = 33, new_desc_blocks = 41 resize2fs: No such file or directory while trying to open mountpoint ·+ The filesystem is mounted as: /dev/mapper/s-unseen /mnt/unseen ext3 rw 0 0 Can you send me a copy of your /etc/mtab, /etc/fstab and /proc/mounts files on your system, please? 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#535452: resize2fs fails to read mountpoint for online resize
severity 535452 normal
tags 535452 +pending
thanks
OK, I see what's going on. We're freeing the mountpoint information
so when we print it in an error message, the error message is getting
printed as garbage.
This probably doesn't qualify as a severity important level bug (a
bug which has a major effect on the usability of a package, without
rendering it completely unusable to everyone), so I've downgraded it
to normal.
I've checked a fix into the e2fsprogs git tree, and it will be fixed
in the next release.
Thanks for reporting the bug!
- Ted
commit 3a4d9869d47c462c84688b0f8b15df5ab6f93381
Author: Theodore Ts'o ty...@mit.edu
Date: Thu Jul 2 13:54:22 2009 -0400
resize2fs: Fix error message so the mountpoint is printed correctly
The resize2fs program was freeing the mountpoint information too
early, so garbage was getting printed instead of the correct
information in an error message.
Addresses-Debian-Bug: #535452
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/resize/main.c b/resize/main.c
index 9b03ba9..2dae161 100644
--- a/resize/main.c
+++ b/resize/main.c
@@ -250,10 +250,8 @@ int main (int argc, char ** argv)
device_name);
exit(1);
}
- if (!(mount_flags EXT2_MF_MOUNTED) || (mtpt[len-1] == 0)) {
- free(mtpt);
+ if (!(mount_flags EXT2_MF_MOUNTED) || (mtpt[len-1] == 0))
break;
- }
free(mtpt);
len = 2 * len;
}
@@ -453,6 +451,7 @@ int main (int argc, char ** argv)
((flags RESIZE_PERCENT_COMPLETE) ?
resize_progress_func : 0));
}
+ free(mtpt);
if (retval) {
com_err(program_name, retval, _(while trying to resize %s),
device_name);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531385: 'man chattr' typo: posible
tags 531385 +pending thanks Thanks for notifying me of this typo in the chattr man page. I have committed a fix into e2fsprogs's source tree, 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#521057: AW: Multiple runs from fsck.ext3 -n -f /dev/md0 create different Output
On Fri, May 29, 2009 at 12:03:46PM +0200, Metzen, Manfred wrote: Meanwhile i think it is an problem with a specific mainboard or bios (ECS P4vxad and Award Bios) and Debian 5. In the following i do the test always 50 times. When i put the RAID in a system with ECS P4vxad, Award Bios and Debian 5, in the majority of cases i got the errors. Putting the same RAID in another system (identical hardware) and Debian 4, no errors occur. Putting the same RAID in a system with different hardware neither with Debian 4 nor with Debian 5 an error was reported. So i switched my serves to a new hardware. This solves the problem for me. Maybe i test an bios-update for ECS P4vxad. Yes, that sounds like a hardware problem of some kind. Hence, I'll close this bug report. If you run into further problems that you think changes this conclusion, and makes you believe that we have some kind of software bug, please don't hesitate to open a new bug report, or reopen this one. 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#516428: broken question about creating a filesystem in regular file
On Sat, Apr 18, 2009 at 01:29:02PM -0400, Theodore Tso wrote: On Sat, Apr 18, 2009 at 06:20:43PM +0200, Robert Millan wrote: Attached. Btw, I forgot to mention how did I create the file. This time I reproduced it with a dd if=/dev/zero of=tmp bs=32k count=1 file. That will blow up instantly with: tmp: Not enough space to build proposed filesystem while setting up superblock I was trying with dd if=/dev/zero of=tmp bs=1k count=32k and it works just fine. Hi, I think this bug was user-error; do you agree? You haven't replied in over a month, so if I don't get response soon so I can reproduce whatever it was you were seeing, I'm going to close this as unreproducible. 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#521057: Multiple runs from fsck.ext3 -n -f /dev/md0 create different Output
On Tue, Mar 24, 2009 at 04:20:31PM +0100, Metzen, Manfred wrote: Package: e2fsprogs Version: 1.41.3-1 After updating some fileserver from debian 4 (etch) to debian 5 (lenny)(new installation) i have a lot of trouble with ext3-filesystems on raidarrays. Rebooting often ends in manually fsck. (examples for two fsck runs, one directly after the other, are posted on http://debianforum.de/forum/viewtopic.php?f=9t=109072). Doing a lot of tests i see that executing the command fsck.ext3 -n -f /dev/md0 multiple times the output was often different. No other aktion was made between the calls of fsck.ext3. I expect that the Output must be equal. They would be, if the hardware is sane. Would I be right in guessing you have a RAID 1 setup? If so, I'm guessing that the two mirrors of your data are not in sync with one another, so depending on which disk the MD driver happens to select to read from, you are getting different results. Have you tried checking to make sure the contents of your two RAID 1 disks are identical? - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516820: e2fsck won't fix a filesystem with a broken block bitmap
tags 516820 +pending
thanks
I found the problem; the following patch should fix things, and I have
this checked into the e2fsprogs SCM.
- Ted
commit 606638906a0229323d1b2871fdb0d45ea0e7ff62
Author: Theodore Ts'o ty...@mit.edu
Date: Thu May 28 23:40:18 2009 -0400
e2fsck: Go back to the original superblock if the backup sb is invalid
In the case where the block group descriptors appear corrupt, e2fsck
will try to use the backup superblock. However, it could be that the
backup superblock itself is completely corrupted, in which e2fsck
should go back to the original superblock instead of refusing to fix
the file system.
Addresses-Debian-Bug: #516820
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/e2fsck/unix.c b/e2fsck/unix.c
index 3e684ae..ffcdcc6 100644
--- a/e2fsck/unix.c
+++ b/e2fsck/unix.c
@@ -890,6 +890,38 @@ sscanf_err:
exit (1);
}
+static errcode_t try_open_fs(e2fsck_t ctx, int flags, io_manager io_ptr,
+ext2_filsys *ret_fs)
+{
+ errcode_t retval;
+
+ *ret_fs = NULL;
+ if (ctx-superblock ctx-blocksize) {
+ retval = ext2fs_open2(ctx-filesystem_name, ctx-io_options,
+ flags, ctx-superblock, ctx-blocksize,
+ io_ptr, ret_fs);
+ } else if (ctx-superblock) {
+ int blocksize;
+ for (blocksize = EXT2_MIN_BLOCK_SIZE;
+blocksize = EXT2_MAX_BLOCK_SIZE; blocksize *= 2) {
+ if (*ret_fs) {
+ ext2fs_free(*ret_fs);
+ *ret_fs = NULL;
+ }
+ retval = ext2fs_open2(ctx-filesystem_name,
+ ctx-io_options, flags,
+ ctx-superblock, blocksize,
+ io_ptr, ret_fs);
+ if (!retval)
+ break;
+ }
+ } else
+ retval = ext2fs_open2(ctx-filesystem_name, ctx-io_options,
+ flags, 0, 0, io_ptr, ret_fs);
+ return retval;
+}
+
+
static const char *my_ver_string = E2FSPROGS_VERSION;
static const char *my_ver_date = E2FSPROGS_DATE;
@@ -903,6 +935,7 @@ int main (int argc, char *argv[])
const char *lib_ver_date;
int my_ver, lib_ver;
e2fsck_tctx;
+ blk_t orig_superblock;
struct problem_context pctx;
int flags, run_result;
int journal_size;
@@ -974,26 +1007,8 @@ restart:
if ((ctx-mount_flags EXT2_MF_MOUNTED) == 0)
flags |= EXT2_FLAG_EXCLUSIVE;
- if (ctx-superblock ctx-blocksize) {
- retval = ext2fs_open2(ctx-filesystem_name, ctx-io_options,
- flags, ctx-superblock, ctx-blocksize,
- io_ptr, fs);
- } else if (ctx-superblock) {
- int blocksize;
- for (blocksize = EXT2_MIN_BLOCK_SIZE;
-blocksize = EXT2_MAX_BLOCK_SIZE; blocksize *= 2) {
- if (fs)
- ext2fs_free(fs);
- retval = ext2fs_open2(ctx-filesystem_name,
- ctx-io_options, flags,
- ctx-superblock, blocksize,
- io_ptr, fs);
- if (!retval)
- break;
- }
- } else
- retval = ext2fs_open2(ctx-filesystem_name, ctx-io_options,
- flags, 0, 0, io_ptr, fs);
+ retval = try_open_fs(ctx, flags, io_ptr, fs);
+
if (!ctx-superblock !(ctx-options E2F_OPT_PREEN)
!(ctx-flags E2F_FLAG_SB_SPECIFIED)
((retval == EXT2_ET_BAD_MAGIC) ||
@@ -1008,11 +1023,20 @@ restart:
ctx-program_name,
retval ? _(Superblock invalid,) :
_(Group descriptors look bad...));
+ orig_superblock = ctx-superblock;
get_backup_sb(ctx, fs, ctx-filesystem_name, io_ptr);
if (fs)
ext2fs_close(fs);
orig_retval = retval;
- goto restart;
+ retval = try_open_fs(ctx, flags, io_ptr, fs);
+ if ((orig_retval == 0) retval != 0) {
+ com_err(ctx-program_name, retval,
+ when using the backup blocks);
+ printf(_(%s: going back to original
+
Bug#527859: e2fsprogs: resize2fs's -f should allow me to resize without having to jump through hoops
On Fri, May 08, 2009 at 08:39:53PM -0400, Andres Salomon wrote: Package: e2fsprogs Version: 1.41.3-1 If I attempt to shrink an ext3 filesystem while mounted (even if read-only) via resize2fs /dev/hda1 8G, it refuses with: Filesystem at /dev/hda1 is mounted on /; on-line resizing required On-line shrinking from $foo to $bar not supported. I don't know if this is a necessary restriction or not, but it's pretty annoying. If it is safe to do when the fs is mounted read-only, it would be nice if '-f' allowed one to bypass the check. Well, it could cause the system to panic and reboot while resize2fs is in the middle of resizing the filesystem --- is that unsafe enough? :-) That's pretty extreme, and it's a pretty low-probability event, but it's definitely within the realm of possibility. If you have the filesystem set up to reboot if a filesystem corruption is detected, it's even more likely. Also note that if you are short on memory, and the system is paging, any program currently running on the system which you are shrinking (possibly including resize2fs itself) could end up reading in trash blocks, which could cause that program to crash. And while resize2fs tries very hard not to leave the filesystem corrupted if it or the system crashes while it is running, there are certain operations which could lead to data loss. Furthermore, if one boots into an initramfs (booting with 'break=mount') in order to resize the filesystem, mounts /dev/hda1, copies resize2fs and associated libs into the initramfs root, unmounts /dev/hda1, and then attempts to shrink the filesystem, one gets: ext2fs_check_mount_point: No such file or directory while determining whether /dev/hda1 is mounted. Even using '-f' doesn't allow it to continue. This is amazingly unhelpful. The code in lib/ext2fs/ismounted.c checks /proc/mounts for the filesystem, doesn't find anything interesting, attempts to check /etc/mtab (which doesn't exist because we're in an initramfs), and returns ENOENT. Please consider the following patch to allow the administrator to override the failed mount point check using the -f option. It would be even better if that check could be made to not happen at all w/ -f (or some other argument). So I'm extremely uncomfortable with this. I would much rather have initramfs create a zero-length /etc/mtab file in the inital ramdisk image, or better yet, have a fully supported and supportable system which allows users to shrink the root filesystem. For example, we could have a script fragment that checks for the existence of a file which matches the pattern /on-initrd-*.tar.gz, and if one or more such files exists, they are copied to the initrd, and then the root filesystem is unmountd, and one by one, the on-initrd-*.tar.gz files are unpacked and the /on-initrd script contained in the tar.gz file is executed. This could be used to perform an off-line shrink of the root partition, by having the user request such a thing, and then rebooting, and having it happen automatically. It could also be used to add or remove a journal safely, as well as repack and optimize directories (e2fsck -fD). Another approach would be to resize the filesystem using a rescue CD. The reason why I suggest these is they are in the long-term much more supportable. If a user doesn't know enough to work around the ext2fs_check_mount_point: No such file or directory while determining whether /dev/hda1 is mounted error by using touch /etc/mtab, do we really want to trust him or her with using resize2fs -f? What if they use it when they shouldn't, and end up trashing their own filesystem? I've already had a bug filed by an Ubuntu user who saw this error message: /dev/ssd/root is mounted. WARNING!!! Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage. Do you really want to continue (y/n)? ... and they were clueless enough to answer yes, and then when his filesystem was severly damanged (as promised) he filed a bug complaining about the fact. Resize2fs -f is even easier for said user to screw up. If I did anything at all, I'd be severly tempted to make the user type something like: Warning! An attempt to resize /dev/XXX while it is mounted may cause your system to crash and your filesystem to be destroyed. To continue please type: 'I ACCEPT ALL LIABILITY FOR TRASHING MY FILESYSTEM AND PROMISE NOT TO FILE A BUG'. Or, if your /etc/mtab file is in error or missing, type ^C, fix it by hand, and rerun re2size2fs: ... and only continue if the user types the required string. :-) - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527859: e2fsprogs: resize2fs's -f should allow me to resize without having to jump through hoops
On Sat, May 09, 2009 at 06:22:00PM -0400, Andres Salomon wrote: Creating a zero-length /etc/mtab file doesn't work if, for some reason, /etc is mounted read-only. Having a fully supported and supportable system isn't always available. If resize2fs is going to stipulate that the filesystem that it's shrinking is not mounted, then users are going to use it in things like recovery cds and initramfs's. You said you had an initramfs mounted, remember? And as I said, if /etc is mounted read-only, then it's almost certain that / is mounted read-only, and an off-line shrink using resize2fs is not safe to run on a mounted filesystem. (Also, if /etc is mounted read-only, there normally is an /etc/mtab file.) The real problem here is that initramfs isn't including a proper /etc/mtab file --- but it's an initramfs, which means you can fix it, by definition. A much simpler and safer solution, instead of trying to subvert resize2fs safety mechanisms, is to fix the initramfs scripts to create the /etc/mtab file in the first place. I like my tools to get out of the way and allow me to what I want to do. That's why I use free software (transparency and hackability). I'm fine w/ all kinds of warnings to tell the user that they shouldn't continue, so long as they are also told of a way to actually continue. Well, it's free software, so if you want to disable the safety mechanisms, you have the freedom to do it. Call me silly, but I'm the sort of person that believes in showing people the right way to use a table saw, and *not* accepting a suggestion to ship table saws with an documented way of subverting the safety guards that (for example) tries to prevent people from sawing their fingers off. What's wrong with fixing the initramfs tools to create a proper /etc/mtab file? For example, we could have a script fragment that checks for the existence of a file which matches the pattern /on-initrd-*.tar.gz, and if one or more such files exists, they are copied to the initrd, and then the root filesystem is unmountd, and one by one, the on-initrd-*.tar.gz files are unpacked and the /on-initrd script contained in the tar.gz file is executed. This could be used to perform an off-line shrink of the root partition, by having the user request such a thing, and then rebooting, and having it happen automatically. It could also be used to add or remove a journal safely, as well as repack and optimize directories (e2fsck -fD). Sounds like additional unnecessary complexity to me. But it's easier and safer for users to use. Teaching users that's it's OK to use force options scares the hell out of me. Trust me. Most Linux users, from numerical standpoint, are stupid. This isn't like it was ten years ago. There's a reason why lawnmowers have safety mechanisms that stop the blade from spinning if one of the wheels is lifted off the ground. It turns out some number of idiots were trying to pick up a lawnwomer and use it to trip their hedges, and then when they dropped the lawnmower on their leg(s), they lost a foot. Oops. They were then able to find a lawyer who was able to successfully sue the lawnmower manufacturer for negligence (which is its own problem, and speaks to the US legal system). This just goes to prove what H. L. Mencken once stated: Nobody ever went broke underestimating the intelligence of the American people Unfortunately, this tends to be true world-wide, not just for the general American Public - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526524: /sbin/fsck.ext3: i_file_acl_hi should be zero reported on a old ro filesystem
On Fri, May 01, 2009 at 08:16:01PM +0200, matthieu castet wrote: Package: e2fsprogs Version: 1.41.5-1 Severity: normal File: /sbin/fsck.ext3 recent version cause a storm of i_file_acl_hi should be zero on a old ext3 partion that I mount readonly. After some investigation it seems i_file_acl_hi is an ext4 feature : it is only present in linux-2.6/fs/ext4/ext4.h, but in linux-2.6/include/linux/ext3_fs.h it is a padding field (i_pad1). That's correct. The field should have always been all zero's, and it would be interesting to investigate how they had gotten set to some non-zero value in the first place. Older (pre 2.6.30) versions of the kernel will blow up in very entertaining ways if you try to mount an ext3 filesystem using the ext4 filesystem code. This is supposed to work, since the ext4 code is fully backwards compatible and is supposed to mount ext2 and ext4 filesystems. So there is a patch that has gone into 2.6.30-rc4 that fixes ext4 to not look at that field unless the 64BIT feature is set. However, in order to make things work better for people using older code, I also added a fix to e2fsck to detect this condition and offer to fix it. On an ext3 filesystem, it is harmless, but it's nice to make fix this problem, which should have never happened under normal circumstance. I believe my readonly partition is valid, but wonder why I doesn't get no error on my read/write partition. May be the ext3 linux driver, did some modification. This is quite annoying as it stop the system from botting. Probably the right thing to do is to mark this type filesystem corruption as one that can be fixed in preen mode. That way the filesystems with this should never happen condition will be cleaned up, but it won't stop users' systems from booting. Thanks for reporting this 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#524567: resize2fs: -M does not work as expected
On Sun, Apr 19, 2009 at 09:59:55PM +0200, Wouter Verhelst wrote: I tried, but those patches do not cleanly apply to the version in Debian. I presume there's a git repository somewhere that I can clone? I'll happily try compiling and running that one, if necessary. There's a git repository here: git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git But the fix should be in the latest e2fsprogs version 1.41.4-2 which I uploaded to unstable. If you can give that a try and see if that fixes things, then I'll close this bug. 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#516428: broken question about creating a filesystem in regular file
On Sat, Apr 18, 2009 at 06:20:43PM +0200, Robert Millan wrote: Attached. Btw, I forgot to mention how did I create the file. This time I reproduced it with a dd if=/dev/zero of=tmp bs=32k count=1 file. That will blow up instantly with: tmp: Not enough space to build proposed filesystem while setting up superblock I was trying with dd if=/dev/zero of=tmp bs=1k count=32k and it works just fine. ty...@closure:/tmp$ dd if=/dev/zero of=tmp bs=1k count=32k 32768+0 records in 32768+0 records out 33554432 bytes (34 MB) copied, 0.756256 s, 44.4 MB/s ty...@closure:/tmp$ /sbin/mke2fs -j tmp mke2fs 1.41.3 (12-Oct-2008) tmp is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 8192 inodes, 32768 blocks 1638 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=33554432 4 block groups 8192 blocks per group, 8192 fragments per group 2048 inodes per group Superblock backups stored on blocks: 8193, 24577 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 36 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. I'm not sure what's going on, but I definitely can't reproduce 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#524567: resize2fs: -M does not work as expected
On Sat, Apr 18, 2009 at 09:05:19AM +0200, Wouter Verhelst wrote: Package: e2fsprogs Version: 1.41.3-1 Severity: normal When running resize2fs on an offline filesystem, after calling e2fsck -f on the filesystem, it now consistently reports 'No space left on device'. Freeing up space before retrying does not help; and this issue also appears on a 5G filesystem with 758M of used diskspace, so the notion that there would not be enough free space would seem to be in error. Hi Wouter, Is this for an ext4 or an ext3 filesystem? If it is an ext4 filesystem it's likely to be a problem that can be solved with these patches: http://comments.gmane.org/gmane.comp.file-systems.ext4/12763 or, you may find this interface more convenient: http://patchwork.ozlabs.org/patch/26175/ http://patchwork.ozlabs.org/patch/26176/ http://patchwork.ozlabs.org/patch/26174/ If you don't feel like building your own version of e2fsprogs, could you send me the output of dumpe2fs, and also if you are willing a compressed raw e2image file. See the RAW IMAGE FILES section of the e2image man page for more details. 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#516428: broken question about creating a filesystem in regular file
tags 516428 +unreproducible thanks On Sat, Feb 21, 2009 at 01:20:09PM +0100, Robert Millan wrote: Package: e2fsprogs Version: 1.41.3-1 Severity: normal $ /sbin/mke2fs -j tmp mke2fs 1.41.3 (12-Oct-2008) tmp is not a block special device. Proceed anyway? (y,n) y $ This used to work 1.39+1.40-WIP-2006.11.14+dfsg-2etch1, now it won't do it unless -F was used. I wasn't able to reproduce this on e2fsprogs 1.41.4, and so I went to a debian sid chroot, and tried exactly what you did above, and it worked for me. Can you still reproduce it, and if so, can you send me an strace of mke2fs -j tmp? 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#521602: e2fsprogs: FTBFS on hurd-i386 due to PATH_MAX
tags 521602 +pending thanks On Sat, Mar 28, 2009 at 10:13:36PM +0100, Samuel Thibault wrote: e2fsprogs currently FTBFS on hurd-i386 because of unconditional use of the PATH_MAX limit which hurd-i386 doesn't have. The attached patch just exactly allocates what is required. Your patch didn't do error checking in case malloc() return NULL. I fixed that up and have committed it into the e2fsprogs source tree. Thanks for reporting this, - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517015: e2fsprogs: tune2fs accept negative reserved blocks percentage
tags 517015 +pending
thanks
On Tue, Feb 24, 2009 at 08:48:35PM -0800, Mike Bird wrote:
Package: e2fsprogs
Version: 1.41.3-1
Severity: minor
tune2fs -m -1 /dev/foo should be an error.
Thanks for reporting this bug. I've committed a fix for this in the
git repository.
- Ted
commit 8d8224550c1f5b5c77afbf5acd95f73979276a0a
Author: Theodore Ts'o ty...@mit.edu
Date: Fri Mar 6 02:23:59 2009 -0500
mke2fs, tune2fs: Do not allow the reserved_ratio to be negative
Add a check to make sure the argument to the -m option (which
specifies the reserved ratio) is greater than zero.
Addresses-Debian-Bug: #517015
Signed-off-by: Theodore Ts'o ty...@mit.edu
diff --git a/misc/mke2fs.c b/misc/mke2fs.c
index 746d973..15948e0 100644
--- a/misc/mke2fs.c
+++ b/misc/mke2fs.c
@@ -1260,7 +1260,8 @@ static void PRS(int argc, char *argv[])
break;
case 'm':
reserved_ratio = strtod(optarg, tmp);
- if (reserved_ratio 50 || *tmp) {
+ if ( *tmp || reserved_ratio 50 ||
+reserved_ratio 0) {
com_err(program_name, 0,
_(invalid reserved blocks percent -
%s),
optarg);
diff --git a/misc/tune2fs.c b/misc/tune2fs.c
index 887a702..d779611 100644
--- a/misc/tune2fs.c
+++ b/misc/tune2fs.c
@@ -720,7 +720,8 @@ static void parse_tune2fs_options(int argc, char **argv)
break;
case 'm':
reserved_ratio = strtod(optarg, tmp);
- if (*tmp || reserved_ratio 50) {
+ if (*tmp || reserved_ratio 50 ||
+ reserved_ratio 0) {
com_err(program_name, 0,
_(bad reserved block ratio - %s),
optarg);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516820: e2fsck won't fix a filesystem with a broken block bitmap
Hm, I wish you could have grabbed the output of dumpe2fs on the parition before you ran the old e2fsck. That would have been very helpful indeed. The change in question is this one: commit 009c02baf90a55b4b2d9c9e3d0a4cfc3e2531640 Author: Theodore Ts'o ty...@mit.edu Date: Thu Jul 10 16:35:05 2008 -0400 Make ext2fs_check_desc() more stringent to force use of backup superbocks E2fsck could to do more damage to a filesystem by trying to relocate inode tables due to corrupted block group descriptors, and the relocation could seriously damage the filesystem. This patch enhances ext2fs_check_desk() so it detects more self-inconsistent block group descriptors, including the cases where e2sck might be tempted to relocate the inode table, and reports the block group descriptors as invalid; this will cause e2fsck to attempt to use the backup superblocks, which hopefully have not been trashed. Addresses-Sourceforge-Bug: #1840291 Signed-off-by: Theodore Ts'o ty...@mit.edu And yes, it was intentional that it did what it did; basically, you got lucky because the older e2fsck could have seriously screwed up your filesystem to the point where seriously data loss could have occurred (you do keep regular backus, right?). What puzzles me is how come you got as far as you did with the first (boot-time) fsck: During a routine filesystem check at boot, e2fsck discovered the following: # /dev/vg2/backuppc has gone 264 days without being checked, # check forced. # /dev/vg2/backuppc: Group 15625's block bitmap at 512001023 conflicts # with some other fs block. # /dev/vg2/backuppc: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. # (i.e., without -a or -p options) The corruption reported when you ran fsck manually, to wit: # e2fsck 1.41.3 (12-Oct-2008) # e2fsck: Group descriptors look bad... trying backup blocks... # e2fsck: Bad magic number in super-block while trying to open # /dev/vg2/backuppc Should have shown up at the boot-time fsck, unless somehow the filesystem was further corrupted after (or during) the initial boot-time fsck run. Worse yet, whatever corruption you had apparently had spread to your backup blocks, which is also very wrong. E2fsck is only supported to write to the master superblock only until it is sure everything is consistent. I'll have to try to play around with some test filesystems to see if I can reproduce what you saw. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511207: e2fsprogs-udeb: mkfs.ext4 symlink missing
tags 511207 +pending thanks On Thu, Jan 08, 2009 at 02:21:18PM +, Colin Watson wrote: Package: e2fsprogs-udeb Version: 1.41.3-1 Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch jaunty In order to support ext4 in d-i (which I'm working on now), we need the /sbin/mkfs.ext4 symlink. The obvious trivial patch to add this is attached. Thanks, I've applied this to the e2fsprogs git SCM. - Ted -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509893: e2fsprogs: mkfs.ext4 produces unusable filesystem
On Sun, Dec 28, 2008 at 04:33:28PM +0100, Christoph Thomas wrote:
Package: e2fsprogs
Version: 1.41.3-1
Followup-For: Bug #509893
EXT4-fs: dm-5: Filesystem with huge files cannot be mounted read-write
without CONFIG_LSF.
Is there a particular reason why you are choosing to build your kernel
without CONFIG_LSF? This is really more of a kernel configuration
problem than anything else. Unfortunately there is no way for mke2fs
to know whether or not the user has disabled CONFIG_LSF in their
kernel.
If you must disable CONFIG_LSF (it saves a massive 4 bytes per inode),
you can create the filesystem with mke2fs -O ^huge_file. Or you can
edit /etc/mke2fs.conf. Just remove huge_file, from the
configuration stanza:
[fs_types]
ext4 = {
features =
has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
inode_size = 256
}
It may be possible to enhance the kernel to allow mounting a
filesystem with huge_file, but to force the system to fail open() or
stat() operations for files that are bigger than 2TB, and to prohibit
creating files larger than 2TB, but this would be a kernel fix, and
not anything we can do in mke2fs.
For I'm going to have to treat this as either a kernel or mke2fs.conf
misconfiguration.
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#509893: e2fsprogs: mkfs.ext4 produces unusable filesystem
On Sat, Dec 27, 2008 at 03:51:30PM +0100, Christoph Thomas wrote:
Package: e2fsprogs
Version: 1.41.3-1
Severity: normal
Tags: patch
Hello,
due to an error in the confiuration /etc/mke2fs.conf it is not
possible to mount an ext4 /ext4dev fs after creation.
Line 12 / 16 use the unknown featuer huge_file instead of large_file
Wrong:
features =
has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
Correct:
features =
has_journal,extents,large_file,flex_bg,uninit_bg,dir_nlink,extra_isize
The huge_file feature is a very valid ext4 filesystem feature. In
fact, it is necessary if you want to be able create files larger than
2TB.
tytso.r...@closure {/usr/projects/linux/base}, level 2 [master]
574# dumpe2fs -h /dev/thunk/testext4 | grep features
dumpe2fs 1.41.3 (12-Oct-2008)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
tytso.r...@closure {/usr/projects/linux/base}, level 2 [master]
575# mount -t ext4 /dev/thunk/testext4 /mnt
tytso.r...@closure {/usr/projects/linux/base}, level 2 [master]
576# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/thunk-testext4
31729 4491 25600 15% /mnt
tytso.r...@closure {/usr/projects/linux/base}, level 2 [master]
577# umount /mnt
It works just fine for me.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507581: e2fsprogs: Build-Depend on libexception-class-perl needs explicit relation
On Tue, Dec 02, 2008 at 02:45:17PM +0200, Eric Pozharski wrote: Package: e2fsprogs Version: 1.088-1 Severity: normal Accidental build against stable Blibexception-class-perl (1.21-1) discovered that BPerl::Critic prerequires BException::Class explicitly. It needs 1.23 at least. Buildlog in attach. 1.24-1 is OK. Um, I think you got the wrong package. Here. I suspect the right package is libperl-critic-perl, but I'm not 100% sure - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503057: mkinitfs fails in /usr/share/initrd-tools/scripts/e2fsprogs
tags 503057 +pending thanks Thanks for bug report and for the patch to fix things. I've committed it into the e2fsprogs source tree for updating. I'm guessing this blows up the ability to make initrd's on x86_64 systems, so it would be worthwhile to apply for an freeze exception for this package, yes? (Actually, I have a set of relatively critical bug fixes that should probably go into a Lenny upgrade, although I know this gets painful since it impacts the d-i team as well.) - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502583: scary messages in dmesg
On Tue, Oct 21, 2008 at 08:15:10AM -0200, Rogério Brito wrote: On Oct 20 2008, Alexandre Lymberopoulos wrote: It's not a memory stick, it's a hard disk with ext3 file system. I just plugged it it and the disk was automatically mounted in /dev/ext3 with no abnormal messages in dmesg. Ok, this far. That weird messages appeared when I unpplugged the disk (without umounting it, as it should be done when using usbmount, right?). Did you sync the device? From the message, it seems that some data were to be written to the device, but the device was already gone by that time, but I'm not a specialist on the filesystem subsystem and perhaps others could say more about it. A patch to suppress the WARN information will be in 2.6.28 when the user does something stupid (i.e., yank out a USB stick without unmounting the filesystem first). This was done mainly to suppress the scary message in dmesg, which on distributions that support uploading such messages to http://www.kerneloops.org for analysis, was cluttering the reports. However, the patch does not make it any *safer* to uncerimoniously yank out a USB stick without unmounting it first. This can still lead to data loss, unless you're *sure* that no process is writing to the stick and you issued the sync command, and you know enough time has passed so all of the data has been written to the USB stick. [39071.160167] Buffer I/O error on device sda1, logical block 1545 [39071.160170] lost page write due to I/O error on sda1 [39071.160184] Buffer I/O error on device sda1, logical block 1545 [39071.160187] lost page write due to I/O error on sda1 These errors you'd still get, since these messages are the sound of users' data being irretrivably being lost. Well, it is a bug. It just needs more investigation to see where the bug lies. I don't know if you would call it a bug or not. Fundamentally, yanking out a USB stick without unmounting it first is dangerous, and can lead to data loss. Printing the stack trace when this happens implies it's a problem which can be fixed by a developer, so perhaps that could be considered a bug, and in any case, that should be fixed in 2.6.28. (I'm pretty sure akpm has sent the ext3 version of that patch to Linus by now, but if not, it should make the 2.6.28 merge window.) If you see lost page write due to I/O error, then you will have lost data due to premature removal of the USB stick, and fundamentally *that* bug exists between the keyboard and the chair. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502583: scary messages in dmesg
On Tue, Oct 21, 2008 at 12:35:00PM -0200, Rogério Brito wrote: I don't know if you would call it a bug or not. Fundamentally, yanking out a USB stick without unmounting it first is dangerous, and can lead to data loss. At least sync'ing... I'm loath to suggest just syncing, because if there is some program still writing to the USB stick (example: you fire up openoffice and ask it to export to PDF. That command returns instantly, and the PDF export happens in the background --- as you will discover if you try to exit OpenOffice. Well, if a user doesn't try to exit OpenOffice, and just uses the sync command, they could still end up trashing data. Also note that for older flash drives, pulling the power while it is writing could potentially lead to corruption of the USB stick's flash translation layer (FTL), which could cause the device to become totally non-functional. It's for that reason that one particular Digital SLR's stop writing to the compact flash card the instant the access door to the flash card is opened, throwing away all of the last 7-8 pictures in the digital camera's write buffer. I'm assuming they did this because some users ejected the flash card while it was writing leading to loss of the flash card plus *all* of the pictures on the flash card, and they decided the risk of having a Very Unhappy User was worth the tradeoff of throwing away only the recently taken photographs that hadn't made it onto the card yet. If you have a USB stick that has a flashing light to indicate write activity, and you type the sync command, and you wait for the flashing light to stop, and you *know* nothing else might be trying to write to the device, sure it might be safe to eject. But if we have a command-line user who knows enough to type sync into a command-line shell, wouldn't it be better to create a setuid shell command, call it something like usbeject which finds any USB storage device that was auto-mounted (i.e., not mounted manually by the user or via an /etc/fstab entry), and if there is only one such devices, automatically tries to unmount it? If there is more than one such device, it should ask the user (or maybe use lsof to see if there is only one that appears not to be in use), and if it fails, it should print a huge warning message as well as the output of lsof so the user knows which program(s) to close before unmounting the device. Solving this problem for desktop users is harder; probably the best thing you can do is to throw up shame dialog box telling them that they did Something Wrong, and while they may have gotten lucky this time, that next time they should close all programs using the USB storage device, and then right-click on the mounted disk icon and select eject. That's what Windows does, and IIRC, what Mac OS X does; there really isn't much else that can be done. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502323: e2fslibs: typo in changelog entry 1.41.3-1
tags 502323 +pending thanks Thank you for reporting the typo in the changelog; it will be fixed in the next release. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502541: e2fsprogs: blkid returns true even if device is non-existent
On Fri, Oct 17, 2008 at 06:39:55PM +0400, Kondrat Pushkarev wrote: Package: e2fsprogs Version: 1.41.2-1 Severity: critical Justification: breaks unrelated software blkid returns true even if specified device does not exist (it should return 2). This appears to be a new bug in lenny, as the behavior was normal in etch. What software does it break? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502541: e2fsprogs: blkid returns true even if device is non-existent
severity 502541 normal thanks On Fri, Oct 17, 2008 at 10:14:41PM +0400, Peter Bray wrote: Hi Ted, Well, it broke one of my custom boot scripts which relied on the return value to determine if a usb device was up or not. That script broke when I upgraded to lenny, leaving my system temporarily unbootable. Whether it breaks anything in the Debian distribution I don't know, but it seems to me the program ought to behave as documented. Sure, that makes it a bug, and I'll fix it. But breaks unrelated software is not an adequate justification make the bug be severity critical, and certainly not some random boot script. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501974: e2fslibs: Add function to get the number of blocks used by the group table in a given group
On Sun, Oct 12, 2008 at 02:00:19PM +0200, Mike Hommey wrote: There seems to be no such function, which would be equivalent to ext3_bg_num_gdb in fs/ext3/balloc.c in the kernel source. Why would you find such a function useful in a user application? What are you trying to do? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498033: Fix for xzgv scaling crash
tags 498033 +pending
severity 498033 minor
thanks
Andrian,
Thanks for the proposed patch! Actually, you want to check to see if
theimage is NULL before the recursion check; otherwise, the in_routine
variable gets left set non-zero, which disables the command for the
rest of the xzgv run. Also, this is a much more general problem that
affects not just the 'd' command (which you reported), but also the
's'command (which your patch didn't address but which had been
reported by the bug submitter), as well as 'm', 'd', 'f', and a number
of other bugs that try to operate on the currently selected image and
crash if one isn't selected.
Also, since this bug report falls into the Doctor, doctor, it hurts
when I do that --- then don't that!, I've also reprioritized this bug
as minor, since, according to the definition of minor, this bug is
a problem which doesn't affect the package's usefulness, and
certainly NOT a bug which has a major effect on the usability of a
package (the definition of important). Remember, every time you
abuse bug priority levels, Cthulu kills a kitten. :-)
The following patch has been checked into xzgv's source repository to
address the problem.
- Ted
commit beee6e36a62dca10892351e76d156fbd6cb8393b
Author: tytso [EMAIL PROTECTED]
Date: Tue Sep 9 12:58:25 2008 +
Make sure an image has been selected before trying to operate on it
This fixes a core-dumping bug if the user types 's', 'd', 'm', 'f',
'r', or any other keys which cause xzgv to operate on an image if none
is present -- for example, if xzgv is started without any arguments,
and before an image has been selected.
Addresses-Debian-Bug: #498033
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
git-svn-id: https://xzgv.svn.sourceforge.net/svnroot/xzgv/[EMAIL PROTECTED]
03f28338-6b37-0410-8b42-ade5b4edbc38
diff --git a/xzgv/src/main.c b/xzgv/src/main.c
index 69f89d1..04e9358 100644
--- a/xzgv/src/main.c
+++ b/xzgv/src/main.c
@@ -1705,6 +1705,9 @@ void xy_scaling_double(int do_x,int do_y)
static int in_routine=0;
int xtmp=xscaling,ytmp=yscaling,oldxsc=xscaling,oldysc=yscaling;
+/* if there's no image, don't do anything */
+if (!theimage) return;
+
/* if recursed, don't bother */
if(in_routine) return;
in_routine=1;
@@ -1753,6 +1756,9 @@ void xy_scaling_add(int do_x,int do_y)
static int in_routine=0;
int xtmp=xscaling,ytmp=yscaling,oldxsc=xscaling,oldysc=yscaling;
+/* if there's no image, don't do anything */
+if (!theimage) return;
+
/* if recursed, don't bother */
if(in_routine) return;
in_routine=1;
@@ -1801,6 +1807,9 @@ void xy_scaling_halve(int do_x,int do_y)
static int in_routine=0;
int xtmp=xscaling,ytmp=yscaling,oldxsc=xscaling,oldysc=yscaling;
+/* if there's no image, don't do anything */
+if (!theimage) return;
+
/* if recursed, don't bother */
if(in_routine) return;
in_routine=1;
@@ -1852,6 +1861,9 @@ void xy_scaling_sub(int do_x,int do_y)
static int in_routine=0;
int xtmp=xscaling,ytmp=yscaling,oldxsc=xscaling,oldysc=yscaling;
+/* if there's no image, don't do anything */
+if (!theimage) return;
+
/* if recursed, don't bother */
if(in_routine) return;
in_routine=1;
@@ -2102,6 +2114,7 @@ listen_to_toggles=1;
void cb_flip(void)
{
+if (!theimage) return;
RECURSE_PROTECT_START;
backend_flip_vert(theimage);
orient_current_state=orient_state_flip[orient_current_state];
@@ -2112,6 +2125,7 @@ RECURSE_PROTECT_END;
void cb_mirror(void)
{
+if (!theimage) return;
RECURSE_PROTECT_START;
backend_flip_horiz(theimage);
orient_current_state=orient_state_mirror[orient_current_state];
@@ -2122,6 +2136,7 @@ RECURSE_PROTECT_END;
void cb_rot_cw(void)
{
+if (!theimage) return;
RECURSE_PROTECT_START;
/* swap x and y scaling, since the effect if we don't do that
* is of the image mysteriously changing. :-)
@@ -2136,6 +2151,7 @@ RECURSE_PROTECT_END;
void cb_rot_acw(void)
{
+if (!theimage) return;
RECURSE_PROTECT_START;
backend_rotate_acw(theimage);
orient_current_state=orient_state_rot_acw[orient_current_state];
@@ -2147,6 +2163,7 @@ RECURSE_PROTECT_END;
void cb_normal_orient(void)
{
+if (!theimage) return;
RECURSE_PROTECT_START;
if(orient_current_state!=0)
{
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498033: Fix for xzgv scaling crash
On Tue, Sep 09, 2008 at 11:32:25PM +1000, Trent W. Buck wrote: On Tue, Sep 09, 2008 at 08:59:02AM -0400, Theodore Tso wrote: Also, since this bug report falls into the Doctor, doctor, it hurts when I do that --- then don't that!, The situation is that I do this: xzgv `mainline -v -c @ | grep Saved | cut -d\ -f 2` The mainline -v -c @ | grep Saved | cut -d\ -f 2 pipeline returns a list of files, right? If xzgv is given a list of files it should just display the files right away, and not give you an empty image. So for example, if I use the command xzgv /home/tytso/images/chalk/*.jpg, I immediately get the first image displayed, and 's' will simply scale up the image. Your reproduction case only mentioned what happened if xzgv was started without any arguments. In fact, I can only get this bug to trigger if xzgv is started with no arguments, or if xzgv is started with a single argument, and that argument points at a directory instead of a file. So I'm a bit confused how you are running into this situation given the scenario you have described. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498033: Fix for xzgv scaling crash
On Wed, Sep 10, 2008 at 12:41:19AM +1000, Trent W. Buck wrote: If xzgv is given a list of files it should just display the files right away, and not give you an empty image. [...] So I'm a bit confused how you are running into this situation given the scenario you have described. Hmm, that's true; but I was typing s before it managed to display the first image. I can reproduce this by running xzgv `find Comics -type f` ...and holding s while xzgv starts up. Ah, OK. Thanks, that's good to know. I'm fairly confident the patch should address this scenario as well, since basically what's happening is that the callback function is getting called before the theimage global variable is set correctly, and the patch will catch this case as well. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498101: Bug#49810[0123]: various e2fsprogs man page spelling mistakes
tags 498100 +pending tags 498101 +pending tags 498102 +pending tags 498103 +pending thanks Thanks for pointing these spelling errors. I've committed fixes to all of them to the maint branch of the e2fsprogs git repository. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496956: Re_Re_ Bug#496956_ e2fsprogs_ e2fsck does not complete check and reboots system
Hi, Any progress on this your being able to figure out what is going on your system? As I said, this is almost certainly not an e2fsprogs bug, so I will likely soon close this bug. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497619: netinst: fail to create ext3 file systems
On Thu, Sep 04, 2008 at 04:33:20PM +0200, Frans Pop wrote: Looking at the diff between the Lenny and Sid versions, I wonder at the dropped build dependencies on libdevmapper/libselinux1. From the release notes: The blkid library is now much more efficiently handling devicemapper devices, mainly by no longer using the devicemapper library. This can speed up access for systems with a large number of device mapper devices. I also now notice the build dependency on dietlibc, which is a complete unknown for D-I. I wonder if the real reason for the broken dependencies may be there. D-I uses libc... No, dietlibc is only used when building e2fsck.static, to further shrink the size of the generated binary. The udeb's don't use e2fsck.static at all; it's only used for the e2fsck-static package. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497619: netinst: fail to create ext3 file systems
On Thu, Sep 04, 2008 at 12:55:23AM +0200, Frans Pop wrote: The Depends on e2fsprogs-udeb are e2fslibs (= 1.41.0), libblkid1 (= 1.37), libc6 (= 2.7-1), libcomerr2 (= 1.37), libuuid1 (= 1.37) The e2fsprogs-udeb used to depend on just libblkid1-udeb and libc6, all the other dependencies are completely new. Looks like the dependencies have randomly changed because of a serious packaging error with the most recent upload(s) of the latest upstream of e2fsprogs. This was caused by the introduction of the use dpkg-gensymbols in 1.41.1-2, I suspect. I'll fix the control file to manually specify the dependencies for the udeb packages. Reassigning to that package. Ted: please fix with highest urgency as this completely breaks all daily builds of the Debian Installer which are essential for pre-release testing. TIA. I will, although I'm travelling at the moment so I probably won't be able to upload new packages until tomorrow night or Friday morning. I'll get to it as soon as I can. Stupid question, though --- I thought D-I would be doing builds against testing, not unstable? As much as I would like to get the quite large number of bug fixes that are in the 1.41.1 maintenance release into Lenny, I thought the Lenny Freeze ship had sailed long ago (to horribly Vita-Mix a metaphor). Lenny currently has e2fsprogs 1.41.0-3, which would not have this problem. I'm a bit surprised that Debian Installer would be doing daily builds against what is currently in unstable. - Ted P.S. Here are some of the bug fixes which are in 1.41.1 that are not in 1.41.0 that might be especially relevant: * Fix dumpe2fs -i and debugfs -i. (Closes: #495830) * Fix blkid cache validation and some possible blkid crashes (Closes: #493216) * Fix filefrag's ideal extent calculation (Closes: #458306) * Fix resize2fs incorrectly managing directory in-use counts when shrinking filesystems and directory inodes need to be moved. (and a whole bunch of ext4-related fixes, which are important to people trying out ext4, but not that relevant to most Debian stable users.) But in any case, I had not planned to try to ask for a Freeze exception, precisely because I didn't want to cause problems for some of its downstream dependencies, such as the d-i. My thought was to wait until a future update of Lenny, and backport just the most critical non-ext4 related bugs at that time --- especially if Lenny is releasing in September. That's why I was a bit surprised that the d-i was depending on the e2fsprogs in unstable. If I had known about that, maybe I would have uploaded the 1.41.1 releases into experimental. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496956: Re_Re_ Bug#496956_ e2fsprogs_ e2fsck does not complete check and reboots system
Well, the fact that 'dd' can cause the system to crash, at least with some kernels, makes it seem pretty conclusive to me. My guess is that it is some combination of kernel and hardware problem, and exactly when it happens may be triggered by timing or order of disk accesses, or something very strange like that. Keep in mind that thousands, if not millions of Linux users have used IDE drives without problems, including being able to dd'ing disk images around. And even if this is a problem that has only showed up in 2.6.26, I would have thought that there would have been plenty of other people reporting regressions like this. So this is why I am very suspicious that there is something unique about your system. Can you try removing the hard drive a hooking it up to another computer, and seeing if the problem persists? Can you try taking another IDE disk and hooking it up to your computer, and see if the problem persists on the new hard drive. Have you checked the IDE cable to make sure it hasn't shaken loose on one side or another? Yes, the fact that it seems to die reliably at the same point of fsck on both systems tends to lead one to believe it's not a flaky cable, but I've seen enough hardware-induced problems that look very much like software issues I've learned to be very cautious. Another thing to try is hooking up a serial console; it may be that there is some kernel crash message that is disappearing so quickly that you can't see it on the screen, but if you use a serial console, it might be reveal itself. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497010: libuuid1: install fails when group is in ldap and local
tags 497010 +pending thanks On Fri, Aug 29, 2008 at 05:18:02PM +1000, Alex Samad wrote: My group libuuid is in my ldap DB, install of package fails unless I place it in my /etc/group file Whilst checking the postinst file I also notice you check for user in /etc/passwd - my user is kept in ldap, maybe a check against gentent passwd would be better ! Thanks, the following patch should address your issue. - Ted commit 5e10c242cfe5ae02d5326bd094d1ebdf347ff873 Author: Theodore Ts'o [EMAIL PROTECTED] Date: Fri Aug 29 19:53:34 2008 -0400 debian: Fix postinstall scripts when the user/group is in LDAP Addresses-Debian-Bug: #497010 Signed-off-by: Theodore Ts'o [EMAIL PROTECTED] diff --git a/debian/libuuid1.postinst b/debian/libuuid1.postinst index 27ca205..5336fcf 100644 --- a/debian/libuuid1.postinst +++ b/debian/libuuid1.postinst @@ -24,9 +24,10 @@ if test -z $LAST_SYSTEM_GID; then LAST_SYSTEM_GID=999 fi -groupadd -f -K GID_MIN=$FIRST_SYSTEM_GID -K GID_MAX=$LAST_SYSTEM_GID libuuid - -if ! grep -q libuuid /etc/passwd; then +if ! getent group | grep -q libuuid; then + groupadd -f -K GID_MIN=$FIRST_SYSTEM_GID -K GID_MAX=$LAST_SYSTEM_GID libuuid +fi +if ! getent passwd | grep -q libuuid; then useradd -d /var/lib/libuuid -K UID_MIN=$FIRST_SYSTEM_UID -K UID_MAX=$LAST_SYSTEM_UID -g libuuid libuuid fi diff --git a/debian/uuid-runtime.postinst b/debian/uuid-runtime.postinst index 36cd7b9..3c1adb6 100644 --- a/debian/uuid-runtime.postinst +++ b/debian/uuid-runtime.postinst @@ -1,8 +1,10 @@ #!/bin/sh set -e +if ! getent group | grep -q libuuid; then groupadd -f -K GID_MIN=1 -K GID_MAX=999 libuuid -if ! grep -q libuuid /etc/passwd; then +fi +if ! getent passwd | grep -q libuuid; then useradd -d /var/lib/libuuid -K UID_MIN=1 -K UID_MAX=499 -g libuuid libuuid fi chown libuuid:libuuid /usr/sbin/uuidd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496956: e2fsprogs: e2fsck does not complete check and reboots system
severity 496956 normal thanks Sounds like your kernel is crashing when a certain part of the disk is being accessed. If a userspace program can cause a system crash, by definition that's a kernel bug, not a userspace bug. The fact that the system is crashing on you any way if you abort e2fsck with ctrl-c, drop into maintenance mode, and then type ctrl-d to continue rebooting without checking the filesystem shows this isn't an e2fsprogs problem. If it's not crashing when you boot a Knoppix CD, yes, it could be because you're using a much older version of e2fsprogs --- but remember, the Knoppix CD is also using a significantly older kernel, too. I don't know if this is caused by some kind of hardware fault which the kernel isn't handling properly, or this is a kernel bug which was introduced when you upgraded to a newer kernel, but that is what I would suspect. 1) What kernel version are you running? 2) What kind of disk drive are you using for your filesystem? What kind of disk controller are you using? Is it SCSI, IDE, SATA, etc.? 3) What happens if you run this command from maintenance mode: dd if=/dev/hda5 of=/dev/null bs=32k In case 3), e2fsck start showing triplets of data (using -C 1 option) starting from 1 1 734 and it always reboots shortly after the triplet 1 64 734 as showed below: The fact that it always reboots around the time when e2fsck is checking block group #64 (out of the 734 block groups on that filesystem) strongly suggests some kind of hardware fault. The hardware is returning some kind of error, which the kernel can't handle and it is causing it to panic and reboot. That's why I suggested the dd command above; it would demontrate the problem without any use of e2fsprogs. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495830: e2fsprogs: e2image/debugfs -i not working?
tags 495830 +pending thanks On Wed, Aug 20, 2008 at 03:30:34PM -0400, Dale Harris wrote: Package: e2fsprogs Version: 1.41.0-3 Severity: normal Perhaps I'm just doing this wrong, but it seems it should work: arrr:/test# e2image /dev/rootvg/tmplv tmplv.img e2image 1.41.0 (10-Jul-2008) arrr:/test# debugfs -d /dev/rootvg/tmplv -i tmplv.img debugfs 1.41.0 (10-Jul-2008) tmplv.img: Attempt to read block from filesystem resulted in short read while reading inode bitmap debugfs: quit Yep, that was a bug I introduced in e2fsprogs 1.41.0. Thanks for pointing that out. Here's the fix I've checked into the maint branch of e2fsprogs; it will be in the next release. - Ted commit 57fd39e94339f6a60f3c1df0818e5305cdbb7569 Author: Theodore Ts'o [EMAIL PROTECTED] Date: Thu Aug 21 17:56:44 2008 -0400 libext2fs: Fix reading bitmaps from e2image files Fix a signed vs. unsigned bug that was accidentally introduced in commit f1f115a7, which was introduced in e2fsprogs 1.41.0 Addresses-Debian-Bug: #495830 Signed-off-by: Theodore Ts'o [EMAIL PROTECTED] diff --git a/lib/ext2fs/rw_bitmaps.c b/lib/ext2fs/rw_bitmaps.c index b7fda5a..d3bdc2a 100644 --- a/lib/ext2fs/rw_bitmaps.c +++ b/lib/ext2fs/rw_bitmaps.c @@ -139,8 +139,8 @@ static errcode_t read_bitmaps(ext2_filsys fs, int do_inode, int do_block) char *block_bitmap = 0, *inode_bitmap = 0; char *buf; errcode_t retval; - unsigned int block_nbytes = EXT2_BLOCKS_PER_GROUP(fs-super) / 8; - unsigned inode_nbytes = EXT2_INODES_PER_GROUP(fs-super) / 8; + int block_nbytes = EXT2_BLOCKS_PER_GROUP(fs-super) / 8; + int inode_nbytes = EXT2_INODES_PER_GROUP(fs-super) / 8; int csum_flag = 0; int do_image = fs-flags EXT2_FLAG_IMAGE_FILE; unsigned intcnt; @@ -169,7 +169,7 @@ static errcode_t read_bitmaps(ext2_filsys fs, int do_inode, int do_block) if (retval) goto cleanup; retval = ext2fs_get_mem(do_image ? fs-blocksize : - block_nbytes, block_bitmap); + (unsigned) block_nbytes, block_bitmap); if (retval) goto cleanup; } else @@ -182,7 +182,7 @@ static errcode_t read_bitmaps(ext2_filsys fs, int do_inode, int do_block) if (retval) goto cleanup; retval = ext2fs_get_mem(do_image ? fs-blocksize : - inode_nbytes, inode_bitmap); + (unsigned) inode_nbytes, inode_bitmap); if (retval) goto cleanup; } else -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493216: labeled mounts break with recent udev
On Fri, Aug 01, 2008 at 02:13:31PM +0200, Marco d'Itri wrote: On Aug 01, Guido Günther [EMAIL PROTECTED] wrote: Reason is that findfs and friends query /etc/blkid.tab to find the device matching the UUID. Since blkid.tab has things like /dev/.static/dev/hda7 (no idea why blkid picked that one in favour of /dev/hda7) this breaks the mount. I am sorry to hear that blkid has been broken for a long time. Can you someone explain to me what the heck the /dev/.static/dev/hda7 hack is all about? I don't get those crazy names in my /etc/blkid.tab file... - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493216: labeled mounts break with recent udev
severity 493216 important thanks On Fri, Aug 01, 2008 at 08:24:38AM -0400, Theodore Tso wrote: On Fri, Aug 01, 2008 at 02:13:31PM +0200, Marco d'Itri wrote: On Aug 01, Guido Günther [EMAIL PROTECTED] wrote: Reason is that findfs and friends query /etc/blkid.tab to find the device matching the UUID. Since blkid.tab has things like /dev/.static/dev/hda7 (no idea why blkid picked that one in favour of /dev/hda7) this breaks the mount. I am sorry to hear that blkid has been broken for a long time. Can you someone explain to me what the heck the /dev/.static/dev/hda7 hack is all about? OK, now I know what /dev/.static is, but I still don't get those names in my /etc/blkid.tab file, and I'm not sure how they got into yours. It certainly isn't the name which is used by default, so I'm not sure how they would have gotten into the blkid file at all in the first place. All I can think of is that at some point someone accidentally typed the command blkid /dev/.static/dev/sda7 while running as root, and this errant got stuck in your /etc/blkid.tab file. I see (and will fix) the bug which causes blkid to not fix this problem automatically, but this is something which I've never seen show up in peoples /etc/blkid.tab files in the normal course of events. If you run the command the command blkid -g as root the errant /dev/.static entry will go away. cp /dev/null /etc/blkid.tab will also make the problem go away, and I haven't been able to find a way to make blkid put those names into /etc/blkid.tab unless forced via explicit human intervention. Am I right in assuming that udev 0.125 is not something that you guys are planning on trying to slide into Lenny? - Ted P.S. The huge bug with libvolumeid is that it relies on /dev/disk/by-*, which only gets updated at boot-time. So freshly created filesystems, swap spaces, etc., won't be foud by libvolumeid until after you reboot. That is so hugely windows-eque that I'm amazed users of libvolumeid put up with it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493216: labeled mounts break with recent udev
On Fri, Aug 01, 2008 at 03:30:08PM +0200, Marco d'Itri wrote: On Aug 01, Theodore Tso [EMAIL PROTECTED] wrote: Am I right in assuming that udev 0.125 is not something that you guys are planning on trying to slide into Lenny? No, both me and the d-i team definitely expect it to be in lenny. Ok, I'll do a poll to see how common a problem this is. As I said, I haven't seen this show up on most systems. P.S. The huge bug with libvolumeid is that it relies on /dev/disk/by-*, which only gets updated at boot-time. So freshly created filesystems, swap spaces, etc., won't be foud by libvolumeid until after you reboot. That is so hugely windows-eque that I'm amazed users of libvolumeid put up with it. Either you teach the kernel to know when a filesystem has been created, or you teach mkfs etc. to tell the kernel that a filesystem has been created (echo change /syc/block/sda4/uevent). Or you use libblkid. :-) - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491620: e2fsprogs: Inconsistent max size for journal in POT file
tags 491620 +pending thanks On Sun, Jul 20, 2008 at 11:07:06PM +0100, Pedro Ribeiro wrote: In POT file there are two different references to the maximum journal size, the first in a message near line 4402 (message from misc/util.c:228) and the second one in line 4424 (message from misc/util.c:265). Thanks for pointing this out! I've fixed in the repository for the next maintenance release of e2fsprogs. The correct number is the larger one (1024 blocks). - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486528: Please enhance mke2fs to respect the RECOMP area of CMS minidisks
On Wed, Jul 16, 2008 at 11:16:47AM +0200, Peter 1 Oberparleiter wrote: Ok, now I understand the core of your point. I must admit that with my Linux background I haven't been aware of this association at all. I'm wondering if some kind of documentation would help clear up any confusion about the non-standard way that Linux prepares CMS formatted DASDs for IPL.. Yes, I think some documentation here would be very helpful. Part of the problem is that the Mainframe acronyms and way things are booted are so different from the way Linux names its concepts and has its own acronyms, that simply communcation can be hard. A How zLinux boots paper which describes not only how Linux does things, but how its fits into the VM/CMS/zOS world and compares and contrasts those booth paths with Linux's, and with a nice glossary that translates between the two, would no doubt be highly helpful. Stephen, maybe this is an area where you might be willing to help? Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487758: Please reopen the bug - your patch is only a partly success
Holger, It is deliberate that the cache is not flushed after a device is remoed. So just because you are seeing stale entries in blkid does *not* mean that there are any problems. Before an entry is used, it will be validated. Keep in mind that blkid's main function is not to show you all of the devices on your system; it is to show you the current contents of the blkid cache. We do keep the last known device where a filesystem is found so that when doing a lookup by LABEL, we try to last known device name *first*, and if it is found there, we return it; otherwise, we have to scan every single device in the system. The reason for the blkid cache is that if you have potentially tens of thousands of devices (for example, as might be the case on a large-end storage array from EMC or IBM). Or suppose you have a hundred CD-ROM drivers with a set of CDR's semi-permanently installed in each drive. You might not want to spin up each and every driver just to verify the contents of the blkid cache is correct. On such a system blkid -g can be quite slow. You don't want to do it all the time. As a result, what the code currently does is when you *lookup* a specific device, which is what mount or fsck does when you give it a specifier such as mount LABEL=my-pictures, it will at that point look up an entry in the blkid cache, and then verify it to make sure its contents are correct. You can also simulate this by using the command blkid -l -t LABEL=my-pictures. The bottom line is that just because a device that is no longer on your system shows up blkid is not an indication of a bug. If, while running as root, blkid -l -t LABEL= or blkid -l -t UUID=xxx returns the wrong value, please let me know. It shouldn't at this point, though. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490540: Segmentation fault on 'blkid -c /dev/null -t LABEL=usbdos'
On Sat, Jul 12, 2008 at 10:29:46AM -0400, Theodore Tso wrote: On Sat, Jul 12, 2008 at 03:45:25PM +0200, Harald Dunkel wrote: blkid -c /dev/null -t LABEL=usbdos dies with segmentation fault. The labeled filesystem is available, but not mounted. I can't replicate this. Can you replicate it this now? If so, please save the /etc/blkid.tab file to make it easier to replicate. I've done more work looking at this, and even knowing that this was done run as a normal user (and so there would be nothing in the cache, since the unprivileged user wouldn't be able to read any disk devices), I can't reproduce this. Is this a reproducible error for you? Thanks, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490637: e2fsck finds invalid group descriptor checksums every boot
On Sun, Jul 13, 2008 at 06:53:25PM +0930, Kevin Shanahan wrote:
Package: e2fsprogs
Version: 1.41.0-1
Thanks for reporting this bug. I will shortly be releasing a fixed
e2fsprogs with this patch.
- Ted
From 4729455f0a68f2fa0a83ec8460d1d4bccba9dcfa Mon Sep 17 00:00:00 2001
From: Theodore Ts'o [EMAIL PROTECTED]
Date: Sun, 13 Jul 2008 19:03:59 -0400
Subject: [PATCH] libext2fs: Don't check the group checksum when !GDT_CSUM
ext2fs_group_desc_csum_verify() is always checking the bg_checksum (to
make sure it is zero) even when the GDT_CSUM feature is not present.
This is normally OK, but apparently there are filesystems in the wild
where this field has not be initialized to zero.
Addresses-Debian-Bug: #490637
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
lib/ext2fs/csum.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/ext2fs/csum.c b/lib/ext2fs/csum.c
index ce1508e..6a49d8f 100644
--- a/lib/ext2fs/csum.c
+++ b/lib/ext2fs/csum.c
@@ -60,8 +60,10 @@ STATIC __u16 ext2fs_group_desc_csum(ext2_filsys fs, dgrp_t
group)
int ext2fs_group_desc_csum_verify(ext2_filsys fs, dgrp_t group)
{
- if (fs-group_desc[group].bg_checksum !=
- ext2fs_group_desc_csum(fs, group))
+ if (EXT2_HAS_RO_COMPAT_FEATURE(fs-super,
+ EXT4_FEATURE_RO_COMPAT_GDT_CSUM)
+ (fs-group_desc[group].bg_checksum !=
+ext2fs_group_desc_csum(fs, group)))
return 0;
return 1;
--
1.5.6.1.205.ge2c7.dirty
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490527: PS: uid != 0
severity 490540 normal thanks On Sat, Jul 12, 2008 at 03:59:25PM +0200, Harald Dunkel wrote: I ran blkid as a regular user. If I run it as root then the core dump is gone. Surely its OK to decrease the severity of this br. I suspect you filed this against the wrong bug report. You carbon copied bug #490527, but I suspect you meant bug #490540, Segmentation fault on 'blkid -c /dev/null -t LABEL=usbdos'. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490540: Segmentation fault on 'blkid -c /dev/null -t LABEL=usbdos'
On Sat, Jul 12, 2008 at 03:45:25PM +0200, Harald Dunkel wrote: blkid -c /dev/null -t LABEL=usbdos dies with segmentation fault. The labeled filesystem is available, but not mounted. I can't replicate this. Can you replicate it this now? If so, please save the /etc/blkid.tab file to make it easier to replicate. Also, it would be very helpful if you could install the libblkid1-dbg and e2fsprogs-dbg program, and run blkid under gdb, and then when it seg faults, to send me a stack backtrace, using the gdb where command. (Mmm debug packages are *way* cool. I'm so glad I started shipping them for e2fsprogs. :-) Many thanks, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490527: blkid to show whether block device is mounted/in use
On Sat, Jul 12, 2008 at 01:54:08PM +0200, Harald Dunkel wrote: Package: e2fsprogs Version: 1.41.0-1 Severity: wishlist It would be very nice if blkid could tell whether a partition or a device is mounted or in use (e.g. part of a logical volume). Well, that really isn't part of blkid's official function, although I can see why that might be handy. You can tell whether it is part of a logical volume just by looking at the type though: /dev/sda5: UUID=RSl8ms-xTzn-0g7n-dd8N-Pfi7-rB2o-07tkve TYPE=lvm2pv That means it's part of an LVM group. There is also no sure way of knowing whether is mounted or not. Looking at /proc/mounts only works in the current namespace. With linux, there can be multiple namespaces, so there is no guarantee that all mounts are visible in the current namespace. I'll think about adding it as a convenience function, but it will never be guaranteed to be accurate. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490527: blkid to show whether block device is mounted/in use
tag 490527 +pending
thanks
On Sat, Jul 12, 2008 at 01:33:48PM -0400, Theodore Tso wrote:
On Sat, Jul 12, 2008 at 01:54:08PM +0200, Harald Dunkel wrote:
Package: e2fsprogs
Version: 1.41.0-1
Severity: wishlist
It would be very nice if blkid could tell whether a partition
or a device is mounted or in use (e.g. part of a logical volume).
The following should implement what you desire.
- Ted
From 60dfb6164c4a9d70134536b21bf4a46a877d4127 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o [EMAIL PROTECTED]
Date: Sat, 12 Jul 2008 22:06:30 -0400
Subject: [PATCH] blkid: Add new option -L which pretty-prints the device list
Also accessed via -o list, this new output format is much more
user-friendly and lists whether or not a particular device is mounted.
Addresses-Debian-Bug #490527
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/Makefile.in |4 +-
misc/blkid.8.in |8 ++-
misc/blkid.c | 166 --
3 files changed, 170 insertions(+), 8 deletions(-)
diff --git a/misc/Makefile.in b/misc/Makefile.in
index 7232c15..e48a276 100644
--- a/misc/Makefile.in
+++ b/misc/Makefile.in
@@ -61,8 +61,8 @@ DEPLIBS= $(LIBEXT2FS) $(LIBCOM_ERR)
STATIC_LIBS= $(STATIC_LIBEXT2FS) $(STATIC_LIBCOM_ERR)
STATIC_DEPLIBS= $(STATIC_LIBEXT2FS) $(STATIC_LIBCOM_ERR)
-LIBS_BLKID= $(LIBBLKID) $(LIBUUID)
-DEPLIBS_BLKID= $(DEPLIBBLKID) $(DEPLIBUUID)
+LIBS_BLKID= $(LIBBLKID) $(LIBUUID) $(LIBEXT2FS)
+DEPLIBS_BLKID= $(DEPLIBBLKID) $(DEPLIBUUID) $(LIBEXT2FS)
LIBS_E2P= $(LIBE2P) $(LIBCOM_ERR)
DEPLIBS_E2P= $(LIBE2P) $(LIBCOM_ERR)
diff --git a/misc/blkid.8.in b/misc/blkid.8.in
index 8a4e971..408dbc9 100644
--- a/misc/blkid.8.in
+++ b/misc/blkid.8.in
@@ -11,7 +11,7 @@ blkid \- command\-line utility to locate/print block device
attributes
.SH SYNOPSIS
.B blkid
[
-.B \-ghlv
+.B \-ghlLv
]
[
[
@@ -90,10 +90,16 @@ parameter may be
.IR value ,
(only print the value of any tags printed by
.BR blkid)
+.IR list ,
+(print the devices in a user friendly format)
or
.I device
(only print the device name).
.TP
+.B \-L
+Print the devices in a user-friendly list format. This is the
+equivalent of using the option \fB-o list\fR.
+.TP
.B \-s
Show only the tags for each (specified) device that match
.IR tag .
diff --git a/misc/blkid.c b/misc/blkid.c
index c0fda73..d64f4ce 100644
--- a/misc/blkid.c
+++ b/misc/blkid.c
@@ -11,7 +11,17 @@
#include stdio.h
#include stdlib.h
+#include unistd.h
#include string.h
+#ifdef HAVE_TERMIOS_H
+#include termios.h
+#endif
+#ifdef HAVE_TERMIO_H
+#include termio.h
+#endif
+#ifdef HAVE_SYS_IOCTL_H
+#include sys/ioctl.h
+#endif
#ifdef HAVE_GETOPT_H
#include getopt.h
#else
@@ -22,7 +32,9 @@ extern int optind;
#define OUTPUT_VALUE_ONLY 0x0001
#define OUTPUT_DEVICE_ONLY 0x0002
+#define OUTPUT_PRETTY_LIST 0x0004
+#include ext2fs/ext2fs.h
#include blkid/blkid.h
const char *progname = blkid;
@@ -38,8 +50,8 @@ static void usage(int error)
print_version(out);
fprintf(out,
- usage:\t%s [-c file] [-ghl] [-o format]
- [-s tag] [-t token]\n[-v] [-w file] [dev ...]\n
+ usage:\t%s [-c file] [-ghlLv] [-o format]
+ [-s tag] [-t token]\n[-w file] [dev ...]\n
\t-c\tcache file (default: /etc/blkid.tab, /dev/null = none)\n
\t-h\tprint this usage message and exit\n
\t-g\tgarbage collect the blkid cache\n
@@ -78,6 +90,133 @@ static void safe_print(const char *cp, int len)
}
}
+static int get_terminal_width(void)
+{
+#ifdef TIOCGSIZE
+ struct ttysize win;
+#endif
+#ifdef TIOCGWINSZ
+ struct winsize win;
+#endif
+const char *cp;
+
+#ifdef TIOCGSIZE
+ if (ioctl (0, TIOCGSIZE, win) == 0)
+ return (win.ts_cols);
+#endif
+#ifdef TIOCGWINSZ
+ if (ioctl (0, TIOCGWINSZ, win) == 0)
+ return (win.ws_col);
+#endif
+cp = getenv(COLUMNS);
+ if (cp)
+ return strtol(cp, NULL, 10);
+ return 80;
+}
+
+static int pretty_print_word(const char *str, int max_len,
+int left_len, int overflow_nl)
+{
+ int len = strlen(str) + left_len;
+ int ret = 0;
+
+ fputs(str, stdout);
+ if (overflow_nl len max_len) {
+ fputc('\n', stdout);
+ len = 0;
+ } else if (len max_len)
+ ret = len - max_len;
+ do
+ fputc(' ', stdout);
+ while (len++ max_len);
+ return ret;
+}
+
+static void pretty_print_line(const char *device, const char *fs_type,
+ const char *label, const char *mtpt,
+ const char *uuid)
+{
+ static int device_len = 10, fs_type_len = 7;
+ static int label_len = 8, mtpt_len = 14;
+ static int term_width = -1;
+ int len, w
Bug#457252: Patch for xzgv thumbnail crash
Thanks very much for your patch! My apologies for the delay in getting this patch applied and released. But it's in the 0.9+svn40-1, which I just uploaded into unstable. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490003: e2fsck-static: please add bash-static to shell list
tags 490003 +pending thanks On Wed, Jul 09, 2008 at 10:03:32AM +0200, Yann Dirson wrote: Package: e2fsck-static Version: 1.40.11-1 Severity: wishlist This package recommends a bunch of statically-linked shells, but this list does not include bash-static. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471977: e2fsprogs: Different mke2fs defaults when creating a Hurd-owned partition?
tags 471977 +pending
thanks
On Fri, Mar 21, 2008 at 03:34:45PM +0100, Michael Banck wrote:
I wonder whether it would be possible to tell mk2fs to use different
defaults for block and inode size if a Hurd-owned partition (i.e., the
user passed -o hurd) is requested. The ext2fs server in the Debian
GNU/Hurd distribution can only deal with a blocksize of 4096 right now,
and it requires an inode-size of 128, it apparently does not boot with
anything else. As mke2fs recently changed the default inode-size in
unstable, we get reports from users (plus sometimes users create really
small partitions which get a smaller block size than 4096).
The following patch will be in e2fsprogs 1.41.
Regards,
- Ted
Date: Thu, 10 Jul 2008 09:24:25 -0400
Subject: [PATCH] mke2fs: Dumb down filesystems for GNU Hurd
The Hurd only supports filesystems with a blocksize of 4096 bytes, and
128 byte inodes. It also doesn't understand the journal. So force
the defaults to be something which the Hurd can handle if -o hurd is
specified on the command line.
Addresses-Debian-Bug: #471977
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/mke2fs.c|9 +
misc/mke2fs.conf |4
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/misc/mke2fs.c b/misc/mke2fs.c
index 352e66b..960f67b 100644
--- a/misc/mke2fs.c
+++ b/misc/mke2fs.c
@@ -927,12 +927,19 @@ static char **parse_fs_type(const char *fs_type,
const char *size_type;
struct str_list list;
unsigned long meg;
+ int is_hurd = 0;
if (init_list(list))
return 0;
+ if (creator_os (!strcasecmp(creator_os, GNU) ||
+ !strcasecmp(creator_os, hurd)))
+ is_hurd = 1;
+
if (fs_type)
ext_type = fs_type;
+ else if (is_hurd)
+ ext_type = ext2;
else if (progname) {
ext_type = strrchr(progname, '/');
if (ext_type)
@@ -997,6 +1004,8 @@ static char **parse_fs_type(const char *fs_type,
free(parse_str);
if (profile_type)
free(profile_type);
+ if (is_hurd)
+ push_string(list, hurd);
return (list.list);
}
diff --git a/misc/mke2fs.conf b/misc/mke2fs.conf
index ea6d7bf..2eb4352 100644
--- a/misc/mke2fs.conf
+++ b/misc/mke2fs.conf
@@ -38,3 +38,7 @@
inode_ratio = 4194304
blocksize = -1
}
+ hurd = {
+blocksize = 4096
+inode_size = 128
+ }
--
1.5.6.1.205.ge2c7.dirty
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487849: /sbin/mkfs.ext2: Incorrect description of stripe-width extended option
On Tue, Jun 24, 2008 at 04:29:25PM +0200, Peter Rabbitson wrote: Currently the man-page of mkfs.ext2 reads: ...This is typically be stride-size * N, where N is the number of data disks in the RAID (e.g. RAID 5 N+1, RAID 6 N+2)... which actually should be: ...(e.g. RAID 5 N-1, RAID 6 N-2)... Thanks for pointing this out. The following patch will be in e2fsprogs 1.41. - Ted From 2ac7f06611ea3f7b1fbbc3a778e9bcdab1649a0e Mon Sep 17 00:00:00 2001 From: Theodore Ts'o [EMAIL PROTECTED] Date: Thu, 10 Jul 2008 09:40:48 -0400 Subject: [PATCH] Fix incorrect definition of stripe-width in mke2fs man page Also clarified the definition of the stride-size extended option as well. Addresses-Debian-Bug: #487849 Signed-off-by: Theodore Ts'o [EMAIL PROTECTED] --- misc/mke2fs.8.in |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/misc/mke2fs.8.in b/misc/mke2fs.8.in index 8dc3b6d..dc35549 100644 --- a/misc/mke2fs.8.in +++ b/misc/mke2fs.8.in @@ -191,8 +191,9 @@ following extended options are supported: Configure the filesystem for a RAID array with .I stride-size filesystem blocks. This is the number of blocks read or written to disk -before moving to next disk. This mostly affects placement of filesystem -metadata like bitmaps at +before moving to next disk, which is sometimes referred to as the +.I chunk size. +This mostly affects placement of filesystem metadata like bitmaps at .B mke2fs time to avoid placing them on a single disk, which can hurt the performanace. It may also be used by block allocator. @@ -201,7 +202,8 @@ It may also be used by block allocator. Configure the filesystem for a RAID array with .I stripe-width filesystem blocks per stripe. This is typically be stride-size * N, where -N is the number of data disks in the RAID (e.g. RAID 5 N+1, RAID 6 N+2). +N is the number of data-bearing disks in the RAID (e.g. for RAID 5 there is one +parity disk so N will be the number of disks in the array minus 1). This allows the block allocator to prevent read-modify-write of the parity in a RAID stripe if possible when the data is written. .TP -- 1.5.6.1.205.ge2c7.dirty -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486528: Please enhance mke2fs to respect the RECOMP area of CMS minidisks
On Wed, Jul 09, 2008 at 09:20:52AM -0700, Stephen Powell wrote: The structure I sent to you maps the CMS label record. For FBA devices, the label record is the second 512-byte block of the minidisk. For CKD devices, the label record is cylinder 0, track 0, record 3, which would be the third block of the minidisk. The first four bytes of the CMS label record are always CMS1 in EBCDIC. That would be X'C3D4E2F1'. So here's the problem. The 3rd block of the minidisk (assuming 512 byte blocks), overlaps with the the ext2/3/4 superblock, which lives at byte offset 1024 through 2047. So for CKD devices, it's impossible for the CMS label record and ext2/3/4 to co-exist. Thats a fundamental property of the ext2/3/4 filesystem. This is the fundamental problem with in-band storage of partitioning information, and this is one of the places where the mainframe designers seem to have really screwed up. With Linux, and pretty much all Unix systems, you have the whole disk device /dev/sda, and on that whole disk device, there is a partition table. That partition table is read by OS, which tells it how to divide up the disk, and then each filesystem gets to live in its own partition --- i.e., /dev/sda1, /dev/sda2, etc. There are conventions that the first 1024 bytes should be left alone for the initial blocks of a boot loader, but other than that, the filesystem has free run of its partition --- i.e, it can use the entire disk of /dev/sda1. To have a scheme where you have an RECOMP part of the disk which other filesystems need to somehow have magic knowledge that they need to avoid, and then to put the partition table someplace strange such as offset 1k, is from the point of view of Linux and its Unix bretheren, complete madness. So if thats the way things really work in the mainframe land, I think there's not much e2fsprogs can do to let a RECOMP partition co-exist with an ext2/3/4 filesystem. We could read the CMS label at offset 1024 from the beginning of the disk (which is where the 3rd 512 byte block would start), and we could avoid overwriting the RECOMP space by artifically restricting the size of the ext2/3/4 filesystem. However, when we then write out the ext2/3/4 superblock, we will overwrite the CMS label, which will presumably make it impossible for the IPL loader from finding the RECOMP space, since I assume it must read the CMS label to figure out where the RECOMP space begins and where to start IPL'ing the boot program. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486528: Please enhance mke2fs to respect the RECOMP area of CMS minidisks
I've floated your request to some colleagues of mine at the IBM Linux Technology Center, and one of them sent back this reply. Have spent some time mulling this over with some VM sysprog buddies of mine we've come to the conclusion that it is not clear what this request is trying to achieve. It could be that we have not been told the real problem that needs to be solved, rather someone's interpretation of what the right solution out to be. explanation of RECOMP == recompute, which is effectively a way of doing the moral equivalent of resize2fs on a CMS filesystem to shrink it to make room for a bootstrap loader excised... Some operating systems require a full pack to be assigned to a minidisk i.e. 1-to-1 virtual to real. But not zLinux. The mini disks we define for a virtual machine can be a contiguous range of cyls of a real disk. The Z linux Preparation guide makes this clear in the example of a virtual machine directory entry (= definition). So he wants to resuse a CMS formatted minidisk under linux. Well he can do that, clearly. mke2fs will fix that for him. So does he really want a boot strap to be added to an existing linux disk. in which case we need an ext2resize that will make room for zipl to do its stuff. Or perhaps we need to tell mke2fs to start at some offset into the partition. But why does he want to change zipl as well? I can only assume the real need is to put multiple file systems and multiple bootstraps onto one minidisk. Maybe the need arises from a crude attempt to partition the CMS minidisk rather than define two separate disks. It doesn't seem to me to be satisfying a need for reuse - more a need for co-existence. Before doing anything I'd like a picture of the minidisk layout he is trying to achieve with some justification as to why he needs it this way. I've found bug #486526, which has more context about why you're trying to do this, but I don't have enough background in the issues of CMS, z/VM, and s/390 shops to understand what the issues are. I vaguely gather that you are desperately trying to avoid using ldl and cdl minidisks, but (a) I don't know what ldl and cdl minidisks are what the implications of such things, and (b) why you are trying to avoid them. Thanks, regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486528: Please enhance mke2fs to respect the RECOMP area
FYI, I just got connected to the right people in the zSeries Linux group in Germany, and they are suggesting to me that the CMS label is really more of a partition thing, and the right fix may be in the kernel, to restrict the partition seen by mke2fs to exclude the RECOMP area. Their only concern is some potential backwards compatibility problems, but they're noodling over that. But it may be that no changes to e2fsprogs are needed at all, just a kernel patch. We'll see. There are all sorts of complexities here with how this fits into the System z's boot path that I don't understand, but I will definitely defer to their vastly greater exprience in things z-related. I've also taken the liberty of forwarding your zipl request to them (bug #486526) to see what they think. Of course, no guarantees but we have some very smart people (with more importantly the right s390 knowledge base) looking over your request. Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486528: Please enhance mke2fs to respect the RECOMP area of CMS minidisks
I've looked at the patch, and there are too many acronyms! Where is this CMSFSADT label supposed to be found? According to some comments, for FBA DASD's it is located at offset 512 bytes. I know that DASD is a mainframe-encrypted word for disk, but what is FBA? And then there are these strang things called CKD DASD's. What are CKD DASD's, and how are they different from FBA DASD's? There the volume label seems to be located at a variety of different locations, one of which appears to be at the exact same location as the ext2/3/4 superblock. Anyway, no, this isn't helpful enough, and I really need someone who can explain to me **exactly** what is going on in the disk layout, or I'm not going to be able to do much with this request. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487783: bad information in /etc/blkid.tab, core dump for 'blkid -g'
On Sat, Jul 05, 2008 at 07:19:21AM +0200, Harald Dunkel wrote: Would you mind to increase the priority of this report? I've got a small Linutop PC (booting from a USB memory stick). Now I have to wipe out blkid.tab before every reboot, or it doesn't :-(. I've just released e2fsprogs 1.41-WIP-0707, which is currently in the upload queue for experimental, and it should have this bug fixed. It's stalled in the NEW queue for now because it has some new dbg packages, but you could manually grab them out if you're in a big rush. Hopefully with the new ftp assistants this will get turned around fairly quickly. This will probably the last pre-release candidate before I release e2fsprogs 1.41, at which point it will be entering the unstable and testing distributions. AFAICS blkid.tab is supposed to be some kind of cache. Is there a way to turn off this feature? Well, the simplest way for now would be: cp /dev/null /etc/blkid.tab; chattr +i /etc/blkid.tab. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487298: badblocks: double free or corruption with lots of -t patterns
tags 487298 +pending
thanks
On Fri, Jun 20, 2008 at 04:44:28PM -0400, Ariel wrote:
I haven't figured out what pattern of -t tests is needed to trigger it.
Adding or removing one might make it stop crashing, and changing a
random to a fixed number also changes it.
Creating more than 8 -t tests will trigger the problem, due to a
rather embarassing bug. It's rare that anyone wants that many test
batterns (I'm guessing you're trying to scrub a disk before discarding
it, probably to some DOD specification or some such?), so it hasnt
been noticed until now.
In any case, the following patch has been checked into my source tree
to fix the problem. Probably the best workaround if you aren't
interested in recompile e2fsprogs, and if you really need to do this
level of paranoid scrubbing, is to use a separate badblock invocation
for each set of 8 test patterns.
Regards,
- Ted
From 26575946739f78c789641c8c7d54a5d6815a92b3 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o [EMAIL PROTECTED]
Date: Sun, 6 Jul 2008 18:50:44 -0400
Subject: [PATCH] badblocks: Fix crash when lots of -t patterns given
With more than 8 -t patterns given, badblocks will overwrite the
t_patts array boundary due to realloc not taking into account the size
of an int. (Dons paper bag.)
Addresses-Debian-Bug: 487298
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/badblocks.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/misc/badblocks.c b/misc/badblocks.c
index 866144e..df74db4 100644
--- a/misc/badblocks.c
+++ b/misc/badblocks.c
@@ -995,7 +995,8 @@ int main (int argc, char ** argv)
if (t_flag + 1 t_max) {
unsigned int *t_patts_new;
- t_patts_new = realloc(t_patts, t_max + T_INC);
+ t_patts_new = realloc(t_patts, sizeof(int) *
+ (t_max + T_INC));
if (!t_patts_new) {
com_err(program_name, ENOMEM,
_(can't allocate memory for
--
1.5.6.1.205.ge2c7.dirty
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488663: mke2fs: File too large while trying to determine filesystem size
tags 488663 +pending
thanks
I've applied the following two patches to e2fsprogs's git repository.
- Ted
From b4d5105b2527a5279cf5b885b957e1e07a53e725 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o [EMAIL PROTECTED]
Date: Sun, 6 Jul 2008 20:24:29 -0400
Subject: [PATCH] mke2fs: Use a fs_type of 'journal' when creating an external journal
If creating a an external journal via mke2fs -O journal_dev,
override the fs_type list (i.e., ext2, small), and replace it with
an fs_type list of journal. This will prevent external journals
smaller than 512MB from being created with a block size of 1k, which
is not very useful and leads to much confusion.
Addresses-Debian-Bug: #488663
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/mke2fs.c | 29 ++---
1 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/misc/mke2fs.c b/misc/mke2fs.c
index acb3054..c47470b 100644
--- a/misc/mke2fs.c
+++ b/misc/mke2fs.c
@@ -1446,25 +1446,6 @@ static void PRS(int argc, char *argv[])
fprintf(stderr, _(Failed to parse fs types list\n));
exit(1);
}
- if (verbose) {
- fputs(Fs_types for mke2fs.conf resolution: , stdout);
- print_str_list(fs_types);
- }
-
- if (!fs_type) {
- int megs = (__u64)fs_param.s_blocks_count *
- (EXT2_BLOCK_SIZE(fs_param) / 1024) / 1024;
-
- if (fs_param.s_feature_incompat
- EXT3_FEATURE_INCOMPAT_JOURNAL_DEV)
- fs_type = journal;
- else if (megs = 3)
- fs_type = floppy;
- else if (megs = 512)
- fs_type = small;
- else
- fs_type = default;
- }
/* Figure out what features should be enabled */
@@ -1492,6 +1473,16 @@ static void PRS(int argc, char *argv[])
if (tmp)
free(tmp);
+ if (fs_param.s_feature_incompat EXT3_FEATURE_INCOMPAT_JOURNAL_DEV) {
+ fs_types[0] = strdup(journal);
+ fs_types[1] = 0;
+ }
+
+ if (verbose) {
+ fputs(_(fs_types for mke2fs.conf resolution: ), stdout);
+ print_str_list(fs_types);
+ }
+
if (r_opt == EXT2_GOOD_OLD_REV
(fs_param.s_feature_compat || fs_param.s_feature_incompat ||
fs_param.s_feature_incompat)) {
--
1.5.6.1.205.ge2c7.dirty
From f8df04bcc638585ee73cb795153f4456279b9b85 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o [EMAIL PROTECTED]
Date: Sun, 6 Jul 2008 20:57:17 -0400
Subject: [PATCH] mke2fs: Print a better error msg when ext2fs_get_device_size() returns EFBIG
Print a message when mke2fs uses a default blocksize from an external
journal device, and print a more self-explanatory message so that if
that blocksize is used and ext2fs_get_device_size() returns EFBIG, the
user has a better chance of understanding why mke2fs issued that error
message.
Addresses-Debian-Bug: #488663
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/mke2fs.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/misc/mke2fs.c b/misc/mke2fs.c
index c47470b..352e66b 100644
--- a/misc/mke2fs.c
+++ b/misc/mke2fs.c
@@ -1353,6 +1353,7 @@ static void PRS(int argc, char *argv[])
exit(1);
}
blocksize = jfs-blocksize;
+ printf(_(Using journal device's blocksize: %d\n), blocksize);
fs_param.s_log_block_size =
int_log2(blocksize EXT2_MIN_BLOCK_LOG_SIZE);
ext2fs_close(jfs);
@@ -1404,6 +1405,13 @@ static void PRS(int argc, char *argv[])
}
}
+ if (retval == EFBIG) {
+ fprintf(stderr, _(%s: Size of device %s too big
+ to be expressed in 32 bits\n\t
+ using a blocksize of %d.\n),
+ program_name, device_name, EXT2_BLOCK_SIZE(fs_param));
+ exit(1);
+ }
if (retval (retval != EXT2_ET_UNIMPLEMENTED)) {
com_err(program_name, retval,
_(while trying to determine filesystem size));
--
1.5.6.1.205.ge2c7.dirty
Bug#486528: Please enhance mke2fs to respect the RECOMP area of CMS minidisks
On Mon, Jun 16, 2008 at 08:44:23AM -0700, Stephen Powell wrote: Package: e2fsprogs Version: 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 Severity: wishlist This is an enhancement request that applies to the s390 and s390x architectures only. Currently, when mke2fs is run against the single implicit partition of a CMS minidisk, and the minidisk has been formatted by the CMS FORMAT command with the RECOMP option, the RECOMP option is ignored and the entire minidisk, including the RECOMP area, is used for the file system. The RECOMP option is turned off in the process. The enhancement request is to respect the RECOMP area and not include it in the filesystem created by mke2fs. The RECOMP flags in the disk directory should not be altered. I'm sorry, but I have absolutely no idea what this means. From the rationale it sounds like s390 stashes some kind of label or bootable area at the end of a minidisk, which is visible to the Linux program accessing the device file, and that mke2fs is supposed to somehow recognize the RECOMP area (how?), figure out how big is it (how?) and when mke2fs is not given a filesystem size, to pick by default a new filesystem size which hdoesn't overwrite the RECOMP area. Did I guess this correctly? If so, you're going to have to tell me how to do this, or better yet, supply code (patches) which does this. Thanks, regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475167: e2fsprogs: fsck.ext3 fails with undefined symbol: ext2fs_dblist_get_last , trace
On Thu, Jul 03, 2008 at 11:47:17PM +0200, Philippe Coval wrote: Package: e2fsprogs Version: 1.40.8-2 Followup-For: Bug #475167 I am also affected, by this bug for a few weeks, here follows the traces your were asking for I am about to update to more recent versions in unstable (and experimental) If you have a chance, before you upgrade, can you please send me the out put of the command: fsck.ext3 -V It should look something like this: e2fsck 1.41-WIP (17-Jun-2008) Using EXT2FS Library version 1.41-WIP, 17-Jun-2008 (Although with 1.40.8 instead of 1.41-WIP, of course.) The key is what version of the ext2fs library you are using. Oh, and what does which fsck.ext3 return? nrv:~# ldd $(which fsck.ext3) linux-gate.so.1 = (0xe000) libext2fs.so.2 = /lib/libext2fs.so.2 (0xb7ec8000) OK, so you are definitely using the /lib/libext2fs.so.2 from the system Versions of packages e2fsprogs depends on: ii e2fslibs 1.40.8-2 ext2 filesystem libraries And you are using the 1.40.8-2 version of e2fslibs, from which /lib/libext2fs.so.2 comes. So I just downloaded e2fslibs_1.40.8-2.deb from ftp.us.debian.org. The file I downloaded has an MD5 checksum of: 205126c8d83044f4ce1b5845818c7731 /tmp/e2fslibs_1.40.8-2_i386.deb I extracted the deb file using: dpkg-deb -X /tmp/e2fslibs_1.40.8-2_i386.deb -. This extracted lib/libext2fs.so.2 as a symlink to libext2fs.so.2.4, and the md5checksum of that file is: 9fac5bd53f38914ba33c9b913fe33c9a libext2fs.so.2 And if I run nm -D /lib/libext2fs.so.2 | grep ext2fs_dblist_get_last on that file, I get: % nm -D /lib/libext2fs.so.2 | grep ext2fs_dblist_get_last f250 T ext2fs_dblist_get_last Since you are not seeing this symbol when you use nm, and yet your system claims that you have e2fslibs 1.40.8-2 install, I can only conclude that your /lib/libext2fs.so.2 file must be getting corrupted or overwritten somehow. How, I can't imagine Can you double check the md5 checksums listed above? And can you try reinstalling e2fslibs 1.40.8-2, and then re-trying the nm -D test? - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488663: mke2fs: File too large while trying to determine filesystem size
On Tue, Jul 01, 2008 at 08:47:58AM +0200, Paul Slootman wrote: I created the external journal without specifying the blocksize, not realizing that I needed to. Perhaps the blocksize parameter should be mandatory when creating an external journal... Oh, I bet I know what happened. The external journal logical volume was probabyl smaller than 512 megabytes, right? So it probably defaulted to 1k. I should probably change things so it defaults to use a 4k blocksize when mke2fs is run with -O journal_dev. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
