Systemd automount luks partition in background

A bit of a technical story for systemd experts.
Systemd causes a few seconds delay on boot when it automounts all fstab entries and one of those entries is an encrypted volume. The problem is when I mount a data partition which is really not important, i.e. it can wait until the system is completely booted. I can fix this by using noauto in crypttab and fstab or I can use a rc.local script to mount the partition manually. But how can I tell systemd this partition is not important and mounting this partition should never delay booting? Is it even possible with systemd?
/etc/crypttab:
data /dev/... /root/data.key
/etc/fstab
/dev/mapper/data /mnt/data ext4 rw,relatime 0 0

Thanks aesiris, I've tried this but it's the same. When I don't mount the encrypted data partition on boot the system goes from text mode to X within 2 seconds. If I do mount the data partition the console goes from text mode to framebuffer (not sure how to call it but when you got a higher resolution text console) and then to X. Guess what I want is not possible with systemd.

Similar Messages

X-systemd.automount and sshfs

I've been using sshfs to access files on my pi for serveral months now. Today i tried to enable automatic mounting with x-systemd.automount, but although a manual mount is still possible, the automatic mount fails constantly with a "no such device" error since i added the additional option in /etc/fstab. Journalctl -f on the pi reveals that the "Connection is closed [preauth]", so I would guess that something is wrong with my client authenticating. But I don't understand how is this possible because I can in fact mount the partition manually. Even if I use the exact command used by systemd (found via ps -fe) with root it prompts me for the password of my key and then it mounts correctly. Shouldn't automount then prompt for my password, when my X starts? Any ideas?
line in /etc/fstab:
herrzinter-pi.local:/media/mediacrypt /home/herrzinter/Multimedia fuse.sshfs users,noauto,_netdev,reconnect,x-systemd.automount 0 0
Last edited by MrTea (2013-07-01 15:34:13)

WonderWoofy is right, until now I always used the automatically generated nautilus entry to mount the remote folder. In this case mount command is executed as <user> and so I don't need to put the additional information in the /etc/fstab. btw i didn't exactly look this up, but I've used this setup for quiet some time now, and I guess, that I forgot the herrzinter@ part once and noted that it worked anyway
I now added this and the "IdentityFile=/..." option pointing to a dummy ssh key without passphrase and it then it's working, but I am not to happy with this, as an empty passphare key is not really nice, and also nautilus is showing me duplicated entries... but in genreal I have to look at the setup again I am not sure anymore if the x-systemd.automount option is really such a good idea in my case, as the network setup of my laptop is changing quite often... perhaps a bash script at login, or a custom systemd unit is better suited for my purpose
Thank you all anyway

[Solved] Problem booting root in LVM, which spans two LUKS partitions

Hello,
I recently switched to Arch from OpenSuse, and I'm having a bit of trouble getting my encrypted disks to boot properly. I have two disks, the first is a 4 TB drive set up like this:
MBR partition table
Partition 1 - Windows 7, 200GB
Partition 2 - Linux boot, 200MB
Partition 3 - Luks partition, 1.7TB
Partition 4 - Luks partition, 1.7TB
Within partition 3 and 4 is an LVM volume which spans the two partitions. The reason for that is just that I can't have a 3.4TB partition on an MBR formatted drive (as I understand it). I have the root volume and swap, etc within this LVM. The second hard drive is simply a data drive, also encrypted. My problem is that I don't know how to tell the system to open both of these encrypted partitions at boot, in order to boot the root volume. This worked fine under OpenSuse and I only needed to enter the Luks password once (it is the same for both partitions).
As it is right now, my boot parameters in /etc/default/grub look like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset cryptdevice=/dev/sda3:sda3_crypt root=/dev/mapper/vg_arch-root"
Currently the system boots, asks for the password to /dev/sda3, hangs for roughly 20 seconds and then kicks me into a root prompt. I can manually open /dev/sda4 at this point using cryptsetup and the system will continue booting normally... but I would like to have it set up properly, so I don't need to do that. Considering OpenSuse does this out of the box I figured it should be possible under Arch. Any help would be appreciated.
Thanks
Last edited by keitolainen (2015-06-09 21:56:08)

