How can I manually mount external encrypted media with system

Hi,

I manually mount encrypted media (with the appropriate entries in fstab
and /etc/crypttab) by doing:


systemctl start systemd-cryptsetup@cr_aux
mount /data/aux

However, when I try that with a disk that I plug after the system boots,
this happens:


> Telcontar:~ # systemctl start systemd-cryptsetup@crmm_Min-Rimmon
> Failed to issue method call: Unit systemd-cryptsetup@crmm_Min-Rimmon.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-cryptsetup@crmm_Min-Rimmon.service' for details.
> Telcontar:~ #

The definitions are these:


> fstab:
> /dev/mapper/crmm_Min-Rimmon     /mnt/Jz1-5_Min-Rimmon    xfs             noauto,nofail   1 10

> /etc/crypttab:
> crmm_Min-Rimmon                 /dev/disk/by-uuid/267e513f....   none    noauto

The problem is that systemd is not aware that the device
“/dev/disk/by-uuid/267e513f…” has appeared, so the service file is
not there. Is there a command to tell systemd to reevaluate devices and
mounts?


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I cannot reproduce it.

bor@opensuse:~> cat /etc/crypttab 
cr_test    /dev/disk/by-id/usb-USB2.0_Flash_Disk_F77DEE41-0:0 none noauto
bor@opensuse:~> grep cr_test /etc/fstab
/dev/mapper/cr_test    /mnt    ext2    noauto,nofail    0 0
bor@opensuse:~> systemctl --full -a | fgrep usb\\x2dUSB

Plug in USB stick

bor@opensuse:~> systemctl --full -a | fgrep usb\\x2dUSB
dev-disk-by\x2did-usb\x2dUSB2.0_Flash_Disk_F77DEE41\x2d0:0.device                                              loaded active   plugged       Flash_Disk

bor@opensuse:~> sudo systemctl start mnt.mount
root's password:
Please enter passphrase for disk Flash_Disk (cr_test) on /mnt! ****
bor@opensuse:~> LC_ALL=C df /mnt
Filesystem          1K-blocks  Used Available Use% Mounted on
/dev/mapper/cr_test   1888808  2832   1790028   1% /mnt

Systemd relies on udev events. You can check with “udevadm monitor” that device is detected. If yes, it should also be seen by systemd.

On 2013-06-30 06:26, arvidjaar wrote:
>
> I cannot reproduce it.
> Code:
> --------------------
> bor@opensuse:~> cat /etc/crypttab
> cr_test /dev/disk/by-id/usb-USB2.0_Flash_Disk_F77DEE41-0:0 none noauto
> bor@opensuse:~> grep cr_test /etc/fstab
> /dev/mapper/cr_test /mnt ext2 noauto,nofail 0 0
> bor@opensuse:~> systemctl --full -a | fgrep usb\x2dUSB
> --------------------
>
> Plug in USB stick
>
> Code:
> --------------------
> bor@opensuse:~> systemctl --full -a | fgrep usb\x2dUSB
> dev-disk-by\x2did-usb\x2dUSB2.0_Flash_Disk_F77DEE41\x2d0:0.device loaded active plugged Flash_Disk
>
> bor@opensuse:~> sudo systemctl start mnt.mount
> root’s password:
> Please enter passphrase for disk Flash_Disk (cr_test) on /mnt! ****
> bor@opensuse:~> LC_ALL=C df /mnt
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/mapper/cr_test 1888808 2832 1790028 1% /mnt
>
> --------------------

Ah, but there is a difference: you are using “mnt.mount”, whereas I use
“systemd-cryptsetup@crmm_Min-Rimmon”, in your case
“systemd-cryptsetup@cr_test” Let me try your way.


