why is external disk written to crypttab?
Hi, when booting I have a message a start ob is running for de-disk-by\... It takes one and half a minute until it gives up. After googling I found that this is because of an entry in crypttab for an encrypted disk that is not available at boot time. Actually it is a external back-up disk that I only mount when needed and then remove again. So I removed that entry from crypttab and next boot was fine, but because of some magic the entry in crypttab appeares again and the boot delay also happens again, of course. That external disk isn't in fstab. I just plug it, wait for the notifier to see it, click to attach it, enter the passphrase. Later I remove it with that same notifier. Why is an entry written to crypttab? Can I avoid that somehow? Thanks for hints. Daniel Opensuse 15.1, KDE, all updated to current -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer https://www.daniel-bauer.com
On 22/01/2021 11.41, Daniel Bauer wrote:
Hi,
when booting I have a message
a start ob is running for de-disk-by\...
It takes one and half a minute until it gives up.
After googling I found that this is because of an entry in crypttab for an encrypted disk that is not available at boot time. Actually it is a external back-up disk that I only mount when needed and then remove again.
So I removed that entry from crypttab and next boot was fine, but because of some magic the entry in crypttab appeares again and the boot delay also happens again, of course.
I have not noticed entries reappearing, but most if not all my external encrypted disks are listed there, manually. I think.
That external disk isn't in fstab. I just plug it, wait for the notifier to see it, click to attach it, enter the passphrase. Later I remove it with that same notifier.
Why is an entry written to crypttab? Can I avoid that somehow?
Maybe change some option to "noauto". :-? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-22 05:34:05 Carlos E.R. wrote:
|On 22/01/2021 11.41, Daniel Bauer wrote: |> Hi, |> |> when booting I have a message |> |> a start ob is running for de-disk-by\... |> |> It takes one and half a minute until it gives up. |> |> After googling I found that this is because of an entry in crypttab for |> an encrypted disk that is not available at boot time. Actually it is a |> external back-up disk that I only mount when needed and then remove again. |> |> So I removed that entry from crypttab and next boot was fine, but |> because of some magic the entry in crypttab appeares again and the boot |> delay also happens again, of course. | |I have not noticed entries reappearing, but most if not all my external |encrypted disks are listed there, manually. I think. | |> |> That external disk isn't in fstab. I just plug it, wait for the notifier |> to see it, click to attach it, enter the passphrase. Later I remove it |> with that same notifier. |> |> Why is an entry written to crypttab? Can I avoid that somehow? | |Maybe change some option to "noauto". :-? | I have an external drive with several encrypted partitions for backups, which cause this same delay, even though the entries in fstab include 'noauto'. There is no such option for crypttab. Perhaps something in the boot initrd is cleverly being 'helpful', à la Windows' Clippy.
Leslie --
On 22/01/2021 15.13, J Leslie Turriff wrote:
On 2021-01-22 05:34:05 Carlos E.R. wrote:
|On 22/01/2021 11.41, Daniel Bauer wrote:
...
|> Why is an entry written to crypttab? Can I avoid that somehow? | |Maybe change some option to "noauto". :-? | I have an external drive with several encrypted partitions for backups, which cause this same delay, even though the entries in fstab include 'noauto'. There is no such option for crypttab. Perhaps something in the boot initrd is cleverly being 'helpful', à la Windows' Clippy.
According to the man page, the settings do exist, but I also have problems with them: man crypttab The fourth field, if present, is a comma-delimited list of options. The following options are recognized: ... noauto This device will not be automatically unlocked on boot. nofail The system will not wait for the device to show up and be unlocked at boot, and not fail the boot if it does not show up. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-22 12:44:56 Carlos E. R. wrote:
|On 22/01/2021 15.13, J Leslie Turriff wrote: |> On 2021-01-22 05:34:05 Carlos E.R. wrote: |>> |On 22/01/2021 11.41, Daniel Bauer wrote: | |... | |>> |> Why is an entry written to crypttab? Can I avoid that somehow? |>> | |>> |Maybe change some option to "noauto". :-? |>> | |> I have an external drive with several encrypted partitions for backups, which cause this same delay, even though the entries in fstab include 'noauto'. There is no such option for crypttab. Perhaps something in the boot initrd is cleverly being 'helpful', à la Windows' Clippy. | |According to the man page, the settings do exist, but I also have |problems with them: | | |man crypttab | | The fourth field, if present, is a comma-delimited | list of options. The following options are | recognized: | |... | noauto | This device will not be automatically unlocked on boot. | nofail | The system will not wait for the device to show up and be |unlocked at boot, and not fail the boot if it does not show up. | | Ah, that's right. I remember now, that I tried that just like you did, but it doesn't work. Bug report time?
Leslie --
On 23/01/2021 01.12, J Leslie Turriff wrote:
On 2021-01-22 12:44:56 Carlos E. R. wrote:
|On 22/01/2021 15.13, J Leslie Turriff wrote: |> On 2021-01-22 05:34:05 Carlos E.R. wrote: |>> |On 22/01/2021 11.41, Daniel Bauer wrote: | |... | |>> |> Why is an entry written to crypttab? Can I avoid that somehow? |>> | |>> |Maybe change some option to "noauto". :-? |>> | |> I have an external drive with several encrypted partitions for backups, which cause this same delay, even though the entries in fstab include 'noauto'. There is no such option for crypttab. Perhaps something in the boot initrd is cleverly being 'helpful', à la Windows' Clippy. | |According to the man page, the settings do exist, but I also have |problems with them: | | |man crypttab | | The fourth field, if present, is a comma-delimited | list of options. The following options are | recognized: | |... | noauto | This device will not be automatically unlocked on boot. | nofail | The system will not wait for the device to show up and be |unlocked at boot, and not fail the boot if it does not show up. | | Ah, that's right. I remember now, that I tried that just like you did, but it doesn't work. Bug report time?
I'll have to check on next boot, because I changed one setting. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On sobota, 23 stycznia 2021 01:42:32 CET Carlos E. R. wrote:
On 23/01/2021 01.12, J Leslie Turriff wrote:
On 2021-01-22 12:44:56 Carlos E. R. wrote:
|On 22/01/2021 15.13, J Leslie Turriff wrote: |> On 2021-01-22 05:34:05 Carlos E.R. wrote: |>> |On 22/01/2021 11.41, Daniel Bauer wrote: |... | |>> |> Why is an entry written to crypttab? Can I avoid that somehow? |>> | |>> |Maybe change some option to "noauto". :-? |> |> I have an external drive with several encrypted partitions for |> backups, which cause this same delay, even though the entries in |> fstab include 'noauto'. There is no such option for crypttab. |> Perhaps something in the boot initrd is cleverly being 'helpful', à |> la Windows' Clippy.>> | |According to the man page, the settings do exist, but I also have |problems with them: | | |man crypttab | | The fourth field, if present, is a comma-delimited | list of options. The following options are | | recognized: |... | | noauto | | This device will not be automatically unlocked on boot. | | nofail | | The system will not wait for the device to show up and be | |unlocked at boot, and not fail the boot if it does not show up.
Ah, that's right. I remember now, that I tried that just like you did, but it doesn't work. Bug report time? I'll have to check on next boot, because I changed one setting.
Do you remember to rerun dracut after you mess with /etc/crypttab? Apparently some script assembles a crypttab used by the initramfs at that time and if you don't regenerate it, your changes won't be reflected at boot time. Regards Radosław Wyrzykowski
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <7eba6c6-55a6-fcc-9e80-9decfd69123d@Telcontar.valinor> On Monday, 2021-01-25 at 08:54 +0100, Radosław Wyrzykowski wrote:
On sobota, 23 stycznia 2021 01:42:32 CET Carlos E. R. wrote:
On 23/01/2021 01.12, J Leslie Turriff wrote:
On 2021-01-22 12:44:56 Carlos E. R. wrote:
...
Ah, that's right. I remember now, that I tried that just like you did, but it doesn't work. Bug report time? I'll have to check on next boot, because I changed one setting.
Do you remember to rerun dracut after you mess with /etc/crypttab? Apparently some script assembles a crypttab used by the initramfs at that time and if you don't regenerate it, your changes won't be reflected at boot time.
No, I forgot. The machine did reboot unintentionally, so I have a log just after my modification. - -- Reboot -- Jan 23 22:24:40 Isengard kernel: microcode: microcode updated early to revision 0x411, date = 2019-04-23 Jan 23 22:24:40 Isengard kernel: Linux version 5.3.18-lp152.60-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Tue Jan> Jan 23 22:24:40 Isengard kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.3.18-lp152.60-default root=UUID=0d457df1-b43d-4587-aa5a-6c919b> ... cryptography starts here: Jan 23 22:24:46 Isengard systemd[1]: Activating swap /dev/disk/by-label/Swap... Jan 23 22:24:46 Isengard systemd[1]: Starting File System Check on /dev/disk/by-uuid/BD39-068A... Jan 23 22:24:46 Isengard systemd[1]: Starting Cryptography Setup for cr_home... <========= Jan 23 22:24:46 Isengard kernel: Adding 9446396k swap on /dev/sda2. Priority:-2 extents:1 across:9446396k SSFS Jan 23 22:24:46 Isengard systemd[1]: Activated swap /dev/disk/by-label/Swap. Jan 23 22:24:46 Isengard systemd[1]: Reached target Swap. ... Jan 23 22:24:46 Isengard systemd[1]: Starting Restore /run/initramfs on shutdown... Jan 23 22:24:46 Isengard systemd[1]: Starting Early Kernel Boot Messages... Jan 23 22:24:46 Isengard systemd[1]: Started udev Wait for Complete Device Initialization. Jan 23 22:24:46 Isengard systemd[1]: Started Restore /run/initramfs on shutdown. ... Jan 23 22:24:57 Isengard kernel: logitech-hidpp-device 0003:046D:404D.0005: HID++ 4.1 device connected. I think here is when I typed the password, because there is a 10 seconds delay. Jan 23 22:25:07 Isengard systemd-cryptsetup[901]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/by-id/ata-KINGSTON_SMS...-part5. Jan 23 22:25:07 Isengard kernel: NET: Registered protocol family 38 Jan 23 22:25:08 Isengard systemd[1]: Found device /dev/mapper/cr_home. Jan 23 22:25:08 Isengard systemd[1]: Started Cryptography Setup for cr_home. Jan 23 22:25:08 Isengard systemd[1]: Starting File System Check on /dev/mapper/cr_home... Jan 23 22:25:08 Isengard systemd-fsck[987]: /sbin/fsck.xfs: XFS file system. Jan 23 22:25:08 Isengard systemd[1]: Started File System Check on /dev/mapper/cr_home. Jan 23 22:25:08 Isengard systemd[1]: Mounting /home... Jan 23 22:25:08 Isengard kernel: SGI XFS with ACLs, security attributes, no debug enabled Jan 23 22:25:08 Isengard kernel: XFS (dm-0): Mounting V5 Filesystem Jan 23 22:25:08 Isengard kernel: XFS (dm-0): Starting recovery (logdev: internal) Jan 23 22:25:08 Isengard kernel: XFS (dm-0): Ending recovery (logdev: internal) Jan 23 22:25:08 Isengard systemd[1]: Mounted /home. Jan 23 22:25:08 Isengard systemd[1]: Starting Cryptography Setup for cr_my_book... Jan 23 22:25:08 Isengard systemd[1]: Starting Cryptography Setup for cr_hoard_2... Jan 23 22:25:08 Isengard systemd[1]: Starting Cryptography Setup for cr_hoard_1... Those three do not need password. Jan 23 22:25:12 Isengard systemd[1]: Started Cryptography Setup for cr_hoard_1. Jan 23 22:25:12 Isengard systemd[1]: Reached target Local Encrypted Volumes. The problem disk appears mentioned first later: Jan 23 22:25:56 Isengard dbus-daemon[1102]: [system] Activating via systemd: service name='org.freedesktop.UDisks2' unit='udisks2.service' requested by ':1.27' (uid=479 pid=2348 comm="/usr/bin/sddm-greeter --socket /tmp/sddm-:0-znlgLC") Jan 23 22:25:56 Isengard systemd[1]: Starting Disk Manager... Jan 23 22:25:56 Isengard udisksd[2358]: udisks daemon version 2.8.1 starting Jan 23 22:25:56 Isengard udisksd[2358]: Can't load configuration file /etc/udisks2/udisks2.conf Jan 23 22:25:57 Isengard dbus-daemon[1102]: [system] Successfully activated service 'org.freedesktop.UDisks2' Jan 23 22:25:57 Isengard systemd[1]: Started Disk Manager. Jan 23 22:25:57 Isengard udisksd[2358]: Acquired the name org.freedesktop.UDisks2 on the system message bus Jan 23 22:25:57 Isengard dbus-daemon[1102]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service' requested by ':1.27' (uid=479 pid=2348 comm="/usr/bin/sddm-greeter --socket /tmp/sddm-:0-znlgLC") Jan 23 22:25:57 Isengard systemd[1]: Starting Daemon for power management... Jan 23 22:25:58 Isengard dbus-daemon[1102]: [system] Successfully activated service 'org.freedesktop.UPower' Jan 23 22:25:58 Isengard systemd[1]: Started Daemon for power management. Jan 23 22:26:02 Isengard nmbd[1994]: [2021/01/23 22:26:02.956931, 0] ../../source3/nmbd/nmbd_become_dmb.c:112(become_domain_master_stage2) Jan 23 22:26:02 Isengard nmbd[1994]: ***** Jan 23 22:26:02 Isengard nmbd[1994]: Jan 23 22:26:02 Isengard nmbd[1994]: Samba server ISENGARD is now a domain master browser for workgroup VALINOR on subnet 192.168.1.16 Jan 23 22:26:02 Isengard nmbd[1994]: Jan 23 22:26:02 Isengard nmbd[1994]: ***** Jan 23 22:26:08 Isengard sddm-greeter[2348]: Adding view for "HDMI3" QRect(0,0 1920x1080) As can be seen, the system is starting sddm, so this is much later than initramfs. Jan 23 22:26:09 Isengard sddm-greeter[2348]: QDBusConnection: name 'org.freedesktop.UDisks2' had owner '' but we thought it was ':1.28' Jan 23 22:26:09 Isengard sddm-greeter[2348]: Message received from daemon: Capabilities Jan 23 22:26:09 Isengard sddm-greeter[2348]: Message received from daemon: HostName Jan 23 22:26:09 Isengard sddm-greeter[2348]: Hunspell dictionary is missing for "en_GB" . Search paths ("/usr/share/qt5/qtvirtualkeyboard/hunspell", "/usr/share/hunspell", "/usr/share/myspell/dicts") This is the disk it wants, that is not connected: Jan 23 22:26:13 Isengard systemd[1]: dev-disk-by\x2dpartlabel-Telcontar_1.device: Job dev-disk-by\x2dpartlabel-Telcontar_1.device/start timed out. Jan 23 22:26:13 Isengard systemd[1]: Timed out waiting for device dev-disk-by\x2dpartlabel-Telcontar_1.device. Timeout waiting for the disk. I think that is the problem, it should just ignore the absence and continue booting: Jan 23 22:26:13 Isengard systemd[1]: Dependency failed for Cryptography Setup for cr_my_book_tlcntr. Jan 23 22:26:13 Isengard systemd[1]: Dependency failed for dev-mapper-cr_my_book_tlcntr.device. Jan 23 22:26:13 Isengard systemd[1]: Dependency failed for File System Check on /dev/mapper/cr_my_book_tlcntr. Jan 23 22:26:13 Isengard systemd[1]: Dependency failed for /mnt/BookTelcontar. Jan 23 22:26:13 Isengard systemd[1]: Dependency failed for NFS server and services. Jan 23 22:26:13 Isengard systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'. Jan 23 22:26:13 Isengard systemd[1]: mnt-BookTelcontar.mount: Job mnt-BookTelcontar.mount/start failed with result 'dependency'. Jan 23 22:26:13 Isengard systemd[1]: systemd-fsck@dev-mapper-cr_my_book_tlcntr.service: Job systemd-fsck@dev-mapper-cr_my_book_tlcntr.service/start failed with result 'dependency'. Jan 23 22:26:13 Isengard systemd[1]: dev-mapper-cr_my_book_tlcntr.device: Job dev-mapper-cr_my_book_tlcntr.device/start failed with result 'dependency'. Jan 23 22:26:13 Isengard systemd[1]: systemd-cryptsetup@cr_my_book_tlcntr.service: Job systemd-cryptsetup@cr_my_book_tlcntr.service/start failed with result 'dependency'. Jan 23 22:26:13 Isengard systemd[1]: dev-disk-by\x2dpartlabel-Telcontar_1.device: Job dev-disk-by\x2dpartlabel-Telcontar_1.device/start failed with result 'timeout'. Jan 23 22:26:13 Isengard systemd[1]: Starting Notify NFS peers of a restart... Jan 23 22:26:13 Isengard systemd[1]: Starting SuSEfirewall2 phase 2... Jan 23 22:26:13 Isengard sm-notify[2533]: Version 2.1.1 starting Jan 23 22:26:13 Isengard systemd[1]: Started Notify NFS peers of a restart. No mention in the entire log of autofs. It is not configured: Isengard:~ # cat /etc/autofs.conf | egrep -v "^[[:space:]]*$|^#" [ autofs ] timeout = 300 browse_mode = no [ amd ] dismount_interval = 300 Isengard:~ # /etc/crypttab: cr_home /dev/disk/by-id/ata-KINGSTON_SMS...-part5 none timeout=300,discard cr_my_book_tlcntr /dev/disk/by-partlabel/Telcontar_1 /home/keyfile noauto,nofail /etc/fstab: /dev/mapper/cr_home /home xfs lazytime,exec,nofail 1 2 /dev/mapper/cr_my_book_tlcntr /mnt/BookTelcontar btrfs lazytime,compress,nofail 1 3 As you can see, systemd automount is not involved, either. It is for nfs, and it works: telcontar.valinor:/data/storage_c/repositorios_zypp/ /var/cache/zypp/nfs_packages nfs noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=300,_netdev,nfsvers=4 0 0 man crypttab: The fourth field, if present, is a comma-delimited list of options. The following options are recognized: ... noauto This device will not be automatically unlocked on boot. nofail The system will not wait for the device to show up and be unlocked at boot, and not fail the boot if it does not show up. Well, it doesn't fail, but it does try. There was a noticiable small delay during boot, although I can't see it on the log, but I may have missed it. Maybe if there were a tool to scan the log and print one line per each different timescan, I could spot it. I can still try "noauto" in the fstab file, but I think I tried that months ago and did not work. Also, I think that, when the disk is connected, it prompts for the password, which it shouldn't. But that is another problem. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYA7C1xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVT8oAn2UgF5Nt6T6hGqqNHcy1 a4LPXAJwAJ4wgNCsJTbcn5XSrlgdNXmgApMjUA== =neLU -----END PGP SIGNATURE-----
On 2021-01-25 01:54:05 Radosław Wyrzykowski wrote:
|On sobota, 23 stycznia 2021 01:42:32 CET Carlos E. R. wrote: |> On 23/01/2021 01.12, J Leslie Turriff wrote: |> > On 2021-01-22 12:44:56 Carlos E. R. wrote: |> >> |On 22/01/2021 15.13, J Leslie Turriff wrote: |> >> |> On 2021-01-22 05:34:05 Carlos E.R. wrote: |> >> |>> |On 22/01/2021 11.41, Daniel Bauer wrote: |> >> |... |> >> | |> >> |>> |> Why is an entry written to crypttab? Can I avoid that somehow? |> >> |>> | |> >> |>> |Maybe change some option to "noauto". :-? |> >> |> |> >> |> I have an external drive with several encrypted partitions for |> >> |> backups, which cause this same delay, even though the entries in |> >> |> fstab include 'noauto'. There is no such option for crypttab. |> >> |> Perhaps something in the boot initrd is cleverly being 'helpful', à |> >> |> la Windows' Clippy.>> | |> >> |According to the man page, the settings do exist, but I also have |> >> |problems with them: |> >> | |> >> | |> >> |man crypttab |> >> | |> >> | The fourth field, if present, is a comma-delimited |> >> | list of options. The following options are |> >> | |> >> | recognized: |> >> |... |> >> | |> >> | noauto |> >> | |> >> | This device will not be automatically unlocked on boot. |> >> | |> >> | nofail |> >> | |> >> | The system will not wait for the device to show up and be |> >> | |> >> |unlocked at boot, and not fail the boot if it does not show up. |> > |> > Ah, that's right. I remember now, that I tried that just like you |did, |> > but it doesn't work. Bug report time? |> I'll have to check on next boot, because I changed one setting. | |Do you remember to rerun dracut after you mess with /etc/crypttab? Apparently |some script assembles a crypttab used by the initramfs at that time and if you |don't regenerate it, your changes won't be reflected at boot time. | |Regards |Radosław Wyrzykowski | Why would I remember to do that, when there is no mention of dracut in either crypttab or cryptsetup man files? I had never even heard of dracut until you asked. (And, in the dracut man file there is no mention of crypttab at all, either.)
Leslie --
On 26/01/2021 09.11, J Leslie Turriff wrote:
On 2021-01-25 01:54:05 Radosław Wyrzykowski wrote:
|On sobota, 23 stycznia 2021 01:42:32 CET Carlos E. R. wrote:
...
|Do you remember to rerun dracut after you mess with /etc/crypttab? Apparently |some script assembles a crypttab used by the initramfs at that time and if you |don't regenerate it, your changes won't be reflected at boot time.
Why would I remember to do that, when there is no mention of dracut in either crypttab or cryptsetup man files? I had never even heard of dracut until you asked. (And, in the dracut man file there is no mention of crypttab at all, either.)
On openSUSE you may run the old "mkinitrd", which in fact runs dracut with the proper options. Well, it is one of those administrivia and admin must know ;-) Dracut man page doesn't mention initrd, because after all, there are hundreds of configuration files it worries about, depending on each distribution setup. cryptab file might contain a reference to this. If the encrypted disk is "/", then the initrd or initramfs must know how to open it. That's why. In my case, my initrd file is dated "Jan 17 04:08". My machine booted on "Jan 23 22:24:40", so no, I did not run mkinitrd. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 2021-01-26 03:12:37 Carlos E. R. wrote:
|On 26/01/2021 09.11, J Leslie Turriff wrote: |> On 2021-01-25 01:54:05 Radosław Wyrzykowski wrote: |>> |On sobota, 23 stycznia 2021 01:42:32 CET Carlos E. R. wrote: | |... | |>> |Do you remember to rerun dracut after you mess with /etc/crypttab? Apparently |>> |some script assembles a crypttab used by the initramfs at that time and if you |>> |don't regenerate it, your changes won't be reflected at boot time. | |> Why would I remember to do that, when there is no mention of dracut in either crypttab or cryptsetup man files? I had never even heard of dracut until you asked. (And, in the dracut man file there is no mention of crypttab at all, either.) | |On openSUSE you may run the old "mkinitrd", which in fact runs dracut |with the proper options. | |Well, it is one of those administrivia and admin must know ;-) | And each of us who runs Linux for their own use is essentially its system administrator. If dracut and crypttab interact, their documentation ought to say so.
|Dracut man page doesn't mention initrd, because after all, there are |hundreds of configuration files it worries about, depending on each |distribution setup. | |cryptab file might contain a reference to this.
It does not.
| |If the encrypted disk is "/", then the initrd or initramfs must know how |to open it. That's why. | | |In my case, my initrd file is dated "Jan 17 04:08". My machine booted on |"Jan 23 22:24:40", so no, I did not run mkinitrd. |
Leslie --
On 26/01/2021 11.27, J Leslie Turriff wrote:
On 2021-01-26 03:12:37 Carlos E. R. wrote:
|On 26/01/2021 09.11, J Leslie Turriff wrote: |> On 2021-01-25 01:54:05 Radosław Wyrzykowski wrote: |>> |On sobota, 23 stycznia 2021 01:42:32 CET Carlos E. R. wrote: | |... | |>> |Do you remember to rerun dracut after you mess with /etc/crypttab? Apparently |>> |some script assembles a crypttab used by the initramfs at that time and if you |>> |don't regenerate it, your changes won't be reflected at boot time. | |> Why would I remember to do that, when there is no mention of dracut in either crypttab or cryptsetup man files? I had never even heard of dracut until you asked. (And, in the dracut man file there is no mention of crypttab at all, either.) | |On openSUSE you may run the old "mkinitrd", which in fact runs dracut |with the proper options. | |Well, it is one of those administrivia and admin must know ;-) | And each of us who runs Linux for their own use is essentially its system administrator. If dracut and crypttab interact, their documentation ought to say so.
Not directly. They interact because the distribution designers have configured them to interact, I understand. Not because of upstream. Or because dracut finds out, somehow, that crypttab must be included. I don't know exactly how dracut works, I have to make educated guesses.
|Dracut man page doesn't mention initrd,
crypttab (typo)
because after all, there are |hundreds of configuration files it worries about, depending on each |distribution setup. | |cryptab file might contain a reference to this.
It does not.
I know it doesn't :-) If you want the reference to be there, writeup a bugzilla asking for a comment to be added on the file ;-) -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On 2021-01-26 05:41:12 Carlos E. R. wrote:
|On 26/01/2021 11.27, J Leslie Turriff wrote: |> On 2021-01-26 03:12:37 Carlos E. R. wrote: |>> |On 26/01/2021 09.11, J Leslie Turriff wrote: |>> |> On 2021-01-25 01:54:05 Radosław Wyrzykowski wrote: |>> |>> |On sobota, 23 stycznia 2021 01:42:32 CET Carlos E. R. wrote: |>> | |>> |... |>> | |>> |>> |Do you remember to rerun dracut after you mess with /etc/crypttab? Apparently |>> |>> |some script assembles a crypttab used by the initramfs at that time and if you |>> |>> |don't regenerate it, your changes won't be reflected at boot time. |>> | |>> |> Why would I remember to do that, when there is no mention of dracut in either crypttab or cryptsetup man files? I had never even heard of dracut until you asked. (And, in the dracut man file there is no mention of crypttab at all, either.) |>> | |>> |On openSUSE you may run the old "mkinitrd", which in fact runs dracut |>> |with the proper options. |>> | |>> |Well, it is one of those administrivia and admin must know ;-) |>> | |> And each of us who runs Linux for their own use is essentially its system administrator. If dracut and crypttab interact, their documentation ought to say so. | |Not directly. | |They interact because the distribution designers have configured them to |interact, I understand. Not because of upstream. | |Or because dracut finds out, somehow, that crypttab must be included. | |I don't know exactly how dracut works, I have to make educated guesses. | | |>> |Dracut man page doesn't mention initrd, | |crypttab (typo) | |>> because after all, there are |>> |hundreds of configuration files it worries about, depending on each |>> |distribution setup. |>> | |>> |cryptab file might contain a reference to this. |> |> It does not. | |I know it doesn't :-) | |If you want the reference to be there, writeup a bugzilla asking for a |comment to be added on the file ;-) | Yes, I think I will.
Leslie --
Am 23.01.21 um 01:12 schrieb J Leslie Turriff:
On 2021-01-22 12:44:56 Carlos E. R. wrote:
|On 22/01/2021 15.13, J Leslie Turriff wrote: |> On 2021-01-22 05:34:05 Carlos E.R. wrote: |>> |On 22/01/2021 11.41, Daniel Bauer wrote: | |... | |>> |> Why is an entry written to crypttab? Can I avoid that somehow? |>> | |>> |Maybe change some option to "noauto". :-? |>> | |> I have an external drive with several encrypted partitions for backups, which cause this same delay, even though the entries in fstab include 'noauto'. There is no such option for crypttab. Perhaps something in the boot initrd is cleverly being 'helpful', à la Windows' Clippy. | |According to the man page, the settings do exist, but I also have |problems with them: | | |man crypttab | | The fourth field, if present, is a comma-delimited | list of options. The following options are | recognized: | |... | noauto | This device will not be automatically unlocked on boot. | nofail | The system will not wait for the device to show up and be |unlocked at boot, and not fail the boot if it does not show up. | | Ah, that's right. I remember now, that I tried that just like you did, but it doesn't work. Bug report time?
Leslie
I added noauto to that entry in crypttab. No difference. My computer insists on waiting 1 minute and 30 seconds at boot. On bigbrother I found: https://bugzilla.redhat.com/show_bug.cgi?id=1524759 The last entry says: "To prevent that device from being unlocked automatically, you also need to disable the mount unit." But I have no idea what this could mean :-) a detail: I use several eternal USB-disks, all encrypted the same way, but this happens with only one of them (a WD_Elements). The only difference between those external disks is that this one is one with external power supply, while the others are connected only with USB. -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer https://www.daniel-bauer.com
On 23/01/2021 12.01, Daniel Bauer wrote:
Am 23.01.21 um 01:12 schrieb J Leslie Turriff:
On 2021-01-22 12:44:56 Carlos E. R. wrote:
|On 22/01/2021 15.13, J Leslie Turriff wrote: |> On 2021-01-22 05:34:05 Carlos E.R. wrote: |>> |On 22/01/2021 11.41, Daniel Bauer wrote:
|According to the man page, the settings do exist, but I also have |problems with them: ... Ah, that's right. I remember now, that I tried that just like you did, but it doesn't work. Bug report time?
I added noauto to that entry in crypttab. No difference. My computer insists on waiting 1 minute and 30 seconds at boot.
Should be both noauto and nofail.
On bigbrother I found: https://bugzilla.redhat.com/show_bug.cgi?id=1524759
The last entry says: "To prevent that device from being unlocked automatically, you also need to disable the mount unit." But I have no idea what this could mean :-)
Huh. Systemd, I fear. Do: systemctl status mnt-[tab][tab] and you should see them. Huh, no, I don't see mine. I see one, the one that fails. Isengard:/etc/systemd/system # systemctl status mnt- mnt-BookTelcontar.mount mnt-Moria.mount Isengard:/etc/systemd/system # The second one I don't know what it is. You can "cat", maybe "edit"... I have never tried to edit them, I think they are generated on the fly, so perhaps an override unit. Someone may know. Isengard:/etc/systemd/system # systemctl cat mnt-BookTelcontar.mount # /run/systemd/generator/mnt-BookTelcontar.mount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Requires=systemd-fsck@dev-mapper-cr_my_book_tlcntr.service After=systemd-fsck@dev-mapper-cr_my_book_tlcntr.service [Mount] Where=/mnt/BookTelcontar What=/dev/mapper/cr_my_book_tlcntr Type=btrfs Options=lazytime,compress,nofail Isengard:/etc/systemd/system # "edit" creates an override file directly, but I don't know what to add. I can't try, my disk is currently connected, I have another problem to handle first (automatic password failing).
a detail: I use several eternal USB-disks, all encrypted the same way, but this happens with only one of them (a WD_Elements). The only difference between those external disks is that this one is one with external power supply, while the others are connected only with USB.
No idea how that could matter. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 1/23/21 5:01 AM, Daniel Bauer wrote:
I added noauto to that entry in crypttab. No difference. My computer insists on waiting 1 minute and 30 seconds at boot.
On bigbrother I found: https://bugzilla.redhat.com/show_bug.cgi?id=1524759
The last entry says: "To prevent that device from being unlocked automatically, you also need to disable the mount unit." But I have no idea what this could mean :-)
a detail: I use several eternal USB-disks, all encrypted the same way, but this happens with only one of them (a WD_Elements). The only difference between those external disks is that this one is one with external power supply, while the others are connected only with USB.
I'm not sure if this is relevant to your issue, but there are a long of mount timeouts listed in /etc/sysconfig/autofs -- David C. Rankin, J.D.,P.E.
That must be platform-dependent. Here's what I see in my OpenSuSE Leap 15.2: | ## Path: System/File systems/Autofs | ## Description: Options that will be used when the daemon is started. | ## Type: string | ## Default: "" | ## ServiceReload: autofs | # | AUTOFS_OPTIONS="" | | ## Description: Use AutoFS miscellaneous device (/dev/autofs). | ## Type: string | ## Default: "yes" | # | # Determine whether the AutoFS misc device (/dev/autofs) will be used | # for routing ioctl commands. Requires kernel support (2.6.28 and newer). | USE_MISC_DEVICE="yes" | Leslie On 2021-01-24 03:02:18 David C. Rankin wrote:
|On 1/23/21 5:01 AM, Daniel Bauer wrote: |> I added noauto to that entry in crypttab. No difference. My computer insists |> on waiting 1 minute and 30 seconds at boot. |> |> On bigbrother I found: |> https://bugzilla.redhat.com/show_bug.cgi?id=1524759 |> |> The last entry says: |> "To prevent that device from being unlocked automatically, you also need to |> disable the mount unit." |> But I have no idea what this could mean :-) |> |> a detail: |> I use several eternal USB-disks, all encrypted the same way, but this happens |> with only one of them (a WD_Elements). The only difference between those |> external disks is that this one is one with external power supply, while the |> others are connected only with USB. |> | |I'm not sure if this is relevant to your issue, but there are a long of mount |timeouts listed in /etc/sysconfig/autofs |
--
On 24/01/2021 10.02, David C. Rankin wrote:
On 1/23/21 5:01 AM, Daniel Bauer wrote:
I added noauto to that entry in crypttab. No difference. My computer insists on waiting 1 minute and 30 seconds at boot.
On bigbrother I found: https://bugzilla.redhat.com/show_bug.cgi?id=1524759
The last entry says: "To prevent that device from being unlocked automatically, you also need to disable the mount unit." But I have no idea what this could mean :-)
a detail: I use several eternal USB-disks, all encrypted the same way, but this happens with only one of them (a WD_Elements). The only difference between those external disks is that this one is one with external power supply, while the others are connected only with USB.
I'm not sure if this is relevant to your issue, but there are a long of mount timeouts listed in /etc/sysconfig/autofs
No, autofs is not related to the mounting of external devices, that is systemd. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [01-24-21 14:53]:
On 24/01/2021 10.02, David C. Rankin wrote:
On 1/23/21 5:01 AM, Daniel Bauer wrote:
I added noauto to that entry in crypttab. No difference. My computer insists on waiting 1 minute and 30 seconds at boot.
On bigbrother I found: https://bugzilla.redhat.com/show_bug.cgi?id=1524759
The last entry says: "To prevent that device from being unlocked automatically, you also need to disable the mount unit." But I have no idea what this could mean :-)
a detail: I use several eternal USB-disks, all encrypted the same way, but this happens with only one of them (a WD_Elements). The only difference between those external disks is that this one is one with external power supply, while the others are connected only with USB.
I'm not sure if this is relevant to your issue, but there are a long of mount timeouts listed in /etc/sysconfig/autofs
No, autofs is not related to the mounting of external devices, that is systemd.
no autofs has been around, automount is part of systemd. note: cc'ing this post as my censorship has recently taken >26 hours to pass muster. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
On 24/01/2021 21.01, Patrick Shanahan wrote:
* Carlos E. R. <> [01-24-21 14:53]:
On 24/01/2021 10.02, David C. Rankin wrote:
On 1/23/21 5:01 AM, Daniel Bauer wrote:
I added noauto to that entry in crypttab. No difference. My computer insists on waiting 1 minute and 30 seconds at boot.
On bigbrother I found: https://bugzilla.redhat.com/show_bug.cgi?id=1524759
The last entry says: "To prevent that device from being unlocked automatically, you also need to disable the mount unit." But I have no idea what this could mean :-)
a detail: I use several eternal USB-disks, all encrypted the same way, but this happens with only one of them (a WD_Elements). The only difference between those external disks is that this one is one with external power supply, while the others are connected only with USB.
I'm not sure if this is relevant to your issue, but there are a long of mount timeouts listed in /etc/sysconfig/autofs
No, autofs is not related to the mounting of external devices, that is systemd.
no autofs has been around, automount is part of systemd.
Er... no. There are two methods: one is old, called autofs; another is an automount internal to systemd, and is recent. Both most be explicitly configured and activated, and neither apply to the case of Daniel. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 25/01/2021 06.21, Andrei Borzenkov wrote:
24.01.2021 22:50, Carlos E. R. пишет:
No, autofs is not related to the mounting of external devices, that is systemd.
You are hopelessly confusing kernel module and user space.
As far as I know, the kernel is not responsible for triggering the mount of this disk automatically, that's the job of userspace. Also as far as I know, Daniel is not using neither autofs nor systemd automout on this disk, at least intentionally. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
participants (8)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Daniel Bauer -
David C. Rankin -
J Leslie Turriff -
Patrick Shanahan -
Radosław Wyrzykowski