Disk lookup fails when WWN has vendor extension
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
curtin |
Fix Committed
|
Undecided
|
Olivier Gayot | ||
subiquity |
Fix Released
|
Undecided
|
Olivier Gayot |
Bug Description
We got multiple private reports of failed installs where curtin logs show the following pattern:
found candidate disks [set(), {'/dev/sda'}, {'/dev/sda'}]
An error occured handling 'disk-sda': ValueError - Failed to find storage volume id='disk-sda' config: {'ptable': 'gpt', 'serial': '12121212121212
When trying to look up the disk, the value of the wwn field (i.e., 0x123456789abcd
However, the wwn variable is not always initialized from the ID_WWN variable. If present, the ID_WWN_
source_keys = {
}
Example
-------
"ID_WWN": '0x123456789abc
"ID_WWN_
"ID_WWN_
Since present, the wwn variable gets initialized from ID_WWN_
Later on, we compare the wwn variable with ID_WWN and the lookup fails.
Related branches
- Server Team CI bot: Needs Fixing (continuous-integration)
- Dan Bungert: Approve
-
Diff: 42 lines (+19/-1)2 files modifiedcurtin/commands/block_meta.py (+2/-1)
tests/unittests/test_commands_block_meta.py (+17/-0)
- Dan Bungert: Approve
- Server Team CI bot: Approve (continuous-integration)
-
Diff: 42 lines (+19/-1)2 files modifiedcurtin/commands/block_meta.py (+2/-1)
tests/unittests/test_commands_block_meta.py (+17/-0)
Changed in curtin: | |
assignee: | nobody → Olivier Gayot (ogayot) |
Changed in subiquity: | |
assignee: | nobody → Olivier Gayot (ogayot) |
Changed in curtin: | |
status: | New → In Progress |
Changed in subiquity: | |
status: | New → In Progress |
Changed in curtin: | |
status: | In Progress → Fix Committed |
Changed in subiquity: | |
status: | In Progress → Fix Committed |
Changed in curtin: | |
status: | Fix Committed → Fix Released |
Changed in subiquity: | |
status: | Fix Committed → Fix Released |
Changed in curtin: | |
status: | Fix Released → Fix Committed |
Hello All,
We have downloaded the daily build image on April 05, 2023 and performed the installation on a Virtual machine hosted on Hyper-V server. The installation went through and we have now a successful installation process. We will also perform some tests on ESXI servers and assess that the problem is indeed fixed
If other people can test and confirm, would be nice
Thank you all for the quick action and providing the fix