As a quick update in case anyone is reading this, I cleaned up the script a bit and hopefully made it something closer to a "proper" fix.
Rather than editing /usr/lib/initcpio/hooks/encrypt directly, I did the following:
cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/
then changed the following section of /etc/initcpio/hooks/encrypt from:
# Ask for a passphrase
if [ ${dopassphrase} -gt 0 ]; then
echo ""
echo "A password is required to access the ${cryptname} volume:"
#loop until we get a real password
while ! eval cryptsetup open --type luks ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}; do
sleep 2;
done
fi
to:
# Ask for a passphrase
if [ ${dopassphrase} -gt 0 ]; then
echo ""
while true ; do
echo -n "A password is required to access the ${cryptname} volume: "
read -sr password
echo $password | cryptsetup open --type luks ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}
if [ $? = 0 ] ; then
break
fi
done
echo $password | cryptsetup open --type luks /dev/sda4 sda4_crypt
echo ""
fi
then edited /etc/mkinitcpio.conf and changed:
FILES=""
to:
FILES="/etc/initcpio/hooks/encrypt"
and ran
mkinitcpio
This is working well for me and I think it's a little cleaner than the solution I posted earlier. Sorry for the awkward bash, if anyone has a more elegant solution please let me know.

[Solved] How to resize an encrypted luks partition?

Edit: This worked: http://www.enigmacurry.com/2007/04/28/r … ilesystem/
I have some empty space on my harddrive, and wish to fill it up, with my existing partition.
This is my harddrive setup in gparted:
And fdisk respectively:
[ricky@archlinux ~]$ sudo fdisk /dev/sda -l
Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x58bd1192
Device Boot Start End Blocks Id System
/dev/sda1 * 63 289169 144553+ 83 Linux
/dev/sda2 289170 195607439 97659135 83 Linux
/dev/sda2 (the crypted luks partition) contains an lvm group.
I am trying to enlarge the luks partition, to fill all of the empty space, soi can give some more space to the lvm's inside the encrypted partition.
I did come across an interesting page here: http://www.enigmacurry.com/2007/04/28/r … ilesystem/
Is this the correct approach, by deleting the WHOLE partition (not the data), and then simply creating a new partition, with the same start-sector, and the higher end-sector?
Will that allow me to then resize my lvm's inside of the luks partition?
I am sorry if this is confusing.
Last edited by xdemo (2011-03-18 07:53:35)

jakobm wrote:Please be sure to use the bbs search: Defragment a NTFS partition from LINUX
That thread has absolutely no information other than a list of motivations to use Windows to defrag it... and a link to a buggy Python defragger.
Here's the only bulletproof way to defrag NTFS under Linux:
Make a new partition of the same size (or bigger), and format it to NTFS and mount it at /defragged
Mount your fragged partition at /fragged
rsync -av /fragged /defragged
Wha-la. /defragged is now your fragged partition, defragged. Reformat /fragged and rsync it back if you really must.
Drives get fragmented if you do multiple copies at the same time, so don't do anything else on the drive while it's syninc.
Last edited by dagelf (2014-08-28 07:21:54)

Resizing luks partition "in front"