> Telcontar:~ # systemctl start[TAB][TAB]
> alsa-restore.service                                   local_fs.target                                        sys-kernel-config.mount                                systemd-fsck@dev-disk-by\x2dlabel-d_storage.service
> alsa-store.service                                     localfs.service                                        syslog-ng.service                                      systemd-fsck@dev-disk-by\x2dlabel-raid5.service
> autofs.service                                         lvm.service                                            syslogd.service                                        systemd-fsck@dev-mapper-cr_Datum.service
> basic.service                                          mail-transfer-agent.target                             systemd-ask-password-wall.path                         systemd-fsck@dev-mapper-cr_cripta.service
> capisuite.service                                      multipath.service                                      systemd-ask-password-wall.service                      systemd-fsck@dev-mapper-cr_other.service
> cifs.service                                           network-remotefs.service                               systemd-binfmt.service                                 systemd-hibernate.service
> cyrus.service                                          nmb.service                                            systemd-fsck-root.service                              systemd-initctl.service
> device-mapper.service                                  nss-user-lookup.target                                 systemd-fsck@dev-disk-by\x2dlabel-Jazz1.service        systemd-journal-flush.service
> dmraid.service                                         openibd.service                                        systemd-fsck@dev-disk-by\x2dlabel-a_boot_1.service     systemd-random-seed-load.service
> earlysyslog.service                                    openslp.service                                        systemd-fsck@dev-disk-by\x2dlabel-a_boot_2.service     systemd-random-seed-save.service
> earlyxdm.service                                       plymouth-quit-wait.service                             systemd-fsck@dev-disk-by\x2dlabel-a_one.service        systemd-readahead-done.service
> emergency.service                                      plymouth-start.service                                 systemd-fsck@dev-disk-by\x2dlabel-a_storage.service    systemd-shutdownd.service
> emergency.target                                       purge-kernels.service                                  systemd-fsck@dev-disk-by\x2dlabel-a_vmware.service     systemd-tmpfiles-clean.service
> exim.service                                           rescue.service                                         systemd-fsck@dev-disk-by\x2dlabel-b_main_opt.service   systemd-update-utmp-runlevel.service
> firstboot.service                                      rescue.target                                          systemd-fsck@dev-disk-by\x2dlabel-b_main_usr.service   systemd-update-utmp-shutdown.service
> hylafax.service                                        resmgr.service                                         systemd-fsck@dev-disk-by\x2dlabel-b_storage.service    winbind.service
> isdn.service                                           scsidev.service                                        systemd-fsck@dev-disk-by\x2dlabel-c_home.service       ypbind.service
> kbd.service                                            sendmail.service                                       systemd-fsck@dev-disk-by\x2dlabel-c_home_mail.service  ypserv.service
> krb5kdc.service                                        setserial.service                                      systemd-fsck@dev-disk-by\x2dlabel-c_storage.service
> ldap.service                                           slpd.service                                           systemd-fsck@dev-disk-by\x2dlabel-c_usr_local.service
> loadmodules.service                                    sound.target                                           systemd-fsck@dev-disk-by\x2dlabel-c_usr_src.service


Lets try forcing it:


> Telcontar:~ # systemctl start /mnt/Ext.CR/Jz1-5_Min-Rimmon.mount
> Failed to issue method call: Unit mnt-Ext.CR-Jz1\x2d5_Min\x2dRimmon.mount.mount failed to load: No such file or directory. See system logs and 'systemctl status mnt-Ext.CR-Jz1\x2d5_Min\x2dRimmon.mount.mount' for details.
> Telcontar:~ #


I don’t really know what name would “/mnt/Ext.CR/Jz1-5_Min-Rimmon”
convert to… the exact mount place, edited on the first post, is
“/mnt/Ext.CR/Jz1-5_Min-Rimmon.mount”.

Grepping:



> Telcontar:~ # l /dev/disk/by-uuid/ | grep sde
> lrwxrwxrwx 1 root root  10 Jun 30 02:17 267e513f-fa60-404c-b2c5-ab4b80e0a1af -> ../../sde5
> lrwxrwxrwx 1 root root  10 Jun 30 02:17 54603e0c-b36b-4731-a174-112753ab04eb -> ../../sde1
> lrwxrwxrwx 1 root root  10 Jun 30 02:17 6a746c0e-632c-45f9-a1d9-5fdbb29f4ae5 -> ../../sde6
> lrwxrwxrwx 1 root root  10 Jun 30 02:17 c7169986-a153-419f-bb11-a6ddc22ee1c6 -> ../../sde7
> Telcontar:~ #

Disk is present. Verify the UUID is listed in crypttab:

> Telcontar:~ # grep 267e513f-fa60-404c-b2c5-ab4b80e0a1af /etc/crypttab
> crmm_Min-Rimmon                 /dev/disk/by-uuid/267e513f-fa60-404c-b2c5-ab4b80e0a1af          none    noauto
> Telcontar:~ #

Verify correct identifier in fstab:

