Puppy Linux Discussion Forum

For some better testing platforms I compiled the very latest QEMU-8.0.0-rc3 which when queried reports it is version 7.2.93

I compiled and built this QEMU with many features enabled to better test Kennel Linux's and new Puppy Linux distro's.

Considering making a PET for F96-CE+ after first test show it boots a KLV and has a working network, so if anyone wants a copy or a PET of it I can prepare a package. Uncompressed the entire package is like 3+ gigabytes so maybe a lighter version can be built with some of the more exotic QEMU systems removed for a PET.

I am just getting to the build a package out of it and still experimenting with it.

So in a nut shell there is a latest greatest version of QEMU compiled on a F96-CE_4 that can be shared here
The full version PET is 643 mb so I trimmed the package down to 128 mb. The version has x86_64, i386, ARM and ARRCH qemu-system binaries.

Tested on the command line with:

/usr/local/bin/qemu-system-x86_64  -smp 4 -device ac97 -machine accel=kvm -m 4096 -cdrom "/mnt/home/KLV-Airedale-rc16.iso" -hda "/root/.aqemu/KLV_Airedale_rc14_HDA.img"  -boot once=d,menu=off -net nic -net user -rtc base=localtime -name "KLV-Airedale-rc16" -vnc 192.168.254.13:0 -cpu host $*

Download qemu-8.0.0_rc3.pet 33 mb

Needs to be tested on a fresh installation of a F96-CE or newer Fossapup64's. The QEMU-7.2.93 (8.0.0_rc3) is compiled and packaged on F96-CE_4

AS I understand that this is designed for F96, I did test on my FossaPUP64 that I run constantly.

I got this result:

root# qemu-system-x86_64 --version
QEMU emulator version 7.1.50 (v7.1.0-1-g93fac696d2)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
root# echo "Un-install this version and install v8RC3"
Un-install this version and install v8RC3
root# sync;sync
root# echo "Test the new v8 installed via PET"
Test the new v8 installed via PET
root# qemu-system-x86_64 --version
bash: /usr/bin/qemu-system-x86_64: No such file or directory
root# echo "v8 PET has issues. Revert back to prior release"
v8 PET has issues. Revert back to prior release
root# sync;sync
root# echo "Test the prior version installed via its PET"
Test the prior version installed via its PET
root# qemu-system-x86_64 --version
QEMU emulator version 7.1.50 (v7.1.0-1-g93fac696d2)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
root#

This is NOT a request for fixing it for older distro version(s). I expect to update this FossaPUP64 which I have been using since it original release...to F96CE

Merely FYI

@Clarity I compiled QEMU 8.0.0-rc3 which shows as version 7.2.93. I am using it /usr/local/bin and have a version 5 in /usr/bin running on a F96-CE_4 together. I compiled this QEMU 8 with GTK support enabled.

rockedge wrote: ↑Fri Apr 07, 2023 4:09 pm

Download qemu-8.0.0_rc3.pet 128 mb

The pet is too large (128 and unpacked almost 800 M). Make strip. In this case, unpack the pet, then go to /usr/local/bin/ and then run the strip command. And then reassemble the pet.
Here it is ready to use:

strip qemu-x86_64 qemu-system-x86_64 qemu-system-i386 qemu-system-arm qemu-system-aarch64 qemu-storage-daemon qemu-img qemu-i386 qemu-arm qemu-aarch64 elf2dmp

And now we compare :

@Grey I stripped the build and repackaged the PET at 33 MiB which is ready for download.

I will keep the full version with the debug headers saved somewhere but I will probably compile a newer version 8 when it's a stable release.

rockedge wrote: ↑Wed May 10, 2023 10:47 pm

stable release.

Such soft as Qemu is probably better to compile and make a pet only for the stable version. An emulator of some game console like the NES, for example, can be done at any stage, it's not particularly critical there.

I remember, when compiling Qemu from Git, a dilemma arises. Or compile a stable one from the source archive, but then there will be no dependencies. Or a fresh one with recursive attraction of dependencies. But in the second case, the version numbers will be different and there may be some kind of rc3-XXX, which is undesirable.