Hello
I have currently the following partitioning scheme:
.-(~)----------------------------------------------------------------------------------------------------(root@tirion)-
`--# fdisk -l /dev/sda
Disk /dev/sda: 107.1 GiB, 115033153536 bytes, 224674128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4488c4dc
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 192779 192717 94.1M 83 Linux
/dev/sda2 192780 224674127 224481348 107G 83 Linux
sda1 is a normal ext4 partition, sda2 LUKS with ext4
I found out, how I can grow a LUKS partition on the "end", but how can I get rid of sda1 and resize the luks partition to take all of the space?

Growing, or resizing in general, only happens on the end. So the way to do that would be to delete sda1 & sda2 (in the partition table that is) and create a new partition sda1 over the entire disk. Then you'd need to move the data from the old sda2 to be located where they outta be, so say for example your new partition would be like e.g.
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 224674127 224672080 107G 83 Linux
That would mean sda2 used to start at 192780*512=98703360 and the new one would now start at 2048*512=1048576 -- So I guess you could move data e.g. with dd:
dd bs=4M if=/dev/sda skip=98703360 iflag=skip_bytes of=/dev/sda seek=1048576 oflag=seek_bytes
It should put the data of the old sda2 right in the new sda1 location, so you can use it as expected. Then you can then grow your filesystem as usual (on the end) to take all the space/partition.
Assuming sda2 has a LUKS header, a simply way to make sure your at the right place would be:
dd if=/dev/sda bs=4 count=1 skip=98703360 iflag=skip_bytes
If it's right, it should read/show "LUKS"
Of course you should have a backup of your data before doing any of that. (Also some tools like maybe gparted or something might be able to do the whole thing "automatically" for you, I don't know.)

X-systemd.automount nfs drive

Hi,
I can't seem to get systemd.automount to behave. I have an nfs share available on machine 'kombi' and am trying to access it from machine 'forrest':
[root@forrest ~]# showmount -e kombi
Export list for kombi:
/mnt/nfs4/georgia 192.168.1.202
/mnt/nfs4 192.168.1.202
It is set up to automount in /etc/fstab:
kombi:/georgia /mnt/georgia nfs4 rw,suid,dev,exec,noauto,nouser,async,clientaddr=192.168.1.202,_netdev,x-systemd.automount,x-systemd.device-timeout=8 0 0
Logging output from journalctl indicates it timed out but then mounted:
Dec 14 17:45:11 forrest systemd[1]: mnt-georgia.mount mounting timed out. Stopping.
Dec 14 17:45:11 forrest systemd[1]: Mounted /mnt/georgia.
Dec 14 17:45:11 forrest systemd[1]: Mounted /mnt/georgia.
However it is not mounted. Any process trying to access /mnt/georgia hangs.
Any ideas where I have gone wrong? I don't care if it automounts at boot or at first access. What I'd like is for it to gracefully handle mounting when 'kombi' is up, and unmounting when 'kombi' is down.

Thanks, I guess I have misread other advice on the forums. Even systemd.mount man page states:
If x-systemd.device-timeout= is specified it may be used to configure how long systemd should wait for a device to show up before giving up on an entry from /etc/fstab.
From this statement I would expect the remote filesystem to not be mounted if the other machine is down, but not to cause a local process to hang trying to access the unmounted directory.
It looks like autofs may be the way to go - from the NFS wiki:
Using autofs is useful when multiple machines want to connect via NFS; they could both be clients as well as servers. The reason this method is preferable over the earlier one is that if the server is switched off, the client will not throw errors about being unable to find NFS shares.

Can systemd automounter unmount inactive fileystems?

Hi,
tl;dr: Can systemd automounter unmount fileystems after a period of inactivity, like autofs does?
I've just started discovering the wonderful new world of systemd, and to my great joy I found that it contains an automounter, so I thought that I would be able to use that instead of using autofs.
The single thing that I like to automount is my home NAS on my laptop (via NFSv4) that I every day take from home to work and then back home.
To do this with autofs is kind of like killing mosquitoes with a flamethrower. I would much rather just have my automounted NAS defined in my fstab than having to force the slightly mysterious autofs.xxx-files to mount the drive with the options I want it to use.
So, I got systemd to automount my NAS and all was joy! Until I realized that it wasnt unmounting it after a time of non-use. I have googled quite a bit, searched the forums, but have found no mention that systemd either has or doesnt have this kind of functionality.
So my purpose with this post is to get a definitive answer, does systemd do this? And if it doesn't, maybe others searching for the same information will end up here, and find the answer...
/DonO

I've been having this problem for as long as I can remember. I have finally decided to sit down and work something out instead of my laptop hanging all the time when it can't find the nfs server. The systemd.automount feature is nice, but it really sucks that it does not auto unmount when the share is not found.
Also, having systemd.automount means that every time I open vim, or a manpage, and there is no network connection, systemd tries to mount the shares. I'm not sure why because I am not directly accessing them. Everything loads slowly when systemd automount is active for my shares and there is no network connection.
Using soft instead of hard is a workaround, but then when the network connection is lost, corruption can occur.
It seems like the only way to really solve this problem is to have some kind of script run when the network comes up to mount the shares, and to unmount when it goes down. This would require custom systemd units or something. Diving into the systemd manuals is something I have been putting off because they are so hefty.
For anyone that is interested, here is my fstab:
lithium:/mnt/data /mnt/data nfs noauto,noatime,rsize=32768,wsize=32768,soft,retry=0,timeo=3,x-systemd.automount,x-systemd.device-timeout=1ms 0 0
lithium:/var/cache/pacman /var/cache/pacman nfs noauto,noatime,rsize=32768,wsize=32768,soft,retry=0,timeo=3,x-systemd.automount,x-systemd.device-timeout=1ms 0 0
Last edited by demizer (2013-07-14 09:00:23)

Setting up a LUKS partition to use a USB key

Im playing with an old netbook I've been given, essentially practicing for when I get a new desktop. Anyway, I want to install Arch on a LUKS encrypted partition and have it unlocked at boot time using a key located on a USB key.
This is what I did first time round and whilst the root partition is indeed encrypted I'm having to type a passphrase every boot:
loadkeys uk
lsblk
gdisk /dev/sda
outout should eventually look like:
Command (? for help): p
Disk /dev/sda:
Logical sector size: 512 bytes
Disk identifier (GUID):
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 8191 3.0 MiB EF02 BIOS boot partition
2 8192 1032191 500.0 MiB 8300 boot
3 1032192 8300 root
cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sda3
enter a passphrase twice here
cryptsetup open /dev/sda3 ARCHROOT
mkfs.ext4 /dev/sda2
mkfs.btrfs /dev/mapper/ARCHROOT
mount /dev/mapper/ARCHROOT /mnt
cd /mnt
Would I need to
cryptsetup luksAddKey /path/to/keyfile
after the first cyptsetup step? If so can the live Arch environment mount USB drives at this point in the installation process?

frostschutz wrote:Do you have a backup of those headers, then? Kinda sucks to lose all your data to a faulty USB key.
hehe, yes several USB keys and other secure storage.
frostschultz wrote:Security wise it shouldn't matter, if someone can modify my Initramfs, they can also modify my Grub.
The other thing I forgot to mention is that my USB stick is also my boot device. There's no Grub or any other bootloader on the target systems to mess with. If started without the key, they just say "operating system not found". Even if someone got hold of the USB stick, as a last line of defence, all the keys and headers that Grub needs (as well as the Grub boot config) is stored on an encrypted partition on the USB stick that requires a passphrase to unlock.
frostschultz wrote:
I can pull my USB stick as soon as Grub is done loading the kernel and initramfs, i.e. the moment kernel messages start to appear. They keys and all are part of the Initramfs, so the USB stick is no longer necessary.
Basically, it's this method: https://wiki.gentoo.org/wiki/Custom_Ini … ed_Keyfile and the first example here: https://wiki.gentoo.org/wiki/Custom_Initramfs/Examples
That gentoo example doesn't use systemd. I wanted to use the native systemd functionality as much as possible. My my initramfs opens what's necessary for boot (essentially the root filesystem) and the main early-boot does everything else. I wanted to use the standard /etc/fstab and /etc/crypttab and allow systemd to sort everything out but I encountered the dependency problem. I have a very simple workaround for it, however.
I'll just add to that as well that the systemd issue is only on systems where the initramfs is insecure and, therefore, cannot contain keys. Those systems with the initramfs on an encrypted filesystem don't need the usb key to unlock the rest of the encrypted filesystems because the keys are in the encrypted initramfs. They only need the USB key to unlock the root. I cannot secure the initramfs on some systems because of the way they boot (specifically, non-x86 boxes that cannot use Grub or are unable to boot off arbitrary devices).
Last edited by starfry (2015-02-07 14:09:29)

[SOLVED] Initramfs fails to properly mount luks partition

Hello All,
As I foreshadowed in my intro, I'm having trouble getting encrypted Archlinux to work on my Acer Aspire 5750. I've previously had encrypted Debian Netinst and encrypted Aptosid working on this device. The arch iso I'm using is 2011.08.19-core-i686.
https://bbs.archlinux.org/viewtopic.php?id=124415 appears similar and Tallahassee offers a workaround, but it doesn't work for me (unless I'm doing something wrong?)
I suspect there is a bug in the init scripts used by the initramfs. I would like to first of all determine whether I really should file a bug report (and if so where), and secondly whether we can find a workaround to get things up and running in the meantime.
Now for the meaty bits.
Old grub doesn't appear to support lvm or luks, so I first of all prepare for grub 2 by installing the gptfdisk package into the iso environment. I use gdisk to set up a 1 or 2 mb bios boot partition at the start of /dev/sda, followed by a 256mb partition (/dev/sda2) for /boot, with the rest of the drive given to the partition intended for the encrypted root partition (/dev/sda3).
I use cfdisk to toggle the partition type for /dev/sda3 to 8e (Linux LVM).
Run the following commands, with credits to Aptosid: Installing to a Cryptroot:
pvcreate /dev/sda3
vgcreate vg /dev/sda3
lvcreate -n crypt --extents 100%FREE vg
cryptsetup --verify-passphrase -c aes-xts-plain:sha512 luksFormat /dev/mapper/vg-crypt
cryptsetup luksOpen /dev/mapper/vg-crypt cryptroot
pvcreate /dev/mapper/cryptroot
vgcreate cryptvg /dev/mapper/cryptroot
lvcreate -n swap --size 2g cryptvg
lvcreate -n root --extents 25%FREE cryptvg
lvcreate -n home --extents 100%FREE cryptvg
/arch/setup
Go through the arch setup as normal. At the bit where you configure hard-drives, you'll find all your encrypted partitions ready waiting to be labelled and formatted. Stop after installing packages.
After installing packages, press CTL-ALT-F2 and log in. Edit /mnt/etc/rc.conf and /mnt/etc/mkinitcpio.conf. CTL-ALT-F1 and reinstall packages. Proceed with the configure step.
Don't install a boot loader; just quit after configuring everything.
Follow the steps here: Grub 2 During Archlinux Installation.
The automatically generated grub.cfg doesn't include things necessary to lvm and luks. Before running grub_bios-install, I edit the grub.cfg to insmod lvm and flag the kernel with cryptdevice=/dev/mapper/vg-crypt:cryptvg-root and rootfstype=ext4 (because that is the encrypted root's filesystem).
At this point, I would expect the system to be bootable, so reboot.
Grub2 loads up. I can verify the changes I made to grub.cfg by pressing `e'. So boot and see the messages,
Loading Linux linux ...
Loading initial ramdisk ...
A password is required to access the cryptvg-root volume:
Enter passphrase for /dev/mapper/vg-crypt:
So far so good. I enter my passphrase. The following messages ensue:
vgscan: unrecognized option '--sysinit'
Error during parsing of command line.
device-mapper: create ioctl failed: Device or resource busy
mount: mounting /dev/mapper/cryptvg-root on /new_root failed: Device or resource busy
ERROR: Failed to mount he real root device.
Bailing out, you are on your own. Good luck.
So I get dumped into the ramfs. That ain't much fun.
Does anyone have some ideas on things to try next? Should I file a bug report?
Last edited by /dev/zero (2011-10-22 00:28:52)