> Telcontar:~ # grep crmm_Min-Rimmon /etc/fstab
> /dev/mapper/crmm_Min-Rimmon     /mnt/Ext.CR/Jz1-5_Min-Rimmon    xfs             noauto,user,noatime,nodiratime,nofail   1 10
> Telcontar:~ #

And in systemd:

> Telcontar:~ # systemctl --full -a | grep "sde\|ab4b80e0a1a"
> dev-disk-by\x2duuid-267e513f\x2dfa60\x2d404c\x2db2c5\x2dab4b80e0a1af.device                            loaded active   plugged       ST3500418AS
> dev-sde.device                                                                                         loaded active   plugged       ST3500418AS
> dev-sde1.device                                                                                        loaded active   plugged       ST3500418AS
> dev-sde2.device                                                                                        loaded active   plugged       ST3500418AS
> dev-sde5.device                                                                                        loaded active   plugged       ST3500418AS
> dev-sde6.device                                                                                        loaded active   plugged       ST3500418AS
> dev-sde7.device                                                                                        loaded active   plugged       ST3500418AS
> sys-devices-pci0000:00-0000:00:1c.2-0000:04:00.0-ata2-host1-target1:0:0-1:0:0:0-block-sde-sde1.device  loaded active   plugged       ST3500418AS
> sys-devices-pci0000:00-0000:00:1c.2-0000:04:00.0-ata2-host1-target1:0:0-1:0:0:0-block-sde-sde2.device  loaded active   plugged       ST3500418AS
> sys-devices-pci0000:00-0000:00:1c.2-0000:04:00.0-ata2-host1-target1:0:0-1:0:0:0-block-sde-sde5.device  loaded active   plugged       ST3500418AS
> sys-devices-pci0000:00-0000:00:1c.2-0000:04:00.0-ata2-host1-target1:0:0-1:0:0:0-block-sde-sde6.device  loaded active   plugged       ST3500418AS
> sys-devices-pci0000:00-0000:00:1c.2-0000:04:00.0-ata2-host1-target1:0:0-1:0:0:0-block-sde-sde7.device  loaded active   plugged       ST3500418AS
> sys-devices-pci0000:00-0000:00:1c.2-0000:04:00.0-ata2-host1-target1:0:0-1:0:0:0-block-sde.device       loaded active   plugged       ST3500418AS
> Telcontar:~ #


I’m not sure what combination I should use to start it :-?

robin_listas;2568444 Wrote:

The problem is that systemd is not aware that the device
“/dev/disk/by-uuid/267e513f…” has appeared, so the service file is
not there. Is there a command to tell systemd to reevaluate devices and
mounts?

Systemd relies on udev events. You can check with “udevadm monitor”
that device is detected. If yes, it should also be seen by systemd.

No, nothing. It is an eSATA disk, detection is seen in the messages log.


Telcontar:~ # umount /mnt/Ext/Jazz1
Telcontar:~ #

power off disk, power on again. Mount non-encripted sde1:

Telcontar:~ # mount /mnt/Ext/Jazz1
Telcontar:~ #

And the log for that sequence is:


> <0.5> 2013-06-30 10:40:30 Telcontar kernel - - - [382212.794805] XFS (sde1): Mounting Filesystem
> <0.6> 2013-06-30 10:40:30 Telcontar kernel - - - [382212.815197] XFS (sde1): Ending clean mount
> <0.3> 2013-06-30 10:40:49 Telcontar kernel - - - [382231.899285] ata2: exception Emask 0x10 SAct 0x0 SErr 0x990000 action 0xe frozen
> <0.3> 2013-06-30 10:40:49 Telcontar kernel - - - [382231.899289] ata2: irq_stat 0x00400000, PHY RDY changed
> <0.3> 2013-06-30 10:40:49 Telcontar kernel - - - [382231.899292] ata2: SError: { PHYRdyChg 10B8B Dispar LinkSeq }
> <0.6> 2013-06-30 10:40:49 Telcontar kernel - - - [382231.899295] ata2: hard resetting link
> <0.6> 2013-06-30 10:40:50 Telcontar kernel - - - [382232.622030] ata2: SATA link down (SStatus 0 SControl 300)
> <0.6> 2013-06-30 10:40:55 Telcontar kernel - - - [382237.622011] ata2: hard resetting link
> <0.6> 2013-06-30 10:40:55 Telcontar kernel - - - [382237.927030] ata2: SATA link down (SStatus 0 SControl 300)
> <0.4> 2013-06-30 10:40:55 Telcontar kernel - - - [382237.927042] ata2: limiting SATA link speed to 1.5 Gbps
> <0.6> 2013-06-30 10:40:56 Telcontar kernel - - - [382238.940456] ata2: hard resetting link
> <0.6> 2013-06-30 10:41:02 Telcontar kernel - - - [382244.773026] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> <0.6> 2013-06-30 10:41:02 Telcontar kernel - - - [382244.775393] ata2.00: configured for UDMA/133
> <0.6> 2013-06-30 10:41:02 Telcontar kernel - - - [382244.786014] ata2: EH complete
> <0.5> 2013-06-30 10:41:16 Telcontar kernel - - - [382258.927645] XFS (sde1): Mounting Filesystem
> <0.6> 2013-06-30 10:41:16 Telcontar kernel - - - [382258.985657] XFS (sde1): Ending clean mount


