fusecompress on knoppix-data.img?

[dinosoep]

rsync story didn't work out, cause after an rsync + delete you get nfs stale locks

[dinosoep]

Nfs stale locks can be overcome by remounting /UNIONFS. Here is the problem, with a (kinda) clean knoppix I can't unmount an aufs mount point, just mounting.
Is this normal?
Can I fix this easily?

[kl522]

Here is the problem, with a (kinda) clean knoppix I can't unmount an aufs mount point, just mounting.
Is this normal?

If you mount your own aufs mount point, you should be able to umount it.
However if you want to umount KNOPPIX mount point, you can't do it.
I mentioned this sometime ago, but probably no one notices it and no one bothers about it.

As result, when Knoppix shutdowns down, knoppix does not manage to umount everything before it halts. PROBABLY it does not matter if you mount the persistent file over file system such as VFAT and ext2/ext3. But if you mount Knoppix persistent file over NTFS, Knoppix kills the fuse process before shutdown and and it can corrupt the persistent file system.

If you ask is this normal, then I would say it is not normal but it is a knoppix behaviour.

Can I fix this easily?

Yes this can be fixed but perhaps not so easily. In my own customization I umount EVERYTHING before shutdown down.

[dinosoep]

Well kl522, I want to unmount the /UNIONFS mount point and then remount that. For some crazy reason I am not able to do this.
And it would be great if you could share your fixes with us as your solution seems way cleaner compared to the default knoppix behaviour

[kl522]

Well kl522, I want to unmount the /UNIONFS mount point and then remount that. For some crazy reason I am not able to do this.
And it would be great if you could share your fixes with us as your solution seems way cleaner compared to the default knoppix behaviour

Before I share with you how I accomplish "clean unmounting' of the entire KNOPPIX system, I would like to understand a bit more. Can you explain to us why do you want to unmount /UNIONFS and then remount it ?

If you are trying to do all this in the middle of system running, I think the chances of it succeeding will be slim. If you are trying to do this while the system is shutting down, chances of it succeeding will be higher. Because to umount /UNIONFS you will have to kill the processes which are using the file system.

I succeeded in umount /UNIONFS, /KNOPPIX-DATA and /mnt-system, but all these are done during system shutdown.

[dinosoep]

when I use rsync to copy everything from ramdisk to knoppix-data there is no problem but as soon as I remove everything from the knoppix-data-ramdisk (after a copy) I get nfs stale handle. This is because the filesystem still thinks to know where the files are while in fact they are moved to somewhere else.
Every site I came up with suggested remounting the whole package and I don't see a better solution

[kl522]

A quick check on the script aubrsync also contains rsync however it does not contain umount, but it does include 'remount'. So I suggest you still use aubrsync. What you need to do is to manually copy 'mount.aufs' to /sbin, aubrsync to /usr/bin, since your 'make install' has failed. There is no need to 'umount' before you 'remount'.

If you want I can post you my compiled aufs-utils. But it was done for kernel 2.6.38.7 which I am not sure it will be compatible with your kernel.

[Capricorny]

A quick check on the script aubrsync also contains rsync however it does not contain umount, but it does include 'remount'. So I suggest you still use aubrsync. What you need to do is to manually copy 'mount.aufs' to /sbin, aubrsync to /usr/bin, since your 'make install' has failed. There is no need to 'umount' before you 'remount'.

If you want I can post you my compiled aufs-utils. But it was done for kernel 2.6.38.7 which I am not sure it will be compatible with your kernel.

I think it would be nice to have the complete aufs2-package compiled with the kernel version of the actual release - as a starting point. Speaking for myself, I'm pretty sure that I will be able to break things during kernel updates, so I think I need a safe and stable place to start. From sourceforge, it seems that basically the same aufs2 version goes with a series of kernel releases?

In addition, could there be compatibility problems with 32/64-bits compiles?

As result, when Knoppix shutdowns down, knoppix does not manage to umount everything before it halts. PROBABLY it does not matter if you mount the persistent file over file system such as VFAT and ext2/ext3. But if you mount Knoppix persistent file over NTFS, Knoppix kills the fuse process before shutdown and and it can corrupt the persistent file system.

If you ask is this normal, then I would say it is not normal but it is a knoppix behaviour.

Can I fix this easily?

Yes this can be fixed but perhaps not so easily. In my own customization I umount EVERYTHING before shutdown down.

I think your way is the right way here. And I really can't see why this should not be fixed, as it may also provide keys to better and safer system administration. I see very little reason for not having two alternatives on exiting X: The ordinary command-line, and the basic start position where /UNIONFS is unmounted. The ordinary shutdown/reboot then proceeds through the basic stage, with several possibilities for adding in system administration procedures.

BTW, maybe we should ask the aufs developer to include a restricted varaiant of aufs-mounting branches from aufs-mounted volumes? It is mentioned among future possibilities, and one major reason why aufs is invisible and not too useful for our day-to-day tasks with Knoppix, is that we can't perform anything unless we have volumes outside of /UNIONFS mounted.

Typical uses would be database storage directories, where a cloop startup is unified with extra storage (outside the persistent image), or web content, like directories with large downloadable files.

[dinosoep]

Well, that was the problem kl522, when you remount "sudo mount -o remount" it throws those
/sbin/mount.aufslink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device
errors.
It would be great to have a starting point with an actually working mount - umount - remount for aufs

[kl522]

Well, that was the problem kl522, when you remount "sudo mount -o remount" it throws those
/sbin/mount.aufslink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device
errors.

This is because the /usr/include/linux/aufs_type.h included in Knoppix is a very very old version. Either you fix it yourself or you have to get Klaus Knopper to fix it.

Also your downloaded aufs-utils source code is questionable too, as we discussed earlier, it does not seem to compile a few other programs.

It would be great to have a starting point with an actually working mount - umount - remount for aufs

There is also a design problem with this approach. As I mentioned before, because /UNIONFS is kind of the root file system for Knoppix. If you insist on unmounting it, though it can be done, but it is only suitable during system shutdown. Meaning, your 'no-wear' thingie is only able to flush the changes during system shutdown. So if there is a power failure in between, you lose all the changes.

Anyway I have included my compiled aufs2-tools for kernel 2.6.38. If you test the tools against a non-root file system, you can convince yourself that it is working.

http://dl.free.fr/pFytkL0aw

I believe you will still have other errors even with using the said tools, for reason that /UNIONFS is kind of the root file system for Knoppix.