Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
severity 1035543 normal retitle 1035543 e2fsprogs: on an upgrade from bullseye e2scrub-reap.service may be wanted by default.target instead of multi-user.target thanks On Thu, Jun 01, 2023 at 07:40:25PM +0100, James Addison wrote: > > So it's not a big deal; is that correct so this patch is not worth > > trying to shoehorn in beform Bookworm ships, and this particular patch > > can be safely downgraded from important, right? > > I think all of that is true, yep. OK, I've reset this to normal. > Also, arguing against my own revert-patch: I think it could be said > that multi-user is the "better" target to use here, because the > default could be "graphical" or some later-reached system state > whereas this is a relatively low-level (if small) system cleanup > service. Right, that's I believe the point of bug #991349; it's possible that the system adminsitrator might manually set default.target to point to graphical.target, per [1]. And since multi-user.target is a subset of graphical.target, it makes sense to make the Wanted-by to be multi-user.target. [1] https://www.baeldung.com/linux/systemd-target-multi-user And so it's fair to keep this bug open, but I think it makes it a normal bug, with the resumption that hopefully it can be fixed via deb-systemd-helper or init-system-helpers. In this particular case, since we *always* want it to be default.target, since the whole *point* is to clean up after a failed e2scrub, it seems really unlikely to me that the system administrator would change this. So this is one where it's probably fair for the postinstall script to just fix the wanted-by link **always** if the the systemd unit file says Wanted-by: default.target, and the symlink is inconsistent with it. Maybe this will mess with some kind of hidden systemd rules of the road, but quite frankly, the fact that this is causing so much pain and confusion, I'm not sure I care. > I'd agree with downgrading the severity to below RC (and it's your > package, so feel free, I think? maybe even close it?). If anyone > arrives here/reports other bugs as a result of experiencing it, I > think we can let them know that it's safe to remove the legacy > 'default.target' symlink (does that sound correct too?). I think so. The symlink should *never* be considered normative, right? The unit file should be considered the single source of truth. If the system administrator wants to do something weird, they are supposed to copy /lib/systemd/system/e2scrub_reap.service to /etc/systemd/system/e2scrub_reap.service, and if the symlink is inconsistent with what's in the unit file (with the one in /etc/systemd/... if it exists taking precedence over the one in /lib/systemd/..., we should just fix the symlink. So this should be fixable in deb-systemd-helper, or I can just implement a Big Fat Hammer in e2fsprogs's postinst script. Does that sound right? - Ted
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
In addition to Bookworm being hard frozen, I question the importance of this patch, the bug priority, and whether the title is correct. After all, at least with respect to e2fsprogs systemd unit *will* still be enabled. It will just be enabled using ../multi-user.target/wanted instead of ../default.target/wanted. Ok, piuparts whines about it, and I agree that it's ideal if things are the stame regardless of whether the distro is freshly installed or uprgaded --- but e2scrub-repeat.service will *still* be enabled, right? And so the bug title is misleaing, right? So it's not a big deal; is that correct so this patch is not worth trying to shoehorn in beform Bookworm ships, and this particular patch can be safely downgraded from importanted, right? Or else, what am I missing? Thanks, - Ted P.S. And repeat after me, "systemd is *so* much more simpler than init.d scripts because it's declarative"
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Sat, May 27, 2023 at 11:09:32PM +0200, Helmut Grohne wrote:
> Hi,
>
> I sat down with Jochen in Hamburg to try and fix this.
>
> On Sun, May 14, 2023 at 03:21:24PM -0400, Theodore Ts'o wrote:
> > Can someone send the instructions on how to fix this?
>
> We wish we could give you. Instead, we document our findings, so maybe the
> next one looking into this bug has a better idea, but for now we give up
> as it is too late for bookworm anyway.
Helmut, Jochem, thanks so much for trying to look into this. Here's
some additional context from my research.
First of all, the change to use WantedBy=default.target to
Wantedby-multi-user.target, as described in Message #19 of this bug,
was in response to a bug report from Ansgar, bug report #991349:
>I noticed that e2scrub_reap.service uses
>
> WantedBy=default.target
>
>instead of the more usual
>
> WantedBy=multi-user.target.
>
>As default.target is usually just an alias for multi-user.target or
>graphical.target, this means it will even be pulled in if someone uses
>some other custom target. This feels rather unexpected.
>
>Is there any reason not to use WantedBy=multi-user.target?
At the time, I thought to myself, sure, makes sense, and made the
change in commit b42c9788c75d ("e2scrub: use
WantedBy=multi-user.target in e2scrub_reap.service"), and in the
commit I noted "Addresses-Debian-Bug: #991349"
As near as I can tell, on a system that started with the Bullseye
version of e2fsprogs, and which has then updated to the Bookform
version e2fsprogs, via periodic updates to testing (Bookworm), the
default.target link still exists:
% ls -l /etc/systemd/system/default.target.wants/e2scrub_reap.service
0 lrwxrwxrwx 1 root root 40 Dec 19 2020
/etc/systemd/system/default.target.wants/e2scrub_reap.service ->
/lib/systemd/system/e2scrub_reap.service
... and this is enough for systemctl status to seem to think that
e2scrub_reap is still enabled:
% systemctl status e2scrub_reap
○ e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots
Loaded: loaded (/lib/systemd/system/e2scrub_reap.service; enabled; preset:
enable>
Active: inactive (dead) since Sat 2023-05-27 17:53:22 EDT; 1h 34min ago
Docs: man:e2scrub_all(8)
Process: 1309 ExecStart=/sbin/e2scrub_all -A -r (code=exited,
status=0/SUCCESS)
Main PID: 1309 (code=exited, status=0/SUCCESS)
CPU: 12ms
...
So sure, /etc/systemd.d/system/multi-user.target.wants/e2scrub_reap.service
doesn't exist. *But* it still exists in .../default.target.wants/...
which seems to be enough to keep the e2scrub_reap service enabled. Right?
What am I missing?
In any case, I am still unclear (a) what is actually broken in this
particular setup, since according to systemctl status the systemd unit
is apparently still appropriate enabled, even if it isn't via the
expected Wanted-b: multi-user.target.
And secondly, (b) what is e2fsprogs's control scripts supposed to have
done differently? That is, if this is indeed this is a bug in
e2fsprogs --- what did I do wrong, and how do I fix it?
And if the answer is you should never, ever, try to change a Wanted-by
line in a systemd script, because debian's systemd unit file
infrastructure is too fragile to handle this correctly, given that
bookworm is about to ship with "Wanted-by: multi-user.target", what's
the best path forward at this point?
I'll note that e2scrub_reap.service is just a helper unit file which
is only needed to clean up after a system crash while e2scrub is
running --- and that will only happen if the user has edited and
appropriately configured e2scrub in /etc/e2scrub.conf.
So from my maintainer's perspective, what I am going for is that
e2scrub_reap.service and e2scrub_all.timer should *always* be enabled,
since the real control point (as far as I am concerned) is
/etc/e2scrub.conf. I really don't actually *care* whether it is
enabled via default.target.wanted or multi-user.target.wanted.
If I need to be sent to some systemd re-educational camp to understand
the finer points about default.target vs multi-user.target, and
whether it acctually makes any difference whether the systemd unit
file says "Wanted-by: multi-user.target", but in the upgraded
bullseye->bookworm installation, the symlink is still in
*/default.target.wanted/* --- please point me at the documentation.
Otherwise, I'm beginning to think that nothing is actually broken, and
the bullseye2bookworm piuparts tests is just being overly picky, but
nothing is actually broken in actual practice. And perhaps I should
just close this bug as "Working as Intended".
Again, what am I missing?
- Ted
P.S. I really *am* trying to get with the systemd program, but this
all of this complexity is just hopelessly confusing. :-( :-( :-(
P.P.S. And there is actually a case where thi
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Sun, May 14, 2023 at 06:03:59PM +0200, Michael Biebl wrote: > > Please reassign it there together with instructions how to fix it, i.e. > > what should be done in the maintainer scripts. Can someone send the instructions on how to fix this? I'm always amused by people who claim systemd is "simpler" to understand than init.d scripts. :-) I have no clue what's going on; is default.target obsolete? If we change the Wanted-by in a systemd unit file, what magic incantation is required? Can someone point me at documentation that describes all of this? Thanks, - Ted
Bug#1031622: d-i regression since bookworm alpha 1: creates a filesystem with FEATURE_C12 unsupported by the installed e2fsck
On Sun, Feb 19, 2023 at 01:23:19PM +, Simon McVittie wrote: > > I think this could be caused by debian-installer having udebs from > e2fsprogs 1.47.0-1 in the installation environment, so that the version > used to create the root filesystem has newer feature flags than the > installed version of e2fsck can cope with (similar to #1030939 and > #1031325). I thought the Debian-Installer would only be using udebs from Testing? I'm confused how it would be picking up e2fsprogs 1.47.0-1 from unstable, if it is going to be installing. Currently e2fsprogs is blocked from migrating to testing precisely because we didn't want d-i to be picking up e2fsprogs 1.47.0. That being said FEATURE_C12 is the orphan_file feature which is only going to be enabled by default in e2fsprogs 1.47.0. I'm just really confused why d-i would be picking up the e2fsprogs udebs from unstable. - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Fri, Feb 17, 2023 at 10:34:29PM +0200, Adrian Bunk wrote: > > The same general problem applies in various "building non-Debian > embedded Linux filesystem on Debian" situations where the target > chroot does not contain mkfs.ext4. In practice, if the root file system is using ext4, the target chroot has to have e2fsprogs installed so that fsck.ext4 exists. So I'm not sure it's all that unreasonable? > Or if it is present, it would be a chroot for the target architecture > where you might have to run mkfs.ext4 under qemu. Sure, but that's not that difficult; I have a script[1] that will setup chroots for foreign architectures which use binfmt_misc to run (for example) arm32 or arm64 binaries using qemu on an x86 machine, without needing to boot an arm32/arm64 kernel. For a more detailed explanation see slide #8 of this slide deck[2]. The setup-buildchroot script is turn-key; my experience is that several new college grads and interns hired at $WORK have had no problems setting it up. [1] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot#L364 [2] https://thunk.org/android-xfstests Also, in practice, if you are building an image for a foreign system, you'll need to have a qemu setup to run the second stage of the debootstrap in any case. I've just found it simpler to run the mkfs and debootstrap in a chroot using qemu-user-static compared to messing around with debootstrap --second-stage, which requires running a chroot and qemu in any case. > All image building tools that support bookworm (including all image > building tools we ship in bookworm) have to ensure that what they > produce works on the intended target. There is no general solution > *how* to do that that could be applied in all cases. Well, the general solution we can give them is instructions to adjust /etc/mke2fs.conf on those systems needing to run those image building systems. It's a one-line change. This can be documented in the release notes, or in an e2fsprogs NEWS entry. If the RT really insists, we can edit /etc/mkefs.conf for Bookworm to not enable metadata_csum_seed by default. This will make it more difficult for root file systems cloud VM's to be able adjust the file system UUID on the fly, while the file system is mounted, so that's the tradeoff. Quite frankly, the distro that I really care about for $WORK is Arch, since Google's Cloud Optimized OS is based off of Arch userspace packages. So if the Debian Release Team would like to disable metadata_csum_seed by default in e2fsprogs, I will make that change and upload a new version of e2fsprogs 1.47.0. I don't think that's the right way to go, since I don't consider image building to be a super-common use case, and those who do that can edit /etc/mke2fs.conf on their own. However, I accept that this is the Release Team's call. If we do make this change to mke2fs.conf for Bookworm, my intention is to upload a version of e2fsprogs which reverts this change as soon as Bookworm ships as stable, so that Debian 13 will enable metadata-csum-seed by default. At that point, people using Sid or Debian Testing will have problems if they want to build images for Bullseye, and I'll note that Daniel, who originally registered this objection, was building images using Debian Unstable. So this will will only give him a reprieve for a few months before he will need to push changes to vmdb2 or make that one-line change to /etc/mke2fs.conf. If the Debian release team could let me know which path they would prefer, I would appreciate it. At this point, the grub2 package version (2.06-8) which supports metadata-csum-seed has migrated to testing. So the only thing the e2fsprogs migration is now blocked on is the RT's decision on this bug. Best regards, - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Fri, Feb 17, 2023 at 12:43:01PM -0700, Sam Hartman wrote: > > I am not entirely convinced that using current rather than guest > tools for image building is an anti-pattern. You've been working on > filesystems for a long time; I've been working on various image > building projects since my first watchmaker project at MIT. For what it's worth, I've been building test appliances[1] for the purposes of file system testing since 2013 (initially just for Qemu, but now for Cloud[2] environments as well as Android[3]). Admittedly, I haven't been doing this as long as you, but I'm not unfamiliar with building appliance images using debootstrap, and I've *always* built my KVM/Qemu images using a build chroot[4], including the mkfs and debootstrap steps. [1] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/gen-image [2] https://thunk.org/gce-xfstests [3] https://thunk.org/android-xfstests [4] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot So I'm happy to talk to you off-line about best practices for building images, but this is something that I do *regularly*, since there are weekly updates from upstream xfstests. Thus, I have personal experience that using a build chroot for image creation really is *not* *that* *hard*. For that matter, when I'm doing test appliance development, I'm running regression tests[5] several times a day which build images in a chroot. [5] https://github.com/tytso/xfstests-bld/blob/master/selftests/appliance Everything is automated. No fuss, no muss, no dirty dishes. :-) Futher, it provides better build reproducibility, no matter who is building the image, and it also makes full GPL compliance (if you are publishing the test appliances) much, *much* easier --- I can provide an exhaustive list of all components (including mkfs.ext4!) and control scripts involved with the creation of the image. Cheers, - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Fri, Feb 17, 2023 at 02:08:28PM -0500, Theodore Ts'o wrote: > So enabling what may be > convenient, but ultimately an anti-pattern is something that hopefully > in the long-term Debian should be striving towards. Sigh, I managed to invert the sense of what I was trying to say. This should have read: So enabling what may be convenient, but ultimately an anti-pattern is something that hopefully in the long-term Debian should be trying to *avoid*. - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Fri, Feb 17, 2023 at 08:51:33AM -0800, Russ Allbery wrote: > Adrian Bunk writes: > > > The image creators could just set the features they enable to what they > > copied from /etc/mke2fs.conf from the target distribution, a label with > > a timestamp wouldn'tbring much benefit here. > > That's a very good point and I'm embarrassed it wasn't immediately obvious > to me. Sorry about the noise. One other thing I woud add here is (a) this whole discussion of mke2fs.conf only helps for ext4, and the general problem is something that extends to all file system. The immediate question may be ext4 specific, but as I mentioned earlier, XFS is enabling the "bigtime" feature for the first time in Bookworm. So enabling what may be convenient, but ultimately an anti-pattern is something that hopefully in the long-term Debian should be striving towards. Yes, it's annoying and and extra work. So is using build chroots if we are building packages for a older Distro versions. But it's the right thing to do. Secondly, (b) there may be a misapprehension that it is possible to get an identical file system just by controlling the contents of mke2fs and/or specifying the file system features on the command line. While this is mostly true, it is not the whole story. For example, the size and location of the journal is determined hueristically, and in the past, this has changed as we have discovered that (for example) making the default journal size larger would result in better performance. The location of the journal has also changed from the beginning of storage device (low-numbered LBA's) to the middle of the device. So just as a binary compiled using the default gcc on Buster might be different from a binary build using Sid, even if you you force the use of older glibc shared libraries at link time or use -static to statically link with the glibc installed in your random desktop environment, the results from using mke2fs on Debian N may be different from using mke2fs on Debian M, even if you control for thea file system features. (And other things which _are_ controllable on mke2fs.conf, but which go beyond mke file system features. For example, in Bookworm starting with e2fsprogs 1.46.4, the default inode size is forced to always be 256 bytes, even for small file systems. This was not true in Buster and older Debian distributions.) So if you want a bootable image that is identical to what would be created by using the Buster or Bullseye debian-interaller, you *really* want to use the mkfs that was supplied by Buster or Bullseye, and that means running the mkfs from a chroot. Best regards, - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Thu, Feb 16, 2023 at 11:45:23AM -0800, Russ Allbery wrote:
>
> Yes, I'm probably understating the difficulty of making this change in
> practice inside image building software as it's currently constructed.
>
> My concern about changing mkfs options is that I worry that this would be
> a constantly-changing target that has to be synchronized across multiple
> pieces of software that are not currently well-aligned with file system
> development. One thing that would make this much easier would be for mkfs
> to support some sort of compatibility level flag that sets all of the
> options, whatever they may be, to their defaults as of some point in the
> past. Image building software could then pick a conservative default set
> point when building images for older distributions. That change still has
> to be added to all of the image building software, but it might be easier
> than building a local chroot of the target distribution before using it to
> build the file system the actual installation is going into.
As a long-term solution, one could image changing the various image
creation tools to do something like "mfks.ext4 -T grub2_dumbdown
/dev/XXX", and then have something like the following in
/etc/mke2fs.conf:
[fs_types]
grub2_dumbdown = {
features = ^metadata_csum_seed,^casefold
}
If you care about being able to run fsck.ext4 on really old
distributions, one could even add things like
[fs_types]
jessie_dumbdown = {
features = ^metadata_csum_seed,^metadata_csum
}
etc.
Maintaining this would be a nightmare, and I'd want to ask for help,
since this would be change if we also want to add dumbdown file system
usage types for Ubuntu, and potentially, other Debian derivitives.
Even if we stick with grub2_dumbdown, again, how far back do we go?
Some people have said, "just one release", but I bet there will be
people wanting to create Stretch installer images using a sid
userspace. So I'd want to have some kind of formal understanding
about what it is that we feel obliged to support.
Given the number of users of the iamge building tools, it's a pretty
specialized use case with not a lot of users, and they can also just
edit /etc/mke2fs.conf to have their favored default. From my
e2fsprogs maintainers hat on, that's my position --- I interpret
"users" in the Debian Social Contract for the general users, and not
necessarily something that needs to work for every single exotic use
case, especially if they tend to be more of the power users.
If we're not allowed to inconvenience *any* users, then it's hard to
make forward progress. Certainly some people (including myself) were
inconvenienced for things like /usr-unification and the transition to
systemd. We went ahead with the transition even though some users
were inconvenienced. And quite honestly, if a few power users need to
edit /etc/mke2fs.conf to remove metadata_csum_seed because they want
to do something which is *REALLY* not a good idea (using Debian M to
build a file system meant for use on Debian M-X) --- for *ALL* file
systems, not just ext4. It may be that some users have gotten lucky,
and it mostly works. But it's a bad idea, and encouraging this bad
practice is eventually going to lead to tears.
But, if the Debian Release team would like to override my position, my
suggestion would be to just change the default for /etc/mke2fs.conf
for *everyone* running Debian bookworm, and with the understanding
that this will be reverted in Debian testing after the next stable
release, and that moving forward, we make it the image building tools
problem if they want to support this highly dubious practice of using
Debian N+X's mkfs to build images for Debian N. I would strongly
suggest that they figure out which file system features they need to
explicitly turn off for ext4, xfs, btrfs, etc., if they want to build
old distro versions using whatever random software they have installed
on their desktop.
Best release engineering practice is that you use a known, controlled
build environment, and not whatever random package versions might be
on your desktop. While that might be "inconvenient" when building
packages, we've learned to live with it. I use sbuild; others might
use pbuild, or their own custom schroot setup. But I dare say all
responsible people doing release engineering use a known build
environment. Why should this be any different if you are building
images --- especially images that you expect *your* users or customers
to be depending on? What are your responsibilities to them? (Whether
or not the Debian Social contract applies to them or not.)
- Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Wed, Feb 15, 2023 at 07:39:28PM -0800, Russ Allbery wrote: > It had never occurred to me before that the version of the system on which > I run mke2fs would matter as long as I didn't pick a newer file system > type (ext5 or something). Now I know! Until today, I had no idea ext4 > even *had* "incompat" features or that mke2fs could make file systems that > grub couldn't understand. While ext2 pioneered the whole concept of "compat", "rocompat" and "incompat" features, these days pretty much all modern Linux file systems have this. As I mentioned earlier, xfs is enabling their incompat "bigtime" feature for the first time in Bookworm. File sysems have been evolving pretty much continuously since ext2 was first released 30 years ago. Poeple may have gotten lucky that grub only (mostly) cares about incompat and rocompat features, but things like adding extended attributes, 64-bit block number support, post-2038 timestamps, etc., all require changes to the on-disk format. And may of these updates did not happen at a extN to extN+1 boundary. As far as the kernel is concerned, ext2/ext3/ext4 is really more about allowing multiple implementations co-existing. These days, "ext3" file systems are handled by the code in fs/ext4/*.c, and the only reason why we've kept fs/ext2/*.c is to provide sample file system code more than anything else. Many distributions (including Debian) use fs/ext4 to support the ext2 file systems, via kernel config CONFIG_EXT4_USE_FOR_EXT2. As I mentioned, for the most part file system developers have tended to care much more about kernel and file system utility back-compatibility. This is probably because we have our own ways of controlling these issues using controls such as /etc/mke2fs.conf, but also because we tend to worry much more about data disks than installers. And if much fewer Debian users tend to boot using say, xfs or f2fs, perhaps people have just not noticed and complained. Moving forward, certainly I and other fs developers will be spending more time worrying about grub2 handling various file system features. For example, grub2 doesn't understand the ext4 "casefold" feature, and someday someone might want to make a Debian derivitive where users' home directories work like MacOS and Windows... Documenting this in ext4(5) is a bit challenging, because (a) not all users use the grub2 bootloader, and (b) that means we'd have to continuously update ext4(5) as grub2 changes. But certainly we could make a generic warning in ext4(5). It might be that a Wiki is the best place for this. The Arch and Gentoo wikis have some of this already, since Arch and Gentoo users tend to believe in enabling all file system developers (whether it is good for them or not). That's great for me in terms of beta testers for features that I don't think is 100% ready for prime time, but that's another reason why using a newer mkfs is a bad idea. For example, the inline_data feature is *not* ready for prime time, but it's been getting better, and someday we might enable it by default in Debian N+x. It'll *mostly* work so long as you don't stress-test creating writing, truncating, etc., small files, but if vmdb2 enables inline_data for Bookworm even though the Bookworm e2fsprogs doesn't enable inline_data by default (but some future Debian N+x does enable it by default), some users' lives might get *exciting*, since the Bookworm will probably will be on the 6.1 LTS kernel. - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote: > > You argue about shared libraries for non-packaged binaries. > I think we mostly don't care about that, and again, I think that's at > least a generally recognized thing that came out of our focus on > packages and package dependencies. Note that package dependencies doesn't allow a binary created on Debian N to work on Debian N-1. It just *prevents* the package from being installed on Debian N-1. If you care about allowing the package to be instaslled on Debian N-1, that's what build chroots are for. That's how we create packages for backports, after all. I'm making a similar argument for mkfs and bootable images for older distributions. Just as you use a build chroot when you build a package for Debian N-1, you should use a chroot when building a bootable image for Debian N-1. And that means using the chroot for *everything*; not just installing the grub bootloader, but also running mkfs. (Note that using the sid grub bootloader while using the sid's mkfs.ext4 would work in this particular case, but if you want a pure "Bullseye" image which is identical to what running the Bullseye d-i would create, then you should run Bullseye's mkfs, not sid's mkfs.) - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote: > > I.E. I think your question of "for how long" has a very simple answer > based on our history: if we care about stability in this instance it's > for +/-1 Debian release. > > I'm struggling trying to figure out whether we should commit to that > stability. I recogniuze that there are precedents that go in both directions. We have *never* required that shared library linkages created in Debian N work in Debian N-1. Sure, there are workarounds that you can use (e.g., compiling with -static), but I've listed workarounds for mke2fs as well. In other cases, we may have gone out of our way to provide these sorts of transitions. > I also think it would be reasonable for the project to decide we care > about this stability, and that we want bullseye grub to work with a > filesystem made on sid. Well, I agree that it's a Distribution level decision. And if the distribution decides that we should acccomodate this particular case case, we can certainly make a Debian-specific change to the /etc/mke2fs.conf config file which doesn't enable metadata_csum_seed by default. > I understand you do not support that stability decision. The argument I would make is that it is a case by case decision, and not a global one where *all* all generated objects created by Debian N have to work in Debian N-1. For example, this is most manifestly *not* true for any shared library compiled by default that uses glibc. And I don't personally consider vmdb2 to be important enough to be worth this kind of solicitude when we haven't done it for shared library lankage --- just based on the popcon statistics if nothing else. But, if the release team belives that a note in the release notes is not sufficient, I can certainly change the default for Debian. The *reason* why the default features can be configured in /etc/mke2fs.conf is because distributions or individual users might want to make different decisions about the defaults than the upstream maintainer of e2fsprogs. So I'll certainly abide by the ruling of the release team in this matter, and I guess if Daniel doesn't like the decision they make, he can always appeal this to the Debian TC. The appeal chain on this one seems pretty clear. As the Debian maintainer for the e2fsprogs package; I have my opinion on how this can be resolved. Daniel has appelaed this to release team, and if necessary, he can appeal to the Technical Committee, and he can ever try to organize a Debian GR if he feels so strongly about the issue. Given that there are some *very* easy workarounds, which I have listed, just as there are simple workarounds for creating a binary for Bookworm that will work for Bullseye, I really do believe this is a tempest in a teacup. Best regards, - Ted
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
On Wed, Feb 15, 2023 at 11:47:08AM +0200, Adrian Bunk wrote:
>
> For normal library dependencies
> Depends: libc6 (>= 2.34)
> will do the right thing automatically.
Sure, but dependencies only apply if you are using building packages.
If you are not building packages, but just moving binaries between
distribution versions --- which is analogous to what is going on here
when someone moves a file system from one distro version to another.
For example:
% echo 'int main() { printf("Hello, world\n"); return 0; }' > /tmp/foo.c ; gcc
-w -o /tmp/foo /tmp/foo.c ; /tmp/foo ; schroot -c bullseye-amd64 /tmp/foo
Hello, world
/tmp/foo: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
(required by /tmp/foo)
> e2fsprogs adding Breaks against older versions of bootloaders and other
> software that lacks support for the new default might be a good idea.
>
> The situtation is different when a relationship cannot be reliably
> expressed by package dependencies.
Unfortunately, package dependencies won't address the concern raised
by Daniel. The mkfs.ext4, debootstrap, etc., are being run on a one
version of the distro, such as for example sid or Bookworm, but then
when the grub bootloader is installed --- presumably in a chroot, so
that you get the Bullseye grub on a Bullseye VM image --- it won't
know that the base file system was built on Sid or Bookworm. Of
course, if you run the mkfs.ext4 in a Bullseye chroot, everything will
work *just* *fine*. It's just that this isn't Daniel's workflow.
> For the kernel the answer to your "how long" is that packages should
> also work with the kernel from the previous and the kernel from the
> next Debian release.
This isn't a problem with the kernel. For the ext4 feature that
Daniel cited, metadata_csum_seed was first supported in 4.4 kernel
(note that Debian *stretch* used the 4.9 kernel and 4.4 was first
released in 2016 --- six years ago). On the file system utility side,
e2fsprogs 1.43 also support for metadata_csum_seed (again, support
going back to stretch).
The xfs bigtime feature, which was similarly enabled in Bookworm, was
supported in the kernel the xfsprogs for **many** years. In general,
file system developers do understand the concern of needing to wait
before enabling a feature by default in mke2fs.conf.
The issue here is in grub support. Part of the issue is that
admittedly, file system developers don't worry as much about
bootloaders as much as we do for kernels and the file system
utilities. The other is that the grub2 upstream simply hasn't been as
responsive or quick at doing releases. The fix landed in grub2
upstream in June of 2021. So all distributions tend to carry large
number of grub2 cherry-picks.
> If the feature stays enabled by default in bookworm:
> Everyone using grub is an x86 thing, for embedded ARM it is more common
> to use a once ported ancient u-boot on your hardware forever.[1]
> A bug against the release-notes pseudo-package with text describing
> the incompatibility and possible workarounds would be appreciated.
Would you prefer that we repurpose (and retitle) this bug, or open a
new one?
Here's a quick rough draft of what that text might look like, at least
for the ext4 metadata_csum_seed. (If it's helpful, I can try to also
write a blurb for XFS, although I'd want to run it by the XFS kernel
maintainer, Darrick Wong first.)
cut here ---
In the Bookworm release, the mkfs.ext4 will enable the orphan_file and
metadata_csum_seed feature. The orphan_file feature significantly
improves performance for workloads which are truncated or deleting
files in parallel. The orphan_file feature is an ext4 "compat"
feature, so file systems with the orphan_file feature can be mounted
on older kernels who do not understand the orphan_file feature, so
long as the file system was cleanly unmounted. If the file system was
not cleanly unmounted (for example, due to a crash or power failure),
the file system must be fsck'ed or mounted on a Bookworm system before
the file system is transferred to an older system.
The metadata_csum_seed feature allows the file system UUID to
be modified without needing to update all of the file system metadata,
which is often important in VM context where root file systems are
cloned from read-only images, and having unique UUID's is important to
avoid confusion when the block device might be mounted on another
whose root file system is similarly cloned from the same base image.
The metadata_csum_seed feature is an ext4 "incompat" feature, which
means that the kernel must understand the feature before it will be
able mount a file system with that feature. Fortunately, the Linux
kernels starting with 4.4 (and the Debian 9.0 "stretch" release)
support the metadata_csum_seed feature. So data disks formatted with
metadata_csum_seed can be mounted on systems with older distro
versions without concerns in nearly all case.
Unfortunately, grub2 support for the metadata_csum_seed
Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible
There is more about this in the referenced bugs, but I dispute Daniel's characterization of the issue. I will draw the analogy of building a program which links against glibc for Bookworm resulting in a binary that will not run on Buster. We expect that, and we tell people to use build chroots. This is not something which is actionable, and we don't hold back glibc updates just because you can no longer build on Debian 10.0 something that won't work on Debian 9.0, or 8.0. The same is true for file system featuers. We add new features to improve the user experience. This is true for all file systems: ext4, xfs, btrfs. For example, in Bookworm, the version of xfsprogs is going to enable the incompat "bigtime" feature for the first time. This fixes XFS's 2038 problem. A file system has the bigtime feature enabled won't boot on Grub versions older than 2.06. That is just the way of the world. As it truns out, for e2fsprogs, users (or distributions) can very easily change the default file system features by editing the configuration file /etc/mke2fs.conf. So if a user wants to ask mke2fs to disable certain features by default, and "dumb down" the capabilities of the file system, they can to do that --- on the command line, by tuning the file system after the fact, or by editing the /etc/mke2fs.conf file. They can even set the MKE2FS_CONFIG environment variable to point at their own custom config file if they would like. We can change the default for mke2fs.conf file for Debian. I don't think it's warranted, and I'm not aware of any other distribution doing this. The fact that file system featuers that fix certain problems (such as the 2038 bug) will cause older versions the distribution to fail to accept that file system is always going to be the case. So how long do we hold back some new feature? A year? Two years? Five years? Ten years? Again, we don't do this with shared library linkages; we just tell people to use a build chroot. I would gently suggest that the most general solution to this problem is to do the same for building VM images, if people won't want to be bothered to learn how to configure the mfks program. After all, according to popcon, there are 960 times as many people who have use gcc-10 recently (7685) as vmdb2 (8). So if we are to hold e2fsprogs and xfsprogs to the standard that a file system created by default must work on all older Debian and Ubuntu distributions to some arbitrary point in history, should we 1000 times as much hold gcc-10 and clang to the same standard? Obviously, that is a ridiculous thing to do. Best regards, - Ted
Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Tue, Feb 14, 2023 at 07:35:51PM +0100, Daniel Leidert wrote: > > As soon as this version hits testing, you have successfully disabled > the last working environment to use vmdb2 to create images of Ubuntu > and Debian. As soon as this version hits Testing, one then can no > longer build images for either any Ubuntu release nor Debian Bullseye > or older. I can then only build images for Bookworm and Sid. Please > think about that. The number of users who use vmdb2 are quite small; for those users who do, there is a simple fix. You can either diable the feature using tune2fs, or you can just make an edit to your /etc/mke2fs.conf file to not enable the feature. A one line change to /etc/mke2fs.conf is hardly what I'd call "impossible". > You *seriously* break the debootstrap method of installing Debian or > Ubuntu. As you have pointed out, this is not a debootstrap issue, since it doesn't create the file system. The uestion is in how the file system is created, and this is not hard to fix. You can just run "mke2fs -O ^metadata_csum_seed _file_or_block_device_"; you can run "tune2fs -O ^metadata_csum_seed _file_or_block_device"; you can make a one-line change to /etc/mke2fs.conf. > You haven't documented how to disable that > breaking change when creating filesystems for distributions where grub > does not support this (there is not even a NEWS entry). You haven't > even announced that breaking change. And yet you are going to break one > of our two standard methods of installing Debian or Ubuntu. How is any > of what you have been saying so far addressing any of these issues? Sorry, as far as I'm concerned, vmdb2 is not that important. We don't document in a NEWS entry or anywhere else, how to build a binary that links against a newer version of glibc so it will work on an older system. And I would consider the compiler toolchain to be far more common a usecase than vmdb2. Indeed, your use of "toolchain" for file system utilities is a new one for me. I've never heard the term "toolchain" used in such a way before. > I do not understand why you are pushing 1.47.0 over 1.46.6, which you > had uploaded just five days before the former. You haven't even > presented a reason yet. It has anumber of new features that will improve ext4's performance on highly parallel workloads; it makes it possible for cloud VM's to be able to safely update the root file systems's UUID while it is mounted, among other changes. - Ted
Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
There is another issue with vmdb2 if you are using XFS. Starting with
xfsprogs 5.15 (which is already in testing), bigtime is enabled by
default, so that newly created XFS file systems won't be subject to
timestamp overflow in 2038. Grub didn't land support for this feature
until 8b1e5d1936ff ("fs/xfs: Add bigtime incompat feature support") in
May 2021, despite the fact that XFS has had this feature for years and
years and years.
So if you aren't using the latest security fixes, and you are using
XFS as the boot partition --- it won't work on buster and bullseye.
"Fortunately", there were were massive number security vulnerabilities
in grub2 which forced a backport of grub2 2.06 to bullseye and buster,
so if you have the security updates enabled, you'll probably be OK ---
but it was only because of massive number of security problems forced
that backport.
In any case, a version of grub that will support the csum_seed feature
will be landing in Bookworm in just a few days. So at that point,
you'll be able to create VM images for Bookworm and Sid that will work
with the e2fsprogs in sid. The current plan of record is that it will
only be at that point that e2fsprogs will be allowed to migrate into
Bookworm.
For slowly moving upstreams like grub2, distributions *have* to take
updates before grub2 finally gets around to doing a release --- to get
security fixes if nothing else! The support for csum_seed has been in
Fedora and other distributions for a while, since the patches had
landed in grub2 in June 2021. I probably should have made sure the
feature had landed in Debian's grub2 packaging earlier; that's my bad,
and my apologies for that.
Note that Debian's grub2 has well over 100 patches, nearly all of
which are backports from grub2's git repo. So the argument that
"there doesn't exist a formally released grub2 release" isn't
particularly compelling, since all the distros are backporting
patches. The only question is how *many* commits release has an
individual distribution taken.
By the way, in the case of the csum_seed feature, it's pretty
straightforward to just run "tune2fs -O ^metadata_csum_seed
/tmp/boot.img". If the UUID has been changed since the file system
was created, you'll have to do this while the file system is unmounted
and it will take a few seconds, but that's almost certainly not the
case with vmdb2.
- Ted
Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Tue, Feb 14, 2023 at 01:01:38AM +0100, Daniel Leidert wrote: > Hi Steve, > > I believe that your fix to grub2 in Sid is not enough to handle > #1030939/#1030846. > > This problem breaks e.g. vmdb2. I can no longer create a Bullseye > system image with vmdb2 on Sid, because the grub-install step in the > Bullseye chroot now fails, because the created filesystem (created with > e2fsprogs on Sid) cannot be recognized by grub. I'm confused, why does using vmdb2 on *sid* involve running grub-install on a *bulleye* chroot? That seems to be extremely ill-advised. If you are trying to install a bullseye system, why can't you using vmdb2 on bullseye? And if you are trying to install a sid or bookworm system using vmdb2, why can't you (or vmdb2) use a sid or bookworm chroot for doing the grub-install? > I have to downgrade e2fsprogs to the version in Testing to get the > build going again. It also means that a Bookworm system can never be > used to format and debootstrap a Bullseye or Buster system that > requires a grub installation. > > I guess that the fix applied to grub2 in Sid would have to be applied > to grub2 in Bullseye as well (and basically to any grub2 package in any > Debian or Ubuntu or Raspbian release supported by debootstrap). I can understand why we need to keep things synchronized so that a debian installer for Bookworm be able to generate a bootable system using the version of grub and e2fsprogs in Bookworm. But a generalized requirement that we be able to use debootstrap and vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't seem to be reasonable. It would mean that we couldn't update to newer versions of the C library, or of new file system featuers, because we are somehow obliged to be able to boostrap ancient versions of the system. After all, we don't require that a binary built using Bookworm be able to run on Bullseye. How is this any different? I generate test appliances for file system regression testing which run on Debian Bullseye on my Debian Bookworm system --- and this gets done using build chroot[1]. I even have super-convenient scripts to create the build chroot[2]. This is not hard why can't vmdb2 do the same thing? [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/building-xfstests.md [2] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot - Ted
Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Fri, Feb 10, 2023 at 08:31:04AM +0100, Cyril Brulebois wrote: > > Holding back file system development because grub2 uptsream is super > > slow doesn't seem like a reasonable way forward, so I really don't > > want to set this precedent. > > The Bookworm freeze has started, we need to be able to install stuff, so > we need a solution for the grub2/e2fsprogs situation *now*. > > I really don't care about “setting a precedent”. But that problem has already been solved by cloning the bug back to e2fpsrogs (#1030939) which will prevent e2fsprogs from transitioning to testing, no? So what's the problem. The fact that grub2 upstream is super-slow in doing releases is already a pain in *ass that has caused much pain over the years. Adding a conflict just adds more pain, without adding any additional benefit. So what's the point? - Ted
Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote:
> >>
> >> Thanks from me as well :-). To prevent e2fsprogs from migrating to
> >> testing before grub2 and breaking d-i, I am reassigning a copy of this
> >> bug back to e2fsprogs. It may be closed once grub2 2.06-8 enters
> >> Bookworm. Perhaps it would also be a good idea to add a versioned
> >> "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.
> >
> > Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to
> > e2fsprogs-udeb?
>
> That is not going to help, because IIUC grub-install is run from the
> target system that you are installing, and there is no
> grub2-common-udeb.
Right, but if the conflict in e2fsprogs-udeb prevents the installer
from pulling in an overly new version of e2fsprogs-udeb, that woul be
sufficient, no?
After all, you can install e2fsprogs 1.47, and install a newer version
of grub, and there is no problem --- unless you enable the the
csum-seed function on an already installed system. And you can't do
that, because you it's an incompat feature.
OTOH, with e2fsprogs 1.46 you can *ready* run the command "tune2fs -O
large_dir /dev/root" on a running system, and then when you reboot,
the system won't come back, because grub will see the large_dir
feature and freak out (unecessarily). But adding an conflict with
1.46 and grub makes no sense, since it's not _that_ likely that user
will deploy that particular foot-gun. (It happens with Arch and
Gentoo, but those users tend to be much more adventurous, aided and
abetted by Wiki pages that encourage users to help kernel developers
beta test new features. :-)
The reason why I really don't want to add the conflicts with e2fsprogs
1.47 is because for people who are using sid, there is aboslutely
nothing wrong with installing e2fsprogs 1.47. It's only if they use
the installer that sucks in e2fsprogs that there's a problem --- it's
not an inherent conflict with grub per se. If it were, then we
shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream
is painfully slow in putting out releases --- and that's not
reasonable.
Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to
remove the default use of the csum-seed feature but is it worth
it? Hopefully the new version of grub2 will come out soon, at which
point I would then need to revert the hacked mke2fs.conf --- and your
dup'ing this bug should prevent the installer from picking up
e2fsprogs 1.47 until the new version of grub gets released.
I'll note that grub is trying to use an independent implementation of
ext4, as opposed to using the upstream libraries such as libext2 for
ext2/3/4 and libxfs for XFS, combined with grub's very slow release
cycle, means that this kind of thing is going to be happening a *lot*.
It's something that I and Darrick Wong (the XFS maintainer) have
kvetched about a number of times on our weekly conference calls.
For example, recent grub commits that impact XFS that aren't in 2.06
include:
commit a4b495520e4dc41a896a8b916a64eda9970c50ea
Author: Erwan Velu
Date: Wed Aug 25 15:31:52 2021 +0200
fs/xfs: Fix unreadable filesystem with v4 superblock
The commit 8b1e5d193 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes
Holding back file system development because grub2 uptsream is super
slow doesn't seem like a reasonable way forward, so I really don't
want to set this precedent.
Thinking about this some more, I'd much rather have some kind of
explicit scheme, such as:
mkfs.xfs -T grub2-dumbdown /dev/XXX
Which disables various new file system features that aren't yet
supported by grub, but which users might very well want to use on
non-boot disks.
This could be done by doing something as simple as adding to mke2fs.conf:
[fs_types]
grub2-dumbdown = {
features = ^large_dir,^metadata_csum
}
Then we could teach the Debian installer to use the file system usage
type "grub2-dumbdown".
Of course, moving forward we'd have to update mke2fs.conf as grub
finally learns new features, and since mke2fs.conf is a config file,
people would have to edit it by hand post-install if they have
customized it in any way. Unless we add the above in
/etc/mke2fs.conf.d/grub2-dumbdown, and then teach mke2fs to understand
the /etc/mke2fs.conf.d directory...
- Ted
Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Thu, Feb 09, 2023 at 06:04:23PM +0100, Sven Joachim wrote: > > Thanks from me as well :-). To prevent e2fsprogs from migrating to > testing before grub2 and breaking d-i, I am reassigning a copy of this > bug back to e2fsprogs. It may be closed once grub2 2.06-8 enters > Bookworm. Perhaps it would also be a good idea to add a versioned > "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs. Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs-udeb? After all, it's not that e2fsprogs breaks grub2-common, per se, unless the *installer* happens to to use << grub 2.06-8~ and e2fsprogs 1.47.0-1. - Ted
Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Wed, Feb 08, 2023 at 09:12:05PM +, Steve McIntyre wrote: > > I've just queued these up in our repo for the next grub upload, due in > a few days. Many thanks, Steve! - Ted
Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize
On Wed, Feb 08, 2023 at 11:39:48AM +0100, Cyril Brulebois wrote:
>
> Spotted via debian-installer tests: grub-install fails with “unknown
> filesystem” when trying to run a simple `grub-install /dev/sda` with
> an all-default installation.
The fix for this issue landed in the grub2 repository on June 11,
2021:
commit 7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763
Author: Javier Martinez Canillas
Date: Fri Jun 11 21:36:16 2021 +0200
fs/ext2: Ignore checksum seed incompat feature
This incompat feature is used to denote that the filesystem stored its
metadata checksum seed in the superblock. This is used to allow tune2fs
changing the UUID on a mounted metdata_csum filesystem without having
to rewrite all the disk metadata. However, the GRUB doesn't use the
metadata checksum at all. So, it can just ignore this feature if it
is enabled. This is consistent with the GRUB filesystem code in general
which just does a best effort to access the filesystem's data.
The checksum seed incompat feature has to be removed from the ignore
list if the support for metadata checksum verification is added to the
GRUB ext2 driver later.
Suggested-by: Eric Sandeen
Suggested-by: Lukas Czerner
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Lukas Czerner
Reviewed-by: Daniel Kiper
Unfortunately, this just missed the last grub release, since grub 2.06
was tagged on June 8, 2021.
There are two ways we can fix this. One is we can disable the
checksum seed feature in the Debian release of mke2fs.conf. Or we can
land this above-mentioned commit into the grub2 package. Since the
hard freeze is almost upon us, I'm happy to handle this either way.
If we *are* going to backport some grub2 patches, may also make a plug
for this one, which is also in the upstream grub2 git repo:
commit 2e9fa73a040462b81bfbfe56c0bc7ad2d30b446b
Author: Theodore Ts'o
Date: Tue Aug 30 22:41:59 2022 -0400
fs/ext2: Ignore the large_dir incompat feature
Recently, ext4 added the large_dir feature, which adds support for
a 3 level htree directory support.
The GRUB supports existing file systems with htree directories by
ignoring their existence, and since the index nodes for the hash tree
look like deleted directory entries (by design), the GRUB can simply do
a brute force O(n) linear search of directories. The same is true for
3 level deep htrees indicated by large_dir feature flag.
Hence, it is safe for the GRUB to ignore the large_dir incompat feature.
Fixes: https://savannah.gnu.org/bugs/?61606
Signed-off-by: Theodore Ts'o
Reviewed-by: Daniel Kiper
Otherwise, what can happen is that users may choose to enable the
large_dir feature, and if they do it on the root file system, they can
end up making their system unbootable. I've had some Arch and Gentoo
users get bitten by this
> The “e2fsprogs gets a new upstream release and new flags” hypothesis was
> confirmed by building d-i with e2fsprogs-udeb_1.46.6-1_amd64.udeb
> rebranded as 1.48, which made the problem disappear.
Alternatively, I can apply this patch to e2fsprogs:
diff --git a/misc/mke2fs.conf.in b/misc/mke2fs.conf.in
index b7fc95df7..ff47bdb39 100644
--- a/misc/mke2fs.conf.in
+++ b/misc/mke2fs.conf.in
@@ -11,7 +11,7 @@
features = has_journal
}
ext4 = {
- features =
has_journal,extent,huge_file,flex_bg,metadata_csum,metadata_csum_seed,64bit,dir_nlink,extra_isize,orphan_file
+ features =
has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize,orphan_file
}
small = {
blocksize = 1024
Which will kind of suck, since the reason for enabling
metadata_csum_seed is to be able to reliably change the label and file
system uuid on a mounted file system, which matters for certain cloud
workloads. Specifically, for Google's Cloud Optimized OS, which
attempts to update the file system UUID and resize the root file
system to fit the size of the cloud-emulated block device on two
separate, racing systemd unit files. This which works 99.9% of the
time, but when you launch a huge number of cloud images, that last
0.1% of the time is really noticeable.
But that's for COS; if we have to disable the metadata_csum_seed
feature on Debian file systems, I can live with that.
Cheers,
- Ted
Bug#1022096: e2fsprogs: debian: make the copyright file machine readable
On Wed, Oct 19, 2022 at 11:45:22PM +0200, Bastian Germann wrote: > Source: e2fsprogs > Severity: serious > Tags: patch > Version: 1.46.6~rc1-1 > > Hi Theodore, > > There are several distribution licenses and copyright information not > mentioned, which are required by Debian Policy §12.5. I have attached > a patch fixing this, which also has the conversion of the copyright > files that are still in use to the machine-readable format. > > Also attached is a patch for the upstream source (as you are also the > upstream maintainer) that applies a license requirement that I found > not to be present. Applied to e2fsprogs upstream maint branch, thanks. - Ted
Bug#991922: FTBFS on s390x: Tests failed: f_baddotdir
tags 991922 +pending
thanks
On Thu, Aug 05, 2021 at 02:54:38PM -0300, Antonio Terceiro wrote:
> Source: e2fsprogs
> Version: 1.46.3-1
> Severity: serious
> Justification: fails to build from source
>
> e2fsprogs currently fails to build on s390x buildd, and I was just able
> to reproduce it on a porter box.
(Note: the bug doesn't exist in 1.46.2, which is fortuante since
things are locked down for the upcoming stable release.)
Thanks for the bug report. I'm glad to report that this is already
fixed upstream:
commit 225e5d093b519f9dbe9fcaacd995426f0e5194f6
Author: Theodore Ts'o
Date: Wed Jul 28 13:51:13 2021 -0400
e2fsck: fix f_baddotdir failure on big-endian systems
Commit 63f44aafb1f2 ("e2fsck: fix ".." more gracefully if possible")
changed the check_dot() function to try to avoid resetting the '..'
entry when the '.' entry is too large.. But if we do that, then on
big-endian systems, we need to try byte swapping the rest of the
directory entries, or else the f_baddotdir test will fail on
big-endian systems.
Also add a check to avoid UBSAN warning when there is not enough space
at the end of the directory block for a directory entry, and so we can
potentially overflow some pointer arithmetic when trying to byte swap
the remainder of the (negative) space in the directory block.
Fixes: 63f44aafb1f2 ("e2fsck: fix ".." more gracefully if possible")
Signed-off-by: Theodore Ts'o
I only noticed the problem when I uploaded 1.46.3-1 to experimental on
July 27th, and like you, was able to reproduce it on a porter box and
fixed it the next day. I am planning 1.46.4 release next week to fix
this and a number of other bugs:
ea97af65 - (maint) libext2fs: improve error handling in POSIX ACL conversions
(6 days ago)
165c8541 - setup-schroot: install the acl and libreadline-dev packages (6 days
ago)
5148709f - tests: skip m_rootdir_acl on GNU Hurd (6 days ago)
7a97083d - libext2fs: fix translation of Posix ACL's on big-endian systems (6
days ago)
654be045 - contrib: add setup-schroot command for use on Debian porter boxes (7
days ago)
c3062042 - tests: add description for j_recover_fast_commit (7 days ago)
5a3ea390 - tests: force test file systems to be built for the Linux OS (7 days
ago)
4d988e1b - tests: try using truncate command before falling back to using dd (8
days ago)
9aba0528 - libsupport: fix sort_r.h to work on the GNU Hurd (8 days ago)
225e5d09 - e2fsck: fix f_baddotdir failure on big-endian systems (8 days ago)
- Ted
Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel
On Mon, May 03, 2021 at 11:00:37PM +0200, Aurelien Jarno wrote: > > Maybe I should give a bit of context here. First of all, there is one armhf > buildd, arm-arm-01, setup as an arm64 machine with a 32-bit armhf chroot. It > has been setup following [1] a study from Steve McIntyre [1]. It appears > that e2fsprogs first failed to build there [2] and got requeued on another > buildd where it succeed. > > Now with my DSA and buildd maintainer hat on, we have been experiencing for > quite a lot of VM crashes when building packages in 32-bit armhf/armel VMs > on arm64 machines, so we have recently stopped using VMs to build them and > instead rely on chroots. Thanks for the context. I had indeed noticed shortly after 1.46.2-1 was released that it had failed on the first armhf buildd, and then when it was retried, it got successfully built. Given that this was right before the bulleye release freeze hardened, this had been on my radar screen to fix, since it was clearly non-optimal, but I had assumed that it would be OK to let things slide until after the Bullseye release, since after all e2fsprogs 1.46.2-1 *did* successfully get built on armhf. For me, this is really a question of timing. It will definitely be the case that the next source upload of e2fsprogs will have the armhf/armel build fix. The question I have is should I upload the fix before Bullseye releases, or after the Bullseye release. What is the impact on the buildd and DSA support effort if we wait until after the Debian 11.0 release? What is the pain if we leave this unfixed until Bullseye releases (I'm assuming that it's going to be released soon)? The buildd's aren't going to be rebuilding e2fsprogs until the next source upload, I would think. Contrawise, what is the impact on the Debian Release and Debian Installer teams if I push out a bug-fix-only e2fsprogs source package in the next week or so? I'll do what is least disruptive for all of the relevant teams. Let me know what's preferred. Cheers, - Ted
Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel
On Mon, Apr 26, 2021 at 11:01:45PM +0200, Aurelien Jarno wrote:
> Source: e2fsprogs
> Version: 1.46.2-1
> Severity: serious
> Tags: upstream ftbfs
> Justification: fails to build from source (but built successfully in the past)
> Forwarded: https://github.com/tytso/e2fsprogs/issues/65
>
> e2fsprogs builds fine on armel/armhf when built on a machine with a
> 32-bit kernel. However it fails to build on a machine with a 64-bit
> kernel due to alignments issues which are not trapped by the kernel:
>
> A build log is available there:
> https://tests.reproducible-builds.org/debian/logs/unstable/armhf/e2fsprogs_1.46.2-1.build2.log.gz
Hi, thanks for the bug report. I have a patch which should address
this problem. (See below).
I have a question for the Debian Release Team (cc'ed). Do you agree
this is considered "serious"? It will build from source on a system
with a arm-32 kernel. It is only when cross-compiling on armel or
armhf on a aarch64 platform that some regression tests
(j_recover_csum2_32bit, j_recover_csum2_64bit, and j_recover_fast_commit)
will fail, and it is this which causes dpkg-buildpackage when run on a
arm-32 chroot on a 64-bit arm system to fail.
So it is not completely clear to me that this qualifies as a FTBFS,
such that the release team would grant an migration into bullseye
given that we are currently in "frozen hard to get hot"[1]
[1] https://lists.debian.org/debian-devel-announce/2021/03/msg6.html
I actually wouldn't mind it if I could sneak in an update into
Bullseye, especially if I could fix one or two other bugs at the same
time that don't qualify for RC. (For example, Debian Bug: #984472[2],
and a bug fix for mke2fs -D which was reported by the Yocto
project[3].
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984472
[3] https://github.com/tytso/e2fsprogs/pull/68
However, given that e2fsprogs is used by the installer, and we're
pretty late in the Bulleye Freeze --- I'd like to get a general
approval of the concept of an e2fsprogs update for Bullseye at this
point in time before I prepare an update and file a formal unblock
request.
Or we can do this after the initial Bullseye release, if that would be
more convenient for the release process.
What say ye?
Many thanks,
- Ted
commit bc8e4e56fcdd2a9e65cc87f6303dd127f79ad22d
Author: Theodore Ts'o
Date: Mon May 3 15:37:33 2021 -0400
e2fsck: fix portability problems caused by unaligned accesses
The on-disk format for the ext4 journal can have unaigned 32-bit
integers. This can happen when replaying a journal using a obsolete
checksum format (which was never popularly used, since the v3 format
replaced v2 while the metadata checksum feature was being stablized),
and in the fast commit feature (which landed in the 5.10 kernel,
although it is not enabled by default).
This commit fixes the following regression tests on some platforms
(such as running 32-bit arm architectures on a 64-bit arm kernel):
j_recover_csum2_32bit, j_recover_csum2_64bit, j_recover_fast_commit.
https://github.com/tytso/e2fsprogs/issues/65
Addresses-Debian-Bug: #987641
Signed-off-by: Theodore Ts'o
diff --git a/e2fsck/journal.c b/e2fsck/journal.c
index a425bbd1..2231b811 100644
--- a/e2fsck/journal.c
+++ b/e2fsck/journal.c
@@ -278,6 +278,23 @@ static int process_journal_block(ext2_filsys fs,
return 0;
}
+/*
+ * This function works on unaligned 32-bit pointers, which is needed
+ * since fast_commit's on-disk format does not guarantee that pointers
+ * are 32-bit aligned.
+ */
+static __u32 get_le32(__le32 *p)
+{
+ unsigned char *cp = (unsigned char *) p;
+ __u32 ret;
+
+ ret = (__u32) *cp++;
+ ret = ret | ((__u32) *cp++ << 8);
+ ret = ret | ((__u32) *cp++ << 16);
+ ret = ret | ((__u32) *cp++ << 24);
+ return ret;
+}
+
static int ext4_fc_replay_scan(journal_t *j, struct buffer_head *bh,
int off, tid_t expected_tid)
{
@@ -344,10 +361,10 @@ static int ext4_fc_replay_scan(journal_t *j, struct
buffer_head *bh,
offsetof(struct ext4_fc_tail,
fc_crc));
jbd_debug(1, "tail tid %d, expected %d\n",
- le32_to_cpu(tail->fc_tid),
+ get_le32(>fc_tid),
expected_tid);
- if (le32_to_cpu(tail->fc_tid) == expected_tid &&
- le32_to_cpu(tail->fc_crc) == state->fc_crc) {
+ if (get_le32(>fc_tid) == expected_tid &&
+ get_le32(>fc_crc) == state->fc_crc) {
state->fc_rep
Bug#930484: e2fsck corrupts sparse files with -E bmap2extent
Control: severity -1 normal Control: fixed -1 1.43.5-1 On Thu, Jun 13, 2019 at 04:09:15PM +0200, Florian Zumbiehl wrote: > Package: e2fsprogs > Version: 1.43.4-2 > Severity: critical > > e2fsck potentially moves blocks around in sparse files when running with > -E bmap2extent, in particular when the blocks are physically adjacent on > the underlying block device, but have a hole in between in the file. > ... > > With version 1.44.5-1~bpo9+1, the test above does not produce corruption on > my system, but I have not investigated whether that is just coincidence or > because the bug has been fixed. As this silently corrupts files, I would > think it should get some fix in stretch, and be it by disabling the > feature. The bug was fixed in e2fsprogs 1.43.5, via the fix: commit 855c2ecb21d1556c26d61df9b014e1c79dbbc956 Author: Darrick J. Wong Date: Wed May 24 21:56:36 2017 -0400 e2fsck: fix sparse bmap to extent conversion When e2fsck is trying to convert a sparse block-mapped file to an extent file, we incorrectly merge block mappings that are physically contiguous but not logically contiguous because of insufficient checking with the extent we're constructing. Therefore, compare the logical offsets for contiguity as well. Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o It's an unfortunate bug, but we've lived with it for about ten years, and it was only noticed in 2017. The reality is very few people actually try to convert an indirect mapped file system the new extent-mapped system, because you get much more of the benefits of using a more modern version of ext4 by doing a backup, reformat, and restore of the file system. Given that so few people have noticed, I don't believe this qualifies as even "important", since doing the conversion is not a fundamental aspect of e2fsck, so it doesn't qualify as a significant impact on the usability of the package. For similar reasons, I don't believe the release team would agree to a new release of e2fsprogs to stretch --- especially since (a) it's fixed in buster, (b) the fix is also available in stretch-backports, and (c) in three weeks, Stretch will become oldstable and Buster will become the new stable release of Debian. Feel free to escalate this to the Debain release team but I don't think this is going to be considered worth their time (or mine) to be worth a backport of the fix to e2fsprogs 1.43.4-2. Cheers, - Ted
Bug#929287: e2scrub_reap.service fails to start
Package: e2fsprogs Version: 1.45.1-3 Fixed in the most recent upload of e2fsprogs. (Sorry, I typo'ed the Closes: number in the changelog. I'll fix that up in a future release.) - Ted
Bug#924591: this requires linking in libsparse, which is from Android sources
clone 924591 -1 reassign 924591 fastboot 1:8.1.0+r23-4 retitle -1 e2fsprogs: add support for dynamically loading libsparse severity -1 wishlist thanks I'm reassigning the original bug back to fastboot. I've cloned the bug and made it a feature request of having e2fsprogs dynamically load libsparse if it is available. That's not happening until after Buster is released, though. - Ted
Bug#924591: this requires linking in libsparse, which is from Android sources
On Mon, Apr 22, 2019 at 10:19:46PM +0200, Hans-Christoph Steiner wrote: > > I don't really know how fastboot in stretch provided the mke2fs support, > but judging by the dependencies, it might have been that fastboot used > to do the formatting itself, based on being linked to > android-libext4-utils and android-libsparse. The buster version of > fastboot is clearly calling mk2efs, which in AOSP is built from an > inline e2fsprogs fork. Yes, that's correct. >From running strings on the fastboot binary from Stretch, it's using the statically linked-in make_ext4fs code. The make_ext4fs was code written years and years ago, back when Android senior management (rumor has it was that it was Andy Rubin himself) didn't want to use any GPL'ed code in userspace. Fortunately, that's no longer the case. The old make_ext4fs code was old, creaky, and didn't exactly work the same way as mke2fs (since it was written as a clean-room reimplementation from scratch). As a result I was very happy when we were finally able to take the make_ext4fs code and KILL IT WITH FIRE[1]. :-) [1] https://www.youtube.com/watch?v=Tnod9vtB4xA Unfortunately, the focus was to make the make_ext4fs replacement work with AOSP only. I wasn't aware of Debian's native Android tools; but even if I did, it's not clear that we could have gotten things working within the scope of the intern project to drop make_ext4fs support and port the necessary support code into e2fsprogs. This change started landing in AOSP in November 2016 (it was a Fall 2016 intern project). I'd have to check to be sure, but looking at the Debian changelog, the AOSP release with the actual KILL IT WITH FIRE commit probably landed in Debian sometime in late 2017. Alas, apparently no one had noticed the problem for well over a year. So I'm guessing Debian's fastboot, or at least its format command, is rarely used by Debian users. :-/ - Ted
Bug#924591: this requires linking in libsparse, which is from Android sources
On Mon, Apr 22, 2019 at 06:09:23PM +0200, Jonas Meurer wrote: > Hans-Christoph Steiner: > > Theodore Ts'o: > >> So your choice --- we can either reassign this bug back to fastboot or > >> android-sdk-platforms-tools, or I can downgrade the severity of this > >> bug for e2fsprogs down to wishlist[1]. Let me know how you want to > >> handle this. > >> > >> [1] This is because I view this both as a "feature request" and "bugs > >> that are very difficult to fix due to major design considerations" > >> (per https://www.debian.org/Bugs/Developer#severities), not to mention > >> that it's going to affect a miniscule fraction of the e2fsprogs > >> package's users. > > > > Makes sense to me. I'm fine with this being done post-Buster or as a > > custom mke2fs in android-platform-system-core. > > So the bottom line here is that the ext4 formatting support in fastboot > remains broken in Buster, right? That would be very unfortunate and a > regression compared to Stretch. I'm not sure whether or not Stretch was using the old-style make_ext4fs from AOSP, or was including the mke2fs from AOSP, but yes, it sounds like it's a regression from stretch. I'm not sure how many Debian users are using the Debian-native fastboot versus using the version from the Google SDK or the AOSP binaries, though. It does seem that if this is considered high priority, the most straightforward way to address this bug is going to be to include building mke2fs from AOSP and placing it in /usr/lib/android-sdk/platform-tools/mke2fs. I know some folks on the android tools teams aren't excited with that approach, but that probably is the best thing to do if you want to address this in Buster. - Ted
Bug#924591: this requires linking in libsparse, which is from Android sources
On Thu, Apr 18, 2019 at 09:32:06PM +0200, Hans-Christoph Steiner wrote: > > One possibility would be including libsparse as a patch, it doesn't > change a lot: > https://android.googlesource.com/platform/system/core/+log/master/libsparse > > But it depends on Android's libbase and libz-host. This might be "serious" bug from the fastboot package's perspective, but there's no way in heck the release time is going to consider this a bug that is "serious" priority for e2fsprogs. More to the point, there's now way in the world I (or the release and installer teams) are going to make e2fsprogs, which is an "important=yes" package with priority "required" drag in the android-libsparse, android-libbase, and zlib1g packages. So the way you changed android-sdk-platforms-tools to use /sbin/mke2fs was a really bad choice, especially this while we are in release freeze for Buster. There's no way in the world we are going to make a change like this to a package like e2fsprogs which is used by the installer at this point. If we had more time, and if android-libsparse-dev shipped a static library, we could have considered statically linking in android-libsparse, android-libbase, and libz --- and see if they would bloat the mke2fs and debugfs binaries by only a minimal amount. This would also require making changes to e2fsprogs configure and Makefiles, since currently we only have support for linking in libsparse in the AOSP build files. The reason for this is historical; at the time when the intern working with Android team was working on replace Android's make_ext4fs program with mke2fs and e2droid, there was no distribution that was shipping libsparse, and trying to make libsparse available to Linux desktop environments was *way* beyond the scope of the Intern's project and time availability. We can work on this trying to find a solution post-Buster --- either using static linking, or *possibly* figuring out a way to optionally use dlopen() to pull in libsparse for sparse_io.c, much like the way libss optionally pulls in the readline library using dlopen at runtime, back when we cared about making mke2fs fit on a two 1.44 MiB boot/root install floppies. :-) Alternatively, you can build your own version of mke2fs using the libsparse from AOSP. If you want a solution that might make it in during the Buster release freeze, that's probably the short-term solution I would suggest. So your choice --- we can either reassign this bug back to fastboot or android-sdk-platforms-tools, or I can downgrade the severity of this bug for e2fsprogs down to wishlist[1]. Let me know how you want to handle this. Cheers, - Ted [1] This is because I view this both as a "feature request" and "bugs that are very difficult to fix due to major design considerations" (per https://www.debian.org/Bugs/Developer#severities), not to mention that it's going to affect a miniscule fraction of the e2fsprogs package's users.
Bug#890866: mesa: regression vs mesa 17.3.3-1: crash on i915 triggered by running emacs
On Tue, Feb 20, 2018 at 11:37:12AM +0100, Andreas Boll wrote: > > Thanks for reporting to upstream! > Could you test Mesa 18.0.0~rc4-1 from experimental? According to [1] > some GPU hangs are supposed to be fixed. Per [1], I've tried 18.0.0~rc4-1, and it appears to fix the issue. Also, I've since noticed there are similar GPU hangs happening with 17.3.3-1 --- it's just that they are much more easy to reproduce with 17.3.4-1. Cheers, - Ted [1] https://bugs.freedesktop.org/show_bug.cgi?id=105169#c2
Bug#886119: WORKSFORME mac-ppc32
On Sat, Jan 13, 2018 at 11:12:51PM -0700, Boyd Waters wrote: > WORKSFORME mac-ppc32 > > Linux ppc32mini 3.16.0-5-powerpc #1 Debian 3.16.51-3+deb8u1 (2018-01-08) ppc > 7447A, altivec supported PowerMac10,1 GNU/Linux It was fixed in e2fsprogs/1.43.8-2 - Ted
Bug#886119: e2fsprogs: FTBFS on big-endian architectures
Hi, thanks for sending me a patch! I had noted the build failures and it was on my todo list to debug and fix today; you saved me a bunch of time. I will apply this and get an updated release out quickly. Cheers, - Ted
Bug#880207: e2fsprogs-l10n: copyright file missing
On Mon, Oct 30, 2017 at 04:23:51PM +0100, Andreas Beckmann wrote: > > a test with piuparts revealed that your package misses the copyright > file, which is a violation of Policy 12.5: > https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile Thanks for pointing this out; I've checked in a fix and it will be addressed in the next release of e2fsprogs. - Ted
Bug#840733: Please remove...
On Sun, Jan 29, 2017 at 12:11:11PM +, Andy Simpkins wrote: > Hi Ted, > > I am currently sat at the Cambridge BSP looking at Debian RC bugs [1]. > > Looking at this bug report we believe that on balance the best course of > action would be to remove lib/et/test_cases/imap_err.et from e2fsprogs. > As you have offered to do this in your capacity as "upstream" [2] > may we please ask you to do this at your earliest opportunity. > Would you mind performing this as an atomic operation as this would make > the process of freeze exception straight forwards. The e2fsprogs in git has been updated with a newer version of imap_err.et that has a DFSG compliant copyright. commit a7ec7532e48660a0239aa8938f22a6b0d90864ab Author: Theodore Ts'o <ty...@mit.edu> Date: Thu Dec 22 22:23:58 2016 -0500 lib/et/testcases: checked in imap_err.et from cyrus-imapd version 2.5.10 This version of imap_err.et has a 4-clause BSD license, which should hopefully be more comforting to lawyers than the license with prohibits non-commercial use --- which shouldn't be a problem since it's in a test case that would never show up in any binary, and so license compatibility wouldn't be an issue. Signed-off-by: Theodore Ts'o <ty...@mit.edu> https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=a7ec7532e48660a0239aa8938f22a6b0d90864ab I was planning on getting a new version of e2fsprogs (1.43.4) out this week. An upload before this hard freeze next week should address this bug. - Ted
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
On Tue, Dec 27, 2016 at 07:56:36PM +, Adam D. Barratt wrote: > Thankfully none of that worked. I say thankfully, because you'd have > given release.d.o an allegedly RC bug (it may be RC for e2fsprogs, it's > certainly not so for release.d.o) and removed the original bug from > where it belongs. (The binNMU doesn't resolve the fact that the original > issue existed - and for some versions still exists - in e2fsprogs.) It only exists in the versions of e2fsprogs shipping in Jessie and before. So unless the SRM's think that it's worth it to fix this issue via a change to e2fsprogs going to proposed-updates for Jessie (I'm not entirely convinced but if you want me to add the Built-Using and ask for a update to Jessie stable, I can do that, and we can punt on the binNMU for e2fsck-static since it will be obsoleted by the fix of e2fsprogs in Debian stable.) Otherwise, I plan to close the e2fsprogs bugs since it's fixed in Debian Stretch, and with the decision not to try to address this in Jessie, a "wontfix" for older versions of e2fsprogs. Apologies for not adjusting the priority as part of my attempt to move this bug to release.debian.org, but the theory was that fixing this via a binNMU of e2fsck-static was sufficient, given how late we are in Jessie's life cycle, and it wasn't worth trying to fix this bug in stable. If I'm wrong in this, and the SRM's would support/prefer to fix this via an update to e2fsprogs in Jessie and spinning new binary debs for all architectures, I'll stand corrected and we can go down that route. Cheers, - Ted
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
retitle -1 release.debian.org: binNMU for e2fsck-static to rebuild against latest dietlibc reassign -1 release.debian.org user release.debian@packages.debian.org usertag -1 binnmu thanks On Tue, Dec 27, 2016 at 12:16:52PM +, Ben Hutchings wrote: > On Wed, 2016-12-21 at 22:49 -0500, Theodore Ts'o wrote: > > I noticed you reopened this and marked this as still being a problem > > in e2fsprogs/1.42.12-2 (it actually _is_ fixed in e2fsprogs/1.43.3-1). > > Is it worth trying to fix this in Debian Stable? Especially given > > that existence of snapshots.debian.org, the sources for dietlibc will > > always be available one way or another --- and that might be good > > enough for GPL compliance. > > I think that snapshot.debian.org should be sufficient to keep Debian > itself in compliance, but not any downstream commercial distributors. > So all GPL sources should be available in the same suite, and Built- > Using provides the information that dak needs to ensure that. > > As it is, e2fsck-static in jessie has been built with dietlibc > 0.33~cvs20120325-6, but dietlibc has had a security update since then > so that version is no longer present. (That issue didn't affect > e2fsck-static so it hasn't been binNMU'd.) > > I think this could be resolved in stable simply by binNMU'ing e2fsck- > static for the architectures where it uses dietlibc. Agreed, that seems to be the best way to handle things. So that means we would need to do a binNMU for e2fsck-static/1.42.12-2 for the following architectures: alpha amd64 arm hppa i386 ia64 powerpc ppc64 s390 sparc I've reassigned this to the release team to see if the Stable Release Managers agree (which hopefully they will). Ted
Bug#847575: closed by Hilko Bengen <ben...@debian.org> (no embedded dietlibc)
fixed 847575 1.43.3-1 thanks On Wed, Dec 21, 2016 at 11:57:43PM +, Ben Hutchings wrote: > > > > I intended to prepare a patch but found that e2fsprogs no longer builds > > the static binary using dietlibc as of 1.43~WIP.2016.05.12-1, so this > > bug can be closed. > > Oops, sorry for the wrong version. I noticed you reopened this and marked this as still being a problem in e2fsprogs/1.42.12-2 (it actually _is_ fixed in e2fsprogs/1.43.3-1). Is it worth trying to fix this in Debian Stable? Especially given that existence of snapshots.debian.org, the sources for dietlibc will always be available one way or another --- and that might be good enough for GPL compliance. - Ted
Bug#840733: e2fsprogs contains non-free file
On Fri, Oct 14, 2016 at 12:18:31PM +0300, Adrian Bunk wrote: > Source: e2fsprogs > Version: 1.43.3-1 > Severity: serious > > lib/et/test_cases/imap_err.et: > > The "for non-commercial purposes only" is a clear violation > of clause 6 of the DFSG. Thanks for pointing that out. Please note that this file is **only** used as a test case so there is absolutely no binary packages from e2fsprogs which are derived from this particular file. I'll remove it from the next version of e2fsprogs sources and can spin a new tarball at that time. Since we don't actually depend on this file it could be easily removed from the e2fsprogs_1.43.orig.tar.gz if someone really is concerned but the mere existence of this "no-commercial-use only file" I don't think will cause any legal risk to Debian, so IMHO it's not worth doing. However, if the FTP team would like to do it, they are free to, of course. - Ted
Bug#766799: resizing root partition with resize2fs makes system unbootable
On Mon, Oct 27, 2014 at 11:37:47PM +0200, Dmitry Borisyuk wrote: Thank you for the detailed explanation, Indeed, I intentionally created the filesystem with that features removed (because something didn't work with the defaults, sadly it was long ago and I don't remember the details). I'm a bit surprised that you have closed the bug. Though my initial filesystem was non-standard, it was not broken, right? Then, I suppose, resize2fs should not break the system silently. It might display some warning, at least... It didn't break the file system; it's a perfectly valid file system to ext4 and e2fsprogs. The fact that grub doesn't support file systems with the meta_bg feature enabled is unfortunate, but that's a grub bug. It wouldn't be that hard to support meta_bg, actually; it's a relatively minor change to the file system format, but grub is GPLv3, and e2fsprogs (because it has kernel code it in it) is GPL-v2 only, and so grub couldn't just use libext2fs from e2fsprogs directly. If they did, then aside from needing to link against a newer version of libext2fs, it would have Just Worked. So you can blame the FSF and GPLv3 for this bug, as well. :-) - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766799: resizing root partition with resize2fs makes system unbootable
Can you check and see if this is completely repeatable? And can you do the following? 1) Send me exactly what resize2fs reported. 2) Send me the output of dumpe2fs /dev/sda1 before and after the resize2fs. 3) Also please confirm that you ran resize2fs /dev/sda1 while in the guest partition, while the root file system was mounted on /dev/sda1. 4) Please also send me the counts of /proc/mounts, /etc/mtab, and /etc/fstab. Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757543: MUST NOT say ***** REBOOT LINUX ***** before safe to do so
severity 757543 normal thanks I agree this should be fixed, but what e2fsck was doing was at best a contributory factor. #1, the user pulled the disk while it was still being active. And #2, e2fsck is writing back the updated superblock and block group descriptors. If any of these changes had been lost, a second run of e2fsck should have fixed them. The fact that the disk did additional damage on a power fail which caused the data loss is the disk's problem, not e2fsck's. I'll fix this, but even so, unexpected power lost should have caused anything other than a need to rerun e2fsck. I suspect the fault of the hardware. - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738460: macchanger: Random mac feature fails in all of the random mac assigning options
On Mon, Jul 07, 2014 at 08:25:25AM +0200, David Paleino wrote: On Sun, 6 Jul 2014 21:23:25 -0400, Theodore Ts'o wrote: Do you have any objections if I upload this as a NMU? Or would you prefer to update the package? Please Ted, go ahead. :) Ok, thanks. I'll do that this evening. Since I got your ack, I won't bother using a delayed queue. BTW, I was looking at the local Debian patches, and with the exception of the OUI list changes patch, I'm not convinced any of the other ones make sense for us to be carrying. In particular, 02-fix_usage_message.patch seems especially pointless, since calling out that both --mac=XX:XX:XX:XX:XX:XX and --mac XX:XX:XX:XX:XX:XX work is spectacularly pointless. That's a fundamental feature of how getopt_long works, and if we really felt the need to explicitly mention this fact for every single option that takes an argument, the usage message for pretty much all of GNU shell utils would grow by a huge amount. Similarly, the chances that we might pick the same random mac address is *possible*, but (a) it's so unlikely that it's not worth bothering about, and (b) having the same MAC address get used once in a very long while is actually a good thing. In fact, growing the number of addresses in the OUI list is actually, paradoxically, more likely to cause people to make MAC address stand out as being more likely to be a spoofed address. Using a smaller number of OUI's, but ones which are known to be commonly used by modern systems, especially ones of the same type as the user (i.e., if you are using a Thinkpad, you might want to use MAC addresses that are used byThinkpads and Dell and HP laptops but if you use a MAC address used by a medical device that would only be found in a hospital or clinic, or research sensor, it might cause comment for that address to show up at a Starbucks cafe). Bottom line, keeping patches that are out of sync from upstream is much more likely to cause harm than good. Cheers, - Ted P.S. In fact, it looks like macchiato[1] is more advanced in terms of actually providing security and privacy to its users, as opposed to something that only *appears* to provide security. [1] https://github.com/EtiennePerot/macchiato So I'm wondering if it's better to package macchiato and then encourage people to switch ot it, or to try to add macchiato's features into macchanger. The advantage of the former is that it's much less work. The advantage of the latter is that it's more likely Debian users will benefit, since they won't have to switch their boot scripts to use macchiato. And of course, probably the best thing to do is that this functionality should be built into network-manager. Where network-manager really should be using random MAC addresses while it is scanning for AP's, and depending on whether an AP (by MAC address) is a known friendly one (i.e., when you are at your home router) or one which is unknown (i.e., at a Starbucks cafe) it should automatically randomize the MAC address before doing the DHCP dance -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738460: macchanger: Random mac feature fails in all of the random mac assigning options
I've merged bugs 740947 and 738460 because they are fundamentally the
same bug. I suspect this was caused by a mistake while upgrading the
patch 08-fix_random_MAC_choice.patch when upgrading to the upstream
1.7.0 release.
Now instead of fixing the random MAC choice, it is completely breaking
it. After creating a random MAC address, the patch is now causing the
mc_mac_random() function to overwrite the freshly created mac address
with the original mac address. :-(
Since this fundamentally breaks the functionality of the macchanger
package, I've upgraded the severity of the bugs to grave. The
mac.c.patch contains the necessary fix to mac.c, and the
0001-Fix-random-mac-address-setting-which-was-completely-.patch
attachment contains a patch suitable for application via git am to
the git repository.
Do you have any objections if I upload this as a NMU? Or would you
prefer to update the package?
- Ted
--- src/mac.c.orig 2014-07-06 20:30:55.499840061 -0400
+++ src/mac.c 2014-07-06 20:31:25.319447245 -0400
@@ -75,8 +75,8 @@
* x1:, x3:, x5:, x7:, x9:, xB:, xD: and xF:
*/
- mac_t newmac;
- mc_mac_copy(mac, newmac);
+ mac_t origmac;
+ mc_mac_copy(mac, origmac);
do {
switch (last_n_bytes) {
@@ -100,9 +100,7 @@
} else {
mac-byte[0] |= 2;
}
- } while (mc_mac_equal (newmac, mac));
-
- mc_mac_copy(newmac, mac);
+ } while (mc_mac_equal (origmac, mac));
}
From e7c13f36b96d6e03e865308cc5690ca18fd9e290 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o ty...@mit.edu
Date: Sun, 6 Jul 2014 20:37:37 -0400
Subject: [PATCH] Fix random mac address setting, which was completely broken
Addresses-Debian-Bug: #738460, #740947
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
debian/changelog | 10 ++
debian/patches/08-fix_random_MAC_choice.patch | 49 ++-
2 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 074365d..27a49e5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+macchanger (1.7.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix a grave security bug -- the macchanger program is fundmantally
+was not working correctly due to a bug in the debian local patch
+08-fix_random_MAC_choice.patch. In fact, it was **breaking** the
+random MAC choice!?! (Closes: #738460, #740947)
+
+ -- Theodore Y. Ts'o ty...@mit.edu Sun, 06 Jul 2014 20:32:38 -0400
+
macchanger (1.7.0-1) unstable; urgency=medium
* New upstream release (Closes: #718849)
diff --git a/debian/patches/08-fix_random_MAC_choice.patch b/debian/patches/08-fix_random_MAC_choice.patch
index d3ba14d..54ccfb1 100644
--- a/debian/patches/08-fix_random_MAC_choice.patch
+++ b/debian/patches/08-fix_random_MAC_choice.patch
@@ -12,6 +12,8 @@ Subject: ensure random new MAC is not same as old MAC
src/main.c |1 +
2 files changed, 34 insertions(+), 19 deletions(-)
+Index: macchanger/src/mac.c
+===
--- macchanger.orig/src/mac.c
+++ macchanger/src/mac.c
@@ -41,6 +41,13 @@ mc_mac_dup (const mac_t *mac)
@@ -28,7 +30,7 @@ Subject: ensure random new MAC is not same as old MAC
void
mc_mac_free (mac_t *mac)
-@@ -68,27 +75,34 @@ mc_mac_random (mac_t *mac, unsigned char
+@@ -68,27 +75,32 @@ mc_mac_random (mac_t *mac, unsigned char
* x1:, x3:, x5:, x7:, x9:, xB:, xD: and xF:
*/
@@ -36,9 +38,25 @@ Subject: ensure random new MAC is not same as old MAC
- case 6:
- /* 8th bit: Unicast / Multicast address
- * 7th bit: BIA (burned-in-address) / locally-administered
-+ mac_t newmac;
-+ mc_mac_copy(mac, newmac);
-+
+- */
+- mac-byte[0] = (random()%255) 0xFC;
+- mac-byte[1] = random()%255;
+- mac-byte[2] = random()%255;
+- case 3:
+- mac-byte[3] = random()%255;
+- mac-byte[4] = random()%255;
+- mac-byte[5] = random()%255;
+- }
++ mac_t origmac;
++ mc_mac_copy(mac, origmac);
+
+- /* Handle the burned-in-address bit
+- */
+- if (set_bia) {
+- mac-byte[0] = ~2;
+- } else {
+- mac-byte[0] |= 2;
+- }
+ do {
+ switch (last_n_bytes) {
+ case 6:
@@ -55,33 +73,18 @@ Subject: ensure random new MAC is not same as old MAC
+ }
+
+ /* Handle the burned-in-address bit
- */
-- mac-byte[0] = (random()%255) 0xFC;
-- mac-byte[1] = random()%255;
-- mac-byte[2] = random()%255;
-- case 3:
-- mac-byte[3] = random()%255;
-- mac-byte[4] = random()%255;
-- mac-byte[5] = random()%255;
-- }
++ */
+ if (set_bia) {
+ mac-byte[0] = ~2;
+ } else {
+ mac-byte[0] |= 2;
+ }
-+ } while (mc_mac_equal (newmac, mac));
-
-- /* Handle the burned-in-address bit
-- */
-- if (set_bia) {
-- mac-byte[0] = ~2;
-- } else {
-- mac-byte[0] |= 2;
-- }
-+ mc_mac_copy(newmac, mac);
++ } while (mc_mac_equal (origmac, mac));
}
+Index: macchanger/src/main.c
+===
--- macchanger.orig/src/main.c
Bug#726578: Ping: pwgen: Multiple vulnerabilities in passwords generation
On Sun, Jan 12, 2014 at 09:27:14PM +0100, Arne Wichmann wrote:
This grave problem is now open for more than two months. Is there any plan
to resolve this?
First, the CVE about having the unavailability of /dev/random fail
hard -- sure, that should be a separate bug since that's a fix that I
think is reasonable at this point. We can now guarantee that
/dev/random exists everywhere. (And by that same token, if an
attacker can cause /dev/random not to be present, they probably have
root, so you're probably toast anyway. So I don't think it's going to
really improve things to remove the drand() fallback, but I don't have
strong feelings about that.)
Secondly, I'll note that one of the CVE's were rejected as not a
vulnerability. (In general it would have been better to have opened
seperate bugs for each CVE.)
Finally, whether you think the other two CVE's justify this to be
serious, let alone grave bug really depends on what you think the
goals of pwgen are. To quote from the manual page:
The pwgen program generates passwords which are designed to be easily
memorized by humans, while being as secure as possible. Human-memo‐
rable passwords are never going to be as secure as completely com‐
pletely random passwords. In particular, passwords generated by pwgen
without the -s option should not be used in places where the password
could be attacked via an off-line brute-force attack.On the other
hand, completely randomly generated passwords have a tendency to be
written down, and are subject to being compromised in that fashion.
So we could change the defaults to be pwgen -csy 20, in which case
you would get passwords like tihs:
L}U@lc_~i^n|ro!4uI- 1`;yXlYVMW%?E9)3A7G **}6BoBu=!~3)y?3v]Or
=:PC;H?E7*+6$c-QH URGgjUNG[\dSw\p7F-] _AXZ~(HYd8Q#%b!]'u:
~)0I-{)}_Ya*Q2nlWN; ^#t~1/'sf@*xz9GOhBuv e_[-_Fe{CD#]DY8@M^a
I'm not sure that would be an improvement, as simply no one would use
them.
OK, how about this? (Generated using pwgen -s).
vQ6uwkMk lSswO2MB tA8dYPpl KU1pQ2Xh 2XfxRyrC Za2xKx7h psPwHZ0c dOsC0JBX
JY3udA9c t6LzoiUq M0jR3AoS GOHkNE7G TeThsZz1 6cVi4ayY Poe4hPj7 o2a7OpPC
Xh24cRLO 1chQyseV 6c2k0O3B OkdgRxy4 K6Vc4JY2 ylO3IE9B gVvNxw6B 7wjcOXwF
Again, this will make the professional paranoids happy (although
perhaps not as happy as =:PC;H?E7*+6$c-QH), but its not clear that
real users would be any less likely to write ylO3IE9B on a sticky
note which is pasted to their monitor, or just in a passwords file
in their home directory.
So ultimately, a lot of this is about an argument over defaults, and I
think the higher level problem is that no matter what password policy
you use, passwords are doomed as a technology. Anything which is
secure against a brute force attack is impossible for a user to use,
unless they share passwords across multiple sites so they only have to
remember one password such as ylO3IE9B --- at which point they get
toast once some web site screws up in some way and gets penetrated by
bad guys.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709947: closed by ty...@mit.edu (Theodore Y. Ts'o) (Bug#708307: fixed in e2fsprogs 1.42.8-1)
On Mon, Aug 12, 2013 at 12:48:36AM -0700, Jonathan Nieder wrote: Odd --- wouldn't building e2fsprogs in a wheezy chroot avoid trouble, since libc in wheezy doesn't have that bug? Sorry, my mistake. I thought my Wheezy system had a pristine build environment, and I didn't realize that I had upgraded to an newer version of libc in order to make some third party software work. I just double checked and indeed there isn't a FTBFS problem in a Wheezy chroot. - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709947: closed by ty...@mit.edu (Theodore Y. Ts'o) (Bug#708307: fixed in e2fsprogs 1.42.8-1)
On Sat, Aug 10, 2013 at 06:39:33PM +0100, Adam D. Barratt wrote: On Thu, 2013-06-27 at 14:01 -0400, Theodore Ts'o wrote: It's a bit more than that. The full patch is here: https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?h=maintid=3df6014a3d216d19be7d2286de24e8ee106f18ad It disables the ability to display a stack trace when e2fsck crashes, which makes it easier for me to debug problems which only occur once and where I can't get access to the file system which provoked the fsck crash. Disabling reduces long term maintainability and RAS, but doesn't cause any other missing functionality to the user. Thanks for the information. Assuming that the fix has been tested on stable, please go ahead using 1.42.5-1.1+deb7u1 as the version number; apologies for the delay in getting back to you regarding this. We have a minor problem with uploading a fix. E2fsprogs currently FTBFS on stable, due to bug #707996, whose root cause is #708061. Personally, I blame glibc (#708061) for once again making a library-visible API change. (If they didn't want programs to use __secure_getenv, they shouldn't have made it visible.) However, the decision was to fix it by forcing a reconfigure and rebuild of all affected packages --- which in the case of e2fsprogs FTBFS, requires a rebuild and re-upload of util-linux (#707996). This has happened in unstable, but it hasn't happened in stable. There is (almost) nothing I can do to work around this problem in e2fsprogs, since the problem is that e2fsck.static is linking against the blkid library found in util-linux, and it is the blkid library which is referencing the symbol in glibc which has vanished in a puff of greasy black smoke. The (almost) referres to something really, REALLY, horrible which I could do, which is to use the antique version of the blkid library found in the e2fsprogs sources, from before we transferred it over to util-linux. I could only do this for e2fsck.static, but that would mean that e2fsck and e2fsck.static would be using different versions of the blkid library. Or I could do it for e2fsprogs as well, but then e2fsck and mke2fs would be using a version of blkid that hasn't been updated for several years, and which will have all sorts of bugs and lack features added since the move to util-linux. The really right answer is to rebuild (it doesn't even require a source-level change, since I believe the configure script should make the right thing happen once we build with the glibc with the gratuitous ABI change) and then reload util-linux. What say the release team? Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719375: xzgv: FTBFS: make[2]: install-info: Command not found
tags 719375 +pending thanks Thanks for the bug report. I've added the missing build-dependency to my sources and this will be fixed in the next release. - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709947: closed by ty...@mit.edu (Theodore Y. Ts'o) (Bug#708307: fixed in e2fsprogs 1.42.8-1)
On Tue, Jun 25, 2013 at 08:54:50PM +0100, Adam D. Barratt wrote:
On Tue, 2013-06-25 at 16:23 +0200, Peter Palfrader wrote:
On Fri, 21 Jun 2013, Debian Bug Tracking System wrote:
* Work around Debian Bug #712530 (Closes: #708307)
Thanks! Is that work-around suitable for a stable update as well?
That's presumably this:
--- e2fsprogs-1.42.5/debian/rules 2012-07-17 05:21:04.0 +
+++ e2fsprogs-1.42.8/debian/rules 2013-06-16 22:39:06.0 +
@@ -171,7 +171,9 @@
USRLIB ?= /usr/lib
endif
-STD_CONF_FLAGS ?= --enable-symlink-install $(MULTIARCH_CONF)
+BACKTRACE_CONF_FLAGS ?= $(shell if ${debdir}/scripts/test-backtrace ; then
echo --disable-backtrace ; fi)
+
+STD_CONF_FLAGS ?= --enable-symlink-install $(MULTIARCH_CONF)
$(BACKTRACE_CONF_FLAGS)
plus the associated script? What's the practical impact of disabling the
functionality?
It's a bit more than that. The full patch is here:
https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?h=maintid=3df6014a3d216d19be7d2286de24e8ee106f18ad
It disables the ability to display a stack trace when e2fsck crashes,
which makes it easier for me to debug problems which only occur once
and where I can't get access to the file system which provoked the
fsck crash. Disabling reduces long term maintainability and RAS, but
doesn't cause any other missing functionality to the user.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707996: Bug#701385: Block
reopen 707996 fixed 701385 e2fsprogs/1.42.8-1 thanks On Sun, May 12, 2013 at 09:08:47PM +0100, Roger Leigh wrote: I've uploaded an NMU of util-linux. This fixes the immediate issue. I'll also file a bug against eglibc. Hi Roger, Thanks for uploading an NMU of util-linux. I see that it is uploaded and version 2.20.1-5.4 is supposed to fix this issue. util-linux (2.20.1-5.4) unstable; urgency=low * Non-maintainer upload. * Rebuild against new eglibc; no source changes. libblkid.a uses the symbol __secure_getenv which is no longer present (it provides secure_getenv). Closes: #707996 It does appear to fix this on some architectures, and so many thanks for that. Unfortunately, e2fsprogs is still failing on some other architectures, including ia64, kfreebsd, mips, powerpc, and s390: https://buildd.debian.org/status/package.php?p=e2fsprogssuite=sid I looked on ia64 and apparently __sceure_getenv is still showing up in 2.20.1-5.4's version of libblkid.a: (sid_ia64-dchroot)tytso@merulo:~/e2fsprogs-1.42.8$ nm /usr/lib/ia64-linux-gnu/libblkid.a | grep secure_getenv U __secure_getenv (sid_ia64-dchroot)tytso@merulo:~/e2fsprogs-1.42.8$ dpkg -S /usr/lib/ia64-linux-gnu/libblkid.a libblkid-dev: /usr/lib/ia64-linux-gnu/libblkid.a (sid_ia64-dchroot)tytso@merulo:~/e2fsprogs-1.42.8$ dpkg -l libblkid-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion ArchitectureDescription +++-===-=-===-== ii libblkid-dev2.20.1-5.4ia64block device id library - headers and static libraries (sid_ia64-dchroot)tytso@merulo:~/e2fsprogs-1.42.8$ I'm not sure what to do at this point, but given that there doesn't seem to be anything I can do from my end as far as e2fsprogs is concerned, my intention is to close bug #701385, and to re-open #707996. - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708307: move libunwind7 to / on ia64/wheezy?
On Mon, May 27, 2013 at 02:00:12PM +0100, Adam D. Barratt wrote: However, in this case, that's somewhat complicated by the fact that libunwind in unstable doesn't actually build libunwind7 any more, which makes updating it somewhat tricky. If the maintainers do agree that Peter's solution is feasible then reports of testing on stable systems using the p-u package would be appreciated _before_ the point release. Is someone working on determinging whether we can move libunwind7 in wheezy? If so, should we move this bug to some other package other than e2fsprogs? I'm currently not working this bug on the assumption that someone is looking into the possibility of fixing this outside of e2fsprogs. If it turns out that ia64's libc is just busted, worst case I can disable the use of backtrace just on ia64 on debian, as a special-case workaround/hack. Let me know what the Debian Release team would prefer. - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708307: Bug#709947: move libunwind7 to / on ia64/wheezy?
Just to give a bit more color commentary, the reason for this is
because e2fsck is now using the backtrace(3) function, which is part
of libc on x86. It's using backtrace() to provide better
debuggability should there be a bug in e2fsck; see the code in
e2fsck/sigcatcher.c. It's a great way of debugging mysterious crashes
when you have e2fsck installed on hundreds of thousands of production
machines (and you don't have access to the file system images since
that might expose you to privacy- and/or security- sensitive data.)
However, on ia64, gcc is including it silently:
% cat /tmp/foo.c
#include stdio.h
#include unistd.h
#include stdlib.h
int main(int argc, const char **argv)
{
printf(Hello, world\n);
return 0;
}
% cc -c -o /tmp/foo.o /tmp/foo.c
% cc -v -o /tmp/foo /tmp/foo.o
...
/usr/lib/gcc/ia64-linux-gnu/4.6/collect2 --sysroot=/ --build-id
--no-add-needed --hash-style=both -dynamic-linker /lib/ld-linux-ia64.so.2 -o
/tmp/foo /usr/lib/gcc/ia64-linux-gnu/4.6/../../../ia64-linux-gnu/crt1.o
/usr/lib/gcc/ia64-linux-gnu/4.6/../../../ia64-linux-gnu/crti.o
/usr/lib/gcc/ia64-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/ia64-linux-gnu/4.6
-L/usr/lib/gcc/ia64-linux-gnu/4.6/../../../ia64-linux-gnu
-L/usr/lib/gcc/ia64-linux-gnu/4.6/../../.. -L/lib/ia64-linux-gnu
-L/usr/lib/ia64-linux-gnu /tmp/foo.o -lgcc --as-needed -lgcc_s -lunwind
--no-as-needed -lc -lgcc --as-needed -lgcc_s -lunwind --no-as-needed
/usr/lib/gcc/ia64-linux-gnu/4.6/crtend.o
/usr/lib/gcc/ia64-linux-gnu/4.6/../../../ia64-linux-gnu/crtn.o
Note the -lunwind which is included in the link line; it's a free gift which
is added
by gcc.
The other way of dealing with this is we could add an ia64-specific
hack which forces HAVE_BACKTRACE to be false in the e2fsprogs'
configure script when compiling for debian. This would be
extraordinarily ugly, and I'd prefer to do this only for ia64, since
as far as I am concerned it's working around an ia64 specific bug in
libc/libunwind. Still, if it's too hard to move libunwind to the root
partition, this would be another way to solve the problem.
Regards,
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708307: e2fsprogs: fsck.ext3 on ia64 is linked to /usr/lib/libunwind, which can live on a different partition, breaking boot
On Wed, May 15, 2013 at 01:57:25AM +0200, Thibaut VARENE wrote: Package: e2fsprogs Version: 1.42.5-1.1 Severity: grave Justification: renders package unusable #1) This looks to be ia64 specific. This is the output of ldd /sbin/fsck.ext3 on an x86-64 platform: linux-vdso.so.1 (0x7eb1a000) libext2fs.so.2 = /lib/x86_64-linux-gnu/libext2fs.so.2 (0x7f437aa07000) libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f437a803000) libblkid.so.1 = /lib/x86_64-linux-gnu/libblkid.so.1 (0x7f437a5db000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f437a3d6000) libe2p.so.2 = /lib/x86_64-linux-gnu/libe2p.so.2 (0x7f437a1ce000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f4379e2) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f4379c04000) /lib64/ld-linux-x86-64.so.2 (0x7f437ac68000) #2) We need to determine whether it's /sbin/fsck.ext3 or one of its shared libraries which is depending upon which is pulling in libunwind. Can you run the command objdump -p /sbin/fsck.ext3 | grep NEEDED? On my x86-64 system, this is what I see: NEEDED libext2fs.so.2 NEEDED libcom_err.so.2 NEEDED libblkid.so.1 NEEDED libuuid.so.1 NEEDED libe2p.so.2 NEEDED libc.so.6 Then do a recursive expansion of each of the libraries which you see, i.e. replace /sbin/fsck.ext3 with /lib/*/libblkid.so.1, etc. Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701385: Block
On Sun, May 12, 2013 at 03:09:42PM +0100, Roger Leigh wrote: This is due to libblkid.a using a symbol removed in the new glibc. It needs either a straight rebuild and/or updating to the latest upstream. Any reason to keep this open? Once util-linux is recompiled, the FTBFS will be resolved automatically. Or is eglibc buggy by not being backwards compatible, such that binaries compiled against the old glibc won't run if eglibc is installed, requiring a rebuild from source of the entire universe, and meaning that any old binaries from say, Steam, will all break? If so, I'd call this a huge, horrendous eglibc bug that should disqualify it from being installed as the default C library until it is fixed. Though Shalt Not Break Backwards Compatibility. - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701385: Block
On Sun, May 12, 2013 at 09:08:47PM +0100, Roger Leigh wrote: There's an additional issue with e2fsprogs: This is presumably the result of some texinfo or some related package in unstable being updated. Note that it also affects the e2fsprogs in experimental. As far as I know, this should be fixed upstream in 1.42.7 by: commit ccfedb17b110d8eec6343a1c3a6a2437fea4dbc2 Author: Theodore Ts'o ty...@mit.edu Date: Wed Jan 2 10:06:09 2013 -0500 Clean up texinfo files Fix up the com_err.texinfo file so it will produce a valid printed output, by cleaning up some errors in the texinfo file, and updating texinfo.tex to be consistent with the version in the doc subdirectory. Also add rules so we can generate pdf and ps files from com_err.texinfo and libext2fs.texinfo. Signed-off-by: Theodore Ts'o ty...@mit.edu There a bunch of bug fixes I need to get into e2fsprogs, after which point I'll release 1.42.8, and then upload into unstable, now that wheezy is finally release (hooray!) Hopefully by the time I'm ready to upload 1.42.7, util-linux will be fixed (or NUM'ed). Regards, - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698879: Bug#698745: dpkg breaks other packages during installation of a package
On Thu, Jan 24, 2013 at 08:41:38PM +0100, Guillem Jover wrote: [ Sven, thanks for the investigation on e2fsck-static! ] Please see the bug log for further details and logs, it's a split of a conglomerate bug, but the gist of it (should) be quoted below. I've still set the severity to serious, even if the issue is caused by very old packages, because as long as this is not handled during an upgrade of a release cycle, then the problem is bound to possibly be carried over from release to release. Is this really considered a serious bug? If so, I'd love to use this as an excuse to upgrade e2fsprogs to 1.42.7 since it fixes some pretty catastrophic data corruption bugs for users who try to resize file systems larger than 16TB, but when I looked at the most recent requirement that wheezy was frozen for all but serious and above error messages, and looking at the definition of serious, grave, and critical, it wasn't obvious that there were sufficient number of users who use 16TB file systems that I could in all honesty justify trying to ask the release team for a freeze exception for e2fsprogs. I'd be eager and delighted to fix this bug as a part of pushing out e2fsprogs 1.42.7, but I'd like to get a ruling from the release team that this is something they would support. Whether the justification is this particular symlink bug, or resize2fs potentially causing data loss for 16TB file systems, either is fine with me. :-) Thanks, - Ted -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685726: linux-image-3.2.0-3-amd64: return error when trying to format image file (mkfs -t ext4 file.img)
On Tue, Aug 28, 2012 at 04:09:05PM -0700, Ben Hutchings wrote: As discussed, Linux 3.2.y needs a backport of the fixes for this, which I think are: 968dee7 ext4: fix hole punch failure when depth is greater than 0 89a4e48 ext4: fix kernel BUG on large-scale rm -rf commands I have a backport of these patches rebased onto 3.2.28. They pass the full set of ext4 regression tests. However, for some reason I wasn't able to reproduce the problem on 3.2.28, even though I thought: mke2fs -t ext4 /dev/vdd mount -t ext4 /dev/vdd /vdd dd if=/dev/zero of=/vdd/test.img bs=1M count=200 mke2fs -t ext4 -F /vdd/test.img should have been a reliable reproduction with the problem. I'm pretty sure it worked to trigger the problem before, but for some reason it's not working for me. Anyway, here are the patches. If someone could confirm wheterh this resolve your problem, I would really appreciate it. Thanks!! - Ted From 4ec615eb5c0dc86d941520e40dfd9afdf8ccef87 Mon Sep 17 00:00:00 2001 From: Lukas Czerner lczer...@redhat.com Date: Mon, 19 Mar 2012 23:03:19 -0400 Subject: [PATCH 1/3] ext4: rewrite punch hole to use ext4_ext_remove_space() Commit 5f95d21fb6f2aaa52830e5b7fb405f6c71d3ab85 upstream. This commit rewrites ext4 punch hole implementation to use ext4_ext_remove_space() instead of its home gown way of doing this via ext4_ext_map_blocks(). There are several reasons for changing this. Firstly it is quite non obvious that punching hole needs to ext4_ext_map_blocks() to punch a hole, especially given that this function should map blocks, not unmap it. It also required a lot of new code in ext4_ext_map_blocks(). Secondly the design of it is not very effective. The reason is that we are trying to punch out blocks in ext4_ext_punch_hole() in opposite direction than in ext4_ext_rm_leaf() which causes the ext4_ext_rm_leaf() to iterate through the whole tree from the end to the start to find the requested extent for every extent we are going to punch out. And finally the current implementation does not use the existing code, but bring a lot of new code, which is IMO unnecessary since there already is some infrastructure we can use. Specifically ext4_ext_remove_space(). This commit changes ext4_ext_remove_space() to accept 'end' parameter so we can not only truncate to the end of file, but also remove the space in the middle of the file (punch a hole). Moreover, because the last block to punch out, might be in the middle of the extent, we have to split the extent at 'end + 1' so ext4_ext_rm_leaf() can easily either remove the whole fist part of split extent, or change its size. ext4_ext_remove_space() is then used to actually remove the space (extents) from within the hole, instead of ext4_ext_map_blocks(). Note that this also fix the issue with punch hole, where we would forget to remove empty index blocks from the extent tree, resulting in double free block error and file system corruption. This is simply because we now use different code path, where this problem does not exist. This has been tested with fsx running for several days and xfstests, plus xfstest #251 with '-o discard' run on the loop image (which converts discard requestes into punch hole to the backing file). All of it on 1K and 4K file system block size. Signed-off-by: Lukas Czerner lczer...@redhat.com Signed-off-by: Theodore Ts'o ty...@mit.edu --- fs/ext4/extents.c | 170 -- 1 file changed, 88 insertions(+), 82 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 54f2bdc..43ccd03 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -45,6 +45,14 @@ #include trace/events/ext4.h +/* + * used by extent splitting. + */ +#define EXT4_EXT_MAY_ZEROOUT 0x1 /* safe to zeroout if split fails \ + due to ENOSPC */ +#define EXT4_EXT_MARK_UNINIT1 0x2 /* mark first half uninitialized */ +#define EXT4_EXT_MARK_UNINIT2 0x4 /* mark second half uninitialized */ + static int ext4_split_extent(handle_t *handle, struct inode *inode, struct ext4_ext_path *path, @@ -52,6 +60,13 @@ static int ext4_split_extent(handle_t *handle, int split_flag, int flags); +static int ext4_split_extent_at(handle_t *handle, + struct inode *inode, + struct ext4_ext_path *path, + ext4_lblk_t split, + int split_flag, + int flags); + static int ext4_ext_truncate_extend_restart(handle_t *handle, struct inode *inode, int needed) @@ -2307,7 +2322,7 @@ ext4_ext_rm_leaf(handle_t *handle, struct inode *inode, struct ext4_extent *ex; /* the header must be checked already in ext4_ext_remove_space() */ - ext_debug(truncate since %u in leaf\n, start); + ext_debug(truncate since %u in leaf to %u\n, start, end); if (!path[depth].p_hdr) path[depth].p_hdr = ext_block_hdr(path[depth].p_bh); eh = path[depth].p_hdr; @@ -2342,7 +2357,7 @@ ext4_ext_rm_leaf
Bug#364516: this bug..
On Sun, Apr 23, 2006 at 08:08:47PM -0400, Joey Hess wrote: Hi Ted.. to summarize what needs doing for this bug, /usr/share/initrd-tools/scripts/e2fsprogs currently contains LD_ASSUME_KERNEL=2.4. This needs to change to LD_ASSUME_KERNEL=2.4.1 Two questions first of all, this is a testing/unstable bug, right? I had a vague memory from a LCA 2006 presentation that we were going to be desupporting the 2.4 kernel, or did I get that wrong? Not that this means we shouldn't fix the bug, but I'm wondering whether this should really be considered an RC bug or not; how many people are still using a 2.4 kernel on testing/unstable, and is that a supported configuration. I would have at thought this was at best an important or normal bug. The answer to this question would basically affect whether or not I try to upload something right away, or after I finish a few other changes currently on deck and can afford to wait a few days. Secondly, could you try this out since you obviously have a 2.4 system handy? What it does is avoid setting LD_ASSUME_KERNEL at all if the script is currently running on a 2.4 kernel. That should make the script more robust, for someone who is purely running 2.4, and glibc changes the minimum kernel version again. It would only set LD_ASSUME_KERNEL in the presumably rare case where you are running a 2.6 kernel, and for some reason want to install and run mkinitrd on a 2.4 kernel. IIRC, that was the scenario that needed the LD_ASSUME_KERNEL environment variable in the first place, so we might as well restrict it to that. Thanks, regards, - Ted diff -r caa07aa7226d debian/initrd-tools.e2fsprogs --- a/debian/initrd-tools.e2fsprogs Sun Apr 23 12:43:40 2006 -0400 +++ b/debian/initrd-tools.e2fsprogs Mon Apr 24 02:34:48 2006 -0400 @@ -9,8 +9,12 @@ cp /usr/lib/e2initrd_helper $INITRDDIR/b case $VERSION in 2.4.*) - LD_ASSUME_KERNEL=2.4 - export LD_ASSUME_KERNEL +case uname -r in + 2.4.*) : ;; + *) LD_ASSUME_KERNEL=2.4.1 + export LD_ASSUME_KERNEL + ;; +esac ;; esac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360652: e2fsprogs: running mkfs.ext3 fails (Device or resource busy)
tags 360652 +pending
thanks
On Mon, Apr 03, 2006 at 10:19:05PM +0200, Michael Prokop wrote:
While older versions of mkfs.ext3 worked without any problems
running mkfs.ext3 with the new version fails.
Oops, thanks for pointing this out. The following patch will fix
things up.
- Ted
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 1bfd437f2f618fe407d8052bbf654204a569919b
# Parent 5fcba7289787d4304d65bdc9aedb6fe7b627cf2d
Fix ext2fs_add_journal_inode() when filesystem is opened in exclusive mode
If the filesystem is opened in exclusive mode, then device will be
busy by definition, so don't return -EBUSY. This caused mke2fs -j to
fail on the 1.39-WIP (29-Mar-2006) release. (Addresses Debian Bug:
#360652)
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
diff -r 5fcba7289787 -r 1bfd437f2f61 lib/ext2fs/ChangeLog
--- a/lib/ext2fs/ChangeLog Sun Apr 2 10:04:36 2006 -0400
+++ b/lib/ext2fs/ChangeLog Tue Apr 4 19:23:41 2006 -0400
@@ -1,3 +1,11 @@
+2006-04-04 Theodore Ts'o [EMAIL PROTECTED]
+
+ * mkjournal.c (ext2fs_add_journal_inode): If the filesystem is
+ opened in exclusive mode, then device will be busy by
+ definition, so don't return -EBUSY. This caused mke2fs -j
+ to fail on the 1.39-WIP (29-Mar-2006) release. (Addresses
+ Debian Bug: #360652)
+
2006-03-29 Theodore Ts'o [EMAIL PROTECTED]
* bitops.h (ext2fs_set_bit, ext2fs_clear_bit): Fix the constraints
diff -r 5fcba7289787 -r 1bfd437f2f61 lib/ext2fs/mkjournal.c
--- a/lib/ext2fs/mkjournal.cSun Apr 2 10:04:36 2006 -0400
+++ b/lib/ext2fs/mkjournal.cTue Apr 4 19:23:41 2006 -0400
@@ -370,7 +370,8 @@
close(fd);
journal_ino = st.st_ino;
} else {
- if (mount_flags EXT2_MF_BUSY) {
+ if ((mount_flags EXT2_MF_BUSY)
+ !(fs-flags EXT2_FLAG_EXCLUSIVE)) {
retval = EBUSY;
goto errout;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360046: e2fsprogs - FTBFS: Missing build dependency: libdevmapper-dev
On Thu, Mar 30, 2006 at 11:44:50AM +0200, Bastian Blank wrote: Package: e2fsprogs Version: 1.38+1.39-WIP-2006.03.29-1 Severity: serious There was an error while trying to autobuild your package: Oops, I thought libselinux1-dev would automatically drag in libdevmapper-dev. Mea culpa. I will be uploading the following fix shortly: - Ted diff -r b4e812bd7b51 debian/changelog --- a/debian/changelog Thu Mar 30 01:06:49 2006 -0500 +++ b/debian/changelog Thu Mar 30 13:03:19 2006 -0500 @@ -1,3 +1,9 @@ +e2fsprogs (1.38+1.39-WIP-2006.03.29-2) unstable; urgency=low + + * Added missing build dependency on libdevmapper-dev. (Closes: #360046) + + -- Theodore Y. Ts'o [EMAIL PROTECTED] Thu, 30 Mar 2006 12:33:30 -0500 + e2fsprogs (1.38+1.39-WIP-2006.03.29-1) unstable; urgency=low * Add udeb: lines to the Debian's shlibs files (Closes: #356293) diff -r b4e812bd7b51 debian/control --- a/debian/controlThu Mar 30 01:06:49 2006 -0500 +++ b/debian/controlThu Mar 30 13:03:19 2006 -0500 @@ -2,7 +2,7 @@ Section: admin Priority: required Maintainer: Theodore Y. Ts'o [EMAIL PROTECTED] -Build-Depends: texi2html, gettext, texinfo, dc, libsepol1-dev, libselinux1-dev, debhelper (= 4) +Build-Depends: texi2html, gettext, texinfo, dc, libsepol1-dev, libdevmapper-dev, libselinux1-dev, debhelper (= 4) Standards-Version: 3.6.1 Package: e2fsck-static -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345519: e2fsprogs: FTBFS: profile.c:70:21: error: com_err.h: No such file or directory
On Sun, Jan 01, 2006 at 03:00:04PM +0100, Kurt Roeckx wrote: Package: e2fsprogs Version: 1.38+1.39-WIP-2005.12.10-2 Severity: serious Hi, Your package is failing to build on most arches with the following error: CC /build/buildd/e2fsprogs-1.38+1.39-WIP-2005.12.10/e2fsck/profile.c /build/buildd/e2fsprogs-1.38+1.39-WIP-2005.12.10/e2fsck/profile.c:70:21: error: com_err.h: No such file or directory make[3]: *** [profile.o] Error 1 Whoops, this patch is needed so you don't have to have the comerr-dev package loaded on your system; thanks for pointing this out. I'll upload a fix soon. - Ted diff -r b3e5c52c1090 e2fsck/profile.c --- a/e2fsck/profile.c Sat Dec 31 16:46:46 2005 -0500 +++ b/e2fsck/profile.c Sun Jan 1 21:24:36 2006 -0500 @@ -67,7 +67,7 @@ #include pwd.h #endif -#include com_err.h +#include et/com_err.h #include profile.h #include prof_err.h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318463: Proposed update to e2fsprogs for stable
On Sun, Aug 21, 2005 at 09:51:21PM -0700, Steve Langasek wrote: Should I go ahead and upload the following to stable-proposed updates? e2fsprogs (1.37-2sarge2) testing; urgency=low ^^^ If so, please be sure to fix the target in the changelog :) Oh, yeah, oops, thanks. :-) - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318463: Proposed update to e2fsprogs for stable
On Mon, Aug 22, 2005 at 10:30:09AM +0200, Martin Schulze wrote: Steve Langasek wrote: On Sun, Aug 21, 2005 at 11:20:49PM -0400, Theodore Ts'o wrote: I would like to upload the following release to sarge to fix a grave bug (#318463), and taking the opportunity to fix a few other potential core-dumping inducing bugs. All of these are cherry picked from the e2fsprogs development tree. Should I go ahead and upload the following to stable-proposed updates? e2fsprogs (1.37-2sarge2) testing; urgency=low ^^^ If so, please be sure to fix the target in the changelog :) Even though this doesn't seem to be critical I'd accept it for the first stable update. Thanks! I've just uploaded e2fsprogs-1.37-2sarge2. Unfortunately thanks to things like SE Linux, Samba, etc., the use of extended attributes is much more common now, and so filesystem corruptions which will lead to e2fsck core dumping are much more likely. (The bug was introduced in e2fsprogs 1.36, BTW). I've been getting a number of people reporting this bug as of late, from Debian, Gentoo, and others. Unfortunately no one detected it the testing/unstable releases until after sarge had released. When is the first stable update planned to be released? Regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318463: Proposed update to e2fsprogs for stable
I would like to upload the following release to sarge to fix a grave bug (#318463), and taking the opportunity to fix a few other potential core-dumping inducing bugs. All of these are cherry picked from the e2fsprogs development tree. Should I go ahead and upload the following to stable-proposed updates? Thanks, regards, - Ted e2fsprogs (1.37-2sarge2) testing; urgency=low * Fix e2fsck segfault if a disconnected inode contains extended attrbutes (Closes: #318463) * Fix compile_et and com_err library so it is compatible with MIT Kerberos 1.4.x (otherwise it's core dump city) * Fix use-after-free bug in e2fsck * Fix type-alias bug which can cause a reproducible SEGV on at least one ia64 configuration. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310823: e2fsprogs: e2fsck gets a signal 11 when clearing a i_fsize
severity 310823 normal tags 310823 unreproducible thanks On Thu, May 26, 2005 at 11:03:59AM +0200, Jo?o Miguel Neves wrote: Subject: e2fsprogs: e2fsck gets a signal 11 when clearing a i_fsize Package: e2fsprogs Version: 1.37+1.38-WIP-0509-1 Severity: critical Justification: breaks the whole system This is hardly a critical bug, as it occurs only in the case of a filesystem corruption. It by the way is also something that I can't reproduce. I had problems with the my root filesystem (setup at /dev/hda2). Automatic fsck at boot failed. fsck -y /dev/hda2 also failed. fsck /dev/hda2 reported a signal 11 everytime after reporting (from memory): i_fsize for inode XXX is YY (...) should be zero. Cleary? Everytime I pushed y, it would crash. When you have a problem like this, ***please*** save the full transcript of the e2fsck run, and ideally, grab an raw e2image dump (see the e2image man page). Otherwise there's very little I can do. The case of clearing i_fsize is something which is already tested in e2fsck's regression test suite (in the test f_badinode), and I always test e2fsprogs against the full set of regression tests before I do a release. I've tried it again, as well as trying a few other variations to see if I can trigger a core dump, and I have not been able to. Workaround was to say no to Cleary?, let fsck put them in /lost +found, note down the inode numbers and delete the files (mounting the filesystem with errors). ... and I assume this means that you didn't capture any further information before you worked around the problem. Sigh. Please send me any additional information, since without any other way to work this bug, I may have to close it as undreproducible. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302200: e2fsprogs: segmentation fault on creating ext2/ext3 on IA-64
On Sun, Apr 03, 2005 at 12:18:14AM -0800, Steve Langasek wrote: Ok. In the meantime, I think not being able to create new filesystems is a grave bug that makes this version of the package unreleasable given that it would completely break the installer on ia64 if it reached sarge. Tagged 'sid' so that it doesn't attract unnecessary attention. E2fsprogs has been frozen for months as it is part of base, so the if it reached sarge is rather moot. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302200: e2fsprogs: segmentation fault on creating ext2/ext3 on IA-64
severity 302200 normal
tags 302200 +pending +patch
thanks
On Wed, Mar 30, 2005 at 06:06:28PM +0200, Michael Vistein wrote:
Package: e2fsprogs
Version: 1.37-1
Severity: grave
Justification: renders package unusable
This is a problem only on IA64, and only breaks mke2fs, and not the
other e2fsprogs programs. The problem seems to be the malloc() goes
wonky if we don't include stdlib.h. The following patch fixes the
problem. I'll upload a fixed set of sources very shortly.
- Ted
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/31 00:01:33-05:00 [EMAIL PROTECTED]
# ostype.c (e2p_os2string): Check to make sure malloc() is
# successful before attempting to copy into it. Add
# #include of stdlib.h to fix a core dump bug on the IA64
# architecture. (Addresses Debian Bug #302200)
#
# lib/e2p/ostype.c
# 2005/03/31 00:01:33-05:00 [EMAIL PROTECTED] +3 -1
# ostype.c (e2p_os2string): Check to make sure malloc() is
# successful before attempting to copy into it. Add
# #include of stdlib.h to fix a core dump bug on the IA64
# architecture. (Addresses Debian Bug #302200)
#
# lib/e2p/ChangeLog
# 2005/03/31 00:01:33-05:00 [EMAIL PROTECTED] +7 -0
# Update log
#
diff -Nru a/lib/e2p/ChangeLog b/lib/e2p/ChangeLog
--- a/lib/e2p/ChangeLog 2005-03-31 00:01:46 -05:00
+++ b/lib/e2p/ChangeLog 2005-03-31 00:01:46 -05:00
@@ -1,3 +1,10 @@
+2005-03-30 Theodore Ts'o [EMAIL PROTECTED]
+
+ * ostype.c (e2p_os2string): Check to make sure malloc() is
+ successful before attempting to copy into it. Add
+ #include of stdlib.h to fix a core dump bug on the IA64
+ architecture. (Addresses Debian Bug #302200)
+
2005-03-21 Theodore Ts'o [EMAIL PROTECTED]
* Release of E2fsprogs 1.37
diff -Nru a/lib/e2p/ostype.c b/lib/e2p/ostype.c
--- a/lib/e2p/ostype.c 2005-03-31 00:01:46 -05:00
+++ b/lib/e2p/ostype.c 2005-03-31 00:01:46 -05:00
@@ -9,6 +9,7 @@
#include e2p.h
#include string.h
+#include stdlib.h
const char *os_tab[] =
{ Linux,
@@ -32,7 +33,8 @@
os = (unknown os);
ret = malloc(strlen(os)+1);
-strcpy(ret, os);
+ if (ret)
+ strcpy(ret, os);
return ret;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