the monitor:


> Telcontar:~ # udevadm monitor
> monitor will print the received events for:
> UDEV - the event which udev sends out after rule processing
> KERNEL - the kernel uevent


:-?


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Here is the problem. As long as kernel does not send any event when disk it inserted user space will not notice it (I doubt any program today does polling itself).

On 2013-06-30 12:46, arvidjaar wrote:
>
> robin_listas;2568484 Wrote:
>>
>>> Systemd relies on udev events. You can check with “udevadm monitor”
>>> that device is detected. If yes, it should also be seen by systemd.
>>
>>
>>>
> Code:
> --------------------
> > >
> > > Telcontar:~ # udevadm monitor
> > > monitor will print the received events for:
> > > UDEV - the event which udev sends out after rule processing
> > > KERNEL - the kernel uevent
> >
> >
> --------------------
>>>
>>
>>
> Here is the problem. As long as kernel does not send any event when
> disk it inserted user space will not notice it (I doubt any program
> today does polling itself).

Ok, the kernel does not send those events. What can I do to mount that
encrypted partition anyway? Can I somehow tell systemd to scan disks or
whatever? Because the only way I know so far is rebooting, the disk is
then listed.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-06-30 13:18, Carlos E. R. wrote:
> On 2013-06-30 12:46, arvidjaar wrote:

>>>
>> Here is the problem. As long as kernel does not send any event when
>> disk it inserted user space will not notice it (I doubt any program
>> today does polling itself).
>
> Ok, the kernel does not send those events. What can I do to mount that
> encrypted partition anyway? Can I somehow tell systemd to scan disks or
> whatever? Because the only way I know so far is rebooting, the disk is
> then listed.

I have tried “daemon-reload” and “daemon-reexec”, no go.


> Telcontar:~ # systemctl status dev-sde5.device
> dev-sde5.device - ST3500418AS
>           Follow: unit currently follows state of sys-devices-pci0000:00-0000:00:1c.2-0000:04:00.0-ata2-host1-target1:0:0-1:0:0:0-block-sde-sde5.device
>           Loaded: loaded
>           Active: active (plugged)
>           Device: /sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ata2/host1/target1:0:0/1:0:0:0/block/sde/sde5
>
> Telcontar:~ # systemctl status systemd-cryptsetup@crmm_Min-Rimmon
> systemd-cryptsetup@crmm_Min-Rimmon.service
>           Loaded: error (Reason: No such file or directory)
>           Active: inactive (dead)
>
> Telcontar:~ #


There has to be a way… or do I have to manually activate the devmap
device, old style? It is absurd.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

That’s something entirely different. Unit file does not exist. What “systemctl list-unit-files” says? Does it exist in /run/systemd/generator?

On 2013-06-30 16:36, arvidjaar wrote:
>
> robin_listas;2568499 Wrote:
>>
>>>
> Code:
> --------------------
> > >
> > > Telcontar:~ # systemctl status systemd-cryptsetup@crmm_Min-Rimmon
> > > systemd-cryptsetup@crmm_Min-Rimmon.service
> > > Loaded: error (Reason: No such file or directory)
> > > Active: inactive (dead)
> > >
> > > Telcontar:~ #
> >
> >
> --------------------
>>>
>>
>
> That’s something entirely different. Unit file does not exist. What
> “systemctl list-unit-files” says?