Not sure what you mean by difficult and buggy to work with... at this low level, if a VM is having issues replicating this sort if thing, it's not a very useful VM. Find one that doesn't suck. I tend to use KVM because it's terminal friendly via emulation of a serial console.
Anyways, I can reproduce your issue and fix it. There's 2 things you'll need to change:
1) You're naming your unlocked cryptdevice the same thing as your root. That's creating a clash with the name you've given your root logical volume. Since the name isn't really important, just change your cryptdevice declare to "cryptdevice=/dev/mapper/vg-crypt:root"
2) Since you're doing the xzibit thing and nesting lvm inside of the crypt device (i still think its really bizzare to do this, but it looks like mkinitcpio supports it anyways), you'll need to add the lvm2 hook a second time to HOOKS in /etc/mkinitcpio.conf after the encrypt hook.
Last edited by falconindy (2011-10-22 00:19:10)

[SOLVED] mkinicpio's systemd hook, LUKS, LVM and resume

I had a working LUKS/LVM/resume using the following HOOKS and kernel parameters:
# /etc/mkinitcpio.conf
HOOKS="base udev autodetect modconf block keymap encrypt lvm2 btrfs resume filesystems keyboard"
# /boot/loader/entries/arch.conf
options cryptodevice=PARTUUID=28230c39-5262-4778-b12a-b5eda11831d0:lvm resume=/dev/mapper/vol0-lv_swap root=/dev/mapper/vol0-lv_root rw
Since systemd 217 is supposed to support hiberation, I am trying to setup a pure systemd initrd image. So I changed my mkinitcpio.conf and arch.conf files to the following:
# /etc/mkinitcpio.conf
HOOKS="systemd autodetect modconf block keymap sd-encrypt sd-lvm2 btrfs filesystems keyboard"
# /boot/loader/entries/arch.conf
options rd.luks.uuid=176a3eb9-90c3-49c7-a0b5-697860d21068 resume=UUID=b89c478e-a1ff-4332-a11b-ceebc3b08de8 root=UUID=e180cd3e-d4c4-4e0a-9426-0f7e460a7303 rw
The change in boot entry is done as suggested in this topic, since using cryptodevice doesn't seem to work. I only changed the resume/root to UUID since this seems to be the right way to do things (UUID is not supposed to change, while labels may change).
And the system boots, but resume doesn't work (tried to run "systemctl hibernate" from terminal, the system hibernates but never resumes). I removed the resume hook since it doesn't seem to be necessary with systemd hook. Even if I put it again it doesn't work (it tries to run the resume hook, I can see the logs during the boot, but nothing changes). I think this is a problem in the root entry or resume entry in my boot parameters (maybe both), probably I need to change for some other think but I didn't find anything searching in Google.
Maybe someone with a Fedora setup may help? The suggestion to use rd.luks.uuid instead of cryptsetup seems to come from there.
Last edited by m45t3r (2014-11-29 22:30:13)

