With a bit of poking around in the latest Qemu 0.15.0 rc2 beta, the S390x now builds by default. Finding something for it to run was a bit of a stretch but I should have figured that Debian would have something.
It does take a few seconds to boot up, and by default you’ll just be sitting at a blank screen until you toggle to the virtcon0 screen.
But it’s VERY snappy… I haven’t gotten it to install (unsupported NIC?!) but I’m pretty positive it’s 100% my fault. I’m just happy I saw it boot. And it runs the busybox stuff just fine so it’s tentatively working.
If anyone wants to give it a whirl, download my exe, and the kernel/init.rd I’ve found that at least boot up here.
I’m hoping this will spur someone to spell out how/what to install onto it, and maybe if things like MUSIC/SP and CMS will run on it… That’d be fantastic!
In the meantime I’d imagine this combined with KVM on people with accelerated configs will enjoy some SERIOUS competition to the IBM Mainframe monopoly!
This is more of a ‘network virtualization’ thing but I LOVE the RDP protocol. Â The issue is when you connect to Linux/UNIX machines they don’t talk RDP it’s either VNC or X11.. and that. well. is a PITA.
Wouldn’t it be cool if you could somehow interface RDP to a private X11 server?
And let me say, if you have UNIX machines with Windows people that need to get involved (Say Oralce on Linux) and what a nightmare it would be to roll out cygwin or some other incredibly complicated thing to rollout, it’ll be a zillion times easier to just let them RDP to the machine.
So touching on my prior long winded post, I was mentioning that running Qemu ‘headless’ on a resource constrained VPS was different then running it interactively at home.  For starters you don’t want to install X11, and all the necessary libraries just for a single program if your VPS is limited to 2GB, as it is more then likely that you will exceed your disk space just by trying to get a workable environment.
Instead, I’ve found the way to go is to take advantage of Qemu’s built in VNC server.
I build my own version of Qemu at home, then just upload the binary.  While there may be packages, because of the expectation that you’ll be running X11 for the SDL output it could easily pull in several gigabytes, that I’d rather use for disk images.  I recommend people build with the same OS as their VPS uses, to keep things ‘sane’.  Not to mention you’ll have a far higher success rate by matching OS levels.  And yes I do this in a VM, all the more reason to have VMs.
Also I should mention that in constrained space, I find that 32bit OS stuff is smaller, if you have a 64MB memory limit, then yes size does matter.
The steps are pretty simple, it’s basically download & unpack the source, then configure it something like this:
Then run make, and after a few minutes it should complete the build. Â I then manually ‘strip’ the qemu executable, tar it up and then take it for a test run. Â For the most part it really is that simple.
Again I’ve found building on the same distro as your VPS is using helped an incredible amount.  Not to mention trying to keep your ‘build’ machine as bare as possible so it’s not pulling in all kinds of wild dependencies.
The next thing with Qemu uploaded is you’ll want to test it. Â It works like normal Qemu with the exception of how you then specify your display to go out via VNC. For me, I run it like this:
Then you can connect with just about any VNC client on VNC port :101 (or TCP 6001)
My OS/2 BBS on Qemu via VNC
And from there I just wrap it in a while true/do true script so that way every time I reboot the VM or if it were to crash for what ever reason it’ll keep on trying to start it over and over.
Back to memory consumption, as you can see I’ve configured my Qemu intance for a whopping 16MB of ram, and this is what it looks like according to top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2785 root 20 0 72868 33m 2164 S 2 57.5 1:03.69 qemu
Which is the resident size is 33MB, out of my 64MB VPS, with lhttpd running and php for the socket support I have a whopping 1MB free!
That about covers it, and for the Debian people out there here is my build of Qemu 0.14.1. I should imagine it’ll run on other i386 Linux OS’s (or x86_64’s with the 32bit compatibility installed)
That’s right. Â Fabrice Bellard, has done it again, he’s given us such great things like TCC, Qemacs, and of course, Qemu. Â But now he’s written a x86 emulator in javascript.
I must say, it’s fast. Â A lot faster than I would have ever expected.
The hardware is a basic CPU, clock chip, and a UART. Â however it’ll run things like vi just fine. Â If you have either browser, give it a shot, it’s nothing short of amazing.
So here we are, 2011. Linux has been around for nearly 20 years.
Would you like to load custom fonts?
No thanks, I’m fine with VGA.
Well FUCK YOU!
Look guys, it’s been WAY too long, and really this is unacceptable. I’ve tried to live the ‘year of the linux desktop’ back in 1994, 1995 ad nauseum, and really, when it comes to simple stuff, like a TEXT MODE INTERFACE, and it’s fucked up… Yeah Linux will remain where it is. And that’s nowhere.
I know that the 0.7% of the internet will rush in to apologize, or flame, because Linux simply cannot drive a simple VGA console, or how it’s my fault, but really get a grip.
It’s 2011, and asking for a normal textmode install is a fucking disaster. I can almost expect that after 40 years of Linux it’ll still fail.
So I got this request about running Mono on the PowerPC. As it stands right now I don’t have a PowerPC box in my home to test, so I thought I’d turn to Qemu & Debian.
Qemu 0.14.0 PowerPC Debian boot
And yes, it surprisingly boots!
I opted for the network install, as I didn’t even know if it would work. But not only did the 32bit version of Linux for the PPC boot up, but the 64bit did as well! The flags were a little involved to get going, but it went something like this for the 32bit version:
qemu-system-ppc.exe -m 512 -boot d -hda debian-ppc.qcow2 -L pc-bios -M mac99 -net nic,model=pcnet -net user -cdrom debian-6.0.1a-powerpc-netinst.iso -boot d
And for the 64bit version:
qemu-system-ppc64.exe -L pc-bios -m 512 -hda ppc64.qcow2 -net nic,model=pcnet -net user -cdrom debian-6.0.1a-powerpc-netinst.iso -boot d
And then it’s a matter of waiting… Maybe I should have just torrented the install DVDs or something.. 😐
Qemu 0.14.0 PowerPC Debian install 33%
But booting from the hard disk produces a:
openbios panic: Unexpected exception 704
So close. Perhaps the macintosh machine type I select means the boot type isn’t PReP like for OpenBIOS to find?
I’ve also been told you can find various pre-built images here.
I don’t know how I didn’t find this earlier, and how it’s been overlooked for so long….
But this incredible program, LINE, will run statically linked Linux ELF binaries on Windows.
Yes, you read that right, this user mode program will load an ELF exe, and run it under a software debugger with no need for device drivers, and intercept all the sycalls (ie int 0x80’s) through the cygwin1.dll, giving you a POSX/Command line linux experience.
It does come bundled with various hello programs, and a few things on testing forks… But the real magic for me was being able to grab a static version of dungeon, and running it on both Windows 7 x64, and emulated NT 4.0.
And it works!
I’ve put my copy of dungeon, along with a copy of cygwin1.dll that works with the LINE package here for anyone interested.
I’m just amazed at the size, and simplicity of the whole thing…..
In the documentation there is even mentions of NSO (Native shared objects?), and dynamic linking…
Clearly this project should have had more of a future to it!
I’ve been going in circles with slirp trying to really get it to run on x86_64 mode so far to no avail…
So first thing, hello from the future of 2020 (I wrote this quick blurb in 2010), and Wheezy has been pulled from the main mirrors. So annoying! You need to update your apt sources to use the archive:
deb http://archive.debian.org/debian/ wheezy main
deb-src http://archive.debian.org/debian/ wheezy main
deb http://security.debian.org/ wheezy/updates main contrib
deb-src http://security.debian.org/ wheezy/updates main contrib
Do your apt-get update;apt-get upgrade and you’ll be ready to roll!
But it’d sure help to be able to compile code in 32bit/64bit on the same machine. Anyways after looking for far too long I managed to find that it’s really simple.
apt-get install lib32bz2-dev
And away we go!
Naturally, you’ll need a compiler already installed ( build-essential).
# cat x.c #include int main(){printf(“int is %d\n”,sizeof(int));return 0;} # # gcc -m64 x.c -o x64 # gcc -m32 x.c -o x32 # file x32 x64 x32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped x64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped # ./x32 int is 4 # ./x64 int is 4
Interestingly enough it seems that the ancient linux circa 0.01 – 0.10 not only didn’t have FPU emulation, but didn’t support FPU instructions at all… Or I could be doing something wrong with gcc 1.40 as there isn’t a libm, nor does it inline the math… So anything with floating point is out. So with a bit of digging around for an ancient distro, I found a Linux 0.97 version of MCC. It’s incredibly small, as things were back then. So I’ve installed it, altered the kernel to default to a US keyboard map, (Sorry to people in the UK), and tried to squeeze the disk image down to something not too big. And I’ve included the f2c components and a build of dungeon.
Another f2c platform!
For anyone interested, I’ve uploaded my MCC image, it’s just under 6 megabytes. WOW how the times have changed!!!!
Again special thanks to Jiong Zhao’s most excellent oldlinux.org.
With that said, I’ve also just gotten a note from Artyom that his SunOS patches have been sent upstream to Qemu, so hopefully they’ll be downstream any day!