> Telcontar:~ # systemctl list-unit-files --no-pager | grep cr
> autoyast-initscripts.service           disabled
> cron.service                           enabled
> crypto-early.service                   masked
> crypto.service                         masked
> cryptsetup.target                      static
> Telcontar:~ #

It is not there.

Does it exist in /run/systemd/generator?

Yes, it does!:


> -rw-r--r--  1 root root  879 Jun 30 13:18 systemd-cryptsetup@crmm_5_Amon_Din.service
> -rw-r--r--  1 root root  879 Jun 30 13:18 systemd-cryptsetup@crmm_6_Eilenach.service
> -rw-r--r--  1 root root  875 Jun 30 13:18 systemd-cryptsetup@crmm_Calenhad.service
> -rw-r--r--  1 root root  879 Jun 30 13:18 systemd-cryptsetup@crmm_Halifirien.service
> -rw-r--r--  1 root root  879 Jun 30 13:18 systemd-cryptsetup@crmm_Min\x2dRimmon.service    <=====


But that is not the name I was looking for, I was looking for
“crmm_Min-Rimmon.service”. It doesn’t like the dash!


> Telcontar:~ # systemctl status systemd-cryptsetup@crmm_Min\x2dRimmon.service
> systemd-cryptsetup@crmm_Minx2dRimmon.service
>           Loaded: error (Reason: No such file or directory)
>           Active: inactive (dead)
>
> Telcontar:~ # systemctl status systemd-cryptsetup@crmm_5_Amon_Din.service
> systemd-cryptsetup@crmm_5_Amon_Din.service - Cryptography Setup for crmm_5_Amon_Din
>           Loaded: loaded (/etc/crypttab)
>           Active: inactive (dead)
>             Docs: man:systemd-cryptsetup@.service(8)
>                   man:crypttab(5)
>           CGroup: name=systemd:/system/systemd-cryptsetup@.service/crmm_5_Amon_Din
>
> Telcontar:~ #
> Telcontar:~ # systemctl start systemd-cryptsetup@crmm_5_Amon_Din.service
> keyword
> ^C
> Telcontar:~ #
> Telcontar:~ # systemctl start systemd-cryptsetup@crmm_5_Amon_Din
> pppp
> pppp
> pppp
> pppp
> pppp
> ^C
> Telcontar:~ #

Wait… ah, wrong name. See:


> Telcontar:~ # systemctl start systemd-cryptsetup@crmm_Calenhad
> Please enter passphrase for disk ST3500418AS (crmm_Calenhad) on /mnt/Ext.CR/Jz1-6_Calenhad! *******************
> Telcontar:~ # ls /mnt/Ext.CR/Jz1-6_Calenhad!
> ls: cannot access /mnt/Ext.CR/Jz1-6_Calenhad!: No such file or directory
> Telcontar:~ # mount /mnt/Ext.CR/Jz1-6_Calenhad!
> mount: can't find /mnt/Ext.CR/Jz1-6_Calenhad! in /etc/fstab
> Telcontar:~ # mount /mnt/Ext.CR/Jz1-6_Calenhad
> Telcontar:~ # ls /mnt/Ext.CR/Jz1-6_Calenhad
> Telcontar:~ #
> Telcontar:~ # df -h /mnt/Ext.CR/Jz1-6_Calenhad
> Filesystem                 Size  Used Avail Use% Mounted on
> /dev/mapper/crmm_Calenhad   50G   33M   50G   1% /mnt/Ext.CR/Jz1-6_Calenhad
> Telcontar:~ #

> Telcontar:~ # systemctl start systemd-cryptsetup@crmm_Halifirien
> Please enter passphrase for disk ST3500418AS (crmm_Halifirien) on /mnt/Ext.CR/Jz1-7_Halifirien! *******************
> Telcontar:~ # ls /mnt/Ext.CR/Jz1-7_Halifirien
> not_mounted
> Telcontar:~ # mount /mnt/Ext.CR/Jz1-7_Halifirien
> Telcontar:~ # ls /mnt/Ext.CR/Jz1-7_Halifirien
> Contenido_temporalmente_guardado_de__data_other  Donde  Donde~  MD5SUM  Nuevos.201010  cryptodata
> Telcontar:~ #


Ok, all 3 are on the same external disk, but “crmm_Min-Rimmon” fails,
probably because of the dash in the name:


