Open simondeziel opened 5 months ago
We've discovered #288 at the same time so maybe the 2 are connected somehow.
@tomponline hypothesized that /mnt
remained mounted in the microceph's snap (see https://github.com/canonical/lxd/pull/12793#discussion_r1475158229) which would explain nicely why doing the swapoff
/umount
before installing the snap would side-step the issue.
That would explain the mystery, Trent and I have had similar experiences with snap namespace. Thanks for the hint.
Issue report
With the reef release (
sudo snap install microceph --edge
), it seems that something is now trying to automatically scan for available block devices or something similar. This caused our CI to fail forcing us to install microceph from thequincy/edge
channel.What version of MicroCeph are you using ?
What are the steps to reproduce this issue ?
In a CI script executing on a GitHub action runner:
sudo snap install microceph --edge
sudo swapoff /mnt/swapfile
sudo umount /mnt
# umount the ephemeral disk of GitHub Action runnerhttps://github.com/canonical/lxd/actions/runs/7715565405/job/21030444998 shows it in action and the exact steps are https://github.com/canonical/lxd/actions/runs/7715565405/workflow#L282-L333
What happens (observed behaviour) ?
If microceph (
--edge
) snap is installed prior toswapoff
/umount
,wipefs
will fail on a busy device. Switching the order toswapoff
/umount
/wipefs
prior to installing the snap works without issue.What were you expecting to happen ?
The available block device shouldn't become unavailable/busy after installing the microceph snap.