Tink Agent: filter out block devices with unknown controller type #321

kmullin · 2025-08-12T20:37:36Z

Description

while testing inside VMs, the auto-discovery feature of the tink-agent discovers disks /dev/ram{1..15} and /dev/nbd{0..15}. This change filters those out and prefers block devices which have a controllerType which isnt Loop or Unknown

This was found on HookOS 0.10.0-build-196.

Why is this needed

I'm unsure if all block devices are going to be discovered

Fixes: #

How Has This Been Tested?

At least in my lab, on VMs and limited hardware types, this still correctly detects block devices which have an actual vendor reported from the device, and does not add every single "block" device to spec.disks in the generated Hardware object.

~~The underlying ghw package reads from /sys/block/<dev>/device/vendor, and if the file doesn't exist will default to "unknown"~~ seen here.

I am fairly confident this is safe, but due to limited hardware availability, I'd love to get some feedback.

How are existing users impacted? What migration steps/scripts do we need?

Checklist:

I have:

updated the documentation and/or roadmap (if required)
added unit or e2e tests
provided instructions on how to upgrade

codecov · 2025-08-12T20:42:55Z

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 50.80%. Comparing base (c26c3ab) to head (568d934).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
tink/agent/internal/attribute/attribute.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #321      +/-   ##
==========================================
- Coverage   50.82%   50.80%   -0.03%     
==========================================
  Files         105      105              
  Lines        8807     8807              
==========================================
- Hits         4476     4474       -2     
- Misses       4068     4070       +2     
  Partials      263      263

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

jacobweinstock · 2025-08-13T23:37:37Z

