severity 1072566 minor
thanks
On Thu, Jun 06, 2024 at 12:19:39PM +0200, Fabio Fantoni wrote:
> You wrote about metadata_csum but the issue is not with it, included
> also in the root filesystem that don't have issue with backup but with
> metadata_csum_seed that is different and newer, anyway
On Tue, Jun 04, 2024 at 02:33:27PM +0200, Fabio Fantoni wrote:
> Package: e2fsprogs
> Version: 1.47.1~rc2-1~bpo12+1
> Severity: important
>
> Dear Maintainer,
>
> After a debug of a issue with backup I spotted that the cause was
> metadata_csum_seed and orphan_file enabled by default in
reassign 1070042 e2fsprogs 1.47.1~rc1-1
retitle mke2fs -d foo.tar is broken on mips64el
thanks
On Tue, Apr 30, 2024 at 11:12:36AM +0300, Peter Pentchev wrote:
> > AC_SYS_LARGEFILE was added to e2fsprogs configure.ac 2 years ago,
> > therefore manual
> > #define _FILE_OFFSET_BITS 64
> >
ps64el=1.47.1%7Erc1-1=1714294103=0
Cheers,
- Ted
commit 018cd6e9a659917ac1374775f5a60b1cf0be182c
Author: Theodore Ts'o
Date: Mon Apr 29 16:31:14 2024 -0400
debian: don't build with libarchive on mips64el
The libarchive functionality in "mke2fs -d foo.tar" is breakin
- Ted
commit 795dcc264f48098ca5b214bba7d1b94189b2e491
Author: Theodore Ts'o
Date: Sun Nov 19 21:06:12 2023 -0500
tune2fs.c: define PATH_MAX if it is not defined by the system headers
This is needed to compile on GNU/Hurd.
Addresses-Debian-Bug: #1056145
Signed-off-by: Theodo
On Sat, Nov 11, 2023 at 10:22:21PM +0100, Christoph Biedl wrote:
> Package: e2fsprogs
> Version: 1.47.0-2+b1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
>
> Greetings,
>
> Summary: If the APM_EMULATION kernel option is enabled (and built-in),
> fsck during
On Tue, Sep 26, 2023 at 10:31:41PM +0200, Helmut Grohne wrote:
> Source: e2fsprogs
> Version: 1.47.0-2
> Tags: ftbfs patch
> User: helm...@debian.org
> Usertags: dep17m2
>
> We want to change the value of systemdsystemunitdir in systemd.pc to
> point below /usr. e2fsprogs' upstream build system
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
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
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
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
On Sun, Apr 23, 2023 at 09:34:39AM +0200, The MH wrote:
> Package: e2fsprogs
> Version: 1.46.5
> Severity: minor
>
> I did not find this bug in the patchnotes for the latest versions on
> e2fsprogs.sourceforge.net/e2fsprogs-release.html, so I assume it is
> still present.
>
> I stumbled upon
On Tue, Feb 21, 2023 at 12:17:20PM +, Christopher Obbard wrote:
> Control: severity -1 important
> Control: retitle -1 e2fsprogs generates filesystems which cannot be
> mounted on systems with older e2fsprogs
>
> It turns out for debos the situation is a bit different. Since debos
> uses
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
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
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
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. Th
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.
>
>
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
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
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
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
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.
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
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
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
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
> >>
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
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
es, 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
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
OK, I've done some final fixups (there was something weird with the
spelling patch that caused dgit to have heartburt) and have done a
"dgit push-source" and pushed git tree to salsa. Thanks again for
your help.
Since you are investigating using f2fs, I thought I would let you know
that there
On Mon, Dec 12, 2022 at 09:41:38AM +0300, Michael Tokarev wrote:
>
> I pushed "mjt" branch yesterday to the repository (without pristine-tar
> and upstream pieces so far) which updates f2fs to 1.15 and adds minor
> cleanups to d/rules. Please take a look.
Thanks! The main thing I will note is
On Sun, Dec 11, 2022 at 09:55:48AM +0300, Michael Tokarev wrote:
>
> Hmm. I'm a bit afraid it will be similar to my experience with samba.
> I come across a (data corruption) bug, discovered it's been fixed upstream
> a few years ago, tried to push the fix to debian, and ended up becoming a
>
On Fri, Dec 09, 2022 at 11:16:46AM +0300, Michael Tokarev wrote:
> Package: f2fs-tools
> Version: 1.14.0-2
> Severity: important
>
> When running an fsck.f2fs on a readonly-mounted filesystem (root filesystem
> for example, which obviously can not be unmounted), fsck.f2fs always fails:
>
> I
ing to improve the testing so this would have gotten caught
earlier.
- Ted
commit 9a8c5b0d061554fedd7dbe894e63aa34d0bac7c4
Author: Theodore Ts'o
Date: Thu Oct 27 16:04:36 2022 -0400
ext4: update the backup superblock's at the end of the online resiz
On Fri, Oct 14, 2022 at 03:37:29PM +0200, Marco d'Itri wrote:
> On Oct 14, Vincent Lefevre wrote:
>
> > > This is obviously convenient on Guillem's part, but we have to optimize
> > > systems by default for the general case and not just for dpkg -i.
> > This dpkg FAQ says that this is not
On Tue, Oct 04, 2022 at 01:45:31PM +0200, David Gonzalo Rodriguez wrote:
> Package: libcom-err2
> Version: 1.46.5-2~bpo11+2
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: z80u...@gmail.com
What is the error message when you run "sudo apt install wine32"?
What is the reason for believing
On Thu, Aug 11, 2022 at 08:02:15PM +1200, Alex King wrote:
> We are using Direct IO to slow mkfs and therefore lower I/O load. I'm not
> aware of a way to directly ask mkfs to reduce the I/O load or work more
> slowly. Using ionice at idle priority would be ideal, but we are using the
>
I'm just curious --- what is your use case for wanting to use Direct
I/O in mke2fs? In general, using buffered I/O is much faster, and the
historically, Direct I/O option was primarily used as a workaround for
kernels (long ago) that were buggy with respect to write throttling,
and userspace
Applied upstream as commit: ab51d587
On Thu, Apr 28, 2022 at 09:30:45AM +0200, Salvatore Bonaccorso wrote:
>
> Theodore, btw the BTS reference for the e2fsprogs issue is #1010263
> and the CVE id CVE-2022-1304.
Yes, I've noted that already.
> #1010264 and CVE-2022-28391 is respectively for busybox. the bug
> already reassigned
On Wed, Apr 27, 2022 at 01:55:27PM +0200, Moritz Muehlenhoff wrote:
> Package: e2fsprogs
> Version: 1.46.5-2
> Severity: important
>
> This issue was found by Alpine:
> https://gitlab.alpinelinux.org/alpine/aports/-/issues/13661
>
> Details and the patches they used are in the report above, but
On Tue, Mar 22, 2022 at 11:59:49AM -0400, Daniel Kahn Gillmor wrote:
> Package: libext2fs2
> Version: 1.46.5-2
> Control: affects -1 + fastboot android-sdk-platform-tools
>
> The -E android_sparse option for mke2fs fails because libext2fs2 reports
> EXT2_ET_UNIMPLEMENTED, presumably because
Hi Jonas,
I was checking Debian Bug tracker to make sure the bug metadata was
correct after closing it, and I realized that you had replied on
Tuesday, February 22nd (Message #10). My apologies, for some reason
that message never arrived at my inbox (and I checked the spam filter
as well). So I
found 1003583 e2fsprogs/1.46.5-2~bpo11+1
notfound 1003583 e2fsprogs/1.46.2-2
thanks
> Dear Maintainer,
>
>* e2fsprogs and libext2fs2 version 1.46.5-2~bpo11+1 are in the
> bullseye-backports repository
>* both depend on libc6 (>= 2.33) for amd64
>* libc6 versions 2.33 and higher do
On Thu, Aug 19, 2021 at 11:46:21AM +0200, Michael Biebl wrote:
> Am 19.08.21 um 08:27 schrieb Michael Biebl:
> > I'll check later today, if i-s-h (init-system-helpers) does properly
> > handle this new path. If so, I'd say the bug should be reassigned to
> > lintian and we should start
tags 992094 +pending
thanks
On Wed, Aug 11, 2021 at 02:56:06PM +0200, Heinrich Schuchardt wrote:
>
> https://ci.debian.net/data/autopkgtest/unstable/amd64/e/e2fsprogs/14285096/log.gz
>
> shows the following errors for debian/tests/fuse2fs:
>
> mke2fs:
> No such file or directory while trying
ble
> 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
tags 986332 +pending
thanks
The following commit should fix things; it will be in the next release
of e2fsprogs.
- Ted
commit a3f844da91f0c01209a5d778a5af57fabe245332
Author: Theodore Ts'o
Date: Fri Jul 16 22:31:26 2021 -0400
libe2p: use
tags 989612 +pending
thanks
Thanks for reporting this bug. The following commit should fix the
issue.
- Ted
commit 942b00cb9d2f2b52f4c58877d523145ee59a89b0
Author: Theodore Ts'o
Date: Wed Jul 21 15:46:09 2021 -0400
mke2fs: do not warn
On Thu, Jun 17, 2021 at 10:39:20AM +0200, Paul Gevers wrote:
> Control: block 988830 by -1
>
> Hi Josh, Theodore,
>
> On Tue, 08 Jun 2021 09:14:41 -0700 Josh Triplett
> wrote:
> > mke2fs with -E offset=N does not seem to take the offset into account
> > when checking the target to see if it
On Sat, Jun 19, 2021 at 08:44:52PM -0700, Josh Triplett wrote:
> On Thu, Jun 17, 2021 at 10:36:48AM +0200, Paul Gevers wrote:
> > On Tue, 08 Jun 2021 20:22:39 -0700 Josh Triplett
> > wrote:
> > > Package: e2fsprogs
> > > Version: 1.46.2-2
> > > Severity: important
> > > X-Debbugs-Cc:
7f92fa430e Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o
+Date: Mon, 3 May 2021 15:37:33 -0400
+Subject: [PATCH 1/5] 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
On Thu, May 13, 2021 at 11:04:14PM -0400, Theodore Ts'o wrote:
> I'll give you another example that we learned the hard way. Depending
> on how tight you make your memory cgroups and how tight you constrain
> your I/O controller, it's possible for write throttling --- where
> pro
ear in files which
were written shortly before the crash."
- https://www.kernel.org/doc/html/latest/admin-guide/ext4.html#data-mode
> I'm also not sure, because everywhere I've looked appears to document
> that this technology is not filesystem specific (except the Facebook
>
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
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 bc8e4e56fcdd2a9e65cc87f6303d
On Mon, Apr 05, 2021 at 12:46:48AM +0200, Chris Hofstaedtler wrote:
>
> AFAICT, for /dev/dri/card0 the ioctl ends up in the kernel's
> drm_ioctl [2], which will blindly call copy_to_user assuming the
> output size is the same as the input size (8 bytes). This is wrong
> for FS_IOC_GETFLAGS, at
When resize2fs exits early, perhaps because of an error, we should
free the file system so that if MMP is in use, the MMP block is reset.
This also releases the memory to avoid memory leak reports.
Addresses-Debian-Bug: #984472
Signed-off-by: Theodore Ts'o
---
resize/main.c | 50
.
Prevent this from happening by reserving the MMP block as a file
system metadata block (which it is) in resize2fs's accounting.
Addresses-Debian-Bug: #984472
Signed-off-by: Theodore Ts'o
---
resize/resize2fs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/resize/resize2fs.c b/resize
On Fri, Mar 05, 2021 at 09:48:50PM -0500, Theodore Ts'o wrote:
> I can't reproduce the problem given your file system image. Given
> your description, this is almost certainly operator error.
OK, I was finally able to reproduce the problem, but not using your
reproduction instructio
I can't reproduce the problem given your file system image. Given
your description, this is almost certainly operator error.
> $ e2fsck -f /dev/zvol/filling/store/nabijaczleweli/e2test
> e2fsck 1.46.2 (28-Feb-2021)
> e2fsck: MMP: e2fsck being run while checking MMP block
> MMP check failed: If
tag 926130 +moreinfo
thanks
On Sat, May 25, 2019 at 06:54:57PM -0400, Theodore Ts'o wrote:
> On Tue, May 14, 2019 at 09:42:58AM +0200, Laurent Bigonville wrote:
> >
> > I've attached the requested logs. I don't see anything weird here.
>
> Yeah, I'm not seeing anythi
On Wed, Jan 27, 2021 at 01:10:33AM +0100, Christoph Biedl wrote:
>
> Yes, and my question here: Is it possible the existence of that bogus
> fscrypt feature flag made e2fsck or the kernel think this is an ext4,
> and things went downhill from there? That's a situation I'd like to
> avoid - since
On Tue, Jan 26, 2021 at 12:10:20AM +0100, Christoph Biedl wrote:
> Package: e2fsprogs
> Version: 1.44.5-1+deb10u3
> Severity: normal
>
> Dear Maintainer,
>
> at first, I am sorry to tell I cannot provide the raw data. I was quite
> in a hurry and overwrote it before realizing its high value for
On Wed, Jan 06, 2021 at 02:31:46PM +0200, Andrei POPESCU wrote:
> Package: e2fsprogs
> Version: 1.44.5-1+deb10u3
> Severity: normal
> Tags: upstream
>
> According to the man page the -p option should print out "percentage
> completion bars", though this was not done on a recent operation
>
n the next release of
e2fsprogs.
- Ted
commit 9b2c33f9daaecc593755fa6d45b6d910f8fe2f7b
Author: Theodore Ts'o
Date: Thu Jul 11 13:28:05 2019 -0400
e2scrub_all: fix "e2scurb_all -r"
The e2scrub_all program was broken by commit c7
Control: tags -1 +pending
On Sat, Jun 29, 2019 at 10:48:35PM +0100, James Clarke wrote:
> As of the above version, e2fsprogs Build-Depends on udev and systemd
> (and cron too which, whilst somewhat perplexing, is not the issue here),
> thereby rendering its build dependencies unsatisfiable on
On Thu, Jul 04, 2019 at 08:52:02PM +0200, Marc Haber wrote:
>
> I agree with you there. A few word of explanation in some readme or in
> the mail sent out by /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_fail)
> would have been nice though.
I'll at adding some comments in the scripts.
> >
ight.
It's therefore unnecessary to have a separate -C flag to achieve the
same outcome for cron jobs. Merge the two together.
Signed-off-by: Darrick J. Wong
Signed-off-by: Theodore Ts'o
> (additional issue #2)
> e2scub_all -n reveals that it would actually invoke
By the way, here are the official criteria from the Debian Developer's
Reference Manual[1]:
Extra care should be taken when uploading to stable. Basically, a
package should only be uploaded to stable if one of the following
happens:
* a truly critical functionality problem
* the
On Fri, Jun 28, 2019 at 11:47:46AM +0200, Rhonda D'Vine wrote:
>
> Bugs that appear in stable have to get fixed in stable. The release
> team doesn't block bugfixes for stable, you are exaggerating here - and
> data loss is obviously a serious problem, especially when it is just a
> one-line
On Wed, Jun 26, 2019 at 10:15:22PM -0400, Theodore Y. Ts'o wrote:
>
> There is a newer version of dwarves upstream (1.14)
Upstream has since released version 1.15, with some miscellaneous bug
fixes. I've updated debian/master at
https://salsa.debian.org/tytso/dwarves.git
I've also
On Thu, Jun 13, 2019 at 11:19:13PM +0200, Florian Zumbiehl wrote:
>
> That fixed versions are available in buster and as a backport is of no use
> to anyone walking into this trap who doesn't know that they are about to
> corrupt their files. As far as I am concerned, that is more than enough
>
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 only noticed in 2017
On Sat, Jun 01, 2019 at 06:16:58AM +0530, Raj Kiran Grandhi wrote:
>
> In a fresh install of Buster with XFCE desktop, locking the screen
> blanks the monitor and the monitor enters a power save state. After
> that, neither moving the mouse nor typing on the keyboard would turn
> the monitor back
Control: reopen -1
On Mon, May 27, 2019 at 01:22:43PM +0200, Matteo wrote:
> Package: e2fsprogs
> Version: 1.44.5-1~bpo9+1
> Followup-For: Bug #907034
>
> in the stretch-backport version (and also in the strech one) of e2fsprogs,
> with italian locale, mke2fs still asks for y/N, but expects "y"
Control: tag -1 +pending
On Sun, Oct 28, 2018 at 06:42:47PM -0300, H. Gabriel Máculus wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
>
> When I run mkfs.ext4 to overwrite existing filesystem it prompt in
> english (last line) and you need reply in spanish (S, n)
This has been fixed in the
On Tue, May 14, 2019 at 09:42:58AM +0200, Laurent Bigonville wrote:
>
> I've attached the requested logs. I don't see anything weird here.
Yeah, I'm not seeing anything in the logs either. :-(
Would you be willing to send me a compressed e2image file? The
commands to generate are:
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
On Mon, May 20, 2019 at 08:17:09PM -0700, Noah Meyerhans wrote:
> At this point, I think it'd be worth revisiting, at the project level,
> the historical tradition of leaving the sbin directories out of non-root
> paths. Setting aside all the single user desktop and laptop systems,
> there are
On Mon, May 20, 2019 at 01:02:25PM -0400, Noah Meyerhans wrote:
> On Mon, May 20, 2019 at 11:26:00AM +0200, Jorge Barata González wrote:
> >Vagrant image debian/stretch64 v9.6.0
> >/usr/sbin is not included by default in $PATH
> >
> >```
> >vagrant@stretch:~$ service
> >-bash:
merge 929186 929254
thanks
On Mon, May 20, 2019 at 04:53:29AM +0200, Marc Lehmann wrote:
> Package: e2fsprogs
> Version: 1.45.1-1
> Severity: normal
>
> I just got this mail from cron:
>
>So sorry, the automatic e2scrub of /db on host failed.
>
>May 19 03:10:39 host systemd[1]:
getting cron spam:
Yeah, sorry, that's Bug #929186, and it's fixed by:
commit fbb9bfa4a5925f8049ef51d8f59eb94920781ec8
Author: Theodore Ts'o
Date: Sat May 18 23:04:49 2019 -0400
e2scrub_all: avoid scrubbing all devices when there is nothing to scrub
Running lsblk when there are no
Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Sat, 18 May 2019 23:04:49 -0400
Subject: [PATCH] e2scrub_all: avoid scrubbing all devices when there is
nothing to scrub
Running lsblk when there are no valid block devicse results in
generating all block devices as the list of devices to scru
On Thu, May 16, 2019 at 02:47:06PM -0400, Theodore Ts'o wrote:
> Control: tags -1 +pending
>
> On Thu, May 16, 2019 at 05:17:10PM +0200, Adam Borowski wrote:
> > Cron spam from a Priority:Required package is not something I'd consider
> > fit for Buster. Thus, could you pl
Control: tags -1 +pending
On Thu, May 16, 2019 at 05:17:10PM +0200, Adam Borowski wrote:
> Cron spam from a Priority:Required package is not something I'd consider
> fit for Buster. Thus, could you please apply this patch?
Thanks for the patch, applied!
Hi. I haven't forgotten about your bug report. The problem has been
I can't find any explanation for how e2fsck could have returned an
exit status of 1 given the output shown below.
> bigon@fornost:~$ sudo LC_ALL=C e2scrub /var/lib/sbuild/
> Logical volume "sbuildbuild.e2scrub" created.
>
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
On Tue, Apr 23, 2019 at 11:09:03AM -0700, Elliott Mitchell wrote:
>
> One of the things encountered in a fortune file: "Every program has at
> least two purposes, one for which it was designed for, and for which it
> wasn't designed for." (inexact quote)
>
> The use case I've got for MMP is
On Mon, Apr 22, 2019 at 07:34:40PM -0700, Elliott Mitchell wrote:
>
> This is several VMs on a hypervisor. Most filesystems aren't shared, I'm
> mostly using MMP for protection against my doing something stupid due to
> typing a command with the wrong device. The VMs have separate /, and
>
On Mon, Apr 22, 2019 at 03:08:09PM -0700, Elliott Mitchell wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> Severity: minor
>
> If being run on a system which uses MMP and they weren't unmounted
> cleanly, e2fsck will clear the MMP flags in order individually heavily
> slowing the check process.
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
>
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.
On Tue, Apr 02, 2019 at 07:43:34PM -0700, Elliott Mitchell wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
>
> Could `mke2fs` and `tune2fs` get some method to initialize the maximum
> mount count to a non-zero value?
>
> Having to search for random values to initialize the maximum mount count
>
On Sun, Mar 31, 2019 at 10:41:15PM +0200, Martin Pitt wrote:
> Package: e2fsprogs
> Version: 1.45.0-1
>
> In a standard sid LXC container, this unit fails:
>
> This is due to `AmbientCapabilities=CAP_SYS_ADMIN CAP_SYS_RAWIO`,
> and containers usually don't (and really should't) have RAWIO. Also,
1 - 100 of 416 matches
Mail list logo
