Problem building aufs-util: default kernel header location

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..f8c78c0

Can I simply ignore aufs-util in small systems?

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

aufs au_warn_loopback:111:loop1[13277]: you may want to try another patch for loopback file on squashfs(0x73717368) branch

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

Re: How to configure aufs3 mounting in fstab for Gentoo?

On Thu, Jul 12, 2012 at 11:23 AM, Armin Ranjbar z...@zoup.org 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

Re: make headers_install

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 to...@slax.org wrote: Hello, I'm compiling aufs for linux 3.2. I

Re: make headers_install

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 to...@slax.org wrote: ... I believe that I will need aufs_type.h in my /usr/include/linux in order to compile

Re: make headers_install

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

Re: aufs standalone module won't load ~ unknown symbols

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

Re: Unprivileged user have no access to filesystem

On Mon, Oct 15, 2012 at 6:10 PM, sf...@users.sourceforge.net 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: /sys/fs/aufs/* config.gz: /proc/config.gz

Re: Unprivileged user have no access to filesystem

On Mon, Oct 15, 2012 at 7:07 PM, sf...@users.sourceforge.net 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)

Re: Unprivileged user have no access to filesystem

On Mon, Oct 15, 2012 at 8:01 PM, sf...@users.sourceforge.net 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

Re: Unprivileged user have no access to filesystem

On Mon, Oct 15, 2012 at 8:45 PM, sf...@users.sourceforge.net 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

Is this an aufs problem?

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:

Re: Is this an aufs problem?

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 Guan, Guan Xin

Re: Is this an aufs problem?

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 the patch and the kernel no longer starts. In my configuration

Re: Is this an aufs problem?

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

Re: aufs3.0 .. aufs3.5 will end

On Thu, Mar 28, 2013 at 3:37 PM, Tomas M to...@slax.org 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

aufs-util for aufs3.2 and later, but aufs is 3.2-20130708

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

Re: aufs-util for aufs3.2 and later, but aufs is 3.2-20130708

On Sat, Jul 13, 2013 at 1:33 AM, sf...@users.sourceforge.net 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

opening deleted file with /proc/$pid/fd/$fd returns ESTALE

if necessary. Best regards, GUAN, Xin -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu

Re: opening deleted file with /proc/$pid/fd/$fd returns ESTALE

Hello Okajima, On Wed, Dec 18, 2013 at 6:02 AM, sf...@users.sourceforge.net 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,

Patch rejected by linux-3.12.7

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

Re: merge conflicts in 3.10.27

On Thu, Jan 16, 2014 at 10:37 AM, Sven Geggus li...@fuchsschwanzdomain.de 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:

Re: aufs3 GIT release

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, sf...@users.sourceforge.net wrote: o news - in

WARNING at lib/idr.c:527

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

Re: WARNING at lib/idr.c:527

On Mon, Jun 9, 2014 at 6:31 PM, sf...@users.sourceforge.net 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 =

Re: WARNING at lib/idr.c:527

On Thu, Jun 12, 2014 at 4:34 AM, sf...@users.sourceforge.net 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

Re: WARNING at lib/idr.c:527

On Thu, Jun 12, 2014 at 11:53 AM, sf...@users.sourceforge.net 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: WARNING at lib/idr.c:527

On Thu, Jun 12, 2014 at 7:20 PM, Nikolay Pertsev nc.e...@gmail.com 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

Re: WARNING at lib/idr.c:527

On Thu, Jun 12, 2014 at 7:36 PM, sf...@users.sourceforge.net 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) {

Re: WARNING at lib/idr.c:527

On Thu, Jun 12, 2014 at 8:22 PM, sf...@users.sourceforge.net 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,

Re: WARNING at lib/idr.c:527

On Sun, Jun 15, 2014 at 7:25 PM, sf...@users.sourceforge.net 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

Re: WARNING at lib/idr.c:527

On Mon, Jun 16, 2014 at 2:36 PM, sf...@users.sourceforge.net 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]

Re: WARNING at lib/idr.c:527

On Mon, Jun 16, 2014 at 9:49 PM, sf...@users.sourceforge.net 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 linux/magic.h and

Re: WARNING at lib/idr.c:527

On Tue, Jun 17, 2014 at 7:30 AM, sf...@users.sourceforge.net 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 linux/magic.h and linux/shm.h otherwise

Re: WARNING at lib/idr.c:527

On Tue, Jun 17, 2014 at 5:48 PM, sf...@users.sourceforge.net 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 --

mm/vmacache.c added to linux-3.14.21, breaking aufs3-mmap.patch

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

Re: aufs3 GIT release

Dear Okajima, The change causes implicit declaration of vfree and vzalloc in fs/aufs/super.c. Could you add back #include linux/vmalloc.h? Thanks! Guan On Sun, Mar 29, 2015 at 5:56 PM, sf...@users.sourceforge.net wrote: All changes are tiny, and the behaviour doesn't change. J. R.

Re: Path to aufhsmd and aufhsm-list

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

Path to aufhsmd and aufhsm-list

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

Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API

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