multipass
multipass copied to clipboard
canonical
`-bash: /usr/bin/df: Input/output error`
Describe the bug Unable to conduct filesystem operations
To Reproduce How, and what happened? In a VM (primary), df does not return a proper result.
Expected behavior df returns a current usage.
Logs Please provide logs from the daemon, see accessing logs on where to find them on your platform.
Additional info
- OS: macOS
- multipass 1.10.1+mac multipassd 1.10.1+mac
-
multipass info --all
State: Running
IPv4: 192.168.64.20
Release: Ubuntu 20.04.4 LTS
Image hash: 0f1a20bcda28 (Ubuntu 20.04 LTS)
Load: 0.00 0.00 0.00
Disk usage: --
Memory usage: --
Mounts: --
-
multipass get local.driver
Additional context Add any other context about the problem here.
Not this time
On Mon, Aug 1, 2022 at 19:28 Ricardo Abreu @.***> wrote:
Hi @ikitayama https://github.com/ikitayama, are you perhaps hitting disk space limits again?
— Reply to this email directly, view it on GitHub https://github.com/canonical/multipass/issues/2686#issuecomment-1201016229, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLBZ5WKJG2GLCPZ2MIDODVW6RGTANCNFSM55EL5LFQ . You are receiving this because you were mentioned.Message ID: @.***>
Hi @ikitayama, do you have any idea how this came about? Any logs we could look at? What makes you think this is a Multipass problem?
The multipass instance is quite fragile; terminal gets disappeared while using it etc
On Mon, Aug 1, 2022 at 19:42 Ricardo Abreu @.***> wrote:
Hi @ikitayama https://github.com/ikitayama, do you have any idea how this came about? Any logs we could look at? What makes you think this is a Multipass problem?
— Reply to this email directly, view it on GitHub https://github.com/canonical/multipass/issues/2686#issuecomment-1201029478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLBZ5AMI6M67DKMRAE5PDVW6S3FANCNFSM55EL5LFQ . You are receiving this because you were mentioned.Message ID: @.***>
Hi @ikitayama, do you have any idea how this came about? Any logs we could look at? What makes you think this is a Multipass problem?
Does multipass provide it's instances a tool to fix file system issues?
For now, I just fix the QEMU image manually by mounting it to another vm as you proposed there?
On Tue, Aug 2, 2022 at 19:26 Ricardo Abreu @.***> wrote:
No, not at the moment, but it is something that we're considering: #1910 https://github.com/canonical/multipass/issues/1910 .
— Reply to this email directly, view it on GitHub https://github.com/canonical/multipass/issues/2686#issuecomment-1202303018, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLBZ4HSHMSQ3U5UGQGVWLVXDZVZANCNFSM55EL5LFQ . You are receiving this because you were mentioned.Message ID: @.***>
Hi @ikitayama, yes, you could try to mount the image and see what you can recover inside. Have a look at /var/root/Library/Application\ Support/multipassd/{qemu/,}vault/instances for the image files.
@ricab In that directory, I've done converting it to raw, then converting back to qcow2 again.
sh-3.2# qemu-img check ubuntu-20.04-server-cloudimg-arm64.img
No errors were found on the image.
306976/2097152 = 14.64% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 20125450240
However, Ubuntu reports it is a read-only filesystem still.
The idea was to mount the image so that you could recover data from it.
Other than that, I don't know why the filesystem would go read-only. If you have any ideas of how to reproduce the issue or logs of when it happened, I can look into it.
Is Multipass implemented so that if there's no default image, .img file in that directory, delete all the other irrelevant files and create a new image file?
No @ikitayama, that image file contains the instance's data. Without it, the instance is gone. You can of course always create new instances with the same release.