microcore 3.3 - tcz remount bug [RESOLVED-not a TC bug at all]

[caminati]

microcore 3.3; boot parameters:

vga=952 text multivt base norestore initrd=microcore.gz

right after boot I have "tce-loaded -i" the squashfs-tools-4.x.tcz extension. Then:

Code: [Select]

tc@box:~$ mkdir -p 1/usr/local/bin
tc@box:~$ mkdir -p 2/usr/local/bin
tc@box:~$ echo echo one > 1/usr/local/bin/zero
tc@box:~$ echo echo two > 2/usr/local/bin/zero
tc@box:~$ chmod 777 1/usr/local/bin/zero
tc@box:~$ chmod 777 2/usr/local/bin/zero
tc@box:~$ mksquashfs 1/ 1.tcz
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on 1.tcz, block size 4096.
[===================================================================================================================================================|] 1/1 100%
Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 4096
        compressed data, compressed metadata, compressed fragments, compressed xattrs
        duplicates are removed
Filesystem size 0.31 Kbytes (0.00 Mbytes)
        70.13% of uncompressed filesystem size (0.44 Kbytes)
Inode table size 76 bytes (0.07 Kbytes)
        46.91% of uncompressed inode table size (162 bytes)
Directory table size 62 bytes (0.06 Kbytes)
        63.92% of uncompressed directory table size (97 bytes)
Number of duplicate files found 0
Number of inodes 5
Number of files 1
Number of fragments 1
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 4
Number of ids (unique uids + gids) 2
Number of uids 1
        tc (1001)
Number of gids 1
        staff (50)
tc@box:~$ mksquashfs 2 2.tcz
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on 2.tcz, block size 4096.
[===================================================================================================================================================|] 1/1 100%
Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 4096
        compressed data, compressed metadata, compressed fragments, compressed xattrs
        duplicates are removed
Filesystem size 0.31 Kbytes (0.00 Mbytes)
        70.13% of uncompressed filesystem size (0.44 Kbytes)
Inode table size 76 bytes (0.07 Kbytes)
        46.91% of uncompressed inode table size (162 bytes)
Directory table size 62 bytes (0.06 Kbytes)
        63.92% of uncompressed directory table size (97 bytes)
Number of duplicate files found 0
Number of inodes 5
Number of files 1
Number of fragments 1
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 4
Number of ids (unique uids + gids) 2
Number of uids 1
        tc (1001)
Number of gids 1
        staff (50)
tc@box:~$ cp 1.tcz 0.tcz
tc@box:~$ tce-load -i 0.tcz
0.tcz: OK
tc@box:~$ zero
one
tc@box:~$ rm /usr/local/bin/zero
rm: remove '/usr/local/bin/zero'? y
tc@box:~$ umount /tmp/tcloop/0/
tc@box:~$ rm /usr/local/tce.installed/0
rm: remove '/usr/local/tce.installed/0'? y
tc@box:~$ cp 2.tcz 0.tcz
cp: overwrite '0.tcz'? y
tc@box:~$ tce-load -i 0.tcz
0.tcz: OK
tc@box:~$ zero
one

The last output should be "two" instead of "one". I don't know if this can be accepted as a bug, since it implies an umounting of the 0.tcz extension, which is probably unsupported.
For sure, there's something strange going on with the squashfs mounting, or am I missing something?

[tinypoodle]

umount-ing a loop device does not automagically delete it   

[caminati]

umount-ing a loop device does not automagically delete it  

Now I got it, thanks. This is not certainly a TC bug (should I delete this thread?).

Still, I feel that if mount creates automagically a lodevice, then umount should delete it.
Not doing that causes confusion to me because lodevice points to inode rather than to file path/name.


Whoops! found that

Code: [Select]

Unmount file systems

Options:
        -a      Unmount all file systems
        -r      Try to remount devices as read-only if mount is busy
        -l      Lazy umount (detach filesystem)
        -f      Force umount (i.e., unreachable NFS server)
        -d      Free loop device if it has been used


So the bottom line is: use umount -d when unloading extension. I recall that non-busybox umount did this automatically, probably my confusion originated from that. My mistake, sorry for the utterly useless thread.

[tinypoodle]

See first thread here:
http://lists.busybox.net/pipermail/busybox/2010-November/thread.html#start

And no I wouldn't delete anything from this thread, as it may be useful to others for future reference.
Besides, you already made use of the "striked font" feature.  

Not a TC bug, neither particular to squashfs, but very clearly a busybox issue.
Just that it could rise to extraordinary significance in TC, as loop mounting is a common routine.