On Tue, May 28, 2019 at 06:43:55PM +0200, Dan wrote:
>
> The ZFS developers proposed the Linux developers to rewrite the whole
> ZFS code and use GPL, but surprisingly the linux developers didn't
> accept. See below:
> https://github.com/zfsonlinux/zfs/issues/8314
I've read the thread, and there
),
the other two used the kernel of the 8.0.0 (amd64) 4 GB iso image.
Another, perhaps useful observation: the installation of Ubuntu 14.04.2
(amd64, Gnome) worked fine (as tested on one server).
Best regards,
François
On 07/03/2015 06:43 PM, Theodore Ts'o wrote:
On Fri, Jul 03, 2015 at 02:02:41PM +0200
Forwarding messages that were dropped from 790...@bugs.debian.org...
---BeginMessage---
On Fri, Jul 03, 2015 at 08:53:28PM +0200, François P. Rotzinger wrote:
I have run mkfs.ext2 manually, and the message displayed on the screen was
that the partition was formatted (there was no error message).
),
the other two used the kernel of the 8.0.0 (amd64) 4 GB iso image.
Another, perhaps useful observation: the installation of Ubuntu 14.04.2
(amd64, Gnome) worked fine (as tested on one server).
Best regards,
François
On 07/03/2015 06:43 PM, Theodore Ts'o wrote:
On Fri, Jul 03, 2015 at 02:02:41PM +0200
On Wed, Apr 01, 2015 at 10:23:37PM +0300, Dmitry Monakhov wrote:
Wow I've just got a good present for a fools day.
It is appeared that stable kernel still has this bug(CVE-2014-8086)
unfixed.
At least my notebook (debian/testing 3.16.5) oopsed like follows:
3.16 is not a stable
On Mon, Jul 28, 2014 at 08:26:59AM -0400, Frank Ch. Eigler wrote:
Please note that the data produced by -g -fvar-tracking is consumed
by tools like systemtap, perf, crash, and makes a significant
difference to the observability of debug AND non-debug kernels. (The
presence of compiled-in
On Mon, Jul 28, 2014 at 10:27:39AM -0700, Alexei Starovoitov wrote:
It's not pretty, but adding it unconditionally was the right thing to do.
Black listing compiler versions is too fragile.
Look at the flip side: now size of build dir will be much smaller :)
White-listing the fixed compiler
On Sat, Jul 26, 2014 at 09:35:57PM +0200, Markus Trippelsdorf wrote:
But fortunately the workaround for the new inode.c bug is the same as
for the original bug: -fno-var-tracking-assignments.
It would make sense to enabled it unconditionally for all debug
configurations for now.
What's
Set a in-memory superblock flag to indicate whether the file system is
designed to support the Hurd.
Also, add a sanity check to make sure the 64-bit feature is not set
for Hurd file systems, since i_file_acl_high conflicts with a
Hurd-specific field.
Signed-off-by: Theodore Ts'o ty...@mit.edu
support file systems larger than 1GB[1] anyway.
[1] http://walfield.org/pub/people/neal/papers/hurd-faq/FAQ.en.html#q2-6
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
fs/ext4/ext4.h | 2 ++
fs/ext4/inode.c | 9 +++--
fs/ext4/super.c | 10 ++
3 files changed, 15 insertions(+), 6
/vdc/bug
umount /dev/vdc
e2fsck -f /dev/vdc
Addresses-Debian-Bug: #738758
Reported-By: Gabriele Giacone 1o5g4...@gmail.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
fs/ext4/inode.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/fs/ext4
On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote:
On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
I don't see any other solution here than moving all the Allwinner code to
DT (as it has been suggested in this thread several times already), as
this is
On Thu, Mar 21, 2013 at 09:46:38PM +0100, Jan Kara wrote:
Good catch! But shouldn't we rather fix jbd2_log_wait_commit() instead of
inventing new function?
In most of the places where we call jbd2_log_start_commit(), we're
actually starting the current running transaction. So the fact that
On Mon, Mar 18, 2013 at 04:53:15AM +, Ben Hutchings wrote:
We need you to verify that this fix works first. If it does, it should
get included in the various 3.x.y stable branches and in Debian kernel
packages.
I suspect it will be hard for George to verify this, since it requires
a tid
One other observeration; problems relating to tid wrap have been
around for a very long time. It's an issue for both ext3 and ext4, so
Red Hat and SuSE have been shipping QA'ed enterprise kernels with this
issue for over a decade. This is one of the reasons why I don't think
it's a good idea to
commit, to more quickly cause an tid wrap, and the regression tests
seem to be passing without complaint.
- Ted
From 76b05344fef573701b22ced444223188f054f94d Mon Sep 17 00:00:00 2001
From: Theodore Ts'o ty...@mit.edu
Date: Sun, 17 Mar 2013 22:24:46
(In the teach a person to fish category...)
If you know the file and line number where a bug/regression was
introduced, the git blame command is a great tool for identifying
the commit which changed a given line of code. Then use git tag
--contains commit it to see when a particular commit was
28623c2f5b0dca3c3ea34fd6108940661352e276
Author: Theodore Ts'o ty...@mit.edu
Date: Wed Sep 5 01:31:50 2012 -0400
ext4: grow the s_group_info array as needed
Previously we allocated the s_group_info array with enough space for
any future possible growth of the file system via online resize
). 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
On Sun, Jul 22, 2012 at 11:26:18AM +0100, Imran Chaudhry wrote:
Thanks for your reply Ben.
As an aside, from what kernel version would you recommend use of ext4 in?
Maybe I should use (tried and rusted) ext3 for my backup devices. I
mentioned this problem in my local LUG and a couple of
On Wed, Aug 24, 2005 at 05:52:32PM +0900, GOTO Masanori wrote:
Thinking about this issue, I agree with Ted's opinion - we don't
probably need to consider about cross-release. However, actually this
problem was caused by glibc, and such change made old e2fsprogs
unusable. It's a bit hard to
On Tue, Aug 23, 2005 at 07:49:23PM +0900, Simon Horman [Horms] wrote:
long time no see. It seems that the problem is indeed fixed if you get
the sarge (or later) versions of e2fsprogs and glibc. However, some
people don't have that, and its causing some breakage for those people.
Would it be
On Tue, Aug 23, 2005 at 10:48:53AM +0900, Horms wrote:
On Mon, Aug 22, 2005 at 04:47:14PM -0700, Tony Godshall wrote:
Hi.
Looks like building the initrd required an upgraded
Depends: directly or indirectly to e2fsprogs.
Not sure the minimum version required, but I had
1.35-6
On Mon, Jul 04, 2005 at 11:39:59AM +0100, Jon Dowland wrote:
It is my believe that the 2.4 kernel is still in wide spread use
both indide and outside Debian, thats a cause for being concerned
about it in my books.
Indeed, its the kernel shipped with RHEL 3.x .
Sort of. 2.4 kernels have
On Fri, Apr 08, 2005 at 02:36:58PM +0900, Horms wrote:
Hi Ted,
It seems that I missunderstood the preferences expressed
by Steve Langasek in my discussions with him. As it turns
out he feels that it would be best to get 0.37-2 ready,
as 0.37-1 is currently in sarge and has been beaten upon
On Thu, Apr 07, 2005 at 12:33:53PM +0900, Horms wrote:
Normally this would just be a matter of waiting for the new versions
to filter down to testing, but as part of the attempts to get sarge
released, testing was fozen a little while ago, so changes aren't
propogating, while unstable marches
On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
Nope, i am aiming to clarify this issue with regard to the debian kernel, so
that we may be clear with ourselves, and actually ship something which is not
of dubious legal standing, and that we could get sued over for GPL violation.
27 matches
Mail list logo