I suppose you still need to download the ISO to test it? Would it be possible to test a distribution from a cloud server (or other dedicated server) without having to download the full iso?

@amethyst It's not a full ISO!

QEMU-8.0.0-rc3.pet is a 33 megabyte PET package.

I compiled the build on a F96-CE_4 but it can possibly work on other platforms.

rockedge wrote: ↑Thu May 11, 2023 2:27 am

@amethyst It's not a full ISO! But a 33 megabyte PET package.

I compiled the build on a F96-CE_4 but it can possibly work on other platforms.

Yes but that is not what I'm talking about. You still need to download the distribution ISO to test it with QEMU?

@amethyst oh now I think I know what you mean. I use ISO's that are locally available. I don't know for sure if it would be possible to run a OS that has it's root_fs on a cloud server. Interesting scenario for sure though

amethyst wrote: ↑Thu May 11, 2023 2:21 am

from a cloud server (or other dedicated server) without having to download the full iso?

As the French say... Monsieur knows a lot about perversions

If you are running an OS like one from the forum in your Cloud, It behaves the same way as if you have your local forum distro running on a PC. You, then install a QEMU package on your distro, local/cloud, and you can run as many VMs as you choose on the running OS (cloud/local).

This may not be what @amethyst is seeking, but the package should behave the same within the OS no matter if a local or cloud OS the user is running.This, of course, is true if one can install a package on the running distro..

I saw this thread and read that @Grey suggested it could be stripped before being packaged.

I have stripped the binaries and also looked to do so for the libs (none).

There is not much of a saving

If you want the repacked pet file provided by @rockedge

If you only wanted a smaller application and did not want the ability to provide an environment for other hardware environments.

I guess the some of these binaries could be removed and then repacked?

rockedge wrote: ↑Thu May 11, 2023 2:36 am

@amethyst oh now I think I know what you mean. I use ISO's that are locally available. I don't know for sure if it would be possible to run a OS that has it's root_fs on a cloud server. Interesting scenario for sure though

Yes, I know this is an old thread, but I tried this and wanted to say, yes, not an issue. Can use a cloud iso as long as you can access it via pretty much any protocol.

Caveat: I don't recommend this... You are booting a flipping iso so need lots of bandwidth and stressing the upstream server, but yes it works. No issue if your own server on your own local network - usually bandwidth not an issue there at all. I was going to include an image taken right now of me with Fossapup booted from cloud, but won't bother since you know what Fossapup looks like. It took quite a long time to boot of course since all the sfs files needed either copied to RAM or even if chosing no copy to RAM from boot menu everything still needs to be accessed. Sorry rockedge, I booted from your server so much like a download for nothing I suppose. I hesitate to print the commandline (it is simplicity per man qemu...) but I do not want to encourage every forum member to run their Puppy or KL Distros via constant booting from your server using Qemu

Okay so just -cdrom and use the appropriate protocol to point to the iso, which can be ssh, but I just used https URL (okay, is that simple sentence enough to explain it???). I suppose this is a technical forum so technical answers should not be hidden to protect rockedge...???!

Sorry about that @rockedge. I hope no-one will be annoying enough to use Qemu to access your isos as a boot mechanism.

I also did it via an actual cloud service that provided a virtual drive. That was trivial, and fast (big internet pipe I guess), but I have a feeling the cloud service might not like it and eventually remove my account if I adopted that as a regular practice...

So just to emphasize what I am doing... I am running Fossapup exactly from the iso on rockedge server. Oops. But just an experiment, I promise. This is not a good thing to do...

Okay, so I now temporarily booted Vanilla Dpup 10.0.33 retro in same way via Qemu. This time I let it copy the Pup sfs files to RAM so took a while of course. I don't feel quite so guilty, but no, this is bad waste of bandwidth - only worth the experiment. I've done the experiment so you don't need to... But fine on your local LAN of course.

HTTP/HTTPS/FTP/FTPS/TFTP
QEMU supports read-only access to files accessed over http(s), ftp(s) and tftp.
Syntax using a single filename:
<protocol>://[<username>[:<password>]@]<host>/<path>