OmegaPhil:
> ' rdu[rdu_cur++] =3D p;' is failing as rdu is NULL.
Thanx for debugging.
Now I can understand the bug.
libau forgot supporting a simple opendir + closedir case (no readdir).
Here is a patch for you. It will be released on next Monday.
J. R. Okajima
diff --git a/libau/rd
o bugfix
- aufs-util.git, opendir/closedir without readdir, reported by OmegaPhil.
J. R. Okajima
- aufs3-linux.git
aufs: tiny, use IS_ENABLED macro
aufs: cosmetic, fix an indentation
aufs: cosmetic, remove an unnecessary semi-colon
- au
o bugfix
- possible bugfix, temporary lockdep_off for debugfs_create_file
aufs4.x-rcN branch in this release is for linux-v4.8-rc1.
J. R. Okajima
- aufs3-linux.git
aufs: possible bugfix, temporary lockdep_off for debugfs_create_file
- aufs3-stan
> o news
> - linux-v4.6 is out and aufs4.6 too
> When linux-v4.7 comes, I will stop maintaining all aufs3 and aufs4.0
> versions and my development base version will be aufs4.1. If you have
> any objection, please let me know.
As linux-v4.7 and aufs4.7 was released, aufs3 and aufs4.0 versio
o bugfix
- possible bugfix, temporary lockdep_off for debugfs_remove_file
This is very similar to the commit in last week which fi for
debugfs_create_file.
aufs4.x-rcN branch in this release is for linux-v4.8-rc2, and is still
testing pariculary around btrfs.
J. R. Okajima
sf...@users.sourceforge.net:
> As linux-v4.7 and aufs4.7 was released, aufs3 and aufs4.0 version will
> end so soon.
By the end of this month (today), aufs3.1[89] and aufs4.0 are not
maintained anymore. My new development base is aufs4.1.
J. R. Okajima
-
I don't know why but a bug report with a patch from Dave Mills was not
delivered to me. I've just find it in the mail archives on SF.net and
mail-archive.com.
If anyone knows him personally, please forward this mail to him since
the mail archive service doesn't display the sender's mail address.
o bugfix
- dirperm1 and whiteout, reported and fixed by Dave Mills.
- aufs-util.git, possible security bugfix, full path for auplink_frw.
o news
- All aufs3 versions and aufs4.0 are not maintained anymore. The new
development base version is aufs4.1.
o misc.
- shrinkable krealloc
- for linux-v
o bugfix
- update_time() for the special files
- mnt_{want,drop}_write() for update_time()
J. R. Okajima
- aufs4-linux.git#aufs4.1..aufs4.2 branch
aufs: bugfix, update_time() for the special files
aufs: bugfix, mnt_{want,drop}_write() for upd
o bugfix
- aufs-util, auplink, handling the non-aufs mountpoint, reported by
Torok Edwin, fixed by Henrik Ahlgren and forwared by Jan Luca Naumann.
- aufs-util, make a default errno for error_at_ilne(3)
- aufs-util, respect -v option even mtab is procfs
o news
- aufs-util.git supports musl-libc
This release doesn't contain the changes in kernel space except several
patches in aufs4-standlone.git (they are just to follow the mainline
v4.8-rc7).
This release contains the chages (which was spotted by Natanael Copa)
in user space. ie. aufs-util.git.
J. R. Okajima
-
o bugfix
- possible bugfix, auplink_ftw, prohibit 'touch' to create a new file
Essentially this release contains the update in aufs-util.git only.
aufs4.x-rcN branches in aufs4-linux.git and aufs4-standlone.git are
updated too, but the changes are just to follow the mainline.
J. R. Okajima
---
Hello OmegaPhil,
Thanx for reporting.
OmegaPhil:
> I'm currently updating aufs-util in the usual way (looks like aufs4.1 is
> the latest branch), building succeeds but make install fails with the
> following:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3
Hello Guan,
Guan Xin:
> 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),
> or is there a reason for not allowing installation to other
> directories such as /usr/libexec, e
OmegaPhil:
> CC is unset, here is the original make command:
Ok, thanx.
I will apply this and release next Monday.
$ .../aufs-util.git$aufs4.1$ git diff -w
diff --git a/Makefile b/Makefile
index 72b68ee..313b62b 100644
--- a/Makefile
+++ b/Makefile
@@ -65,9 +65,7 @@ endef
$(eval Glibc=$(call te
OmegaPhil:
> Reading the top of the main Makefile, I'm assuming that test_glibc is
> doing a compilation that always happens regardless of the make target
> requested.
You are right.
Although I don't think it a big problem, here is a patch for you.
J. R. Okajima
commit 61ba8e01f1960b43e8ff3b7f
OmegaPhil:
> > Cheers - as you're changing that bit now, would also make sense to not
> > compile during the install target as well (can't think of any other
> > targets a normal user would use).
>
>
> Ah sorry, this is precisely when you want it... sorry I'm used to
> autotools systems and this k
OmegaPhil:
> Sorry, I've put this email through patch, and then manually copied out
> the text and tried again, but the patch doesn't apply. Is this supposed
> to go on top of aufs4.1?
Sorry. There is another patch before that.
My current aufs4.1 looks like this.
95f0af1 2016-10-06 make sure all
OmegaPhil:
> OK, applying 4647760 then 3557ce3 on top of 92d857b results in the
> following build failure (from the usual make all call from the top
> directory):
Thanx for testing.
Would you test this patch?
J. R. Okajima
diff --git a/Makefile b/Makefile
index 298ae05..3838f0e 100644
--- a/Mak
OmegaPhil:
> Great, make all works, and make install triggers no compilation (so the
> non-hacked checkinstall command works again).
Glad to hear that!
Thanx again for your repeated tests.
Those patches will be released on next Monday.
J. R. Okajima
o bugfix
All are in userspace aufs-util.git and reported by OmegaPhil.
- simplify LibAuDir variable
- stop evaluating test_glibc when 'make clean'
o news
- linux-v4.8 is released and aufs4.8 too.
- linux-v4.6 is marked as EOL and aufs4.6 too.
J. R. Okajima
---
Hello all,
Almost a month passed since I releaseed aufs4 for linux-v4.8. And the
mainline keeps updating and it is v4.9-rc4 or 5 now.
Unfortunately I am busy now and I have to admit the aufs release for
v4.9 (including any -rcN versions) will be late for a month or two.
If something critical due
Hello Scooby,
Shraptor Shraptor:
> Does your current release include any kernels were dirtyc0w bug is fixed?
Would you explain what dirtyc0w bug is?
J. R. Okajima
--
Developer Access Program for Intel Xeon Phi Process
"Christoph Pleger":
> I am coming back to this old thread from March/April 2015. Because, when
> just switching from Debian 8 to Ubuntu 16.04 on the NFS client, without
> changing anything on the NFS server, I get "Operation not supported" again
> when trying to write anything to a read-write aufs
"Christoph Pleger":
> [ 193.1356342] aufs au_do_cpup_xattr:96:setupcon[987]: system.nfs4_acl,
> err -95
This message means that
- the internal copy-up happens.
- the file on the lower branch has an XATTR called "system.nfs4_acl".
- as a part of copy-up, aufs tries copying all XATTR from lower to
Hello Brenden,
Brenden Carvalho:
> I want to request a new create policy,
>
> create=top
> Select the highest writeable branch
Hmm, let me make sure.
You have multiple writable branches, and what would you do when the
highest branch gets full and you cannot create a new file anymore? Which
branc
Brenden Carvalho:
> The policy should be similar to create=mfs,
> But instead of writing to the branch in order of free space,
> It should write to the highest branch. If that highest branch gets full, it
> can write to the next highest branch
Hmm, I remember that I have discussed such feature i
Brenden Carvalho:
> Although, I was hoping for a quick turnaround on this,=20
> I thought most of the logic/code needed should already be present in the ot=
> her create policies just implemented differently.
>
> A couple of months is a long time, if possible could you do it a bit quicke=
> r? Atl
Hi Brenden,
Brenden Carvalho:
> Yes that is exactly what I need, Glad to know its possible.
>
> Although, I was hoping for a quick turnaround on this,=20
> I thought most of the logic/code needed should already be present in the ot=
> her create policies just implemented differently.
I've just s
o bugfix
- dependency bugfix, linux/fs/mount.h, reported by Jan Luca Naumann and
Philipp Marek.
o news
- linux-v4.9 is released, so is aufs4.9.
+ support new rename flags.
- new create policy tdmfs, requested by Brenden Carvalho.
Currently there are two known problems in aufs.
- "MAX_LOCKDE
Hello Arun,
Arun Chandran:
> 4) Now if I cd to /mnt/mnt and do 'ls' it hangs and I get the below oops.
>
>
> # dmesg
> [ 148.855382] [ cut here ]
> [ 148.855382] kernel BUG at fs/aufs/sbinfo.c:336!
:::
That is interesting.
Smack enters aufs twice.
Generally a sy
Arun Chandran:
> Thank you for the quick reply.
> I have tested the patch. 'ls' behavior is the same, it hangs. There
> are no error messages coming now may be it is doing something inside
> au_h_path_getattr() with holding the lock (When printed locked is -1).
Ah, it was necessary for au_h_path_g
Arun Chandran:
> Are you going to fix this in your tree? Please feel free to ask my
> help in testing it, I will happily do it.
Thanx for testing.
As you might know, aufs3.19 is not maintained now. So the tree won't be
updated anymore. But similar issue will happen in aufs4.1 and later. I
mean th
Arun Chandran:
> Now I moved my testing to 4.1.17(Used origin/aufs4.1.13+ from
> aufs4-standalone + b.patch applied).
>
> As a root user mounted the layers:
> # mount -t aufs -o
> br=./layer2=rw:./layer1=ro:./layer0=ro:,noplink,smackfsdef=k1,smackfsroot=k1
> -o udba=reval none ./rootfs_mnt/
Arun Chandran:
> # mount -t aufs -o br=./layer2=rw:./layer1=ro:./layer0=ro -o
> udba=reval -o noplink,smackfsdef=k1,smackfsroot=k1 none ./rootfs_mnt
I'd suggest you to specify and test smack options on layerN instead of
rootfs_mnt.
Aufs is a virtual filesystem and it doesn't have a backend block
Arun Chandran:
> This happens because aufs handles removal of files through newly
> created file "layer1/.wh..wh.aufs"(I am guessing this from the below
> printk), as this file got created during the mount operation it is
> labeled as "_"
Still I don't get the point.
Would you try these steps? I
Arun Chandran:
> -
> Files in the layers before mounting
> --
> # for i in `find layer* `; do chsmack $i; done
> layer0 access="k1"
> layer0/0.txt access="k1"
> layer1 access="k1"
> layer1/1.txt access="k1"
At
Arun Chandran:
> # id
> uid=1001(test) gid=1001(test) groups=1001(test)
:::
> # cd layer1/
> # >.wh..wh.aufs
> # ln .wh..wh.aufs .wh.0.txt
Ok, succeeded with a normal user.
How about as a superuser?
cd layer1
sudo touch .wh..wh.aufs
ln .wh..wh.aufs .wh.0.txt
Is .wh..wh.aufs created with
Arun Chandran:
> No, It succeeded and created with label "k1", please see below
Ok, then let's make sure again.
- you wrote that the smack label for root user is "_".
- "sudo mount -t aufs ..." created the file with access="_".
- "sudo touch ..." created with access="k1".
Why didn't "touch" and
Hello Nikolaus,
"Demmel Nikolaus (BOSP/PAR)":
> we are using AUFS for our root filesystem with an tmpfs overlay and recentl=
> y wanted to switch to a kernel with PREEMPT_RT patch. Unfortunately, it see=
> ms that mounting aufs seems to hang about 40% of the time during boot (ther=
> e is no spec
Arun Chandran:
> No with 'sudo mount ..' the .wh.* files are created with label of the
> user test not with the label of root.
> [This is because objects gets label of the process; label of user test
> is "k1"; sudo is not changing label]
I see.
It may be a very basic building block of security l
Arun Chandran:
> "sudo mount .." gives correct labels. I can't use it because the
> containers don't get sudo inside ; container might be running with the
> lowest possible privileges.
Our discussion about the smack label is almost done. Thank you.
But I'd suggest you to consider other docker sto
"Demmel Nikolaus (BOSP/PAR)":
> I'm assuming from your response that in general you expect AUFS to work wit=
> h PREEMPT_RT, or is this not the case?
Although I myself don't use RT patch, yes it should work. Of course,
some workaround may be necessary. It won't be clear until lots of tests
and di
o. Please test this patch.
You will need "acl" mount option for aufs to gain the full support of
posix-acl.
By the way, Justin's original post to this ML was not delivered to me. I
just got one line "cc @sfjro" msg from him, which was posted to
https://github.com/docker/docker
Hello OmegaPhil,
OmegaPhil:
> The actual problem is happening in git's
> sha1_file.c:prepare_packed_git_one, the closedir call right at the
> bottom is setting errno to 'Bad file descriptor', git later on notices
> that errno is bad and panics (ironically the fetch itself looks good).
>
> Any ide
Yair Yarom:
> Thanks, the patch works for me (we're usually not using acl, and that's
> what I've checked).
Thanks.
The patch will be included in next aufs release after my local tests
which takes several days.
J. R. Okajima
--
Hello Michael,
"M. J. Everitt":
> I was attempting to apply the aufs3 kernel patches to a 3.12.52 kernel
> I'm running under Gentoo linux, but the patchset for 3.12.31+ now fails.
> I contacted the Gentoo maintainer[1] who pointed me to this kernel
> commit[2], which tallies with my results of pat
Hello all,
The current base version of aufs development is linux-v4.1. And the
latest mainline version is v4.10-rc5. When v4.10 is released, I will
stop maintaining aufs4.[123] versions and the new base will be aufs4.4.
I hope you don't mind.
J. R. Okajima
--
OmegaPhil:
> I understand what you are saying from the manpage, however it does seem
> reasonable to say that any unusual errno state means a failure has
> occurred somewhere (ignoring the fact that released libau currently sets
> EBADF even when a failure has not happened).
>
> If I report this to
"M. J. Everitt":
> Thanks for that, I'll give that a roll, see how I get on. Hopefully that
> will be all!
Good luck, but there is an irritating situation.
The list in my previous mail is the difference between aufs3.12.31+ and
aufs3.13, but I don't know whether all these commits are merged into
v
OmegaPhil:
> Cheers - just out of interest, do you know how to set a watchpoint on
> errno in gdb? That wouldve saved a lot of time. It seems gdb is only
> capable of using errno in an expression when it suits it...
In our ancient age, the global errno was just a intger variable. In
these days, e
This release contains a possible bugfix about syncfs(2), but the commit
is not enough. It will be refined soon.
o bugfix
- possible bugfix, missing s_umount rwsem for branch fs' sync_fs
- for v4.9, support posix acl, reported by Justin Cormack.
- aufs-util.git libau: closedir, clear errno explicit
o news
- for aufs: make __sync_filesystem() global, and export it
- aufs-util.git, libau.so: limit the exported symbols
J. R. Okajima
- aufs4-linux.git#aufs4.1..aufs4.9 branch
for aufs: make __sync_filesystem() global
aufs: refine aufs_sync_fs
o minor
- convert pid bitmap to a flag per task
- tiny, update the copyright year
Currently git.code.sf.net site rejects all connections from me. It
answers to ping, but unable to connect on ssh and https.
$ ssh -v sf...@git.code.sf.net
:::
debug1: Connecting to git.code.sf.net [216.34.18
"M. J. Everitt":
> I'm a bit confused that all the Gentoo instructions point to using a
> Hardened sources kernel .. I don't (yet) see a reason why, as Philip's
> patches work fine on 3.12.52 "gentoo-sources" . If anyone has any
> suggestions as to why this might (have) be(en) the case, it would f
Hello all,
sf...@users.sourceforge.net:
> The current base version of aufs development is linux-v4.1. And the
> latest mainline version is v4.10-rc5. When v4.10 is released, I will
> stop maintaining aufs4.[123] versions and the new base will be aufs4.4.
> I hope you don't mind.
Now linux-v4.10 a
o news
- linux-v4.10 is released, and here is aufs4.10. Also aufs4.x-rcN start
supporting linux-v4.11-rcN.
- new mount option droplvl=N, which gains a performance in return for
the features. Use it carefully.
J. R. Okajima
- aufs4-linux.git#aufs4.4..a
o news
- for linux-v4.5, support for copy_file_range(2).
o misc
- for linux-v4.5, use vfs_clone_file_range() in copy-up
J. R. Okajima
- aufs4-linux.git#aufs4.4 branch
none
- aufs4-linux.git#aufs4.5..aufs4.x-rcN branch
aufs: for v4.5, use vfs_clo
o news
- fine-grained xino lock
It should be a little help for the performance, just a little.
J. R. Okajima
- aufs4-linux.git
aufs: fine-grained xino lock 1/2, callee
aufs: fine-grained xino lock 2/2, caller
- aufs4-standalone.git
ditto
"Graw, Mathis":
> as discusses I send out the needed data form my problem with aufs. To downl=
> oad the used kernel sources and all the data provided here as well
> please use the following link:
Ok, but don't you have sysfs?
> > - /sys/fs/aufs/* (if you have them)
These entries are very import
"Graw, Mathis":
> Actually we are having no chroot afaik, what we do is we are mounting an sd=
> -card copying the most of the sd card into ram and overlaying the root fs T=
> o the stuff in the ram with aufs.
Ok, then where is the file /usr/lib/systemd/libsystemd-shared-231.so
actually? (the file
Hello all,
Linux-v4.11 is released, and aufs4.11 is ready too. But I won't release
it. Because of i915/drm shrinker problem in mainline.
http://marc.info/?l=linux-kernel&m=149353250528487&w=2
I hope the fix (which already exists) will be merged into mainline until
4.11.1 or .2. Then I will releas
sf...@users.sourceforge.net:
> Linux-v4.11 is released, and aufs4.11 is ready too. But I won't release
> it. Because of i915/drm shrinker problem in mainline.
> http://marc.info/?l=linux-kernel&m=149353250528487&w=2
>
> I hope the fix (which already exists) will be merged into mainline until
> 4.11
The mainline v4.12-rc1 doesn't pass my test due to drm/i915 shrinker (as
well as v4.11). So do aufs4.x-rcN branch in this release.
I have aufs4.11 branch in my hand but don't release it because
linux-v4.11 doesn't pass my test. When v4.11.X is fine, I will release
aufs4.11.X. It should not be so lo
Hi,
Philip Muller:
> ERROR: "ilog2_NaN" [fs/aufs/aufs.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:90: __modpost] Error 1
> make: *** [Makefile:1106: modules] Error 2
>
> Any clue what might create this issue?
It might be related to your compiler.
See this commit in mainline.
Befor
o bugfix
i_op.c: uninitialized variable in case of CONFIG_AUFS_FAKE_DM enabled,
reported and fixed by Jason Lunz.
Junjiro Okajima
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay
Jason Lunz:
> When compiling aufs on debian etch, I get this warning with 2007-01-15
> cvs:
:::
> This fixes that, though I don't know if it's worth it. The code looks
> good as-is. Maybe gcc needs fixing instead.
It was my fault, aufs's bug, not gcc.
I was testing disabled CONFIG_AUFS_FA
Wilhelm Meier:
> for anyone who is interested here's a rudimentary /init to be used with
> initramfs which sets up the things for diskless clients using aufs as overlay
> for the read-write directories and fscache for the rootfs on nfs.
I think 'caching locally' is a good idea, while I didn't r
o news
- introduce a new file History.
- rename wh.[ch] to whout.[ch].
o minor
- rename some symbols.
+ do_cache_alloc() to aufs_cache_alloc().
+ do_cache_free() to aufs_cache_free().
+ dt_hidden_dentry in struct dtime, to dt_h_dentry.
+ dtohd()
Hello Nobody/Anonymous who reported a bug to the forum on
sourceforge,
Won't you write to this ML, instead of the forum?
Because it is hard for me to write to the forum.
And if you can, will you try 'strace ls' to see which systemcall returns
the error ESTALE? Also will you show me the file list
"Laville Guillaume":
> Sorry for my previous posting in the wrong place :-)
Hi Guillaume,
Thank you for your reports, log and cooperation.
> All seems to work OK (ls, etc...) but, when I tried to extract a simple
> archive (placed in /var/, so accessible from the within sandbox)
> and to do nex
Hello Martin,
Thank you for your bug report (including /proc/mounts) and the
reproducible script.
Martin Walter:
> cat < a.c
> main() {
> int x = open("x", 0);
> rename("y","x");
> fdatasync(x);
> }
> EOF
In this case, a.c didn't open(2) the file "x" for writing. So
fdatasync(2) may
o
- introduce diropq option.
the behaviour of mkdir(2) and rename(2) dir case is changed. now they don't
make '.wh..wh..opq' when it is not necessary. this is the default. if
you dislike this behaviour and still want to make it always, use
'diropq=always' mount option. see the manual in de
The subject in my last mail should be 20070129.
Sorry.
Junjiro Okajima
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & busin
o bugfix
- bugfix: a test in adding a branch, included in a report from
Laville Guillaume.
check the adding branch to be overlapped or not, even if it is a
mount-point.
- bugfix: unionctl script --whereis option.
the action should print the branch path, instead of the given argument, even
"Joey Parrish":
> I've been using aufs a lot, and it's great. I would like to have the
> ability to nest aufs mounts. For example, make one aufs mount a
> branch in another.
>
> What is the nature of the limitation on this? I am an experienced
> coder in both user- and kernel-space and am very
Tomas M:
> Unionctl has 2 bugs.
:::
> Third thing is not a bug but a feature request, if ./file doesn't exist,
> unionctl should return non-zero exit code (now it just prints empty
> string and exits with zero).
Ouch!
Thank you for your report.
Will you test this patch?
Junjiro Okajima
o pre-announce
- the behaviour of mmap(2) after munmap(2) and add/del branch(es) will change.
aufs mmap(2) function checks whether the file descriptor is currently
mmapped or not. But there is a bug in this checking, and I found it is
very hard to fix it.
Finally, I gave up this checking.
Tomas M:
> I believe it means that aufs can have only 127 branches now. Can I
> simply modify this value to 256 or more? Or is there any problem raising
> the max amount?
I think you can. But I have never tried actually.
Also you need to change the type of aufs_bindex_t, which is also defined
i
Hello again,
Tomas M:
> Second, unionctl --whereis doesn't work if relative pathname is used,
> eg.: unionctl /union --whereis ./file
> so I have to call it this way:
> unionctl /union --whereis `readlink -f ./file`
In this case, do we need to support symbolic link which points to
non-existence
Tomas M:
> Well, I believe that aufs should be made so it can handle branches
> differently, bypassing these limitations. Here is my suggestion. Would
> you please consider branch manipulation through /proc? The /proc/mounts
> would show only aufs is mounted somewhere and xino path and mount
>
Wolfgang Barth:
> mount.aufs (20070205) won't work correctly with busybox - I'm using an old
> version 1.01. mount.aufs depends on the correct order of arguments, but the
> mount program from busybox seems not compatible with the standard linux
> one.
>
> Is there a plan to parse the options in
"Chris Furlough":
> Let me explain it again, I want to mount the root "/" as read-only, and =
> have aufs mounted over the top to catch all the writes that the OS, or =
> applications do. Can someone shoot me a command line, and an fstab =
> entry that would handle this?
It highly depends upon y
"Chris Furlough":
> > $ cd /differnt/filesystem
> > $ mkdir rw aufs
> > $ sudo mount -t aufs -o br:./rw:/ none ./aufs
:::
> aufs test_add:364:mount[3452]: / is overlapped
Are you sure that you chdir-ed to different filesystem, i.e. different disk
partition?
Will you show me your /proc/mou
Tomas M:
> and then I add branches one by one, by using
>
> mount -o remount,add:1:/mnt/images/image1 aufs /union
>
> for example. This works OK and branches are added to the union, but
> remounting the union ro causes the oops I sent you. Do you still agree
> it's a problem of the lenght
Tomas M:
> I tested the patch. No difference, remount,ro causes oops in
> kernel/exit.c:860
How about "BUG: ... NULL pointer ..."?
Your gif file showed me it before "BUG: at kernel/exit.c:860".
Junjiro Okajima
-
Using Tomc
Tomas M:
> It was in Linux Live CD all the time, using 'mount' command from
> busybox. Now I tried it in a normal Linux (installed) and it doesn't
> segfault, remount simply exits with E2BIG (Argument list too long).
Thi is the effect of the patch I sent.
If you used the un-patched aufs, it wou
Wolfgang Barth:
> Oops, I was wrong. The order of options from busybox mount is correct, but
> the following test:
>
>test ! -r $f -o \( $do_update -eq 1 -a ! -w $f \) ...
>
> I'm using aufs during boot phase, so /etc/mtab did not exist. mount -n
> won't update /etc/mtab, so why "test ! -r
"Chris Furlough":
> What I'd like to be able to do, is to mount something over the whole "/"
> mount point.
Then you did it. And you see everything under /root/jukebox_cddb/aufs,
except /proc, /sys, /dev/pts and /dev/shm, don't you?
Is it enough for you?
Junjiro Okajima
---
Flemming Madsen:
> Is anybody by any chance contemplating a backport of aufs to the 2.4 kernel.
> Would be much appreciated for use in embedded systems.
Unfortunately, I don't have such machine and disk space.
If anybody start backporting, I will try answering the questions.
I forgot many things
Hello Peter,
Peter Kruse:
> I just wanted to start using aufs but mounting an nfs branch
> failed with kernel 2.6.15.7 and aufs 20070212.
Basically, aufs doesn't support before 2.6.16.
A user had requested me to support 2.6.15, and I did it with limited
features. NFS branch is one of the dropped
Hello Fernando,
"Fernando A. P. Gomes":
> I try to compile aufs with CONFIG_AUFS = y, but nothing happens in my kernel
> source tree.
While I cannot get what you did or expected, there is a description
about Kconfig in README file. It may help you.
Junjiro Okajima
--
Wolfgang Barth:
> I am using aufs at an very early boot state on a linux live cd, at this
> time all is really non writable, so no program is able to create a
> temporary file (see screenshot attached).
Then, you should use '-i' option to your mount(8), to stop mount.aufs.
The purpose of mount.au
Hi Tomas,
Tomas M:
> The final result is here:
Thank you for your explanation.
> (notice the absence of 'aufs' argument in front of /union) then it
> causes problem in LiveCD. The mount segfaults.
> - It doesn't matter if I have mount.aufs or not
> - it still doesn't matter if aufs is patched
Hello Patrick,
Patrick:
> Now my question is .. do I have to adapt /etc/fstab at all? What also
> concerns me, is that 'mount' does not show any unionfs/aufs related
> stuff (I run-init'ed into the unionfs tho) .. is that normal? I am
> asking because common livecd's (knoppix, grml, etc.) alw
Patrick:
> Err, I used -n and /etc/mtab exists. I dont get at all, what you're
> refering to. My initial question was, wether /etc/fstab needs adaption,
> since mount does not list anything unionfs related. But still it works
What do you mean adaption?
If you use -n option, then /etc/mtab will
"Marty Rosenberg":
> so it seems like aufs gets extremely unstable when running with my setup.
> After attempting to run a du operation or two, the kernel module crashes.
> I'm not sure if it occurs before the module crash, but other actions such as
> ls will hang. Other people using the syst
"Chris Furlough":
> > Then you did it. And you see everything under /root/jukebox_cddb/aufs,
> > except /proc, /sys, /dev/pts and /dev/shm, don't you?
> > Is it enough for you?
>
> Either I don't understand aufs, or it's not working. After the above mount,
> I went to /root, and created a file,
Hi Tomas,
Tomas M:
> would you please write some more info about nwkq parameter for aufs?
> At least, what is the default value, or what it is the
> 'special I/O request' you're refering to in man aufs.5
The default value is described in the manual.
And how about this one?
+The special I/O req
Patrick:
> Heh, will do . but is that behavior of unionctl supposed to be like that? :)
Of course, no it isn't.
And Tomas M suggested you one of the way to research the problem.
Thank you Tomas.
Additionally, there is a description about the time of remount. When you
have lots of inodes and dent
601 - 700 of 2717 matches
Mail list logo
