Thinking about a universal UUID mount

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
Posts: 31
Joined: 05 Jan 2011, 18:53
Location: Alaska

Thinking about a universal UUID mount

Post#1 by sams » 24 May 2012, 03:45

I'm looking at the implementation of magic folders with LUKS container introduced in rc2. What I want is to mount a container on (UUID identified media) in folders.cfg

But the device is mounted in different locations on different computers, it could be /mnt/sdb1, /mnt/sdc1. If I run porteus as copy2ram, the boot media isn't automouted, but KDE will want to mount it in a predictable place, /media/<UUID> (obviously this doesn't help here since the container won't be mounted)

I have toyed with a script expansion in folders.cfg, but that is a severely damaged approach. I feel I want the mount equivalent of /dev/disk/by-uuid (I'm thinking of something on the /proc filesystem). Maybe I'm missing something that's already here?


Posted after 51 minute 23 seconds:
Partially answering my own question, you can put a wildcard in folders.cfg and bash will expand it out. In my case bash expands it to the single mounted match (yuck?), and everything works. ie:

/mnt/*/porteus/container.dat /tmp/alreadyExistingMountPoint

Would be better if there were a reliable way to specify, but this is going to allow some cool stuff for now. Keep the better ideas coming please!


User avatar
Moderator Team
Moderator Team
Posts: 5667
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland

Re: Thinking about a universal UUID mount

Post#2 by fanthom » 24 May 2012, 07:50

hi sams,
If I run porteus as copy2ram, the boot media isn't automouted
please use 'noeject' cheatcode together with copy2ram so nothing will be unmounted during boot.

please update copy2ram cheat description with note about 'noeject' as users may be not aware of this.
What I want is to mount a container on (UUID identified media) in folders.cfg
good idea and this could be default for magic folders. i have implemented UUID->sdXY translation function in rc.S:

Code: Select all

# Source:
src=`sed -n "$x"p /etc/magic_folders/folders.cfg | cut -d " " -f1`
# UUID to sdXY translation:
uuid=`echo $src | cut -d/ -f3`
dev=`blkid -U $uuid | cut -d/ -f3`
src=`echo $src | sed s/$uuid/$dev/g`
# Destination:
dest=`sed -n "$x"p /etc/magic_folders/folders.cfg | cut -d " " -f2`
which translate for example:

Code: Select all

/mnt/120a9458-07c9-4e50-a9ec-894ad115e101/magic /home/guest

Code: Select all

/mnt/sda4/magic /home/guest
and all works ok on my end :)

please include similar function in 'magic folders' tool which does backwards translation: sdXY->UUID.
in short words: we want to have /mnt/UUID in /etc/magic_folders/folders.cfg instead of /mnt/sdXY

Please add [Solved] to your thread title if the solution was found.

User avatar
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: Thinking about a universal UUID mount

Post#3 by brokenman » 24 May 2012, 13:20

Done. Uploaded new gtkmagic-folder to the box.

Reminder for rc.S to accommodate multiple lines in /etc/magic_folders/folders.cfg
How do i become super user?
Wear your underpants on the outside and put on a cape.

Posts: 31
Joined: 05 Jan 2011, 18:53
Location: Alaska

Re: Thinking about a universal UUID mount

Post#4 by sams » 24 May 2012, 21:42

Fanthom, your idea looks good, right on.

(I'm deleting a mistaken bug report here regarding apparent size of a LUKS container...)

Posted after 2 hours 40 minutes 39 seconds:
Here's a shell dump of how I moved a user's directory from /home to an encrypted LUKS container:

Code: Select all

# NOTE: my /tmp is a big place off the union fs, make sure you pick a suitable working directory
$ mkdir -p /tmp/xxx

$ time ( nice dd if=/dev/urandom of=/tmp/xxx/container.dat bs=1M count=644 ; sync )
675282944 bytes (675 MB) copied, 74.0459 s, 9.1 MB/s
real    1m14.081s

$ ls -la /usr/local/bin/makeloop
-rwxr-xr-x 1 root root 201 May 23 09:08 /usr/local/bin/makeloop

$ makeloop 
$ makeloop 

$ mknod /dev/loop20 b 7 20

$ losetup /dev/loop20 /tmp/xxx/container.dat 

$ losetup -a | grep container
/dev/loop20: [0011]:18686 (/tmp/xxx/container.dat)

$ cryptsetup --verbose --verify-passphrase luksFormat /dev/loop20
Enter LUKS passphrase: 
Verify passphrase: 
Command successful.

$ cryptsetup luksOpen /dev/loop20 crybaby
Enter passphrase for /dev/loop20: 

$ mkfs.ext2 -m 1 -O dir_index,filetype,sparse_super /dev/mapper/crybaby

$ mkdir /tmp/containerMountPoint

$ chown mySecureName:myGroup /tmp/containerMountPoint

$ chmod 750 /tmp/containerMountPoint 

$ mount -o noatime /dev/mapper/crybaby /tmp/containerMountPoint

$ mount
/dev/sdc1 on /media/1uuid2uuid3 type ext2 (rw,nosuid,nodev,uhelper=udisks)
/dev/mapper/crybaby on /tmp/containerMountPoint type ext2 (rw,noatime)

$ ls

$ cd ~mySecureName

$ cd ..

$ tar cf - mySecureName | ( cd /tmp/containerMountPoint ; tar xf - ) ; sync

$ cd /tmp/containerMountPoint

$ la
total 24
drwxr-xr-x  4 root           root     4096 May 23 11:26 .
drwxrwxrwt 11 root           root      240 May 23 11:18 ..
drwx------  2 root           root    16384 May 23 10:13 lost+found
drwxr-x--- 13 mySecureName   myGroup  4096 Apr  2 19:27 mySecureName

$ cd 

$ umount /tmp/containerMountPoint

$ cryptsetup luksClose crybaby

$ losetup -d /dev/loop20

$ rm /dev/loop20

$ cp /tmp/xxx/container.dat /media/1uuid2uuid3/porteus/ ; sync
I hope this helps someone. Note that I don't recommend recommend mounting on or big data dumps to /tmp, but my mounts are different than the default.

Post Reply