fanthom wrote:i think you are refering to a padlock_sha.ko (...) syslog is not started yet
Yes, that's it. Thanks for info.
sams wrote:the filesystem reports the free space of the container's filesystem rather than the free space of the container.
Here I misspoke, what I am seeing is the free space of the file system of the mount point (!). In the following, my container is a 630MB luks container residing on flash drive (sdc1), with luks mount point on the tmpfs (which can grow to half of RAM, 8GB).
If I put this in my folders.cfg: (and precreate the mountpoint)
Code: Select all
/mnt/*/porteus/container.dat /tmp/containerMountPoint
Here's the resulting filesystem result:
Code: Select all
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 7.4G 1.7G 5.4G 24% /mnt/sdc1
/dev/mapper/magic13 7.8G 144M 7.7G 2% /tmp/containerMountPoint
tmpfs 7.8G 144M 7.7G 2% /tmp
Ack! The device mapper is decryting my 630 MB container, but the free space is that of the tmpfs that is the container's mount point.
The problem could be an interaction with my code in rc.local to move /tmp to a tmpfs:
Code: Select all
### make /tmp really temporary on a tmpfs
### make the mount point
mkdir /mnt/tmp
### put a ram filesystem on the mount
mount -t tmpfs -o noatime tmpfs /mnt/tmp
### copy the old tmp contents so we retain present state
( cd /tmp ; tar cf - . ) | ( cd /mnt/tmp ; tar xf -)
( cd /var/tmp ; tar cf - . ) | ( cd /mnt/tmp ; tar xf -)
mount --move /mnt/tmp /tmp
rmdir /mnt/tmp
### bind overmount to replace original /var/tmp
mount --bind /tmp /var/tmp
This hack is conceptually a bit ugly, there could be open file descriptors in the old /tmp dir, but this doesn't cause any problems. Is /tmp on a tmpfs in RAM on a live system the best choice? I'm not prepared to make the argument that it should be the system default (I think porteus & slax have excellent default settings) but in my setups its all advantages. It's fast, it doesn't wear the flash drive, and it's really temporary.
So I think the only code that's particular to my setup is where I move /tmp to a tmfs. Other than the mount point, my configuration looks like standard usage of the magic folders code.
If I don't use the magic folders code, but instead mount the container with the 'mountcrybaby' script above (either invoked from rc.local or later by a user) the container decrypts to show the same directory structure, but this time the filesystem free space is correct:
Code: Select all
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 7.4G 1.7G 5.4G 24% /mnt/sdc1
tmpfs 7.8G 102M 7.7G 2% /tmp
/dev/mapper/magic20 631M 44M 581M 7% /tmp/containerMountPoint
So in either case the mount point shows my decrypted container contents, but if the mounting is handled by magic folders I show the wrong free space and I can't unmount cleanly. If I use my own scripts included above and invoked from the rc.locals or a shell, everything works perfectly and stays clean. The other thing that I'm curious about is the device number. For me, magic folders mounts the container at loop13, if I run my 'mountcrybaby' script from rc.local the device is loop20. Since you can see from my 'umountcrybaby' script loop devices are bouncy and hard to delete I wonder if these are getting leaked? Sorry I don't know how to check kernel associations with loop devices.
btw: containers are closed in rc.6 and not rc.K.
Thanks, my bad. I blame Slurpee and brain freeze.
also - no need to delete loop device - just detach it ('umount -d /folder' command)
I will investigate & learn!
I'm suspecting that my problem might be an interaction between my tmpfs desires and abuses and the porteus shutdown order. It's possible that relying on cleanup in rc.6 in this scenario precludes clean shutdown, and then the device mapper is scrogged on remount? It wasn't clear from my reading of the shutdown code that this ought to be problematic, but it has been a no go for me. But I'm going to stick with the tmpfs, you don't want to put an encrypted home directory in a location where it might exist and get archived in the clear if the user errored out of the luksOpen.
I will try your new scripts shortly. Thanks for all.
cheers!