details as needed.
cheers!
--
James B jamesbond3...@gmail.com
--
[55096.152331] Unable to handle kernel NULL pointer dereference at virtual
address 003f
[55096.159197] pgd = a853c000
[55096.160610] [003f] *pgd=380db831, *pte=, *ppte=
[55096.165701] Internal error
.
cheers!
--
James B jamesbond3...@gmail.com
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software
On Wed, 16 Jul 2014 02:14:49 +0700
James B jamesbond3...@gmail.com wrote:
On Tue, 15 Jul 2014 23:49:20 +0900
sf...@users.sourceforge.net wrote:
In this case, this approach may be more effective.
- insert this just before every dput() in aufs_rename().
au_debug_on
the quad-core one does).
cheers!
--
James B jamesbond3...@gmail.com
fs-aufs.diff
Description: Binary data
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code
On Thu, 17 Jul 2014 13:36:47 +0700
James B jamesbond3...@gmail.com wrote:
No worries at all. I'll rebuild the kernel with the conditions, and get back
to you again.
As it turns out, I didn't enable netconsole so I need to re-build the kernel
anyway :)
Netconsole doesn't work :(
netpoll
).
cheers!
--
James B jamesbond3...@gmail.com
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software
On Wed, 23 Jul 2014 22:36:48 +0700
James B jamesbond3...@gmail.com wrote:
On Thu, 24 Jul 2014 00:27:53 +0900
sf...@users.sourceforge.net wrote:
No, I am quite sure that one is set to zero. I can't verify it without
rebooting because the system gets so bogged down trying to push the logs
Thanks, I will apply this.
I also saw earlier last week you fixed a bug on au_unpin.
I haven't applied that - you think I should to that too?
cheers!
On Thu, 24 Jul 2014 01:15:36 +0900
sf...@users.sourceforge.net wrote:
James B:
Okay now I confirm that it is zero. I had to reboot the box
of returning
systemcall with locked instead of dput().
Generally speaking, it is good to use latest version though.
Thank you.
I will bring up the system to the latest AND apply the patch you gave me just
now.
cheers!
--
James B jamesbond3...@gmail.com
s development for a while, at least for this month. In other words, I
> > will not release aufs4.x-rcN for almost all linux-4.2-rcN series.
> > If everything goes well, I will come back in next month and will release
> > aufs4.2.
>
> --
--
James B <jamesbond3...@gmail.com>
--
_map
euid: 65534, egid: 65534
Setting gid map in /proc/27030/gid_map
euid: 0, egid: 0
aufs
Overlay mounting failed: 1 (Operation not permitted)
Looks okay to me.
cheers!
--
James B <jamesbond3...@gmail.com>
--
Site2
Ah OK, I will reboot and test and report back.
cheers!
On Sat, 16 Jan 2016 01:19:26 +0900
sf...@users.sourceforge.net wrote:
>
> Hi!
>
> James B:
> > Tested on 3.18.7. I'm not sure where to set allow_userns=0 or =1; but this
> > kernel has userns enabled.
>
> On Sat, 16 Jan 2016 01:19:26 +0900
> sf...@users.sourceforge.net wrote:
>
> >
> > Thank you very much.
> > allow_userns is aufs's module parameter. You can set it by
> > # modprobe aufs allow_userns=1
> > or
> > append this to your boot loader (the kernel command line)
> >
t now I am
> wondering that the necessary thing might be aufs5.0 and aufs5.x-rcN
> branches.
> I will do that in a week or two. The aufs-util code essentially won't
> change. Just the version checking will change.
>
Thank you, Junjiro-san.
Good to know that.
cheers!
--
James B
, so aufs5.3 too.
> it makes the life of aufs4.1[4-8] to the end.
> my new development base version is now linux-v4.19.
>
> The source code of aufs5.3 doesn't change from previous aufs5.x-rcN.
>
>
> J. R. Okajima
>
--
James B
On Fri, 18 Oct 2019 16:04:10 +0900
"J. R. Okajima" wrote:
>
> James B:
> > > Is it acceptable for you?
> >
> > Yes, this would work.
>
> Ok, here is the fixed proc_mounts.patch for aufs5.3.
> If everything goes well, I will release it on next
On Sat, 19 Oct 2019 11:15:42 +1000
James B wrote:
> On Fri, 18 Oct 2019 16:04:10 +0900
> "J. R. Okajima" wrote:
>
> >
> > James B:
> > > > Is it acceptable for you?
> > >
> > > Yes, this would work.
> >
> > Ok, here i
On Thu, 17 Oct 2019 23:58:04 +0900
"J. R. Okajima" wrote:
> James B:
> > No worries, it's nothing urgent. For now I just use aufs without the patch.
> > Thank you for looking into this.
>
> Now I am fixing the bug. Almost done.
Dear Junjiro-san,
Thank you.
time. Please be patient for a
> while.
No worries, it's nothing urgent. For now I just use aufs without the patch.
Thank you for looking into this.
cheers!
--
James B
know.
cheers!
--
James B
#include
#include
#include
#include
#include
char buf[512*1024];
int main() {
int fd = open("/proc/mounts", O_RDONLY);
int rd = read(fd, buf, sizeof(buf));
printf("read: %d bytes\n",rd);
lseek(fd, SEEK_SET, 0);
rd = read(fd, buf, sizeof(buf
t;nosuid" to carry forward, instead, put "nosuid" in the top-level aufs mount
itself.
After all that's how one does it with any other mounts - one specifies the
parameter that one needs, on the mount that will be seen by the users.
cheers!
--
James B
On 3/7/23 4:00 pm, hooanon...@gmail.com wrote:
> I don't want introducing unnecessary confusing and incompatibility.
Thank you very mmuch for this consideration.
It's important to keep backward compatibility, as not every people will
suddenly update to the latest util-linux.
While it is
On 6/7/23 7:55 pm, J. R. Okajima wrote:
>
> My current development base version is v5.10.
> I tried aufs5.10, and failed compiling tools/lib/subcmd/subcmd-util.h.
> There is a commit in v5.17-rc5,
>
>
> commit 52a9dab6d892763b2a8334a568bd4e2c1a6fde66
>
On 6/7/23 7:27 pm, hooanon...@gmail.com wrote:
> "J. R. Okajima":
>> Now I am thinking about changing mount.aufs(8) helper.
>> - users specify "br:path1:path2" as usual.
>> - mount.aufs helper (in aufs-util.git) translate it into
>> "br=path1:path2" and executes /bin/mount with -i option,
24 matches
Mail list logo