> #Jazz1:  Min-Rimmon (5), Calenhad (6), Halifirien (7)
> crmm_Min-Rimmon                 /dev/disk/by-uuid/267e513f-fa60-404c-b2c5-ab4b80e0a1af          none    noauto
> crmm_Calenhad                   /dev/disk/by-uuid/6a746c0e-632c-45f9-a1d9-5fdbb29f4ae5          none    noauto
> crmm_Halifirien                 /dev/disk/by-uuid/c7169986-a153-419f-bb11-a6ddc22ee1c6          none    noauto


Interestingly, “crmm_5_Amon_Din” and “crmm_6_Eilenach” are not powered
up, yet the service file exists.

So… I can get going, I suppose, by changing that name. However… is
this a bug, or did I do something wrong?


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Agreed, this is the most basic Q, esp I find the expected Unit name odd.
Is this supposed to be a custom Unit file?
To search for your Unit file

systemctl -a | grep systemd-cryptsetup@crmm_Min-Rimmon 

In fact, guessing by the proposed Unit name it should be a script and not an actual Unit file.

Also, I find it odd that this Unit file would be a type service and not mount or possibly target.
Edit - I see by your post it’s indeed supposed to be implemented as a service.

TSU

On 2013-06-30 18:16, tsu2 wrote:
>
> arvidjaar;2568527 Wrote:
>> That’s something entirely different. Unit file does not exist. What
>> “systemctl list-unit-files” says? Does it exist in
>> /run/systemd/generator?
>
> Agreed, this is the most basic Q, esp I find the expected Unit name
> odd.
> Is this supposed to be a custom Unit file?
> To search for your Unit file
>
> Code:
> --------------------
> systemctl -a | grep systemd-cryptsetup@crmm_Min-Rimmon
> --------------------
>
>
> In fact, guessing by the proposed Unit name it should be a script and
> not an actual Unit file.
>
> Also, I find it odd that this Unit file would be a type service and not
> mount or possibly target.
> Edit - I see by your post it’s indeed supposed to be implemented as a
> service.

Notice in my last post that what really exists is
“systemd-cryptsetup@crmm_Min\x2dRimmon.service”, where the dash (-) has
been defanged (is that the word?) or escaped to “\x2d”. But even so, it
fails to work. I had to rename the entries in both fstab and crypttab:


> Telcontar:~ # l /run/systemd/generator | grep crmm_Min
> drwxr-xr-x  2 root root   60 Jun 30 18:19 dev-mapper-crmm_Min_Rimmon.device.requires/
> -rw-r--r--  1 root root  879 Jun 30 18:19 systemd-cryptsetup@crmm_Min_Rimmon.service
> Telcontar:~ #

