Bug 949702 - Need appropriate timeout setting in /etc/crypttab
Need appropriate timeout setting in /etc/crypttab
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
All Linux
medium Severity medium
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-08 15:18 EDT by Stephen John Smoogen
Modified: 2013-05-15 23:01 EDT (History)
22 users (show)

See Also:
Fixed In Version: systemd-201-2.fc18.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 951261 (view as bug list)
Environment:
Last Closed: 2013-04-26 23:12:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stephen John Smoogen 2013-04-08 15:18:05 EDT
Description of problem:

In tracking down [Bug 949697] New: Dracut should not time out and fail waiting for LUKS decryption, Harald Hoyer said that part of the problem is that anaconda needs to set the appropriate flag on setting up the system.

anaconda should write "timeout=0" in /etc/crypttab for everything.

This is a tracker bug on getting that into the Fedora 19 anaconda.
Comment 1 Paul W. Frields 2013-04-08 15:22:58 EDT
Smooge means bug 868421 I think.
Comment 2 Stephen John Smoogen 2013-04-08 15:24:08 EDT
Yes bug 868421. I got cc'd on the other one and chose that number by mistake. My apologies.
Comment 3 David Lehman 2013-04-11 16:02:53 EDT
I changed my mind on this one. If they want a default of no timeout then that's a change that belongs in cryptsetup -- not anaconda or blivet. Feel free to try to convince me otherwise.
Comment 4 Paul W. Frields 2013-04-11 17:21:13 EDT
Moving the bug to cryptsetup...
Comment 5 Milan Broz 2013-04-12 01:40:15 EDT
cryptsetup itself has no timeout as default from the beginning.

But /etc/crypttab is now handled by systemd-cryptsetup unit generator.

So let's reassign it to the proper systemd intergalaxy space...
Comment 6 Harald Hoyer 2013-04-12 03:46:07 EDT
sent patch to the systemd-devel ML:
http://lists.freedesktop.org/archives/systemd-devel/2013-April/010363.html
Comment 7 Fedora Update System 2013-04-22 03:13:30 EDT
systemd-202-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/FEDORA-2013-6070/systemd-202-2.fc19
Comment 8 Fedora Update System 2013-04-24 09:09:25 EDT
systemd-202-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/systemd-202-3.fc19
Comment 9 Fedora Update System 2013-04-24 12:34:21 EDT
Package systemd-202-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-202-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6488/systemd-202-3.fc19
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2013-04-26 23:12:48 EDT
systemd-202-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2013-05-07 09:19:58 EDT
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Comment 12 Fedora Update System 2013-05-07 09:44:40 EDT
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Comment 13 Fedora Update System 2013-05-15 23:01:36 EDT
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.