(old)Puppy Linux Discussion Forum

May 9th, 2014, UPDATE
Title modified. Available in my repo (see sign for address), QEMU 1.53 (32 bit) - tested on Precise 5.7.1 - and QEMU 2.0.0 - tested on Fatdog64 and LHP -. You can choose, only for 2.0.0 version, within SFS (45 M) or PET (57 M). Browse repository for correct section.

For those of you that have still downloaded old SFS (fitted on LHP), to avoid mistakes, this is md5 checksum of the new one: ffe06d0edb37de3edf4797463053875b.

QEMU buggy version 1.6.0 (SFS-packed) will be deleted soon.

Please, note: if you want to share, don't link directly my repo resources. They periodically will be overwritten by newer versions or can be moved for more efficient folder organization or for hosting reasons. Don't leave orphan links all over the web, browse repository instead (that is safe to link).

Please, note also that this one will be, probably, my last effort in QEMU support for Puppy, because my hardware is going dated (I cannot use QEMU anymore since last versions, I can only make a very slow X-test after compiling). So, all my last packages were a gift for community, not usable by me.

--

May 3rd, 2014, UPDATE
Title modified. Now QEMU SFS 1.53 (32 bit)/1.60 (32 bit)/2.0.0 (64 bit) are all together on my repository (see sign for address).
Remember 1.6.0 is a buggy version.
2.0.0 tested in LHP.

Enjoy!

--

EDIT
Now available in repo: qemu-1.5.3_x86.sfs and qemu-1.6.0_x86.sfs.

--

I packed latest Qemu and now is available for you as sfs (in project: constant support - newer will replace old package -).

See my sign for address of my manual repository for a direct download (section: sfs-modules).

Enjoy!

***
Please, note: old software is removed periodically from my repository, so some of my posts, in this forum, can contain old resource announcements not available any more.
***

Is this SFS version for 32bit or 64bit PUPs?

Thanks

1.6.0 is buggy. Just ask 01micko about it. Use 1.5.3 instead until they release 1.6.1.

One thread about qemu is here :

Running sap6 without Raspberri Pi
http://murga-linux.com/puppy/viewtopic.php?t=79358

I remember it running heavy on the cpu and recently saw a message that complained about missing kvm.ko module in the last pre- slacko-5.6 thread .

I cannot remember having loaded that kvm.ko module manually .

Thanks Karl.

I wrote that article and indeed it was rather slow (I used qemu 1.2.2 then). The newer 1.5.x line is much faster if you have multicore CPU. I didn't follow qemu extensively so I don't know from which version the speedup happens - I only compared between 1.2.2 and 1.5.x.

01micko tested 1.6.0 and found that certain emulation platforms are buggy, so that's why I suggest that one sticks with 1.5.3 (actually released two weeks after 1.6.0) unless one really needs 1.6.0 features ...

Side-note: I have updated the instructions for running FatdogArm on Qemu, see here: http://jamesbond3142.no-ip.org/wiki/wik ... ArmForQemu.

cheers!

@gcmartin: SFS is for 32 bit ones.

@jamesbond: I packed 1.5.3, too. You can find it, from now, in my repository.

@Karl Godt: my CPU doesn't support KVM (but my Qemu packages are configured to support it). CPU is heavily loaded (more load on one processor of a dual core one, according Htop), but system is still usable, without problems.

Any feedback will be welcome.

Thanks.

Is this of interest or helpful. QEMU for KVM

FYI

Will the change at dyndns ...ie paid option only..affect your hosting?

Secondly..why does the sfs contain builds for every conceivable architecture when puppy only has x86 and 64 (and perhaps arm) support ...just makes it a little on the large size.

On a similar note whats the difference between the system and non system binaries...a seach on this was unclear.

Thirdly...kernel kvm module... something that comes with the kernels as standard now?
edit ..the system build tries to give full system features? ..my guess

mike

mikeb wrote:On a similar note whats the difference between the system and non system binaries...a seach on this was unclear.

qemu-system runs an entire OS.
qemu-user runs a binary.
Say you have a static ARM binary from somewhere, then you can run it like this "qemu-arm ./static-arm-binary" from you x86 OS. Neat, eh? You can actually run dynamically linked binaries as well, but you need to provide an entire ARM glibc in your harddisk somewhere ...
Of course, ARM is just an example. This is true of other architecture as well.

Thirdly...kernel kvm module... something that comes with the kernels as standard now?

It depends on whether the kernel is compiled with kvm support or not.

Ah ok so for a virtual machine the 'system' one is used.... and the other for static binaries... hmm one to play with.

