Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

azure-init should not assume provisioning media is always at /dev/sr0 #66

Closed
anhvoms opened this issue Mar 20, 2024 · 2 comments · Fixed by #79
Closed

azure-init should not assume provisioning media is always at /dev/sr0 #66

anhvoms opened this issue Mar 20, 2024 · 2 comments · Fixed by #79
Assignees
@dongsupark
Labels
bug Something isn't working

Comments

@anhvoms
Copy link
Contributor

anhvoms commented Mar 20, 2024

Description

Currently azure-init assumes that /dev/sr0 location is where the provisioning iso will surface. While this is true many of the times, it's not always the case. For example, in FreeBSD it will be at /dev/cd0. In some special environment, it might show up as /dev/vda1

The right mechanism to find the device is to enumerate block devices and process all devices that have fstype of iso9660 and udf. Because /dev/sr0 will be the correct choice for > 99% of cases, we might default to /dev/sr0 and fall back to enumeration if /dev/sr0 isn't the right choice. See cloud-init handling of this issue for reference

Impact

azure-init won't be able to mount the provisioning iso if the iso isn't showing up at /dev/sr0

Expected behavior

azure-init should be able to find the provisioning iso in all Azure environments
@anhvoms anhvoms added the bug Something isn't working label Mar 20, 2024
@anhvoms anhvoms mentioned this issue Mar 27, 2024
Merged
@dongsupark dongsupark self-assigned this Apr 8, 2024
@dongsupark
Copy link
Collaborator

I am working on this issue.
To avoid running command line tools like blkid, I am trying to write a function that makes use of native Rust crates for getting devices list, like libparted.

@anhvoms
Copy link
Contributor Author

anhvoms commented Apr 9, 2024

@dongsupark
https://lib.rs/crates/block-utils

@dongsupark dongsupark mentioned this issue Apr 9, 2024
Merged
dongsupark added a commit that referenced this issue Apr 17, 2024
@dongsupark
libazureinit: get mounted CDROM device at runtime (#79)
dd6fef6 
Get mounted device name of CDROM at runtime, instead of hard-coding `/dev/sr0`.

Fixes #66

.github: Install libudev-dev package in the default Ubuntu runner, as it is needed by block-utils Rust crate.
.github: Fix syntax error in clippy-linting.yml, like "every step must define a `uses` or `run` key".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dongsupark dongsupark

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

libazureinit: get mounted CDROM device at runtime dongsupark/azure-init
2 participants
@dongsupark @anhvoms