QEMU seemingly not installed

[Seasoft]

I'm having a problem with QEMU where it doesn't appear to be installed despite seemingly having successfully installed it using apt. When I invoke qemu (variations "qemu-system-x86" and "qemu-system-i386" return the same) I get the "command not found". I tried doing "which qemu" and "which qemu-system-x86", but no paths are actually returned and it returns to prompt instead.

Could anyone enlighten me as to what might be happening?

[Seasoft]

I am using Ubuntu MATE 20.04 installed on Windows using VirtualBox.

[PeterX]

Type "qemu" at the (Ubuntu) commandline and then press the Tab-key to get autocompletion. This should give a list of qemu commands.

Each architecture has its own QEMU-command.

Greetings
Peter

[bzt]

Since you're using a deb based distro, do

Code: Select all

dpkg -l | grep qemu

If you can see any packages listed, then do

Code: Select all

dpkg-query -L (package)

to see what files it has installed. But should be under /usr/bin, or maybe /usr/local/bin, so try

Code: Select all

ls -l /usr/bin | grep qemu

This does not need the exact command name, like whereis and which. It could be qemu-system-x86_64 for example (it is on my machine, but I don't use Bugbuntu).

Cheers,
bzt

[Seasoft]

D'oh! It might just be "qemu-system-x86_64" instead because of my Ubuntu being 64-bit. But I overlooked that part.

[nexos]

Actually, the reason it is called qemu-system-x86_64 is because it is emulating a 64 bit machine. If you are making a 32 bit OS, you can use qemu-system-i386.

[eekee]

Yep, the name corresponds to the guest architecture, not the host.

You can get a list of the files installed from your package manager, either dpkg, apt, or some GUI. I used to have to do this all the time when Linux was newer and less standardized. There's a chance it's installed under /opt; some package maintainers get to thinking this is clever every now and then. If you override $PATH, or if you haven't rebooted/relogged/started new login shells since you installed it, it won't be in $PATH in your current shells. (This is something I found really irritating in POSIX.)

[Seasoft]

Okay, I did type "qemu-system-i386 -cdrom <iso file>" and it actually worked this time for some reason. I don't know what must have happened last time.

[eekee]

Okay, I did type "qemu-system-i386 -cdrom <iso file>" and it actually worked this time for some reason. I don't know what must have happened last time.

You started a new terminal emulator, then it worked. Or: you rebooted, then it worked. Am I right?

Edit: I forgot: The other possibility is bash was slow to update its path cache. You can get it to update with `hash -r`. (I thought this problem had got better, but you never know.)

[nexos]

Wait... Bash really caches the PATH? Why can't it just getenv("PATH") when it needs to use PATH? GNU is more strange then I already thought it was...

[nullplan]

If it is anything like zsh, then only the completion system caches the PATH, or rather, caches all available executables through PATH. It can't do that every time you hit <TAB>, because that would take a lot of time (under some circumstances). If they did use that cache to find commands, and didn't automatically return to the old uncached way of doing things on cache miss, then that would indeed be a very weak showing.

[eekee]

@nullplan: Good point. I'm pretty sure bash had exactly that weakness at some point in the past, but it got better.

My other point, about old shells not getting updated values of PATH, still stands. @nexos: It's worse than what you think. In Unix, each process has its own copy of the environment which is unaffected by changes made by other processes. getenv("PATH") won't help; each running shell needs to source a file containing the updated PATH or have it pasted into its input. "Environment" is really the wrong word; they're shell variables which child processes are granted copies of. This is one of the bigger reasons I don't want to write a Unix and why I no longer use either Unix or Plan 9. Plan 9 might seem better because it can (and even defaults to) sharing environment variables, but in practice it's worse: neither environment nor mount namespace are shared between different windows and every shell script which sets variables will pollute the environment if you're not careful.

[nexos]

Huh, Unix is a strange beast