sf...@users.sourceforge.net:
> sf...@users.sourceforge.net:
>> Thanx for the interesting bug report.
>> Although I could not reproduce the bug, I'm afraid it is an aufs
>> problem. I will try more and investigate it, but it may take some time.
> On the report, I can see that you use aufs in qemu.
sf...@users.sourceforge.net:
> Thanx for the interesting bug report.
> Although I could not reproduce the bug, I'm afraid it is an aufs
> problem. I will try more and investigate it, but it may take some time.
On the report, I can see that you use aufs in qemu.
Would you kindly tell me how you inv
intrigeri:
> OK, sorry. I got confused by:
>
>I am interested in why you set '1' to the aufs module parameter "debug".
>If you had not set, this bug would not appear I guess. Did you see
>something wrong without setting "debug"?
>
> =E2=80=A6 which seemed to refer to that module paramet
sf...@users.sourceforge.net:
> intrigeri:
>> Same problem without debug=1:
> That is not what I meant.
OK, sorry. I got confused by:
I am interested in why you set '1' to the aufs module parameter "debug".
If you had not set, this bug would not appear I guess. Did you see
something wron
intrigeri:
> Same problem without debug=1:
That is not what I meant.
--
As you might know, LOCKDEP is a kernel debugging feature and
AuRwDestroy() macro is enabled only when CONFIG_AUFS_DEBUG is
enabled. So I guess if you disable
intrigeri:
> sf...@users.sourceforge.net:
>> I am interested in why you set '1' to the aufs module parameter "debug".
> IIRC I added it after having noticed the bug, in the hope it would
> yield more useful information for developers to fix it.
>> If you had not set, this bug would not appear I g
sf...@users.sourceforge.net:
> I am interested in why you set '1' to the aufs module parameter "debug".
IIRC I added it after having noticed the bug, in the hope it would
yield more useful information for developers to fix it.
> If you had not set, this bug would not appear I guess. Did you see
>
Jan Luca Naumann:
> I could reproduce the bug using a 4.15 kernel. Could you please take a
> look into this?
Thanx for the interesting bug report.
Although I could not reproduce the bug, I'm afraid it is an aufs
problem. I will try more and investigate it, but it may take some time.
I am interest
Dear aufs-maintainer,
below a Debian bug reporting a seg fault is attached. A online version
of the bug can be found here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886329
I could reproduce the bug using a 4.15 kernel. Could you please take a
look into this?
Thank you very much and best
Hey,
could you please provide the additional information the upstream
developer requests for in the README, then I will forward it to upstream:
5. Contact
When you have any problems or strange behaviour in aufs, please let me
know with:
- /proc/mounts (ins
Jan Luca Naumann:
> the underlying filesystem is a tmpfs for me as well:
> [...]
> I get no segfault for the call still so there has to be another reason...
Indeed!
I've just reproduced this in an up-to-date sid VM where /tmp is on the
ext4 root filesystem. I've purged and reinstalled aufs-dkms t
Hey,
the underlying filesystem is a tmpfs for me as well:
# uname -a
Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64
# mount | grep /tmp
none on /tmp type tmpfs (rw,nosuid,nodev,noatime,nodiratime)
# modprobe aufs debug=1 \
&& mkdir /tmp/{ro,rw,mount} \
&& touch /tmp/ro/bla
anonym:
> I guess that you, Jan, are *not* mounting a tmpfs on /tmp and I am guessing
> that you,
> intrigeri, *are*. Am I correct? :)
I am indeed. Jan, can you reproduce if the underlying filesystem is tmpfs?
> At least for me, the segfault only triggers when the underlying fs
> is a tmpfs.
Th
anonym:
> Jan Luca Naumann:
>> Control: tags -1 unreproducible
>>
>> I tested your code sample below and I could not reproduce the bug with a
>> current 4.14.13 kernel on my system. Could you please test it again?
>
> I am not the reporter, but this bug still affects me using
> linux-image-4.14.0
Jan Luca Naumann:
> Control: tags -1 unreproducible
>
> I tested your code sample below and I could not reproduce the bug with a
> current 4.14.13 kernel on my system. Could you please test it again?
I am not the reporter, but this bug still affects me using
linux-image-4.14.0-3-amd64 4.14.13-1.
Control: tags -1 unreproducible
Hey,
sorry for the long delay for my answer.
I tested your code sample below and I could not reproduce the bug with a
current 4.14.13 kernel on my system. Could you please test it again?
Best regards,
Jan
Am 04.01.2018 um 15:42 schrieb intrigeri:
> Hi,
>
> inte
Hi,
in case it might help other Live systems still using aufs for some
reason, for the record I've implemented a workaround to this bug in
Tails:
https://git-tails.immerda.ch/tails/tree/config/chroot_local-patches/live-boot:_workaround_aufs_bug.patch?h=feature/14976-linux-4.14%2bforce-all-test
Hey,
I am not at home for another two days and do not have a proper computer with
me. I will take a look at the problem on the weekend.
Jan
Am 4. Januar 2018 15:42:56 MEZ schrieb intrigeri :
>Hi,
>
>interestingly, only the first access to the aufs mountpoint triggers
>the bug. See the first `ls
Hi,
interestingly, only the first access to the aufs mountpoint triggers
the bug. See the first `ls' failing and the second one working:
# modprobe aufs debug=1 \
&& mkdir /tmp/{ro,rw,mount} \
&& touch /tmp/ro/bla \
&& mount -t aufs -o dirs =/tmp/rw=rw:/tmp/ro=rr+wh aufs /tmp/mount
Package: aufs-dkms
Version: 4.14+20171218-1
Severity: important
User: tails-...@boum.org
Usertags: misc-reported
X-Debbugs-Cc: ano...@riseup.net
Hi,
this bug makes aufs unusable in the context of Tails with Linux 4.14,
and possibly with any other Debian Live or container system that still
uses au
20 matches
Mail list logo