equinixmetal: Exclude weird devices from flatcar installation #364
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I think we forgot to destroy the device in one place. Instead of trying to remember to add the destruction in every fail case, just destroy the device by default and skip doing it only if everything succeeds.
I don't know if NVMe disks are a recent addition to s3.xlarge.x86 instances, or maybe those disks got shrunk, but the flatcar-install script was picking one of them to install flatcar on. For some reason, the boot agent is not able to boot from them, maybe there is some additional setup needed, which is missing. Fortunately the script already had an option of excluding devices by major numbers, so use this functionality. That way, the script installs the OS on one of `/dev/sdX` disks, which are bootable. For device majors see the kernel documentation at: https://www.kernel.org/doc/Documentation/admin-guide/devices.txt
|
CI is still running, but tests for s3.xlarge.x86 have already succeeded: http://jenkins.infra.kinvolk.io:8080/job/container/job/test/2168/ |
krnowak
force-pushed
the
krnowak/exclude-weird-devices
branch
from
c398f3b to
6be664e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
s3.xlarge.x86has some nvme disks attached, which have the smallest size in bytes from all the available disks. Since we are passing the-sflag toflatcar-install(so the scripts find the smallest disk to install flatcar), they get picked. For some reason, they can't be booted. The nvme devices have major 259, whereas other disks - 8.I had two ways of fixing the issue - either exclude 259, or include only 8. Went with the former.
During trying to find the fix I did some small cleanup.
The commit messages still need to be rewritten.
I also had a commit that drops fiddling with AlwaysPXE flag, and uses reinstall action instead. This might be something to consider, but it's certainly slower, since all the disks seem to be zeroed. So in case of
s3.xlarge.x86instance, the reinstallation caused the timeout to be triggered. Maybe something for follow-up PR.Fixes flatcar/Flatcar#834
changelog/directory (user-facing change, bug fix, security fix, update)