initramfs clevis no carrier after 1s, no retry
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
clevis (Ubuntu) |
Fix Released
|
Undecided
|
dann frazier | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
dann frazier | ||
Groovy |
Fix Released
|
Undecided
|
dann frazier |
Bug Description
[Impact]
Several users have complained of issues with bringing up networking in the initramfs, which causes automatic LUKS volume unlocking via a network server to fail. The original report for this bug is one example, others can be found in the upstream bug:
https:/
The symptoms vary - see the commit message in [Fix] below for an enumerated list - but the general root cause is that we currently fail to wait for device enumeration to complete before trying to configure an interface.
[Test Case]
Boot a system with a slow-to-enumerate network device and confirm that the system is able to use it to automatically decrypt a LUKS root device.
[Fix]
https:/
[Regression Potential]
The biggest risk I see is if a user was somehow benefiting from some unknown side-effect of the existing behavior. The existing "eth_check()" code brings up each interface and checks for a carrier. The new code leaves it to configure_
Changed in clevis (Ubuntu Groovy): | |
status: | Confirmed → In Progress |
assignee: | nobody → dann frazier (dannf) |
Changed in clevis (Ubuntu Focal): | |
status: | New → Confirmed |
Changed in clevis (Ubuntu Bionic): | |
status: | New → Confirmed |
Changed in clevis (Ubuntu Focal): | |
status: | Confirmed → In Progress |
assignee: | nobody → dann frazier (dannf) |
description: | updated |
Status changed to 'Confirmed' because the bug affects multiple users.