Bug 1612131

Summary: dracut: infinite loop when using rd.neednet=1 unless there is a wired network interface with carrier signal present
Product: [Fedora] Fedora Reporter: Javier Martinez Canillas <fmartine>
Component: dracutAssignee: dracut-maint-list
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: dracut-maint-list, jonathan, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-12 11:16:33 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:

Description Javier Martinez Canillas 2018-08-03 14:30:04 UTC
Description of problem:

When adding the rd.neednet=1 parameter to the kernel command line on a system that either has no wired interface or an interface without its carrier signal present, dracut enters into an infinite loop caused by the /lib/dracut/hooks/initqueue/finished/wait-network.sh script.

Version-Release number of selected component (if applicable):

dracut-048-14.git20180726.fc28.x86_64

How reproducible:

Easy

Steps to Reproduce:
1. Generate a initramfs with the mentioned dracut version
2. Add the rd.neednet=1 parameter to the kernel command line
3. Boot a machine that doesn't have a wired network interface with its carrier signal present.

Actual results:

Dracut enters into an infinite loop and the system does not boot.

Expected results:

The system should always boot when adding rd.neednet=1 to the kernel command line parameters.

Additional info:

The regression was introduced by the following upstream commit:

https://github.com/dracutdevs/dracut/commit/f0094476fd8

Comment 1 Javier Martinez Canillas 2018-09-12 11:16:33 UTC

*** This bug has been marked as a duplicate of bug 1574413 ***