Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 51

Thread: fusecompress on knoppix-data.img?

  1. #21
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    Quote Originally Posted by kl522 View Post
    If you are talking about aufs kernel module for KNOPPIX, there is nothing to worry, Klaus K would have compiled the right version for it. If it had been the wrong version, it wouldn't compile with newer kernel and it won't run. It would be noticed !

    By contrast the debian version might be old and faulty, because a typical debian user won't use aufs, so even if it is old and faulty, it would go unnoticed.

    If you are talking about aufs-utils or aufs-tools, then I can't say anything about the debian version, because in a typical use, the aufs-utils are not used at all. It would not be surprising if the package faulty.
    May I suggest that you seem very optimistic about the situation?

    First, aufs is a general tool, and it is used "everywhere", not only in Knoppix. The message I linked to was in response to a Debian user. A "typical" Debian user may not need it, true. But many essential libraries are never required by "typical" users, still they are essential.

    Second, IF Klaus K has compiled the right version for aufs, then he has done a (rare) departure from his (recent?) general Debian compliance. Which would probably mostly be regarded as a hack, since it is not in sync with utils and tools, which we frequently need when we will modify or check something.

    Third, I tend to believe the creator and maintainer of aufs. And the aufs relation to the mainline kernel is - well - "undecided" at best, see for instance the main sourceforge page (http://aufs.sourceforge.net/ ) :

    Note: it becomes clear that "Aufs was rejected. Let's give it up." According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount.
    So, as I interpret this, the last thing we should expect, is any kind of automagical updating and integration of aufs.

  2. #22
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by dinosoep View Post
    [/code]when I tried compiling from source it gave me:
    Code:
    install -d /usr/share/man/man5
    install -o root -g root -p -m 644 aufs.5 /usr/share/man/man5
    install -d /sbin
    install -o root -g root -p -m 755 mount.aufs umount.aufs auplink /sbin
    install: cannot stat `umount.aufs': No such file or directory
    make: *** [install_sbin] Error 1
    The maintainer suggested updating the kernel module which I'm going to try this evening
    I have more confidence on the installed aufs kernel module than your compilation.

    Your compilation output seems to suggest that umount.aufs is not present. But 'umount.aufs' is to be provided by YOUR compilation, so it is still more like your compilation has error. Furthermore the output is coming from 'make install', you should have an error free 'make' prior to 'sudo make install'. Perhaps you have a wrong version of /usr/include/linux/aufs_type.h installed on knoppix.

  3. #23
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    May I suggest that you seem very optimistic about the situation?
    Yes I am. Because I update my kernel very often, each time I have to match it against the correct version of aufs. I have compiled aufs kernel module too many times already.

    First, aufs is a general tool, and it is used "everywhere", not only in Knoppix. The message I linked to was in response to a Debian user. A "typical" Debian user may not need it, true. But many essential libraries are never required by "typical" users, still they are essential.
    I don't know what "essential" libraries you are talking about. A typical aufs user does not even use the aufs tools. Even knoppix does not use the aufs tools ! Only in rare occasions that you need to use the aufs utils or tools.

  4. #24
    Senior Member
    Join Date
    Jan 2011
    Posts
    123
    Yeah, Make was succesfull ...
    Are you able to compile it succesfully?

  5. #25
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by dinosoep View Post
    Yeah, Make was succesfull ...
    Are you able to compile it succesfully?
    You may have to re-read your 'make' output more carefully. Here is my output :-
    Code:
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"   ver.c   -o ver
    ./ver
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"   c2tmac.c   -o c2tmac
    rm -f aufs.5
    ./c2tmac > aufs.5
    awk '{ \
            gsub(/\140[^\047]*\047/, "\\[oq]&\\[cq]"); \
            gsub(/\\\[oq\]\140/, "\\[oq]"); \
            gsub(/\047\\\[cq\]/, "\\[cq]"); \
            gsub(/\047/, "\\[aq]"); \
            print; \
        }' aufs.in.5 >> aufs.5
    chmod a-w aufs.5
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o proc_mnt.o proc_mnt.c
    ar rv libautil.a proc_mnt.o
    ar: creating libautil.a
    a - proc_mnt.o
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o br.o br.c
    ar rv libautil.a br.o
    a - br.o
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o plink.o plink.c
    ar rv libautil.a plink.o
    a - plink.o
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o mtab.o mtab.c
    ar rv libautil.a mtab.o
    a - mtab.o
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o auibusy.o auibusy.c
    cc -static -s  auibusy.o  -L. -lautil -o auibusy
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o auplink.o auplink.c
    cc -static -s  auplink.o  -L. -lautil -o auplink
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o mount.aufs.o mount.aufs.c
    cc -static -s  mount.aufs.o  -L. -lautil -o mount.aufs
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"  -c -o umount.aufs.o umount.aufs.c
    cc -static -s  umount.aufs.o  -L. -lautil -o umount.aufs
    cc -I./libau -O -Wall -DMOUNT_CMD_PATH=\"\"   c2sh.c   -o c2sh
    rm -f etc_default_aufs
    echo '# aufs variables for shell scripts' > etc_default_aufs
    ./c2sh >> etc_default_aufs
    echo >> etc_default_aufs
    sed -e '0,/^$/d' aufs.shlib >> etc_default_aufs
    make -C libau all
    make[1]: Entering directory `/mnt/part3/tmp/linux-2.6.38.7/aufs2-util.git/libau'
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I. -DMOUNT_CMD_PATH=\"\"  -c -o libau.o libau.c
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I. -DMOUNT_CMD_PATH=\"\"  -c -o rdu_lib.o rdu_lib.c
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I. -DMOUNT_CMD_PATH=\"\"  -c -o rdu.o rdu.c
    ln -sf rdu.c rdu64.c
    cc -I./libau -O -Wall -DRdu64 -fPIC -DNDEBUG -D_REENTRANT -I. -DMOUNT_CMD_PATH=\"\"  -c -o rdu64.o rdu64.c
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I. -DMOUNT_CMD_PATH=\"\"  -c -o pathconf.o pathconf.c
    cc --shared -Wl,-soname,libau.so.2  \
            -o libau.so.2.5 libau.o rdu_lib.o rdu.o rdu64.o pathconf.o -ldl -lpthread
    ln -sf libau.so.2.5 libau.so.2
    ln -sf libau.so.2 libau.so
    make[1]: Leaving directory `/mnt/part3/tmp/linux-2.6.38.7/aufs2-util.git/libau'
    ln -sf ./libau/libau*.so .
    rm ver c2tmac c2sh

  6. #26
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    Quote Originally Posted by kl522 View Post
    Yes I am. Because I update my kernel very often, each time I have to match it against the correct version of aufs. I have compiled aufs kernel module too many times already.
    If you compile from latest sourceforge version from the developer, it is surely OK. My concern was about the "correct" version of aufs.

    Quote Originally Posted by kl522 View Post
    I don't know what "essential" libraries you are talking about. A typical aufs user does not even use the aufs tools. Even knoppix does not use the aufs tools ! Only in rare occasions that you need to use the aufs utils or tools.
    "Essential" is of course a relative concept. As a new example, on Friday an error message appeared on R-help: http://www.mail-archive.com/r-help@r...msg137086.html
    A possible explanation, mentioned by Brian Ripley, is Debian's versions of the lapack and blas libraries. When Debian is used on a scientific/engineering workstation, those libraries are surely essential, even though the vast majority of users don't use them. They could, however, crop up anywhere, embedded in image processing routines, games etc.

    A more actual example is provided by this thread: Use of aufs-tools to make no-wear Knoppix versions for flash memory. With widespread use, those tools could migrate into the "essential" category, I think.

  7. #27
    Senior Member
    Join Date
    Jan 2011
    Posts
    123
    this is my make output:
    Code:
    cc -I./libau -O -Wall    c2tmac.c   -o c2tmac
    rm -f aufs.5
    ./c2tmac > aufs.5
    awk '{ \
    		gsub(/\140[^\047]*\047/, "\\[oq]&\\[cq]"); \
    		gsub(/\\\[oq\]\140/, "\\[oq]"); \
    		gsub(/\047\\\[cq\]/, "\\[cq]"); \
    		gsub(/\047/, "\\[aq]"); \
    		print; \
    	}' aufs.in.5 >> aufs.5
    chmod a-w aufs.5
    cc -I./libau -O -Wall   -c -o proc_mnt.o proc_mnt.c
    ar rv libautil.a proc_mnt.o
    ar: creating libautil.a
    a - proc_mnt.o
    cc -I./libau -O -Wall   -c -o br.o br.c
    ar rv libautil.a br.o
    a - br.o
    cc -I./libau -O -Wall   -c -o plink.o plink.c
    ar rv libautil.a plink.o
    a - plink.o
    cc -I./libau -O -Wall   -c -o mtab.o mtab.c
    ar rv libautil.a mtab.o
    a - mtab.o
    cc -I./libau -O -Wall   -c -o auplink.o auplink.c
    cc -static -s  auplink.o  -L. -lautil -o auplink
    cc -I./libau -O -Wall   -c -o mount.aufs.o mount.aufs.c
    cc -static -s  mount.aufs.o  -L. -lautil -o mount.aufs
    cc -I./libau -O -Wall    c2sh.c   -o c2sh
    rm -f etc_default_aufs
    echo '# aufs variables for shell scripts' > etc_default_aufs
    ./c2sh >> etc_default_aufs
    echo >> etc_default_aufs
    sed -e '0,/^$/d' aufs.shlib >> etc_default_aufs
    make -C libau all
    make[1]: Entering directory `/home/knoppix/aufs2.1-tools/libau'
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I.   -c -o libau.o libau.c
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I.   -c -o rdu_lib.o rdu_lib.c
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I.   -c -o rdu.o rdu.c
    ln -sf rdu.c rdu64.c
    cc -I./libau -O -Wall -DRdu64 -fPIC -DNDEBUG -D_REENTRANT -I.   -c -o rdu64.o rdu64.c
    cc -I./libau -O -Wall -fPIC -DNDEBUG -D_REENTRANT -I.   -c -o pathconf.o pathconf.c
    cc --shared -Wl,-soname,libau.so.2  \
    		-o libau.so.2.3 libau.o rdu_lib.o rdu.o rdu64.o pathconf.o -ldl -lpthread
    ln -sf libau.so.2.3 libau.so.2
    ln -sf libau.so.2 libau.so
    make[1]: Leaving directory `/home/knoppix/aufs2.1-tools/libau'
    ln -sf ./libau/libau*.so .
    rm c2tmac c2sh
    as you can see, no errors at all.
    only mount.aufs gets made, umount.aufs doesn't...

  8. #28
    Senior Member
    Join Date
    Jan 2011
    Posts
    123
    hehe, whiteout files seem to simply be .wh..original_filename So rsync should do the job as capricony suggested, going to try it out now

  9. #29
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by dinosoep View Post
    as you can see, no errors at all.
    only mount.aufs gets made, umount.aufs doesn't...
    Then it is obvious your version of source code is faulty.

    If you check careful, my source compilation also compiles another program called 'ver'. This is a program which verifies version matching. If there is a version mismatch, compilation of 'ver' will not pass.
    Last edited by kl522; 06-05-2011 at 11:24 AM. Reason: Additional notes

  10. #30
    Senior Member registered user
    Join Date
    Dec 2009
    Posts
    423
    Quote Originally Posted by Capricorny View Post
    If you compile from latest sourceforge version from the developer, it is surely OK. My concern was about the "correct" version of aufs.
    Whatever it is, the point I want to make is that, I am pretty confident that Klaus K have compiled aufs correctly to match his version of kernel. The last thing to suspect is the version of kernel aufs module is wrong. Knoppix will not run if the kernel aufs module is wrong.

    The aufs toolset is a totally different story. Knoppix does not use it. Most debian users also do not use it. So I am not surprised that it might be faulty.

Page 3 of 6 FirstFirst 12345 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


790097-001 HP 3.4Ghz Xeon E5-2643 V3 CPU Processor for Z840 Z640 Workstation picture

790097-001 HP 3.4Ghz Xeon E5-2643 V3 CPU Processor for Z840 Z640 Workstation

$111.49



Intel - Core i7-12700K Desktop Processor 12 (8P+4E) Cores up to 5.0 GHz Unloc... picture

Intel - Core i7-12700K Desktop Processor 12 (8P+4E) Cores up to 5.0 GHz Unloc...

$242.99



Intel - Core i9-14900K 14th Gen 24-Core 32-Thread - 4.4GHz (6.0GHz Turbo) Soc... picture

Intel - Core i9-14900K 14th Gen 24-Core 32-Thread - 4.4GHz (6.0GHz Turbo) Soc...

$539.99



Intel SR2L6 Core i5-6500 3.2GHz 6th Gen LGA1151 Socket Quad-Core Processor picture

Intel SR2L6 Core i5-6500 3.2GHz 6th Gen LGA1151 Socket Quad-Core Processor

$24.59



Intel 6 Core i5-8600 3.1GHZ Desktop Processor SR3X0 picture

Intel 6 Core i5-8600 3.1GHZ Desktop Processor SR3X0

$50.00



Intel - Core i7-14700K 14th Gen 20-Core 28-Thread - 4.3GHz (5.6GHz Turbo) Soc... picture

Intel - Core i7-14700K 14th Gen 20-Core 28-Thread - 4.3GHz (5.6GHz Turbo) Soc...

$399.99



Intel Xeon E5-2690V2 3.00GHz 10-Core (SR1A5) Processor CPU READ DESCRIPTION picture

Intel Xeon E5-2690V2 3.00GHz 10-Core (SR1A5) Processor CPU READ DESCRIPTION

$12.00



Intel - Core i5-12600K Desktop Processor 10 (6P+4E) Cores up to 4.9 GHz Unloc... picture

Intel - Core i5-12600K Desktop Processor 10 (6P+4E) Cores up to 4.9 GHz Unloc...

$197.99



AMD Ryzen 7 2700X CPU Processor 3.7GHz AM4 picture

AMD Ryzen 7 2700X CPU Processor 3.7GHz AM4

$74.99



AMD EPYC 7F52 CPU processor 16 cores 32 threads 3.5GHZ up to 3.9GHZ 240w picture

AMD EPYC 7F52 CPU processor 16 cores 32 threads 3.5GHZ up to 3.9GHZ 240w

$299.00