What QEMU Packages Need To Be Installed in BookwormPup?

[JusGellin]

What QEMU packages need to be installed on BookwormPup64 to make it work?
I've tried several I thought might work, but had no success.
I've done this with some standard packages for other Linux which didn't help here.
Thanks

[Clarity]

IIRC @Jasper has built and tested a v8+ QEMU for BKWP64.

And, IIRC @radky has a QEMU also. This was done because the OOTB package manager install was broken when trying to run it.

I, currently do not have a BKWP64 running ATM.

[Geek3579]

What QEMU packages need to be installed on BookwormPup64 to make it work?
I've tried several I thought might work, but had no success.
I've done this with some standard packages for other Linux which didn't help here.
Thanks

I had the same problem, and solved it by using a QEMU appimage. This was quite adequate, but then I got the idea to try apt after more research. I googled " installation of QEMU in Debian", and the following was suggested: sudo apt install qemu-utils qemu-system-x86 qemu-system-gui

This has worked flawlessly in Bookwormpup64 on both an intel and amd device, but dont forget to add modprobe kvm-intel or modprobe kvm-amd to the script, and update the audio switch to -device AC97.

EG
modprobe kvm-intel # start KVM
qemu-system-x86_64 -enable-kvm -m 4G -smp 4 -hda DebDogBull-LITE-Starter.img \
-cpu host -vga std -usb -device usb-tablet -device AC97

[dimkr]

Just install qemu-system-gui using Synaptic or apt.

[Clarity]

Hello @Geek3579

... but dont forget to add modprobe kvm-intel or modprobe kvm-amd to the script, and update the audio switch to -device AC97. ...

This was explained in this other QEMU post from @JusGellin. @norgo has made a utility, last year, that has NOT been picked up by WoofCE development to be incorporated into PUPs to satisfy this need automatically and correctly for the CPU type. Its a small script but simple and effective for KVM system need.

@dimkr as was suggested, the repo version of QEMU is broken. Have you had success in installation-use? @Jasper has built a QEMU v8 that I believe was tested with BKWP64. Is there a v8+ in the current repo that works?

[dimkr]

@dimkr as was suggested, the repo version of QEMU is broken.

If you're talking about the Debian Bookworm package of QEMU - I use it all the time with zero issues.

[Clarity]

If you're talking about the Debian Bookworm package of QEMU - I use it all the time with zero issues.

Sorry @dimkr, I was mistaken.

I thought you were exclusively running Vanilla V11. My misunderstanding of the base system you were running for your developments.

To revisit the problem installing QEMU on BKWP64 from its repo, I have to re-download @radky's latest v10... later!

[Geek3579]

@dimkr as was suggested, the repo version of QEMU is broken.

If you're talking about the Debian Bookworm package of QEMU - I use it all the time with zero issues.

Yes, and it is the package version 7.2

[dimkr]

Yes, and it is the package version 7.2

And it will stay at 7.2, it will only get occasional bug or security fixes. You'll get a newer QEMU version only in the next stable Debian release, 13 (Trixie).

[Clarity]

Should QEMU be built-in/included in each WoofCE PUP's DEVX?

You understand its benefit there.

[Geek3579]

Should QEMU be built-in/included in each WoofCE PUP's DEVX?

You understand its benefit there.

Well I'm not sure what the benefit is, as its quite easy to install using APT. You just have to know how.

BTW, Bookwormpup64 is a great platform on which to run QEMU due to its low resource usage.

[Clarity]

Almost every application/system developer uses a VM to test. DEVXs have components important to them. If its there, they DONT have to investigate, install, fix missing libs, etc ... you know the drill most of us have.

Developers want to just go to work in both building and testing, thus its presence is one less thing they have to do to accomplish work task where this is useful/needed.

It would just be present in their course of work...not an add-on.

So much is already done by distro builders for users. This is a idea. Having it in DEVX is merely an idea that I think would be helpful for many/most developers at all levels of development. Others might find its presence, there, a distraction???

[Clarity]

I launched BKWP64 ISO file via SG2D to its desktop to revisit the problem I reported last year. I hope to address 2 things to help. I am working using a pristine SBWP64 on an 8GB Intel i5 test desktop PC.

• To understand the "simplicity' or lack thereof that @dimkr alludes to.

• Why the idea of QEMU v8 started and was addressed by both @Jasper and @rockedge as complete solutions with addressing dependencies for this distro

Let's get started from installing, then using the terminal to boot an ISO file in a VM that runs as CPU speeds.

1. Install QEMU
   Synaptic is probably simple for most non-forum users

   

   Install QEMU from REPO

   Initial Synaptic QEMU install.png (108.68 KiB) Viewed 1368 times

2. Open a terminal to create and run a VM
   This is where, just the installation to be useable, takes on the needs that a user is knowledgible as error messages are going to surface. The following Terminal screen shows 5 cli commands addressing installation needs that any user will see when attempting to use QEMU In the screen.
   THEY are:

   1. first QEMU command use failure

   2. next QEMU command use failure

   3. Then failure again of missing BKWP64 system component

   4. Final at an operational QEMU within the system without issues

   

   What happens when a user tries to use QEMU

   problems getting a simple VM in BKWP64_small.jpg (83.57 KiB) Viewed 1368 times

   1. 1st QEMU command use shows problems: The user MUST go back to Synaptic to hunt for this

      

      Its here

      Synaptic QEMU Screenshot_small.jpg (55.15 KiB) Viewed 1368 times

   2. Next use shows additional problem: The user MUST get a tool from the forum to understand why

   3. Next the tool shows a missing system component: The user must hunt Google to find why

   4. next shows sucess when system component is added to BKWP64.

   5. Finally QEMU is useable. This QEMU command now boots BKWP64 to desktop in a VM

      Code: Select all

      qemu-system-x86_64 -enable-kvm -vga std -m 2G -smp 2 -device ac97 -name 'BKWP64 v1004 on QEMU' -cdrom BookwormPup64_10.0.4.iso

