On Tue, Aug 13, 2024 at 03:18:02PM +0200, Giuseppe Sacco wrote:
> Hello Santiago,
>
> Il giorno mar, 13/08/2024 alle 12.34 +0200, Santiago Vila ha scritto:
> [...]
> > Hello. This looks like a problem with fsck.ext4 to me.
> >
> > Does the problem go away if you regenerate the initrd of the kerne
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 w
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 ../defaul
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 wis
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 "sim
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
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
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 fi
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
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'
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 const
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*
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 dependencie
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 comm
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 b
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. T
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
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 ("f
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 ste
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 t
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
> >> Bookwor
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 i
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
ome 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 t
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
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 225e5d093b519f9dbe9fcaacd995426f0e519
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
date 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 bc8
ficient 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
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
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
libspars
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-ut
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
> >
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.
Thi
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
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
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
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 checke
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
Date: Thu Dec 22 22:23:58 2016 -0500
lib/et/testcases: checked in imap_err.et from cyrus-
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.
500, 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 snaps
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 wro
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 t
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).
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
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 b
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. :)
O
hile (mc_mac_equal (&origmac, mac));
}
>From e7c13f36b96d6e03e865308cc5690ca18fd9e290 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
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
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
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
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". Troub
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=maint&id=3df60
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 st
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 i
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 i
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 de
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
l.
As far as I know, this should be fixed upstream in 1.42.7 by:
commit ccfedb17b110d8eec6343a1c3a6a2437fea4dbc2
Author: Theodore Ts'o
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 clean
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 resolv
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
rd requestes into punch hole to the backing file). All of
it on 1K and 4K file system block size.
Signed-off-by: Lukas Czerner
Signed-off-by: "Theodore Ts'o"
---
fs/ext4/extents.c | 170 --
1 file changed, 88 insertions(+), 82
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 tes
lusive 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/e
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
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/
On Mon, Aug 22, 2005 at 05:24:25PM -0400, Theodore Ts'o wrote:
>
> Thanks! I've just uploaded e2fsprogs_1.37-2sarge2.
>
Oops. It was rejected due to e2fsprogs_1.37-2sarge2 being newer than
what's in testing.
This is apparently because e2fsprogs has been frozen, so
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), a
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 :)
O
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-propose
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 wh
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
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
+ arc
72 matches
Mail list logo