I know this may seem like I am reviving an old topic, but recently I bought a SSD and tried to replicate my setup, including supporting for TRIM. While it's easy to do it's not something trivial since it's not really well docummented.
You will need three things:
A filesystem that supports discard (I am using XFS).
In /etc/lvm/lvm.conf, enable issue_discards option.
Lastly, add rd.luks.options=discard in your kernel boot options
To test if everything is working as it should, just do:
# fstrim /
And if everything is working it should return 0, or a error message in case of error.
Hope this help someone.

Systemd and LUKS password decryption on boot

Hello!
Today I changed over to systemd with my Arch Linux desktop PC. All went fine, but there is one problem where I can't find a solution for. I have two LUKS-encrypted devices in my system, where the password should be asked for on boot. This works, also with systemd, but on my screen, the prompting text first appears, then systemd outputs some other status messages and then seems to wait for the password. This often yields in problems entering the password because I'm not sure where to enter it now. This is how my screen looks like. I marked the positions with the prompt and the associated passwords. As you see, typing the second password yields in an error, but I'm sure I did enter the correct one.
http://0wx.de/993415ef89c04d4287bf52cfd949fb10.jpg
Any idea how to fix this ugly look for the password boot prompt?
Thanks
- beachcoder
-- mod edit: read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_Code [jwr] --

