blob: adce83aebbb8e10e4355d834ee54a2f7d79ea194 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm trying to figure out whether this qemu-img check issue is a user-mode or system-mode problem. Let me break it down.
The user is having trouble with the "qemu-img check" command not working on remote images in Ubuntu 19.10. It worked before with older versions of qemu-utils but now just hangs indefinitely. The image is hosted on an Apache server, and they can wget it without issues. So, the problem isn't accessing the image itself because wget works.
I know that user-mode issues usually involve problems within applications running under a normal user's privileges, not requiring kernel-level access or higher privileges. System-mode issues are more about how the system interacts with hardware, devices, or requires root privileges.
qemu-img is a tool used for disk image manipulation, and when it checks an image over HTTP, it might be dealing with network protocols, which can sometimes involve lower-level operations but often don't require kernel changes unless it's something like accessing raw block devices.
In this case, since the issue started after an upgrade to a new version of qemu-utils (which is part of userland tools), and the command just hangs without returning, it's likely a problem with how the application handles remote images now. Maybe there's a bug in how it processes HTTP requests or streams the image data.
Since the user can access the image via wget, network permissions aren't an issue. It's more about how qemu-img is processing the request. That makes me think it's a user-mode problem because it's specific to the application and not related to kernel-level operations like device drivers or system calls that require higher privileges.
I don't see any mention of needing special permissions or hardware interaction here, so it's probably not a system-mode issue.
</think>
user
|