Replies: 1 comment
-
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Bug
Body
I use GitHub Actions to test an Arch-based distribution installation by a workflow that creates a
.img
file by:and assign it to a loopback device to use it like a disk where to install the distro.
All time, by running:
in the GitHub-hosted runner, it correctly returned loopback device
/dev/loop3
and everything worked.Since today, the command
losetup
above returns/dev/loop0
that should be already in use by the system, and, indeed, when the workflow tries to run the distro install that creates the MSDOS-type partition table, it returns some errors and I guess because/dev/loop0
is generally intended for other use in the runner.Why since today, when I run
sudo losetup --find --partscan --show disk.img
it returns/dev/loop0
instead of giving me a really free loopback device (like/dev/loop3
)?The impacted GitHub Actions workflow is here under Create a raw disk image.
Beta Was this translation helpful? Give feedback.
All reactions