> Telcontar:~ # file /run/systemd/generator/dev-mapper-crmm_Min_Rimmon.device.requires/systemd-cryptsetup\@crmm_Min_Rimmon.service
> /run/systemd/generator/dev-mapper-crmm_Min_Rimmon.device.requires/systemd-cryptsetup@crmm_Min_Rimmon.service: symbolic link to `../systemd-cryptsetup@crmm_Min_Rimmon.service'
&gt; Telcontar:~ #
&gt; Telcontar:~ # file /run/systemd/generator/systemd-cryptsetup\@crmm_Min_Rimmon.service
&gt; /run/systemd/generator/systemd-cryptsetup@crmm_Min_Rimmon.service: ASCII text
&gt; Telcontar:~ #


which do work. I suppose it is an automatically generated service file.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I’d say neither. The primary use case for these unit files is mapping of /etc/crypttab and /etc/fstab. So as long as this works, it can be considered as minor inconvenience.

It is probably still worth discussion on systemd-devel.

On 2013-06-30 20:26, arvidjaar wrote:
>
> robin_listas;2568544 Wrote:
>> However… is
>> this a bug, or did I do something wrong?
>>
>
> I’d say neither. The primary use case for these unit files is mapping
> of /etc/crypttab and /etc/fstab. So as long as this works, it can be
> considered as minor inconvenience.

But it does not work. An encrypted device with a dash on the name does
not work. I had to rename it.

> It is probably still worth discussion on systemd-devel.

If you want to comment it there, go ahead; it is not the place for me. I
can mention the issue on a bugzilla at Novell.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

It does work for intended use case. It generates correct dependencies between units so when top-level unit that needs encrypted container is activated, encrypted container is activated too.

linux-1a7f:~ # cat /etc/crypttab
cr-test /dev/sdb none noauto
linux-1a7f:~ # grep cr-test /etc/fstab
/dev/mapper/cr-test /test    ext2    noauto,nofail    0 0
linux-1a7f:~ # systemctl start test.mount
Please enter passphrase for disk QEMU_HARDDISK (cr-test) on /test! ****
linux-1a7f:~ # df /test
Filesystem          1K-blocks  Used Available Use% Mounted on
/dev/mapper/cr-test      7931    45      7314   1% /test
linux-1a7f:~ # systemctl status test.mount
test.mount - /test
   Loaded: loaded (/etc/fstab)
   Active: active (mounted) since Mon 2013-07-01 08:34:40 MSK; 12s ago
    Where: /test
     What: /dev/mapper/cr-test
  Process: 1983 ExecMount=/bin/mount /dev/mapper/cr-test /test -t ext2 -o noauto,nofail (code=exited, status=0/SUCCESS)

Jul 01 08:34:40 linux-1a7f systemd[1]: Mounting /test...
Jul 01 08:34:40 linux-1a7f systemd[1]: Mounted /test.
linux-1a7f:~ # systemctl status systemd-cryptsetup@cr\\x2dtest.service
systemd-cryptsetup@cr\x2dtest.service - Cryptography Setup for cr-test
   Loaded: loaded (/etc/crypttab)
   Active: active (exited) since Mon 2013-07-01 08:34:40 MSK; 39s ago
     Docs: man:systemd-cryptsetup@.service(8)
           man:crypttab(5)
  Process: 1942 ExecStart=/usr/lib/systemd/systemd-cryptsetup attach cr-test /dev/sdb none noauto (code=exited, status=0/SUCCESS)

Jul 01 08:34:39 linux-1a7f systemd-cryptsetup[1942]: Set cipher aes, mode xts-plain64, key size...b.
Jul 01 08:34:40 linux-1a7f systemd[1]: Started Cryptography Setup for cr-test.
linux-1a7f:~ # systemctl --no-pager show -p After -p Requires test.mount
Requires=-.mount
After=local-fs-pre.target systemd-journald.socket dev-mapper-cr\x2dtest.device -.mount
linux-1a7f:~ # systemctl --no-pager show -p After -p Requires dev-mapper-cr\\x2dtest.device
Requires=systemd-cryptsetup@cr\x2dtest.service
After=

Remember, it was never intended as general purpose crypto-container management interface, but rather as a way to provide support for /etc/crypttab on boot. After boot there are many ways to manage them, including udisks2 :slight_smile:

On 2013-07-01 06:56, arvidjaar wrote:
>
> robin_listas;2568604 Wrote:
>>
>> But it does not work. An encrypted device with a dash on the name does
>> not work.
> It does work for intended use case. It generates correct dependencies
> between units so when top-level unit that needs encrypted container is
> activated, encrypted container is activated too.

You are not getting the point. It works on all, but it fails on one of
the mounts, it fails if there is a dash in the name. You are skipping
commenting on this fact. Why does it fail? Why the escaping?

> Remember, it was never intended as general purpose crypto-container
> management interface, but rather as a way to provide support for
> /etc/crypttab on boot. After boot there are many ways to manage them,
> including udisks2 :slight_smile:

As far as I’m concerned, it is a replacement for SuSE script
/etc/init.d/boot.crypto. I expect no more and no less than what that
script did. After all, systemd is touted as a drop in replacement for
systemv. The partitions I’m using are several years old, and they worked
fine with it.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

My message that you replied to shows that it works for crypto container with dash in name.

> Remember, it was never intended as general purpose crypto-container
> management interface, but rather as a way to provide support for
> /etc/crypttab on boot. After boot there are many ways to manage them,
> including udisks2 :slight_smile:

As far as I’m concerned, it is a replacement for SuSE script
/etc/init.d/boot.crypto. I expect no more and no less than what that
script did. After all, systemd is touted as a drop in replacement for
systemv.

systemd is touted as drop in replacement of sysvinit. It does not try to mimic all possible overloaded usages of initscripts that extend beyond what is required to boot and shutdown system.

On 2013-07-01 14:36, arvidjaar wrote:
>
> robin_listas;2568681 Wrote:
>> it fails if there is a dash in the name. You are skipping
>> commenting on this fact.
> My message that you replied to shows that it works for crypto container
> with dash in name.

Escaping it. I don’t accept that as “working”.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-07-01 16:38, Carlos E. R. wrote:
> On 2013-07-01 14:36, arvidjaar wrote:
>>
>> robin_listas;2568681 Wrote:
>>> it fails if there is a dash in the name. You are skipping
>>> commenting on this fact.
>> My message that you replied to shows that it works for crypto container
>> with dash in name.
>
> Escaping it. I don’t accept that as “working”.

yesterday night I stopped those services - it claimed success, but some
of the partitions were in use, were not disabled and got no error
message. Some of the partitions were not in use, they were umounted, but
the mapped encrypted device was not removed. I had to use dmsetup
directly to remove them.

Ie, I will have to create my own script to handle encripted partitions,
like the old systemv scripts, because systemd is not up to the task :frowning:


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-07-02 12:13, Carlos E. R. wrote:
> On 2013-07-01 16:38, Carlos E. R. wrote:

> yesterday night I stopped those services - it claimed success, but some
> of the partitions were in use, were not disabled and got no error
> message. Some of the partitions were not in use, they were umounted, but
> the mapped encrypted device was not removed. I had to use dmsetup
> directly to remove them.
>
> Ie, I will have to create my own script to handle encripted partitions,
> like the old systemv scripts, because systemd is not up to the task :frowning:

Proof was still in the terminal:


> Telcontar:~ # systemctl stop systemd-cryptsetup@cr_Aux_01
> Telcontar:~ # mount
> devtmpfs on /dev type devtmpfs (rw,relatime,size=4089500k,nr_inodes=1022375,mode=755)
> tmpfs on /dev/shm type tmpfs (rw,relatime)
....
> /dev/mapper/cr_Aux_01 on /data/aux_01 type xfs (rw,relatime,attr2,inode64,noquota)
> gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
> gvfsd-fuse on /var/run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
> Telcontar:~ # l /dev/mapper/cr_Aux_01
> lrwxrwxrwx 1 root root 7 Jun 30 19:43 /dev/mapper/cr_Aux_01 -> ../dm-3
> Telcontar:~ # umount /data/aux_01
> umount: /data/aux_01: target is busy.
>         (In some cases useful info about processes that use
>          the device is found by lsof(8) or fuser(1))
> Telcontar:~ # umount /data/aux_01
> Telcontar:~ # systemctl stop systemd-cryptsetup@cr_Aux_01
> Telcontar:~ # l /dev/mapper/cr_Aux_01
> lrwxrwxrwx 1 root root 7 Jun 30 19:43 /dev/mapper/cr_Aux_01 -> ../dm-3
> Telcontar:~ # l /dev/mapper/
> total 0
> drwxr-xr-x  2 root root     160 Jul  1 22:41 ./
> drwxr-xr-x 20 root root    7040 Jul  1 22:41 ../
> crw-------  1 root root 10, 236 Jun 24 11:43 control
> lrwxrwxrwx  1 root root       7 Jun 30 19:43 cr_Aux_01 -> ../dm-3
> lrwxrwxrwx  1 root root       7 Jun 24 14:55 cr_Datum -> ../dm-2
> lrwxrwxrwx  1 root root       7 Jun 24 11:44 cr_cripta -> ../dm-0
> lrwxrwxrwx  1 root root       7 Jun 24 14:55 cr_other -> ../dm-1
> lrwxrwxrwx  1 root root       7 Jun 30 19:49 crmm_Min_Rimmon -> ../dm-4
> Telcontar:~ # dmsetup remove crmm_Min_Rimmon
> Telcontar:~ # dmsetup remove cr_Aux_01
> Telcontar:~ # l /dev/mapper/
> total 0
> drwxr-xr-x  2 root root     120 Jul  2 03:13 ./
> drwxr-xr-x 20 root root    7000 Jul  2 03:13 ../
> crw-------  1 root root 10, 236 Jun 24 11:43 control
> lrwxrwxrwx  1 root root       7 Jun 24 14:55 cr_Datum -> ../dm-2
> lrwxrwxrwx  1 root root       7 Jun 24 11:44 cr_cripta -> ../dm-0
> lrwxrwxrwx  1 root root       7 Jun 24 14:55 cr_other -> ../dm-1
> Telcontar:~ #


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)