tink/agent/internal/attribute/attribute.go

 	for _, d := range b.Disks {
-		if d == nil {
+		// XXX: inside a VM, we see /dev/ramXX and the underlying library seems to think its a BlockDevice
+		if d == nil || d.Vendor == "unknown" {


Hey @kmullin, thanks for this. We'll need a different approach here though. With this logic, the following devices would be excluded.

This is from a physical machine I have:

{ "name": "nvme0n1", "controllerType": "NVMe", "driveType": "SSD", "size": "239GB", "physicalBlockSize": "512B", "vendor": "unknown", "model": "KINGSTON OM8PDP3256B-A01" }

This is from a qemu VM I regularly use to test:

{ "controllerType": "NVMe", "driveType": "SSD", "model": "unknown", "name": "nvme0n1", "physicalBlockSize": "512B", "size": "10GB", "vendor": "unknown" },

Maybe one of the following options could be used.

if d == nil || strings.HasPrefix(d.Name, "nbd") || strings.HasPrefix(d.Name, "ram") { continue }

OR

if d.StorageController != block.STORAGE_CONTROLLER_LOOP && d.StorageController != block.STORAGE_CONTROLLER_UNKNOWN { ... }

I'm leaning toward the second one. What are your thoughts?

Here are 2 more entries from a Raspberry PI 5. The SD card and the NVMe drive show an unknown vendor.

{ "controllerType": "MMC", "driveType": "SSD", "model": "unknown", "name": "mmcblk0", "physicalBlockSize": "512B", "size": "29GB", "vendor": "unknown" }

{ "controllerType": "NVMe", "driveType": "SSD", "model": "unknown", "name": "nvme0n1", "physicalBlockSize": "512B", "size": "233GB", "vendor": "unknown" }

You're amazing! Thanks for double checking this. Yes I suppose my solution is not great.

I'll take a closer look at what you've proposed with the second option and test out on some other hardware too!

yeah I see that the controller type is basically set from device prefixes already: https://github.com/jaypipes/ghw/blob/e75a40d23a6cb2e7314ccedd4a20a2e92542332f/pkg/block/block_linux.go#L382-L420

So that is likely better than doing another prefix filtering.

I've also updated the references to use the non-deprecated versions of the same thing.

This appears to work in my testing environment the same way.

jacobweinstock

Thanks again for this!

mergify · 2025-08-15T04:28:58Z

This pull request has been removed from the queue for the following reason: pull request dequeued.

Pull request #321 has been dequeued. The pull request could not be merged. This could be related to an activated branch protection or ruleset rule that prevents us from merging. (details: Repository rule violations found

Commits must have verified signatures.

).

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.
If you do update this pull request, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

jacobweinstock · 2025-08-15T04:30:40Z

This pull request has been removed from the queue for the following reason: pull request dequeued.

Pull request #321 has been dequeued. The pull request could not be merged. This could be related to an activated branch protection or ruleset rule that prevents us from merging. (details: Repository rule violations found

Commits must have verified signatures.

).

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you do update this pull request, it will automatically be requeued once the queue conditions match again. If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

Hey @kmullin, apologies. Would you mind setting up the GitHub verified signatures?

while testing inside VMs, the auto-discovery feature of the tink-agent discovers disks /dev/ram{1..15} and /dev/nbd{0..15}. This change filters those out and prefers block devices which have a controllerType which isnt Loop or Unknown Signed-off-by: Kevin Mullin <[email protected]>

kmullin · 2025-08-15T16:35:59Z

Sure thing! I force pushed a signed commit. Sorry for the troubles.

jacobweinstock · 2025-08-15T17:05:56Z

Sure thing! I force pushed a signed commit. Sorry for the troubles.

No worries at all, thanks for doing it!

…nkerbell#321) ## Description while testing inside VMs, the auto-discovery feature of the tink-agent discovers disks /dev/ram{1..15} and /dev/nbd{0..15}. This change filters those out and prefers block devices which have a controllerType which isnt Loop or Unknown This was found on HookOS 0.10.0-build-196. ## Why is this needed I'm unsure if *all* block devices are going to be discovered Fixes: # ## How Has This Been Tested? At least in my lab, on VMs and limited hardware types, this still correctly detects block devices which have an actual vendor reported from the device, and does not add every single "block" device to `spec.disks` in the generated `Hardware` object. ~The underlying `ghw` package reads from `/sys/block/<dev>/device/vendor`, and if the file doesn't exist will default to `"unknown"`~ [seen here](https://github.com/jaypipes/ghw/blob/v0.17.0/pkg/block/block_linux.go#L82-L91). I am fairly confident this is safe, but due to limited hardware availability, I'd love to get some feedback. ## How are existing users impacted? What migration steps/scripts do we need? ## Checklist: I have: - [ ] updated the documentation and/or roadmap (if required) - [ ] added unit or e2e tests - [ ] provided instructions on how to upgrade

jacobweinstock added the tink-agent label Aug 13, 2025

jacobweinstock reviewed Aug 13, 2025

View reviewed changes

kmullin force-pushed the kmullin/block-device-filtering branch from 85f12cc to 7cc8b6c Compare August 15, 2025 04:11

kmullin changed the title ~~Tink Agent: filter out block devices with unknown vendor~~ Tink Agent: filter out block devices with unknown controller type Aug 15, 2025

jacobweinstock approved these changes Aug 15, 2025

View reviewed changes

jacobweinstock added the ready-to-merge Signal Mergify to merge the PR label Aug 15, 2025

kmullin force-pushed the kmullin/block-device-filtering branch from 7cc8b6c to 568d934 Compare August 15, 2025 16:35

jacobweinstock approved these changes Aug 15, 2025

View reviewed changes

mergify bot merged commit c7ede0c into tinkerbell:main Aug 15, 2025
11 checks passed

kmullin deleted the kmullin/block-device-filtering branch August 15, 2025 21:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Tink Agent: filter out block devices with unknown controller type #321

Tink Agent: filter out block devices with unknown controller type #321

Uh oh!

kmullin commented Aug 12, 2025 •

edited

Loading

Uh oh!

codecov bot commented Aug 12, 2025 •

edited

Loading

Uh oh!

jacobweinstock Aug 13, 2025 •

edited

Loading

Uh oh!

jacobweinstock Aug 14, 2025

Uh oh!

kmullin Aug 15, 2025

Uh oh!

kmullin Aug 15, 2025

Uh oh!

jacobweinstock left a comment

Uh oh!

mergify bot commented Aug 15, 2025

Uh oh!

jacobweinstock commented Aug 15, 2025

Uh oh!

kmullin commented Aug 15, 2025

Uh oh!

jacobweinstock commented Aug 15, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Tink Agent: filter out block devices with unknown controller type #321

Tink Agent: filter out block devices with unknown controller type #321

Uh oh!

Conversation

kmullin commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Why is this needed

How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:

Uh oh!

codecov bot commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jacobweinstock Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacobweinstock Aug 14, 2025

Choose a reason for hiding this comment

Uh oh!

kmullin Aug 15, 2025

Choose a reason for hiding this comment

Uh oh!

kmullin Aug 15, 2025

Choose a reason for hiding this comment

Uh oh!

jacobweinstock left a comment

Choose a reason for hiding this comment

Uh oh!

mergify bot commented Aug 15, 2025

Uh oh!

jacobweinstock commented Aug 15, 2025

Uh oh!

kmullin commented Aug 15, 2025

Uh oh!

jacobweinstock commented Aug 15, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kmullin commented Aug 12, 2025 •

edited

Loading

codecov bot commented Aug 12, 2025 •

edited

Loading

jacobweinstock Aug 13, 2025 •

edited

Loading