I hate to bump this for a non-solution-providing post, but I've been starting a truecrypt mounting service manually for a long time as I've not figured out how to do it at boot. Would you be kind enough to post your .service file?
Mine is currently:
ExecStart=/bin/sh -c '/usr/bin/truecrypt -t --protect-hidden=no -k "" --filesystem=none --slot=1 -p `systemd-ask-password "Enter password for truecrypt volume: "` /dev/sda4'
This doesn't seem to work at boot and the systemd-ask-password bit gets ignored during the boot process. I'd love to get this solved to save typing it manually time I boot.
Thanks!

Systemd automount of /home results in locate ignoring /home

Hi,
Per the suggestion on the systemd wiki page, I have instructed systemd (via /etc/fstab) to automount /home. This is supposed to allow me to boot faster on those occasions when my /home needs to be fsck'ed. (Please correct me if I've misunderstood this point.) This results in "mount" reporting that my /home filesystem type is "autofs".
This again results in locate ignoring my entire /home when indexing my harddisk, since the default /etc/updatedb.conf has PRUNEFS="(...) autofs (...)", i.e. it ignores all autofs filesystems. Now, I don't want to remove autofs from this list, since other filesystems that should be ignored (e.g. /proc/sys/fs/binfmt_misc) are of autofs type. I also would prefer to keep the automount trick from the wiki.
Any suggestions as to how this can be accomplished? I have RTFM for updatedb.conf, and it does not have a "whitelist" of any sort. That would be the optimal solution, IMO, but requires an update from the mlocate maintainer upstream. Can I tell systemd to fake the filesystem type of home, or to pass on the actual filesystem type (ext4)?