Conclusion
For those not comfortable with QEMU, just having these issues to get to the ability to start a VM could be addressed with some solution(s) equivalent to what @rockedge and @Jasper provided with an addition of 'qemu_ready' aded to their solutions, as well. QEMU for BKWP64 needs all of these.

It is desired to make the user experience smooth and simple with forum distro usage; no matter a developer or non-skilled user.

Hope this is helpful

[dimkr]

@Clarity If QEMU is part of devx, a user that wants gcc now needs to download a bigger devx that contains, in addition to many things other than gcc (like g++, gdb, ...), also QEMU. And users that want QEMU can't install QEMU alone and need to download the entire devx (with gcc, g++, gdb, ..., many things they don't want). Think about users with limited data plans, who prefer to download as little as possible.

In addition to the data plan argument, I think that only a tiny minority of users runs QEMU on Puppy, rather than running Puppy inside QEMU. People come to Puppy when they need a distro for old computers, many of which don't support VT-x or can't run a VM reasonably well, making the use case of running a VM on Puppy (probably) less common. People also use Puppy when they need a small Linux VM or want a "portable OS" that runs in a VM, but in this case, the host OS (= the OS that runs the VM inside QEMU) is unlikely to be Puppy. Most Puppy users that need devx probably don't use QEMU.

In my dpup builds, I intentionally don't provide devx, so users can specifically install the package they want, without having to download a 100 MB+ SFS. For every use case of devx, a subset of the packages in devx is enough, and this subset is smaller to download and easier to install through the package manager.

[rockedge]

In my dpup builds, I intentionally don't provide devx, so users can specifically install the package they want, without having to download a 100 MB+ SFS. For every use case of devx, a subset of the packages in devx is enough, and this subset is smaller to download and easier to install through the package manager.

We have the same reasoning with the KLV variants. It is far more versatile not having a devx and especially a devx with QEMU integrated.

[JusGellin]

I just noticed all the activity on my topic. I didn't realize it came over here. I'll look to study this more.
Anyway through much trial and error I was able to figure what I needed to get this working for me using apt install. I'm storing the QEMU guest on the hard drive:

1. apt update
2. apt upgrade
3. check lsmod | grep kvm
   If this doesn't give anything:
   a. modprobe kvm
   b. modprobe kvm_intel
4. apt install qemu-system-x86
5. Make my directories for the iso plus a directory to store the qcow2 file
6. apt install qemu-system-gui
7. apt install qemu-utils
8. Make qcow2 file to store the guest
9. Run qemu commands to bring up the guest

[Clarity]

... People come to Puppy when they need a distro for old computers, ...

You have thrown a lot in your view of my comments. Some of which I completely disagree.

But, we all have views, and I respect that.

As you might want to review my suggestion: It was about "DEVELOPERS". No inexperience or normal user has concerns for DEVX except those that are developers for the development tools within.

But, as you note, Vanillas (as does KLs) do not make DEVX facilities. Thus, none of what I commented on about DEVX would apply there.

For others, @Jasper has made a QEMU V8 installation PET for normal system use that he has tested.

[JusGellin]

Ok, I see.
I'm just so new to all of this and don't know my way around here yet. I just thought this was the right place to show what worked for me. That's all I meant. But I'm learning. I've really enjoyed all the activity and learning from all these forums. Also I really have appreciated all the help that I have received.
Thanks

[Geek3579]

On a slightly divergent note, QEMU can also be used to boot standalone HDDs, SSDs, and USBs by a slight change to the code. Much easier than in VirtualBox. In the script example below ( for a legacy installation ), the bootable media is on drive /dev/sdc

modprobe kvm-intel # start KVM
qemu-system-x86_64 -enable-kvm -m 4G \
-smp 4 -hda /dev/sdc \
-cpu host -vga std -usb -device usb-tablet -device AC97

I can even virtually boot a Windows 10 install on the same computer running Puppy Linux. But I would much rather use this technique to test out Linux USB installations. No need to use Windows now for any reason.

QEMU is an extremely useful tool that fits in well with Puppy Linux, and especially when apt is available, such as in BW64.

[OscarTalks]

In my dpup builds, I intentionally don't provide devx, so users can specifically install the package they want, without having to download a 100 MB+ SFS. For every use case of devx, a subset of the packages in devx is enough, and this subset is smaller to download and easier to install through the package manager.

I am strongly against the idea of deliberately not providing a devx and I sincerely hope it does not bleed through into a general Woof-CE policy with other Puppies that are built. The fundamental concept of it is that you load it when you are developing and then you have the easy option to unload it again when you are not developing, so worrying about the size of it when compared to the usefulness of having it available makes no sense to me. It should contain not only gcc and all the other programs needed for common development tasks, but also all the DEV libs which correspond to the list of built-in runtime shared libs. I will probably discuss this more in other threads because I don't want to hijack this one. I have no experience of QEMU so don't have much to offer in relation to installing it or whether it should be in the devx, but just wanted to chip in with my comment about the devx itself, since it was mentioned.