Package: clang-16
Version: 1:16.0.6-26
Severity: normal
Dear Maintainer,
I was trying to track down a regression reported by the ClusterFuzz
service, and when I try to build the fuzzing reproducer on trixie, it
fails. However, it works on Bookworm. So while I can work around the
problem by
Package: src:linux
Version: 6.5.13-1
Severity: normal
Dear Maintainer,
I am running Debian testing in a Parallels VM (6 cores, 8GB memory)
running on Macbook Air M2 15" (10 cores, 24GB memory). gcc13 is
sig faulting when building xfsprogs or the Linux kernel when using make -j6.
Building
Package: snapshot.debian.org
Followup-For: Bug #1034000
I'm seeing similar failures for a number for the last three snapshots
listed at:
http://snapshot.debian.org/archive/debian/?year=2023=8
Namely for:
* 2023-08-06 09:19:12
* 2023-08-07 15:08:23
* 2023-08-09 03:23:42
As noted in [1] and
Package: systemd-sysv
Version: 252.6-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
I was updating the gce-xfstests[1] test appliance to Debian Bookworm from
Debian Bullseye.
[1] https://thunk.org/gce-xfstests
* What exactly did you do (or not do) that was effective
Package: iwd
Version: 1.24-1
Severity: important
Dear Maintainer,
After upgrading to iwd 1.24-1, it is crashing on my system. (Dell
XPS-13 with an ath10k/QCA6174/hw3.0 wireless card.) Downgrading to iwd
1.21-3 allows things to work. Restalling iwd 1.24-1 causes it crash
again.
If I run
Package: debhelper
Version: 13.4+nmu1
Followup-For: Bug #992469
I can confirm Samuel's analysis. When I tried debugging why building
e2fsprogs was causing a new lintian error:
E: e2fsprogs: systemd-service-file-outside-lib
usr/lib/systemd/system/e2scrub@.service
N:
E:
tags 989630 +pending
thanks
I finally had time to investigate this problem. It turns out the only
time this bug manifests is when creating an file system smaller than
(blocksize)**2 bytes (e.g., 16 megabytes when the is block size is
4k).
The bug was introduced almost ten years ago (September
On Thu, May 20, 2021 at 05:55:34PM +0200, Cyril Brulebois wrote:
> Paul Gevers (2021-05-20):
> > On 20-05-2021 00:11, Theodore Y. Ts'o wrote:
> >
> > Unfortunately, there was no release.debian.org bug to track this. Due
> > to the current high volume to our lis
Ping to the debian-release bug. Do you want me to upload a fix to
this bug where e2fsprogs fails its regression test (and thus its
package build) when armhf and armel are running on a 64-bit ARM
platform, but they were built successfully when run on a 32-bit ARM
builder?
No question this is a
On Thu, May 13, 2021 at 09:56:53PM +0100, Marcin Kulisz wrote:
>
> I hope that we're be able to change it, but for me fundamental
> question is if Google is interested in participating in effort to
> keep those packages in Debian main and if so what resources can be
> committed to do so. From my
On Tue, Oct 27, 2020 at 12:24:51AM +0100, Diederik de Haas wrote:
> Package: f2fs-tools
> Version: 1.11.0-1.1
> Followup-For: Bug #970176
>
> On salsa.d.o it looks like version 1.13 was ready to go, but it appears
> that it just never got uploaded to the archives/sid.
> It would be really welcome
reassign 969495 extundelete
thanks
extundelete works by trying to look at the journal and tries to figure
out how to find old metadata blocks left over in older transactions in
the jbd2 journal file. It's not part of e2fsprogs, but its own
separate package.
The extundelete program is a massive
On Thu, May 21, 2020 at 10:04:54AM +0200, Wilmer van der Gaast wrote:
> I just started a downsizing resize2fs operation over an SSH session
> without screen and then realised how bad an idea that was..
>
> Then found this bug as a confirmation. :-)
>
> It looks like resize2fs (still) doesn't
On Mon, Apr 27, 2020 at 09:01:56AM -0700, Igor Dvorzhak wrote:
> Package: e2fsprogs
>
> resize2fs takes extra 90 seconds to resize 2TB boot disk during boot on
> Debian 10 than on Debian 9.
>
> Note that time to create/provision VM instance (gcloud compute instances
> create ...) is the same
On Sun, Apr 12, 2020 at 01:25:49AM -0700, Josh Triplett wrote:
> Package: e2fsprogs
> Version: 1.45.6-1
> Severity: wishlist
> File: /sbin/e2fsck
>
> With a read-only filesystem and the shared_blocks option set, e2fsck
> allows multiply referenced blocks; however, it doesn't like multiple
>
On Thu, Apr 02, 2020 at 02:01:26PM +0200, Adam Borowski wrote:
>
> After a lot of output on a damaged filesystem (SD card copied to an image)
> fsck.f2fs dies with:
>
> - File name : mkfs.ext3.dpkg-new
> - File size : 6 (bytes)
>
> Program received signal SIGSEGV, Segmentation
On Mon, Mar 23, 2020 at 11:47:58PM -0400, Scott Kitterman wrote:
> > If you can't fix postfix's flaky autopkg test, can you please revert the
> > explicit dependency on e2fsprogs?
>
> I've asked in #debci to see if they have any suggestions about the pty
> shortage on arm64.
Thanks; it looks
Package: postfix
Version: 3.5.0-1
Severity: normal
Postfix autopkgtest on arm64 seems to be super flakey. This is
currently blocking e2fsprogs:
https://qa.debian.org/excuses.php?package=e2fsprogs
https://ci.debian.net/data/autopkgtest/testing/arm64/p/postfix/4630231/log.gz
This seems to be a
Package: lintian
Version: 2.58.0
Severity: normal
Dear Maintainer,
Lintian is reporting a number of spurious failures:
E: e2fsprogs-udeb udeb: debian-changelog-file-missing
E: e2fsprogs buildinfo: field-too-long Installed-Build-Depends (5090 chars >
5000)
E: e2fsprogs-udeb udeb:
ontrol
index 71613e11..69471f45 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: e2fsprogs
Section: admin
Priority: required
Maintainer: Theodore Y. Ts'o
-Build-Depends: gettext, texinfo, pkg-config, libfuse-dev [linux-any
kfreebsd-any] , libattr1-dev, debhelper (>=
On Tue, Mar 10, 2020 at 05:57:33AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: e2fsprogs
> Version: 1.45.5-2
>
> Idea: make a new file
> /usr/share/doc/e2fsprogs/Year2038warnings
> that would say:
>
> If you get
> ext4 filesystem being mounted at ... supports timestamps until 2038
> (0x7fff)
On Tue, Mar 10, 2020 at 05:10:29AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: e2fsprogs
> Version: 1.45.5-2
> File: /usr/share/man/man8/mke2fs.8.gz
>
> Please add to the mke2fs man page:
>
> ** This version of mke2fs is guaranteed to make filesystems that
>support timestamps *beyond* 2038. **
On Wed, Jan 22, 2020 at 09:27:01AM +0100, Cyril Brulebois wrote:
> You can upload. And no, it will stay in p-u-new until it's approved by
> some SRM, at which point it will be made available in
> stable-proposed-updates (note word order), until the point release.
Great, thanks!
And thanks for
Oh, one more question. Is a source-only upload OK? I'm still a bit
confused when a source-only upload is required, and when a binary
upload is required? Is the latter only for the NEW queue?
- Ted
On Tue, Jan 21, 2020 at 07:57:54PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
>
> On Thu, 2020-01-09 at 22:34 -0500, Theodore Y. Ts'o wrote:
> > +e2fsprogs (1.44.5-1+deb10u3) buster; urgency=medium
> > +
> > + * Fix CVE-2019-5188: potential stack
: potential stack underflow in e2fsck (Closes: #948508)
+ * Fix use after free in e2fsck (Closes: #948517)
+
+ -- Theodore Y. Ts'o Thu, 09 Jan 2020 20:19:57 -0500
+
e2fsprogs (1.44.5-1+deb10u2) buster-security; urgency=high
* Fix CVE-2019-5094: potential buffer overrun in e2fsck (Closes: #941139
Package: e2fsprogs
Version:
Severity: grave
Tags: security
Justification: user security hole
E2fsprogs 1.45.5 contains a bug fix for a use after free which could
potentially be used to run malicious code if a user can be tricked into
running e2fsck on a maliciously crafted file system. The
Package: e2fsprogs
Version: 1.43.4-2+deb9u1
Severity: grave
Tags: security
Justification: user security hole
E2fsprogs 1.45.5 contains a bug fix for CVE-2019-5188 / TALOS-2019-0973.
The following commits need to be backported to address this
vulnerability in Debian Buster and Debian Stretch:
On Mon, Jan 06, 2020 at 12:39:52AM -0800, Josh Triplett wrote:
> That's an *additional* delay, on top of the sleeps above. The two-second
> sleep in the "exitcode" function seems like the primary culprit. Note
> that I don't even have lvm2-tools installed.
Ah, yes, sorry, I had missed the sleep
On Sat, Jan 04, 2020 at 07:57:16PM -0800, Josh Triplett wrote:
> Package: e2fsprogs
> Version: 1.45.4-1
> Severity: important
>
> The e2fsprogs package installs a service and timer to run e2scrub. That
> service sleeps for 2 seconds before exiting, delaying the boot by 2
> seconds.
It's not
Package: iwd
Version: 1.2-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I upgraded my Debian testing system to the latest version of Bullseye,
and I was completely unable to connect to wireless. In the logs, I see
that iwd is crashing:
Dec 12 09:40:11 lambda
On Wed, Nov 13, 2019 at 11:38:55AM +0100, Svante Signell wrote:
> Source: e2fsprogs
> Version: 1.45.4-1
> Severity: important
> Tags: patch
> Usertags: hurd
> User: debian-h...@lists.debian.org
>
> Hello,
>
> The latest version of e2fsprogs in sid, 1.45.4-1, FTBFS on GNU/Hurd due to two
>
On Sun, Nov 03, 2019 at 11:09:00AM -0800, Darrick J. Wong wrote:
>
> Because if you don't do that, the e2scrub process gets started with fd 0
> mapped to stdout of ls_targets on account of the "ls_targets | while
> read tgt" loop. Yay bash. I guess the problem here is that
> e2scrub_all's stdin
On Sun, Nov 03, 2019 at 05:07:22AM +0100, gregor herrmann wrote:
>
> Cron sends me the following mail once per week:
>
> /sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or
> directory
Gregor, thanks for the bug report! This is coming from:
stdin="$(realpath
On Mon, Oct 14, 2019 at 10:12:34AM -0700, Jaegeuk Kim wrote:
> On 10/14, Theodore Y. Ts'o wrote:
> > Control: tag 942121 +upstream
> >
> > Hi Chao, Jaeguk,
> >
> > Could you take a look at this complaint and let me know if I should
> > close the bug as
Control: tag 942121 +upstream
Hi Chao, Jaeguk,
Could you take a look at this complaint and let me know if I should
close the bug as Working As Intended or not?
The concern seems to be that for desktop distros (which I know was not
f2fs's original target), some users update their kernels
Package: debian
Version: 1.44.5-1+deb10u1
Severity: grave
Tags: security
Justification: user security hole
E2fsprogs 1.45.4 contains a bugfix for CVE-2019-5094 / TALOS-2019-0887.
We need to backport commit 8dbe7b475ec5: "libsupport: add checks to
prevent buffer overrun bugs in quota code" to the
On Fri, Sep 20, 2019 at 11:40:30PM +0200, Francesco Poli wrote:
>
> Hello Thorsten, hello Theodore,
> I am another user who began receiving the same error messages from cron
> on a box with LVM, but without systemd.
It's only going to happen if you aren't using systemd, since if you
are using
On Sat, Sep 14, 2019 at 02:42:29PM +0200, Thorsten Glaser wrote:
> Package: e2fsprogs
> Version: 1.45.3-4
> Severity: minor
>
> From: Cron Daemon
> Message-ID: <20190914011004.3afc6220...@tglase.lan.tarent.de>
> To: r...@tglase.lan.tarent.de
> Date: Sat, 14 Sep 2019 03:10:04 +0200 (CEST)
>
Package: flowblade
Version: 2.2-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I installed flowblade, and then tried to start it. It failed to start;
I expected it to start and be usable. :-)
% flowblade
FLOWBLADE MOVIE EDITOR 2.2
--
Launch
Control: tags -1 +pending
On Wed, Oct 18, 2017 at 10:31:31AM -0400, Theodore Ts'o wrote:
> On Tue, Oct 17, 2017 at 01:56:32PM -0400, Michael Stone wrote:
> > I'd like the fuse2fs package to gain the norecovery option so that read-only
> > sources with dirty journals can be mounted via fuse. This
Control: tags -1 +pending
Control: severity -1 normal
On Sun, Aug 18, 2019 at 04:16:25AM +0200, Mikhail Morfikov wrote:
> There's no error indicating what could be wrong.
>
> Looking through the /usr/sbin/e2scrub_all file, I noticed the following line:
>
> local devices=$(lvs -o lv_path
On Wed, Jan 11, 2017 at 09:27:26AM +0100, Helmut Grohne wrote:
> Source: xzgv
> Version: 0.9.1-4
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> xzgv fails to cross build from source, because it uses build
> architecture build tools. Simply adding the host architecture
/debian/changelog 2018-12-15 22:46:49.0 -0500
+++ e2fsprogs-1.44.5/debian/changelog 2019-08-02 23:49:00.0 -0400
@@ -1,3 +1,9 @@
+e2fsprogs (1.44.5-1+deb10u1) buster; urgency=medium
+
+ * Fix e4defrag crashes on 32-bit architectures (Closes: #920767)
+
+ -- Theodore Y. Ts'o Fri, 02
Oh, one more question --- should I be doing a source-only, or binary
push when I push to buster-proposed-updates.
I'm a bit confused about whether it will be going into the NEW queue,
and hence require a binary push, or a source-only build because that's
the new hotness and it's required for
On Sat, Aug 03, 2019 at 04:08:14PM +0100, Adam D. Barratt wrote:
>
> I assume this is simply a case of an outdated chroot pointing at
> "stable" or similar. The net effect is that the upload ended up in NEW
> (presumably as buster's e2fsprogs builds additional binary packages
> relative to
-1.44.5/debian/changelog 2018-12-15 22:46:49.0 -0500
+++ e2fsprogs-1.44.5/debian/changelog 2019-08-02 23:49:00.0 -0400
@@ -1,3 +1,9 @@
+e2fsprogs (1.44.5-1+deb9u1) stretch; urgency=medium
+
+ * Fix e4defrag crashes on 32-bit architectures (Closes: #920767)
+
+ -- Theodore Y. Ts'o
On Fri, Aug 02, 2019 at 02:09:03PM +1000, Ralph Ronnquist wrote:
> Well,
>
> when I then "agt-get install libuuid1:i386" (on this multiarch)
> I get advice about a page full of packages to be removed, and the
> following (plus a bit more):
> ---
> WARNING: The following essential packages will be
On Fri, Aug 02, 2019 at 11:25:10AM +1000, Ralph Ronnquist wrote:
> Package: libuuid1
> Version: 2.34-0.1
>
> The package is declared to replace e2fsprogs, which it doesn't do.
> Rather, installing it has a fair few ramifications on the installed system.
>
> The package belongs to the util-linux
Phillip,
Peace.
You may not like the fact that David Oberhollenzer (GitHub username
AgentD) started an effort to implement a new set of tools to generate
squashfs images on April 30th, 2019, and called it squashfs-tools-ng.
However, it's really not fair to complain that there is a "violation
of
On Wed, Jul 31, 2019 at 04:22:35PM +0100, Ian Jackson wrote:
> Submodules are intensely frustrating[1]. One way they are frustrating is
> that it is not clear even what it means for a .dsc to be identical to
> a git tree which has submodule references. Are the submodules
> supposed to be
OK, I've upload 1.15-1, so let's not rewrite the history on Salsa any
more. :-)
Thanks!!
- Ted
On Tue, Jul 30, 2019 at 05:54:37PM +0200, Domenico Andreoli wrote:
> Edited history again, just fixed the typo in the only patch. I could
> not find any other low hanging fruit, anything else requires some
> investigation (included the warnings on debian/copyright)
Well,
On Mon, Jul 29, 2019 at 10:32:38AM -0400, Theodore Y. Ts'o wrote:
> On Mon, Jul 29, 2019 at 02:51:49PM +0200, Domenico Andreoli wrote:
> >
> > Here it is: https://mentors.debian.net/package/dwarves-dfsg
> >
> > I found not useful to reuse your git history as-is, al
On Mon, Jul 29, 2019 at 02:51:49PM +0200, Domenico Andreoli wrote:
>
> Here it is: https://mentors.debian.net/package/dwarves-dfsg
>
> I found not useful to reuse your git history as-is, although I could
> not drop your changelog entry ;)
It looks like you did merge in my git changes, though?
On Sun, Jul 28, 2019 at 06:21:57PM +0200, Helmut Grohne wrote:
> Hi Ted,
>
> On Sun, Jul 28, 2019 at 10:04:48AM -0400, Theodore Y. Ts'o wrote:
> > Yes, I had noticed that this was breaking some of the ports build as
> > well, and so I have a similar patch in my tree
control: -1 tags +pending
On Sun, Jul 28, 2019 at 08:09:22AM +0200, Helmut Grohne wrote:
> Source: e2fsprogs
> Version: 1.45.3-3
> Severity: important
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> e2fsprogs fails to cross build from source, since the -3 upload,
On Thu, Jul 25, 2019 at 07:03:50PM +0200, Domenico Andreoli wrote:
> Hi Theodore,
>
> apologies, I'll prepare a new upload. Would you mind sponsoring it?
Sure, I'd be happy to sponsor it.
- Ted
Control: tags -1 +pending
On Wed, Jul 24, 2019 at 05:17:28PM +0200, Thorsten Glaser wrote:
>
> 355 tests succeeded 1 tests failed
> Tests failed: f_pre_1970_date_encoding
>
> I assume this is because x32 is a 32-bit (ILP32) architecture
> with 64-bit time_t.
Thanks for the bug report.
On Wed, Jul 24, 2019 at 05:46:50AM +0200, Sven Joachim wrote:
> Package: logsave
> Version: 1.45.3-1
> Severity: serious
>
> Installing logsave without upgrading e2fsprogs fails:
>
> ,
> | Preparing to unpack .../logsave_1.45.3-1_amd64.deb ...
> | Unpacking logsave (1.45.3-1) ...
> | dpkg:
On Wed, Jul 24, 2019 at 05:52:48AM +0200, Sven Joachim wrote:
> Package: logsave
> Version: 1.45.3-1
>
> Like the package it partially replaces (e2fsprogs), logsave should be
> Multi-Arch: foreign. The initramfs-tools-core package will have to
> depend on logsave, which makes cross-grades (say,
Control: tags 932855 +pending
Control: tags 932859 +pending
Control: tags 932861 +pending
Control: tags 932881 +pending
Control: tags 932888 +pending
My apologies, I hadn't realized initramfs had a dependency on logsave.
I guess I should have known that, but it had slipped my mind. This
will be
control: -1 +pending
On Sun, Jul 21, 2019 at 01:27:38PM +0200, Laurent Bigonville wrote:
>
> The cronjob (/etc/cron.d/e2scrub_all) file is a conffile, that means
> that if the package is removed without being purge, the cronjob will
> still be installed, but the executable will not.
>
> The
This Lintian check is also a false positive for e2fsprogs, where it's
triggering 4 false positive Lintian errors.
Per
https://lintian.debian.org/tags/package-supports-alternative-init-but-no-init.d-script.html:
This lintian tag has:
Emitted (non-overridden): 787, overridden: 22, total: 809
Package: e2tools
Version: 0.0.16-6.1+b2
Severity: wishlist
The original source for e2tools has disappeared (the home.earthlink.net
pages is dead), but it looks like there is activity at:
https://github.com/ndim/e2tools
Hans has modernized the package, fixing the FSF's address in the
copyright
Control: tags -1 +pending
On Wed, Feb 27, 2019 at 03:01:52AM +, Dmitry Bogatov wrote:
>
> Package: e2fsprogs
> Version: 1.44.5-1
> Severity: normal
>
> Dear Maintainer,
>
> for long time e2fsprogs were essential, and bin:initscripts used
> /sbin/logsave from e2fsprogs. Nowdays, e2fsprogs
Package: gcc-8
Version: 8.3.0-19
Severity: normal
Dear Maintainer,
The e2fsprogs package is currently not reproducible. See:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/e2fsprogs.html
This is caused by an unfortunate interaction between LTO and the flags
from
Package: dwarves
Version: 1.12-2
Severity: normal
Tags: patch
Dear Maintainer,
There is a newer version of dwarves upstream (1.14). Version 1.13 is
needed to build the latest kernels with CONFIG_DEBUG_INFO_BTF.
Please consider merging the debian/master branch from:
Regarding in-kernel recovery "being good enough". The reason why some
file systems and system administrators prefer to run fsck at boot,
even you can there is "in-kernel recovery", is that journal/log replay
only works on an unclean shutdown.
However, sometimes there are can be file system
On Thu, Dec 20, 2018 at 03:17:03PM -0500, Daniel Kahn Gillmor wrote:
>
> I wonder whether we can rule out any interaction with gpg-agent itself
> -- does "echo getpin | pinentry-gnome3" itself fall back to curses on
> your system when nfs-kernel-server is installed?
I can confirm that that I did
On Sun, Dec 16, 2018 at 10:35:55AM +, Simon McVittie wrote:
> >* Fix mk_cmds so it works on a usrmerge system when e2fsprogs is built
> > on a non-usrmerge system (Closes: #914087)
>
> In the interests of avoiding inaccurate information, this bug was actually
> the other way round:
On Sat, Dec 01, 2018 at 12:23:51AM +, Gong S. wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> >Can you tell what version of the kernel you are using?
> 4.19.0-trunk-amd64. I guess that I am not getting any semblance of support
> with an experimental kernel.
> However, when I
tags 916188 +pending
thanks
Thanks for sending the patch. I've applied it to the e2fsprogs maint
branch.
- Ted
tags 915942 +pending
thanks
On Sat, Dec 08, 2018 at 04:18:38AM +0100, Andreas Beckmann wrote:
> Package: libext2fs2
> Version: 1.44.4-2
> Severity: minor
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> due to a typo in debian/rules, line 388, the libext2fs2 package ships
> the empty
On Sat, Dec 01, 2018 at 06:57:08PM +0100, Andreas Henriksson wrote:
>
> Debdiff adding SED=/bin/sed in debian/rules attached for your
> convenince.
Thanks for your patch. I already have a fix in queued up for the next
release of e2fsprogs:
commit b7bb80dc7033776149bb1f33c81a753fe21a2f89
This is a kernel bug, not an e2fsprogs bug.
Can you tell what what version of the kernel you are using?
Inline_data is a feature I generally don't recommend using unless you
have a specific reason. It's not on by default. How/when did you
enable this feature? And what were you hoping to
tags 914087 +pending
thanks
Thanks for reporting this; the following patch will be in the next
version of e2fsprogs.
- Ted
commit b7bb80dc7033776149bb1f33c81a753fe21a2f89
Author: Theodore Ts'o
Date: Thu Nov 22 18:01:56 2018 -0500
mk_cmds:
On Tue, Nov 13, 2018 at 11:46:31PM +0100, Adam Borowski wrote:
> what would you say about getting rid of fsck at boot for most filesystems?
The reason why it's important to run fsck at boot is because for many
file systems if a file system consistency problem is detected at run
time (this might
On Fri, Nov 02, 2018 at 01:24:25AM +0100, Kurt Roeckx wrote:
> Anyway, on my laptop I get:
> [ 12.675935] random: crng init done
>
> If the TPM is enabled, I also have an /etc/hwrng, but rng-tools is
> started later after the init is done.
>
> On my desktop (with a chaos key attached)
> [
On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> bare metal with nothing fancy I have:
> [3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
> [ 10.363377] r8169 :05:00.0
On Wed, Oct 31, 2018 at 11:21:59AM +, Sebastian Andrzej Siewior wrote:
> On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o" wrote:
> >
> >So it's complicated. It's not a binary trusted/untrusted sort of
> >thing.
>
> What about RNDRESEEDCRNG? Wou
On Tue, Oct 30, 2018 at 07:37:23PM +0100, Kurt Roeckx wrote:
>
> So are you saying that the /var/lib/random/seed is untrusted, and
> should never be used, and we should always wait for fresh entropy?
>
> Anyway, I think if an attacker somehow has access to that file,
> you have much more serious
On Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote:
> Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
> /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
> the entropy count after it was written. Those two are documented in
> random(4). Or
If e4defrag is run by root, it will try to open the underlying file
system for files that it is trying to defrag so it can get the file
system parameters. It's currently doing this by searching /etc/mtab.
This isn't the best way to go about doing things, but we'll leave it
for now, at least for a
On Fri, Aug 31, 2018 at 01:06:00AM +1200, Stuart Richards wrote:
>
> Attempting to defrag a file with e4defrag -v filetobedefragged on a Raspberry
> Pi gives the error "-v: No such file or directory while trying to open file
> system: /dev/root". The same command works as expected on an AMD64
On Wed, Oct 03, 2018 at 07:08:41PM +0200, ro...@seffner.de wrote:
>
> Using user or session based keys suggests me no other session/user is able
> to take advantage of them. It seems to me as the following
> - permissions/ACL's controls the access rights to en-/decrypted filesystem
> objects
> -
f2fs0 package with libf2fs5 and libf2fs-format4
* Fixed missing libblkid dependency in the shared library
* Updated Standards compliance to 4.2.0
* Added Theodore Ts'o as an uploader for the package
-- Theodore Y. Ts'o Fri, 24 Aug 2018 03:32:49
On Wed, Aug 22, 2018 at 03:51:23AM +0200, hi...@abwesend.de wrote:
> Package: libcom-err2
> Version: 1.44.3-1
>
> When updating libcomerr2 to the testing version, libcom-err2 (1.44.3-1)
> gets installed. This removes libcom_err2.so.2 from the initramfs and
> breaks fsck.ext4 for the root file
On Tue, Aug 21, 2018 at 01:01:10PM -0700, Vincent Cheng wrote:
>
> I can't find a reference right now, but I seem to recall that one of
> the Alioth admins pointed out that mailing lists specifically for
> package/bug tracking purposes (i.e. not used for discussion) shouldn't
> be migrated to
OK, I've created a new project in Salsa for f2fs-tools:
https://salsa.debian.org/debian/f2fs-tools
and I've uploaded git repo with a work-in-progress for a f2fs-tools
v1.11.0 packaging.
A couple of things which I've noted:
1) The maintainers is listed as:
On Sun, Aug 12, 2018 at 02:19:29AM -0700, Vincent Cheng wrote:
>
> Sorry, I haven't had time lately to properly care for my packages.
> Please go ahead with the NMU (bonus points if you have time to move
> everything to salsa, extra bonus points if you're willing to
> co-maintain the package
On Sun, Jul 22, 2018 at 01:49:17PM -0400, Theodore Y. Ts'o wrote:
>
> Please consider packaginging f2fs-tools 1.11.0 from upstream. This
> release includes:
>
> - add sg_write_buffer for UFS firmware update in Android
> - wanted_sector_size to specify sec
On Fri, Aug 10, 2018 at 01:00:03PM +0200, Martin Steigerwald wrote:
> > As it turns out, I do something very differnt which is my .bashrc will
> > run ~/.ssh-setup, which looks for existing ssh-agents or gpg-agents,
> > and if it one doesn't exist, it will start one, e.g.:
>
> I would not do this
On Thu, Aug 09, 2018 at 09:10:57PM +0200, Martin Steigerwald wrote:
>
> Thing is here: It breaks existing workloads. And I have the gut feeling,
> not *just* mine. So no matter what long-standing, under-communicated,
> probably mostly undocumented best practices are in place in your
> opinion,
Thanks for the report. I've checked in a fix for this into the
e2fsprogs git repository, and it will be in the next release of e2fsprogs.
- Ted
Package: f2fs-tools
Version: 1.10.0-1
Severity: normal
Dear Maintainer,
Please consider packaginging f2fs-tools 1.11.0 from upstream. This
release includes:
- add sg_write_buffer for UFS firmware update in Android
- wanted_sector_size to specify sector size explicity
-
On Fri, Jul 20, 2018 at 09:35:53PM +0200, Alexander Dahl wrote:
> Hei hei,
>
> I can confirm that behaviour for Raspbian GNU/Linux 9 (stretch), quote
> from syslog:
>
> Jul 20 17:17:04 darcy systemd-fsck[96]: fsck.f2fs: invalid option -- 'y'
>
> If you have any hints on how to solve that, I
On Sat, Jul 07, 2018 at 11:22:27PM -0700, Elliott Mitchell wrote:
> It is easy to build wildly incorrect mental models of how a feature works
> if you haven't looked at the code, but observed problems due to bugs...
>
> Particularly if the documentation doesn't talk about the implementation.
> At
On Sat, Jul 07, 2018 at 09:21:47AM -0700, Elliott Mitchell wrote:
>
> This then suggests this bug should be against linux-source-4.9 instead of
> e2fsprogs.
>
> A few command sequences and notes on how fast the command executes on the
> machine:
>
> mount / -o rw,remount => slow
> mount / -o
On Fri, Jun 15, 2018 at 07:37:19PM -0700, Elliott Mitchell wrote:
>
> During the process I ended up running `e2fsck -f` multiple times. I
> ended up running `e2fsck -f` after enabling each feature (`tune2fs`
> really didn't like enabling multiple features at once).
OK, so I really need a
1 - 100 of 135 matches
Mail list logo
