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

destroy_virtual_hardware.sh could fail more cleanly when the stack hasn't been uninstalled #1213

Closed
davepacheco opened this issue Jun 15, 2022 · 1 comment
Closed

destroy_virtual_hardware.sh could fail more cleanly when the stack hasn't been uninstalled #1213

davepacheco opened this issue Jun 15, 2022 · 1 comment

Comments

@davepacheco
Copy link
Collaborator

As I understand it:

  • create_virtual_hardware.sh and destroy_virtual_hardware.sh create and destroy devices that make an ordinary system look more like a Gimlet for Omicron.
  • Omicron itself creates other devices that depend on these devices. These dependencies prevent the lower-level devices from being destroyed. Concretely, destroy_virtual_hardware.sh fails if Omicron hasn't been uninstalled -- see omicron-package uninstall leaves a bunch of networking stuff around #1212.
  • The intended invariants are:
    • Omicron only runs after a successful call to create_virtual_hardware.sh and before a call to destroy_virtual_hardware.sh, such that Omicron can always assume these devices are around
    • destroy_virtual_hardware.sh assumes that Omicron has been uninstalled.

If you don't already know the specific devices created by each step and how they depend on each other, then if you get this wrong (or just run into #1212), it's hard to figure out what's wrong. It'd be nice if destroy_virtual_hardware.sh could check its own preconditions (i.e., that Omicron has been uninstalled) or else produce a clearer error message when it fails because Omicron hasn't been uninstalled. Maybe if it gets "device busy" from dladm, it could prompt the user with something like "have you uninstalled Omicron?" [and maybe "see also issue #1212"]
@bnaecker bnaecker mentioned this issue Jul 5, 2022
Merged
@bnaecker
Copy link
Collaborator

bnaecker commented Jul 8, 2022

Resolved by #1352

@bnaecker bnaecker closed this as completed Jul 8, 2022
@leftwo leftwo mentioned this issue Mar 29, 2024
Merged
leftwo added a commit that referenced this issue Mar 29, 2024
@leftwo
Update Propolis and Crucible (#5352)
04be445 
Propolis changes:
Add `IntrPin::import_state` and migrate LPC UART pin states (#669)
Attempt to set WCE for raw file backends
Fix clippy/lint nits for rust 1.77.0

Crucible changes:
Correctly (and robustly) count bytes (#1237)
test-replay.sh fix name of DTrace script (#1235)
BlockReq -> BlockOp (#1234)
Simplify `BlockReq` (#1218)
DTrace, cmon, cleanup, retry downstairs connections at 10 seconds.
(#1231)
Remove `MAX_ACTIVE_COUNT` flow control system (#1217)

Crucible changes that were in Omicron but not in Propolis before this commit.
Return *410 Gone* if volume is inactive (#1232)
Update Rust crate opentelemetry to 0.22.0 (#1224)
Update Rust crate base64 to 0.22.0 (#1222)
Update Rust crate async-recursion to 1.1.0 (#1221)
Minor cleanups to extent implementations (#1230)
Update Rust crate http to 0.2.12 (#1220)
Update Rust crate reedline to 0.30.0 (#1227)
Update Rust crate rayon to 1.9.0 (#1226)
Update Rust crate nix to 0.28 (#1223)
Update Rust crate async-trait to 0.1.78 (#1219)
Various buffer optimizations (#1211)
Add low-level test for message encoding (#1214)
Don't let df failures ruin the buildomat tests (#1213)
Activate the NBD server's psuedo file (#1209)

---------

Co-authored-by: Alan Hanson <alan@oxide.computer>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@davepacheco @bnaecker