Dear Okajima,
On Mon, Jul 3, 2023 at 6:19 AM wrote:
>
//snip
> > For example overlayfs uses lowerdir=/lower1:/lower2:/lower3, so the usage
> > of colon as separator within an option value is not unique.
>
> I know about that.
> But overlayfs doesn't have the layer attribute such as "=rw" and "=
On Mon, Oct 3, 2016 at 4:47 PM, wrote:
>
> Hello Guan,
>
> The reason is that those commands are invoked from another command via
> execve().
> As you might know, specifying the full path is one approach to make it
> secure. If you want to install them other than /usr/lib, you need to
> change th
Hello,
The destination directories to the library can be set on the make
command line according the master Makefile of aufs-util.
However, the Makefile in the fhsm subdirectory has hard coded
install_ulib to install to /usr/lib.
Did I miss something (e.g., another dedicated command line parameter)
Dear Okajima,
The change causes implicit declaration of vfree and vzalloc in
"fs/aufs/super.c".
Could you add back "#include "?
Thanks!
Guan
On Sun, Mar 29, 2015 at 5:56 PM, wrote:
>
> All changes are tiny, and the behaviour doesn't change.
>
> J. R. Okajima
>
> -
Hi Ratheendran and Okajima,
I had a similar problem. When I do the followings in initrd:
mount -t aufs -o br=/mnt-cow:/mnt-ro aufs /new-root
mount --bind /mnt-cow /new-root/live/cow
mount --bind /mnt-ro /new-root/live/ro
umount -l /mnt-cow /mnt-ro
exec switch_root /new-root "$INIT" "$RUNLEVEL"
T
Hello,
I am sure this has been noticed and will be included in tomorrow's
release, but I'd report it anyway, just in case.
The aufs3-mmap.patch on mm/Makefile will be rejected for
linux-3.14.21. The change was trivial.
Best regards,
Guan
--
On Mon, Jul 21, 2014 at 9:11 AM, wrote:
>
> I am going to stop maintaining aufs3.9 ... aufs3.14 versions, and make
> aufs3.15 a new base version. It will happen after aufs3.16 or aufs3.17
> is released.
>
Does it mean the long term 3.{10,12,14} will also be unmaintained?
If it happens after aufs
On Tue, Jun 17, 2014 at 5:48 PM, wrote:
> Here is a new tmpfs-idr.patch for next aufs release. It is much more
> simplified.
>
> J. R. Okajima
>
This one produces no error, no warning.
Guan
--
HPCC Systems Open Source
On Tue, Jun 17, 2014 at 7:30 AM, wrote:
> Here are refined ones, 3.12.x.patch and 3.14.patch.
> Please test.
Nothing wrong this time. Maybe the problem is solved.
>> 1) "fs/proc/task_mmu.c" (3.12.x) must additionally include
>> and otherwise doesn't compile;
>
> Yes, magic.h is necessary for
On Mon, Jun 16, 2014 at 9:49 PM, wrote:
>
> Guan, Nikolay,
> Please test this patch which tries fixing the problem while previous
> patches try finding it.
>
> J. R. Okajima
Two problems:
1) "fs/proc/task_mmu.c" (3.12.x) must additionally include
and otherwise doesn't compile;
2) The warning
On Mon, Jun 16, 2014 at 2:36 PM, wrote:
>
>> [ 158.069589] X[1287]:dentry_iput:339: SYSV f500f000 i32768
>> 0100777 f46570ac
>> [ 158.070099] X[1287]:shmem_evict_inode:660: f500f000, i32768, 0100777
>> f46570ac
> :::
>> [ 158.070290] X[1287]:idr_remove_warning:532: idr_remove
On Sun, Jun 15, 2014 at 7:25 PM, wrote:
> Anyway here is a new and consolidated patch. Apply this after all aufs
> patches you use and tmpfs-idr.patch. In other words, revert all patches
> I've sent via mail.
>
> J. R. Okajima
With your new patch the dmesg looks much more tidy. Relevant messages
On Thu, Jun 12, 2014 at 8:22 PM, wrote:
> simple_xattrs_free(&info->xattrs);
> WARN_ON(inode->i_blocks);
> if (inode->i_ino) {
> + int i = inode->i_ino;
> mutex_lock(&sbinfo->idr_lock);
> - idr_remove(&sbinfo->idr, inode->i_ino);
On Thu, Jun 12, 2014 at 7:36 PM, wrote:
>
> Guan, Nikolay, would you test this patch manually for mm/shmem.c?
> It may produce a new warining once.
>
>
> ino = idr_alloc(&sbinfo->idr, inode, 2, INT_MAX, GFP_NOFS);
> if (ino > 0) {
> inode->i
On Thu, Jun 12, 2014 at 7:20 PM, Nikolay Pertsev wrote:
>
> So, on mach-1 what folders do you mount as aufs branches?
I mounted 3 branches on both machines -- br1:br2:br3
where br1 is tmpfs, br2 and br3 are squashfs.
br3 is the system image, and br2 contains /lib/{firmware,modules}.
> And do yo
On Thu, Jun 12, 2014 at 11:53 AM, wrote:
>
> Then we have two options as next step.
>
> 1. dive into IDR assembler code on MCORE2
>- disassemble IDR object file
>- write a small test program for IDR, run and disassemble it
>
> 2. forget all about chip dendent issues
>- re-build as oth
On Thu, Jun 12, 2014 at 4:34 AM, wrote:
>
> Do you think it happens only specific version?
>
I am running the same (20140609) aufs on Linux 3.12.21 on two real
machines with similar aufs stacks (tmpfs:squashfs:squashfs) but
mach-1) Is an Intel Core 2 Duo, has CONFIG_MCORE2=y, two squashfs
image
On Mon, Jun 9, 2014 at 6:31 PM, wrote:
>
> Would you try testing after this fix?
> - new tmpfs-idr.patch removes a line from
> linux/mm/shmem.c:shmem_get_inode() like this.
> ... ...
>
> - insert this line at the removed line like this.
> inode->i_ino = get_next_ino();
> --> ino
Hello,
The new (3.12.x-20140609) aufs introduced this warning.
Don't know if it is serious or not.
[ 39.235011] [ cut here ]
[ 39.235023] WARNING: CPU: 1 PID: 1320 at lib/idr.c:527
idr_remove.part.6+0x1fb/0x200()
[ 39.235025] idr_remove called for id=32768 which is n
Hello Okajima,
Thanks for the tmpfs patch! This is really good.
For the vfs-ino patch, it does not apply to linux-3.12.20.
However, this is not very important and applying this patch
manually is easy.
Guan
On Sun, May 25, 2014 at 6:35 PM, wrote:
>
> o news
> - in aufs3-standalong.git, introdu
On Thu, Jan 16, 2014 at 10:37 AM, Sven Geggus
wrote:
> Hello,
>
> I get merge conflicts while trying to merge aufs3-linux/aufs3.10 into a
> vanilla Kernel Version 3.10.27.
>
> The Problem is whithin mm/fremap.c
>
Patch by Okajima:
http://comments.gmane.org/gmane.linux.file-systems.aufs.user/4553
Hello,
The aufs3-3.12 patch currently does not apply to Linux 3.12.7 --
user@host:~/linux-3.12.7$ patch -p1 <
../aufs/aufs3-standalone-3.12/aufs3-mmap.patch
patching file fs/buffer.c
patching file fs/proc/nommu.c
patching file fs/proc/task_mmu.c
patching file fs/proc/task_nommu.c
patching file in
Hello Okajima,
On Wed, Dec 18, 2013 at 6:02 AM, wrote:
>
> Several weeks past since my last reply. Today I tried a simple test and
> succeeded reproducing the problem.
> Here is a patch to fix it.
> I am still testing for next Monday release. But, if everything goes
> well, this fix will NOT be
_HNOTIFY is not set
CONFIG_AUFS_EXPORT=y
CONFIG_AUFS_RDU=y
# CONFIG_AUFS_SP_IATTR is not set
# CONFIG_AUFS_SHWH is not set
# CONFIG_AUFS_BR_RAMFS is not set
CONFIG_AUFS_BR_FUSE=y
CONFIG_AUFS_POLL=y
CONFIG_AUFS_BR_HFSPLUS=y
CONFIG_AUFS_BDEV_LOOP=y
# CONFIG_AUFS_DEBUG is not set
Will provide more d
On Sat, Jul 13, 2013 at 1:33 AM, wrote:
>
> It will be fixed in next Monday release.
>
>
> J. R. Okajima
Good. Thanks for the info!
Guan
--
See everything from the browser to the database with AppDynamics
Get end-to-en
Hello,
Today I tried to make aufs-utils and got this:
cc -I./libau-O-Wall-I/usr/src/linux-3.2.48/usr/include
-I/usr/src/aufs/aufs3-standalone/usr/include -DMOUNT_CMD_PATH=\"\" Â ver.c
 -o ver
./ver
Wrong version!
aufs-util for aufs3.2 and later, but aufs
On Thu, Mar 28, 2013 at 5:49 PM, Oliver Welter wrote:
>
> major update every year, just because a bug is not fixed in my kernel, I am
> forced to remove aufs from my systems.
>
Every two months. Not every year.
Guan
-
On Thu, Mar 28, 2013 at 3:37 PM, Tomas M wrote:
> I never understood why people use older kernels. The only reason may
> be that some Linux distributions are made for business audience and
> they use old kernel since they are afraid of new (untested) things or
Not so precise. Those who use old ke
On Tue, Jan 22, 2013 at 6:02 PM, <[1]sf...@users.sourceforge.net> wrote:
Because you enabled the kernel debugging option, I'd make sure one
thing.
Are your system (particulary CPU and RAM) enough to run such kernel?
If you can, I'd suggest you to check how much CPU time and
ve it a chance to
start.
I ssh-ed and executed a dmesg but saw nothing abnormal. No error, no
warning.
Could you point out a way to dig out the problem? Thanks!
Guan
On Sat, Jan 19, 2013 at 4:15 AM, <[1]sf...@users.sourceforge.net> wrote:
Guan Xin:
> I tried
ess to the serial terminal at present and
cannot see any messages until sshd starts.
After removing the patch (patch -R ...) it works again. Of course the old
error message is still there.
Guan
On Fri, Jan 18, 2013 at 12:45 PM, <[1]sf...@users.sourceforge.net> wrote:
Hello Gua
Hello,
I've got an OLinuXino micro recently and tried to run Linux 3.7.3 + aufs
3.7-20130114. When it's up it works. I've got no problem until now but
during early boot, there was this error message:
[Â Â Â 2.58] udevd[48]: starting version 182
[Â Â Â 2.67] usb 1-1.2:
On Mon, Oct 15, 2012 at 8:45 PM, wrote:
>
>
> No.
> To keep the consistency from the point of middle fs's view, the upper
> permission bits should not override the lowers.
>
> As long as the middle branch prohibits such access, aufs simply follow it.
> Otherwise it can be a violation of a securit
On Mon, Oct 15, 2012 at 8:01 PM, wrote:
>
> It is possible if you "mount --move /mnt0 /mnt/mnt0" before switch_root.
>
>
>> But I got the solution:
>> Change mode of my "changes" directory from 700 to 755.
>
> Does it mean that the root dir of your mnt2 was 700?
> If so, you cannot access everyth
On Mon, Oct 15, 2012 at 7:07 PM, wrote:
>
> Hmm...
> Just to make sure, you can success chdir("/mnt[012]/home/username"), right?
> Will you show me the output of this command?
>
> $ ls -ld / /mnt[012] /mnt[012]/home /mnt[012]/home/username /home
> /home/username
>
> chdir(2) essentially calls tw
On Mon, Oct 15, 2012 at 6:39 PM, wrote:
>
> Guan Xin:
>> No. My rw branch is tmpfs. I enabled CONFIG_AUFS_BR_RAMFS
>> and am still getting the same error. My init script in initrd is attached.
>
> I see.
> Your script does
> mount -t aufs -o br=/mnt1:/mnt2:/
On Mon, Oct 15, 2012 at 6:10 PM, wrote:
>
> Guan Xin:
>> I am not sure if this maillist accepts binary attachments. But I will try.
>>
>> Attached are:
>>
>> mounts: /proc/mounts
>> sys_module_aufs.tar: /sys/module/aufs/*
>> sys_fs_aufs.tar: /sy
Does this part (and those below) of the README help?
"You may feel why aufs2-standalone.patch needs to export so many kernel
symbols. Because you selected aufs2-standalone tree instead of aufs2-2.6
tree. All symbols exported here are just for the external aufs module.
If you don't like aufs2-stan
Tomas,
Sorry to repeate myself --
i) aufs has nice README files, just try to believe them
ii) I've been asking the same question in this mailing list so
google may help you. Actually Okajima-san redirected me
to the README file and my problem was immediately solved.
BTW, GNU make has dry-r
See the README
"Otherwise you need to do something like this sample."
and so on.
I've been asking the same question on this mailing list.
Guan
On Mon, Aug 20, 2012 at 1:44 AM, Tomas M wrote:
> ...
> I believe that I will need aufs_type.h in my /usr/include/linux in order
> to compile aufs-utils
Hi Tomas,
I am using aufs with stock slackware smp config (with the aufs CONFIGs
added, of course). "make headers_install" installed "aufs_type.h" to
"linux-3.2.27/usr/include/linux/".
Guan
On Fri, Aug 17, 2012 at 10:40 PM, Tomas M wrote:
> Hello,
>
> I'm compiling aufs for linux 3.2.
> I follo
On Thu, Jul 12, 2012 at 11:23 AM, Armin Ranjbar wrote:
>
>but what about when we are shutting down? there will be attempt unmount
>/root, but i think nothing will ever
>to unmount /wr and /ro (which were mounted at initramfs level)
>am i right here?
Is your "/wr" in "/etc/mtab"? I
Hello,
I have got this warning:
"aufs au_warn_loopback:111:loop1[13277]: you may want to try another
patch for loopback file on squashfs(0x73717368) branch"
from an aufs mount with branches br=br2:br1
where br1 is a squashfs loop mount and br2 is a tmpfs.
What does this mean?
Since I don't mind
Hello,
I am running a small system from memory.
The only mount command involves aufs is:
mount -t aufs -o br:/root/tmpfs:/ aufs /root/new_root
where "/" is the initrd in squashfs.
Can there be any damage if I don't install aufs-util at all?
Because saving every little bit of memory is very helpf
Hello,
Because "make headers_install" actually installs the kernel headers
under the kernel build tree and not "/usr", would it be better to apply
this patch to the Makefile of aufs-util?
- >8 -
diff --git a/Makefile b/Makefile
index 2f905ad..f8c78c
45 matches
Mail list logo
