qemu-static... a failure story

[axl]

hi.

it's not exactly a failure story, it's more like your task was failed with the message success.

Some of your might be familiar with qemu static. some of you might use it for raspberry pi & stuff. qemu is a wonderful thing, and qemu static is even more wonderful.

So this is the setup. A friend of mine bought a raspberry pi based on my recommendation. And asked me to setup the printer. Which was a samsung laser printer m something. Not sure the model matters. It's sold as a network printer. It never worked as a network printer because it's ip was starting with 169.254... smth. Even thought the entire network was 192.168.1.smth. So clearly the problem was that the printer was setup badly.

It took me 6 hours to try and test various solutions. I ended up using a default driver, and just adding a route. route add 169.254.x.y dev wlan0. that. just that. that was the fix.

But all in between I tried to make the x86_64 unified samsung drivers to work on the pi. using qemu static and binfmt. And it worked. Little did I know that even if I did my part in terms of libraries and stuff, it will still not work, because of the ip stuff. Yet none the less, qemu is so freaking versatile. There's a binary in the unified samsung drivers that's i386 and x64 only called rastertospl. I got that thing to work in arm, seamlessly with qemu static... and the thing still didn't work.. because IP.

After the fact, I am just impressed by qemu. it did what it supposed to. and it worked. had to transfer with scp some 20-30 libraries (.so) from a pihole VM to the raspberry pi, but happy thing about debian, they all reside in /usr/lib/${arch}. so no conflicts in having a multi arch system.

Maybe some of you understand things as I stated them. Let me try to go even further.

binfmt is a way to point to an interpreter for certain kinds of binaries. let's say... for things that start with these characters... run qemu-arm or qemu-x86_64 or whatever. linux can do that.

next... things are going to look for certain libraries. the fact that debian puts them in /usr/lib/${arch} is very useful, because things in x86_64 and things in arm dont collide and conflict.

now, my friend is asking is he could use zoom and dropbox client on the pi. I told him, there are no arm clients. but armed with knowledge... I feel compelled at least to try. And I will have my work cut out for me for the next few days.

Linux is fun.

PS not a bad idea to have lib/${arch}/libs.so. in fact it's a wonderful idea. and why I found a new respect for debian.

[axl]

also, if people play with this technology, they should know that the binfmt conf files should include headers from 3 types of files. static bins, shared objects and shared pie objects (position independent objects). just so it's written down somewhere. it's not written down anywhere as far as i know. I worked my butt off to find that out the hard way.

[Hu]

169.254.* is the APIPA range, which suggests the printer failed to acquire a DHCP lease. Does the network have a functioning DHCP server that the printer would see? Does that DHCP server report receiving DHCP client requests from the MAC address of the printer?

[axl]

[NeddySeagoon]

axl,

As its a network printer, you should be able to send it PostScript and have it just work.
It should not need any external rasteriser at all, never mind one running with help from qemu-static. :)

CUPS will need the printer PPD file, if it does not already have it.

All the out of band stuff, like checking supplies may need an evil binary blob though.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[axl]