[systemd-devel] systemd-cryptsetup device requires a valid and unique target UUID - breaks btrfs multivolume?

[Anders Andersson]

Hi! I have been trying to set up the "perfect" (for me) encrypted
server for some time now, and I have been running into a lot of
issues. After extensive digging and trying to learn about systemd, I
think I have found the root cause, and I would like some input from
people with more experience. Please excuse the verbosity of this
email, but it is essentially a detailed bug report containing what I
hope is every little detail that is required to recreate and debug
this issue.

First some background: The problems arise when I want to run a
multi-device btrfs filesystem on LUKS encrypted backing devices, and
use a keyfile that resides on another encrypted filesystem. Since I am
a Debian user I would have previously used the
keyscript=decrypt_derived method to solve this, but now I want to use
systemd, where this is missing. The problem is that I get a lot of
timeouts for no apparent reason, and I have not managed to tell
systemd about the dependencies, and they keep timing out even though
they are obviously correctly unlocked.

After debugging this for a while I think it comes down to that when
systemd tries to unlock an encrypted block device and create a
corresponding /dev/mapper/foo and a dev-mapper-foo.device, it fails if
the unlocked device does not have a valid UUID. It will successfully
unlock the device and create the correct mapping, but then it hangs,
and reports the device as inactive (dead).

I will explain what I expect to work, and what does not work, with
these commands. This is on a Fedora Server virtual machine, which I
have never tried before but installed just to test this!

I have created a partition on a block device (/dev/sdb1) which I have
prepared with luksFormat using a keyfile called "/keyfile", located on
the root filesystem. Nothing fancy here. I put a simple entry in
/etc/crypttab and had systemctl daemon-reload generate the
corresponding files in /var/run/systemd/generator, which I copied to
/etc/systemd/system/.


 /etc/systemd/system/systemd-cryptsetup@crypt.service 
# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8)
man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
RequiresMountsFor=/keyfile
BindsTo=dev-sdb1.device
After=dev-sdb1.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'crypt'
'/dev/sdb1' '/keyfile' 'luks'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach 'crypt'
 /etc/systemd/system/systemd-cryptsetup@crypt.service 


There is also a link from dev-mapper-crypt.device.requires:

dev-mapper-crypt.device.requires
 └── systemd-cryptsetup@crypt.service -> ../systemd-cryptsetup@crypt.service






With this set up, and the encrypted target block device has a plain
old ext4 filesystem, everything works like I expect it to:

[root@fedora ~]# systemctl status dev-mapper-crypt.device
● dev-mapper-crypt.device
   Loaded: loaded
   Active: inactive (dead)
[root@fedora ~]# systemctl start dev-mapper-crypt.device
[root@fedora ~]# systemctl status dev-mapper-crypt.device
● dev-mapper-crypt.device - /dev/mapper/crypt
   Follow: unit currently follows state of
sys-devices-virtual-block-dm\x2d2.device
   Loaded: loaded
   Active: active (plugged) since Sat 2015-12-12 14:12:44 CET; 6s ago
   Device: /sys/devices/virtual/block/dm-2



This means that systemd knows about dev-mapper-crypt.device, it can
start automatically if wanted, and it can be used as a dependency.
Great!

Now I make a change. I remove the ext4 filesystem from the encrypted
target by filling /dev/mapper/crypt with zeros, reboot for good
measure, and try this again:

root@fedora ~]# systemctl status dev-mapper-crypt.device
● dev-mapper-crypt.device
   Loaded: loaded
   Active: inactive (dead)
[root@fedora ~]# systemctl start dev-mapper-crypt.device

... and here it stops. Nothing happens. If I log in again and check
what's going on I see this:
 1197 pts/0Ss 0:00  |   \_ -bash
 1219 pts/0S+ 0:00  |   \_ systemctl start
dev-mapper-crypt.device
 1220 pts/0S+ 0:00  |   \_
/usr/bin/systemd-tty-ask-password-agent --watch
 1221 pts/0Sl+0:00  |   \_ /usr/bin/pkttyagent
--notify-fd 5 --fallback

But there are no password prompts anywhere, not in any SSH sessions
nor in the actual console. Eventually the original command times out:

Job for dev-mapper-crypt.device timed out.
[root@fedora ~]# systemctl status dev-mapper-crypt.device
● dev-mapper-crypt.device
   Loaded: loaded
   Active: inactive (dead)

Dec 12 14:34:44 fedora.localdomain systemd[1]:
dev-mapper-crypt.device: Job dev-mapper-crypt.device/start timed out.
Dec 12 14:34:44 fedora.localdomain systemd[1]: 

Re: [systemd-devel] XSLT error compiling systemd

[David Herrmann]

Hi

On Sat, Dec 12, 2015 at 8:43 AM, Andrew Thompson
 wrote:
> With a new install of Fedora server, I'm having trouble building systemd
> documentation. It's driving me crazy.
>
> I've been able to fix this problem by editing the Makefile by hand, and
> removing the "--no-net" flag from the XSLT build command, but that is less
> than ideal. Has anyone run into this problem? What is the preferred way to
> fix it? Below is the error message I'm getting at the end of the output from
> "make":
>
>
>   XSLT man/bootup.7
> I/O error : Attempt to load network entity
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> warning: failed to load external entity
> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
> compilation error: file ./man/custom-man.xsl line 27 element import
> xsl:import : unable to load
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> Makefile:22089: recipe for target 'man/bootup.7' failed

Do you have the required stylesheets installed? In particular,
docbook-xml and docbook-xsl? It should not load them from external
sources, if they're supplied locally.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] XSLT error compiling systemd

[Andrew Thompson]

That was the tip I needed, thanks.

I ran the command:
sudo yum install docbook-style-xsl

(which translated to the more modern "dnf instsall docbook-style-xsl")
After that it worked fine.

Thanks again!
~Andrew

On Sat, Dec 12, 2015 at 3:14 AM, David Herrmann  wrote:
>
> Hi
>
> On Sat, Dec 12, 2015 at 8:43 AM, Andrew Thompson
>  wrote:
> > With a new install of Fedora server, I'm having trouble building systemd
> > documentation. It's driving me crazy.
> >
> > I've been able to fix this problem by editing the Makefile by hand, and
> > removing the "--no-net" flag from the XSLT build command, but that is less
> > than ideal. Has anyone run into this problem? What is the preferred way to
> > fix it? Below is the error message I'm getting at the end of the output from
> > "make":
> >
> >
> >   XSLT man/bootup.7
> > I/O error : Attempt to load network entity
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > warning: failed to load external entity
> > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
> > compilation error: file ./man/custom-man.xsl line 27 element import
> > xsl:import : unable to load
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > Makefile:22089: recipe for target 'man/bootup.7' failed
>
> Do you have the required stylesheets installed? In particular,
> docbook-xml and docbook-xsl? It should not load them from external
> sources, if they're supplied locally.
>
> Thanks
> David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel