Bug 1762028
| Summary: | clevis-dracut sets rd.neednet=1 without obvious reason | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Dominik Holler <dholler> | ||||||
| Component: | clevis | Assignee: | Sergio Correia <scorreia> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Zelený <mzeleny> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 8.1 | CC: | barry.rhbugzilla, dapospis, mburman, mzeleny, rmetrich | ||||||
| Target Milestone: | rc | Keywords: | AutoVerified, Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | clevis-11-7.el8 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2020-04-28 15:37:11 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1760262 | ||||||||
| Attachments: |
|
||||||||
|
Description
Dominik Holler
2019-10-15 21:34:42 UTC
Please note that RHEL 7.7 is affected, too. Simple test will need to be created. AC: Installation of clevis-dracut package does not automatically add rd.neednet=1 to the dracut cmdline. Created attachment 1641038 [details]
Proposed patch to make clevis-dracut add rd.neednet=1 only when there are tang devices bound
I think I am being affected by this bug on RHEL 8.0 One caveat though is I am bound to both tang server and have a password bound as well. (The desired configuration is to boot automatically if tang is present, otherwise use password to boot). However we have noticed that if network is not present then boot hangs after accepting password. Eventually it drops us into dracut shell where we only need to exit the dracut shell to continue to boot normally - but it is annoying. So my question is: In this configuration with both tang + password, what will the effects be of removing "rd.neednet=1"? Will the desired configuration above still work? (In reply to Barry from comment #6) > I think I am being affected by this bug on RHEL 8.0 > > One caveat though is I am bound to both tang server and have a password > bound as well. (The desired configuration is to boot automatically if tang > is present, otherwise use password to boot). However we have noticed that if > network is not present then boot hangs after accepting password. Eventually > it drops us into dracut shell where we only need to exit the dracut shell to > continue to boot normally - but it is annoying. > > So my question is: In this configuration with both tang + password, what > will the effects be of removing "rd.neednet=1"? Will the desired > configuration above still work? Hi Barry. We will not be removing rd.neednet=1. What happens is right now it's added unconditionally: if we have the clevis-dracut package installed and generate a new initramfs, dracut cmdline will contain rd.neednet=1, always. This may cause confusion in situations where people would not be expecting any such changes, considering they had not added any tang bindings, for instance. With the change available in clevis-11-7.el8, when generating the initramfs, we will check whether any of the devices is bound to tang; if we have any such devices, we will then add rd.neednet=1 as we did before. If no devices are bound to tang, we will not add rd.neednet to dracut cmdline. So your use case of having tang + a password will not see any changes. You may want to open a separate bug to track the issue you describe with the boot hanging after accepting the password. Many thanks for the clear explanation. I will open new issue for my specific case. *** Bug 1784079 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:1595 |