So if kvm is present is it usually built into the kernel or need to be modprobed? /dev/kvm and shm seem to be the same just the names changed... I have a gui based around qemu 0.9 and kqemu.ko so need to adjust to match the current releases.

mike

mikeb wrote:Ah ok so for a virtual machine the 'system' one is used.... and the other for static binaries... hmm one to play with.

Well get the FatdogArm glibc and you can run dynamic ARM binaries too

So if kvm is present is it usually built into the kernel or need to be modprobed? /dev/kvm and shm seem to be the same just the names changed... I have a gui based around qemu 0.9 and kqemu.ko so need to adjust to match the current releases.

In my system, udevd loads the module for me, I don't have to do anything. In other system, depending on the kernel version, you *may* need to modprobe it. And you're right, kvm actually replaces kqemu (it's a bit sad though, kqemu enables acceleration *without* the need for hardware support; kvm however *requires* hardware support --> so if your system doesn't support hardware support and you want speed, stick with qemu 0.9 + kqemu).
/dev/kvm is what qemu uses to talk to kvm kernel module via ioctl, it is a real device node (like /dev/sda, /dev/dsp, etc). /dev/shm remains the same as before - a mountpoint for tmpfs.

cheers!

Ok thanks for the clarification...from the horses mouth works better for me.

Yes indeed was tring out kqemu on a core duo 1.666 and it flew compared to what I am normally used to. So kvm is a hardware issue then..which makes sens with udev loading it...basically its there or not there and of course requires a kernel built to include it.

Well seems like all this info is getting me up to speed to match up the script now.

Only bum was trying to run qemu 64 on a dual core atom machine that ran lighthouse but it was a no go so makes testing awkward.

One question you might know... are there still problems with say windows 98 or 2000 guests and the kernel like there used to be?
Will adding the kvm parameter when there is no support matter..ie will it just be ignored?
yes thats 2 questions.... no brain in a morning

mike

mikeb wrote:Only bum was trying to run qemu 64 on a dual core atom machine that ran lighthouse but it was a no go so makes testing awkward.

That's odd. Even if your atom doesn't support 64-bit (some do and some don't) - qemu-system would still boot LH64, although slower (using emulation instead of virtualisation).

One question you might know... are there still problems with say windows 98 or 2000 guests and the kernel like there used to be?

I don't know, sorry. I haven't touched those two for a long time - in fact I'm not sure whether I still hold a copy.

Will adding the kvm parameter when there is no support matter..ie will it just be ignored?

Nope, qemu will fail to start when given -enable-kvm and the machine can't do it. If the machine doesn't support kvm, don't use -enable-kvm.

Right got it for the parameter.

98 and 2000---i could test if i could lol.... my main use of windows emulation is for gruesome apps that want IE , mshta or .net to run and I refuse to add that stuff to my real installs.
98 fails if kqemu is used and 2000 wont install with kqemu but does run.

The atom machine I happen to have does have 64 bit support and lighthouse runs.

When I try to run qemu I get a file or directory not found but its there and I am using the right path but sounds more like the error I get if I try running a 64 bit app on a 32 bit system so methought its something lacking in the atom 64 bit implementation compared to AMD.

mike

mikeb wrote:The atom machine I happen to have does have 64 bit support and lighthouse runs.

When I try to run qemu I get a file or directory not found but its there and I am using the right path but sounds more like the error I get if I try running a 64 bit app on a 32 bit system so methought its something lacking in the atom 64 bit implementation compared to AMD.

Ah, so you're trying to run qemu-user for 64-bit? (qemu-x86_64)? I presume that qemu-system-x86_64 works (since you can boot LH64). If you want to run 64-bit dynamic binaries, then you do need 64-bit glibc (the one from LH64 will do). Is this what you're trying to do?

cheers!

nope...was qemu-system-x86_64

And just to be clear I was running lighthouse 64 as the host.

mike

Okay, so you're saying that LH64 is host, but trying to run LH64 inside qemu-system-x86 doesn't work? Hmmm...

Which version of qemu do you use? 1.6.0 is buggy, I've tested it with 1.2.2, 1.5.3 and 1.6.2 all works fine here.

Anyway, what's the error?

running qemu 64 1.5.3 fails with no such file or directory...binary is there...path is correct.... I do not get to run any virtual machine.

mike

Did you ldd the binary? perhaps missing dependency?

hmm not really a ldd error but I could double check...seems more likely the atom intel 64 support is lacking.

Not sure when I will have access to the machine to test on next...though seems ok working blind for now on the gui...

Thanks for your input on this...

mike