Here is another discussion of this issue: https://bbs.archlinux.org/viewtopic.php?id=154539
Apparently the time savings provided by automounting /home may not be not significant enough to make it worthwhile. You can test this yourself, or continue with the other workarounds you are already aware of.

Mounting an LVM on Luks Partition [SOLVED]

Hello Arch Linux Community:
This likely sounds like a very stupid question, but I have honestly hit a wall and need some advice. To make a long story short I was messing around in some configuration files and forgot to undo a change that I made before rebooting, which has rendered my system mostly inoperable. (I mistakenly changed the address for Bash in /etc/shells, so I can't log in as either my user or root). Now ordinarily this would be a very simple fix, but for whatever reason it is proving to be far more difficult that I anticipated. My root partition is stored as Logical Volume on a Physical Volume on /dev/sda3 and the entire Volume Group (containing my root, home, swap and var partitions) is locked up with Luks.
I booted my computer to an Arch live CD and attempted to mount the root filesystem, though wasn't exactly sure how to go about doing it (I tried several methods). First I tried just opening the root logical volume and mounting that.
# cryptsetup luksOpen /dev/sda3 rootvol
# mount /dev/mapper/rootvol /mnt
This resulted in the system alerting me that the device I was trying to mount was an LVM2 member and that the system could not do it. So next I tried opening the entire Volume Group.
# cryptsetup luksOpen /dev/sda3 VolGroup00
# mount /dev/mapper/VolGroup00 /mnt
Which, as I expected did not work. However, when I tried to mount the root volume again (having opened the entire Volume Group)
# mount /dev/mapper/VolGroup00-rootvol /mnt
and
# mount /dev/VolGroup00/rootvol /mnt
the system alerted me that the device I was trying to mount did not exist, which is odd considering that running
# lvdisplay /dev/VolGroup00
showed all of my logical volumes to exist at the locations /dev/VolGroup00/foo.
I could really use some guidance here. I know that I'm probably missing something very stupid and obvious, but I cannot for the life of me see it. Thank you for your time.
Douglas Bahr Rumbaugh, Jr.
Last edited by douglasr (2013-06-23 23:14:56)

After the luksOpen I believe you need
vgchange -a y

Luks encrypted key file as key for luks partition (two-factor auth)

I'm trying to implement "two-factor" authentication (possession of a keyfile and knowledge of a passphrase required) using dm-crypt in order to open an encrypted root filesystem. In the past I used gpg and later openssl to decrypt a keyfile using a passphrase, which then was used by cryptsetup using --key-file to decrypt the actual data device. I'd like to ditch gpg/openssl and use only cryptsetup.
So the idea is to create a luksFormatted key file (loop device) which, when opened using a passphrase, will be used as the key (using --key-file) to open a luksFormatted hard drive partition.
To illustrate:
# create and luksFormat the key container file
dd if=/dev/urandom of=key_container bs=1M count=4
cryptsetup luksFormat key_container
# open the container and create a random "key" by directly writing pseudo random data to it
cryptsetup luksOpen key_container key_device
dd if=/dev/urandom of=/dev/mapper/key_device
# luksFormat the data device using the random data from the luks key device
cryptsetup -d /dev/mapper/key luksFormat /dev/sda1
# later, to open /dev/sda1
cryptsetup -d /dev/mapper/key_device luksOpen /dev/sda1 encryptedfs
My questions:
1. Is this a valid approach or am I making a mistake/do you see a problem somewhere?
2. How much data from the loop device will cryptsetup use as key to format/open the data device? Everything? Is there a limit?
3. Is there a difference between doing a
cat /dev/mapper/key | cryptsetup -d -
and
cryptsetup -d /dev/mapper/key?
3. Assuming that the answer to 1 is "no mistake/problem" and 2 is "everything there is" or even "the first x bytes", is it possible that the actual contents of the loop device may change in the future because of different loop device implementations or somethings else I didn't think of? I'd like to avoid bad surprises in the future..
4. What would you recommend as size for the key container file, knowing that the luks header requires some space too?
Any feedback appreciated.
Cheers,
fabriceb

I do the same ( https://wiki.gentoo.org/wiki/Custom_Ini … ed_Keyfile ).
--key-file=- should be equivalent, but it's meant for grabbing a key from gpg output or whatever; since you can specify it directly here, no need to involve anything else like cat etc.
without --key-file=- it would stop reading at newlines or something. this behaviour is quite dangerous as it may cause people who believe they're using a long random key, to use only a very short (or even empty) key instead. one way to avoid such ambiguousness is to make sure there are no newline bytes in your keyfile, so it would use the whole thing in either interpretation.
as for the key length, a key is essentially a passphrase. So it does not have to be very long at all; 8 truly random bytes would require up to 256^8 tries to break after all and with LUKS, each try takes ~1 second per physical CPU... but the smallest unit that LUKS allows is 512 bytes (1 sector) so you could just as well use the whole thing. If you use 4096 bytes, you're confusing bytes with bits somewhere... and as for bits, even 128bit AES is still considered secure...
You could save some bytes in the initrd.gz if you initialize the container file with zeroes instead of random, so it can be compressed. The key will still be random as the random cipher key will turn the zeroes to something else after all...

How to stop GNOME automounting my partitions

Gnome always mounts my Windows partitions to /media. I have shut off all automount options in the gnome-volume-manager, but it still mounts them all. They are ofcourse not listed in my /etc/fstab. Is this supposed to be some kind of "feature"?
Does anyone know how I can fix this annoying behaviour?

Okay, I managed to make it so they do not show up anywhere, here is my preferences.fdi file located in /etc/hal/fdi/policy/:
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="storage.hotpluggable" bool="false">
<match key="storage.removable" bool="false">
<merge key="storage.automount_enabled_hint" type="bool">false</merge>
</match>
</match>
</device>
<device>
<match key="volume.uuid" string="2E2C05502C05150D">
<merge key="volume.ignore" type="bool">true</merge>
</match>
<match key="volume.uuid" string="afba1791-11b8-496d-a232-04805eaef6b2">
<merge key="volume.ignore" type="bool">true</merge>
</match>
</device>
</deviceinfo>
Technically, the "storage.automount_enabled_hint" is not needed anymore, but it's not a bad thing to have it there.
I use UUID's to address my partitions, and that's pretty straight forward with the "volume.uuid" key, but for the people who want to use the normal partition names, I don't really know how that would work. There is a "volume.partition.number" key, but that only accepts a integer, and not a string like "sda6" for example.
You can find the UUID's of your partitions in /dev/disk/by-uuid/. Just do ls -l.
Thanks for all the help. One step closer to a perfect Arch system
Last edited by HyperBaton (2008-04-18 11:56:05)

Systemd automount luks partition in background

Similar Messages

Maybe you are looking for