trinity/src
1
0
Fork 0
Code

2023-10-22

Browse Source
This commit is contained in:
dtb 2023-10-22 21:29:47 -05:00
parent 1606eecc90
commit 0dd012051d
1 changed files with 303 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

303
homepage/homepage
View File

@ -1929,6 +1929,309 @@ If I don't, escalate the issue to the host of this site (this can also be found
</HTML>
/blah/2023-10-22.html
: more adventures trying to run a .exe file
So long as you can get QEMU.
qEMU?
qEmu?
QEMU according to its website.
I grabbed the RAR file of this Windows game and now I desperately want to run
it because it looks really cool. Now that I figured out unRARing it's time to
play it. However WINE (an API conversion layer from Win32 to Linux+other OSes)
won't work on the Raspberry Pi because this is an ARM processor which can't
execute x86 code, even if the API calls are translated. So I've decided this
game warrants mucking around in a lot of complicated compatibility shims.
The stack will look something like this:
__ Raspberry Pi 4B+ 8GB _______________________________
| |
| __ Linux __________________________________________ | ; I'm including the
| | | | ; kernel as its own
| | Chimera | | ; layer-maker
| | __ X11 server _________________________________ | | ; because QEMU will
| | | | | | ; be booting the
| | | WINE display<---------------------------------------. ; kernel image
| | | __ urxvt __________________________________ | | | | ; itself without a
| | | | | | | | | ; bootloader and
| | | | __ QEMU amd64 _________________________ | | | | | ; from the kernel
| | | | | | | | | | | ; init etc will be
| | | | | __ Linux __________________________ | | | | | | ; spawned. The
| | | | | | | | | | | | | ; Raspberry Pi also
| | | | | | Alpine | | | | | | | ; basically just
| | | | | | __ WINE _______________________ | | | | | | | ; boots the kernel
| | | | | | | ^-(X11 client)--------------------------' ; image sans loader
| | | | | | | | | | | | | | ; because U-Boot.
| | | | | | | The Coffin of Andy and Leyley | | | | | | | ; The details
| | | | | | | | | | | | | | ; mentioned are the
| | | | | | |_______________________________| | | | | | | ; ones I expect to
| | | | | | | | | | | | ; add non-trivial
| | | | | |___________________________________| | | | | | ; overhead to
| | | | | | | | | | ; processor load,
| | | | |_______________________________________| | | | | ; which might be a
| | | | | | | | ; problem in
| | | |___________________________________________| | | | ; practice.
| | | | | |
| | |_______________________________________________| | |
| | | |
| |___________________________________________________| |
| |
|_______________________________________________________|
This seems fine!
I had sex four times tonight and this is what I'm doing with the clarity.
So the first order of business is QEMU. This is packaged for Chimera in
multiple variants. I don't know what I'm doing so I looked it up and I think I
need qemu-system-* because I'm emulating the processor as well as the software.
# apk add qemu-system-x86_64
Now I need Alpine. I think it comes in really small images for containers.
$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/\
alpine-virt-3.18.4-x86_64.iso
Let's try booting.
$ qemu-system-x86_64 -cdrom alpine-virt-3.18.4-x86_64.iso
Error relocating /lib/libspice-server.so.1: __aarch64_ldadd4_acq_rel: symbol no
Error relocating /lib/libspice-server.so.1: __aarch64_ldset4_acq_rel: symbol no
Error relocating /lib/libspice-server.so.1: __aarch64_ldclr4_acq_rel: symbol no
Error relocating /lib/libspice-server.so.1: __aarch64_cas4_acq_rel: symbol not
Hm. Same thing as root. Maybe I need a kernel image outside of the ISO? Let me
try something:
$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/\
alpine-minirootfs-3.18.4-x86_64.tar.gz
$ tar tf alpine-minirootfs-3.18.4-x86_64.tar.gz | head
./
./sys/
./srv/
./run/
./root/
./opt/
./mnt/
./media/
./media/usb/
./media/floppy/
$ mkdir amd64
$ <alpine-minirootfs-3.18.4-x86_64.tar.gz gzip -cd | tar x -C amd64
$ man -k qemu
qemu(1) - QEMU User Documentation
qemu-img(1) - QEMU disk image utility
qemu-storage-daemon(1) - QEMU storage daemon
virtfs-proxy-helper(1) - QEMU 9p virtfs proxy filesystem helper
qemu-block-drivers(7) - QEMU block drivers reference
qemu-cpu-models(7) - QEMU CPU Models
qemu-ga-ref(7) - QEMU Guest Agent Protocol Reference Contents 0.0 • 2 QEMU Gu
qemu-qmp-ref(7) - QEMU QMP Reference Manual Contents 0.0 • 2 QEMU QMP Referen
qemu-storage-daemon-qmp-ref(7) - QEMU Storage Daemon QMP Reference Manual Con
qemu-ga(8) - QEMU Guest Agent
qemu-nbd(8) - QEMU Disk Network Block Device Server
$ man qemu # brb...
$ ls amd64 | grep linux
$ # fuck... I'm just gonna look up a tutorial
The good news is I don't think X forwarding will be necessary so that saves a
lot of trouble. The bad news is I don't know what I'm doing and am tired so
this will wait for tomorrow.
https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/item/images/alpine/genimg
How does Drew do it?
It was at this point the file got corrupted so here's my reconstruction of this
section based on the nvim swapfile:
I return well rested, ten hours later.
# apk add qemu-img
[ 1:20 AM] trinity: trying to figure out qemu
[ 1:20 AM] trinity: not going well
[ 1:21 AM] trinity: trying again with the sun up
[ 1:21 AM] [...]: I remember I used that for the class where we
re-implemented a lobotomized risc-v operating system
[ 1:22 AM] trinity: i just wanna play this rpgmaker game
[ 1:24 AM] [...]: which one?
[ 1:29 AM] trinity: coffin of andy and leyley
[ 1:29 AM] trinity: i think i can figure this out tomorrow
[ 1:29 AM] trinity: \/when i wake up
[ 1:29 AM] [...]: why do you need qemu to run a rpgmaker game?
[ 1:30 AM] [...]: they run in wine
[ 1:30 AM] [...]: someone must have built some wrapper for them if
wine/proton does not work
[ 1:30 AM] [...]: you just need the fonts
[ 1:31 AM] [...]: also I remember running touhou mother in easyrpg on my
steam deck
[ 1:31 AM] trinity: not on arm64
[ 1:31 AM] [...]: oh i see
[ 1:32 AM] [...]: WHYYYYYYYY
[ 1:32 AM] [...]: WHY HAS THIS SPREAD SO FAR
[ 1:32 AM] [...]: is that the incest canibalism one?
[ 1:33 AM] [...]: no comment
[ 1:33 AM] [...]: :3
Drew bootstraps an extremely minimal Alpine x86_64 image with just enough
packages to self-host. However in the genimg script there is this one line:
30 dd if=/usr/share/syslinux/mbr.bin of=/dev/nbd0 bs=1 count=440
which relies on there being an existing SYSLINUX installation on the host. This
won't work on ARM64 for which there is no SYSLINUX and Chimera doesn't have a
GCC x86_64 cross compiler packaged and I don't wanna have to compile gcc for
this so I'm just gonna find a way that's different from Drew's way.
I'm gonna try using the standard ISO now because that should have a kernel and
means to boot on x86_64 already. I wonder if I can boot it as a live system and
no shit it has no X server. Maybe it wouldn't be too bad to install?
Fuck this shit. I'm just gonna figure out Box86.
Actually Box64 because I don't wanna figure out armhf stuff today.
; doas gmake
[ 1%] Building C object CMakeFiles/interpreter.dir/src/emu/x64run.c.o
/usr/local/src/box64/src/emu/x64run.c:1351:47: error: expected expression
emu->segs[_ES] = *(__uint16_t*)(((char*)ED)+4);
^
/usr/local/src/box64/src/emu/x64run.c:1351:36: error: use of undeclared identif
ier '__uint16_t'
emu->segs[_ES] = *(__uint16_t*)(((char*)ED)+4);
^
/usr/local/src/box64/src/emu/x64run.c:1364:47: error: expected expression
emu->segs[_DS] = *(__uint16_t*)(((char*)ED)+4);
^
/usr/local/src/box64/src/emu/x64run.c:1364:36: error: use of undeclared identif
ier '__uint16_t'
emu->segs[_DS] = *(__uint16_t*)(((char*)ED)+4);
^
4 errors generated.
gmake[2]: *** [CMakeFiles/interpreter.dir/build.make:76: CMakeFiles/interpreter
.dir/src/emu/x64run.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:113: CMakeFiles/interpreter.dir/all] Error
2
gmake: *** [Makefile:166: all] Error 2
it is all so tiresome. This also matters less because I'm gonna need Box86
anyway. Maybe I should make a QEMU virtual machine for Raspberry Pi OS, install
Box86 and Box86's packages on that, and then have it all nice and dandy?
# apk add qemu-system-arm
# apk del qemu-system-x86_64
End recovered segment.
I'm gonna use the armhf image because I don't think this EXE is 64-bit and
it'll cut out all of the compat stuff.
$ curl https://downloads.raspberrypi.com/raspios_armhf/images/\
raspios_armhf-2023-10-10/2023-10-10-raspios-bookworm-armhf.img.xz \
| xz -cd \
>2023-10-10-raspios-bookworm-armhf.img
1238MB... jeez... time to plug in the laptop fan
The tutorial I'm following provided a link to a GitHub repo with a Raspberry Pi
QEMU Linux kernel image which is awesome. Except there's no Linux 6.1 so I'm
gonna have to go a version behind. This is all to play one video game so we can
move fast and break things without risking all hell breaking loose.
$ rm 2023-10-10-raspios-bookworm-armhf.img
Except where are the old OS versions? I can't find them on the Raspberry Pi
website.
Found by looking up, good old no-TLS HTTP: http://downloads.raspberrypi.org/
The newest kernel provided by the GitHub repo is 5.10.63, which corresponds
according to the Raspberry Pi OS Full armhf release notes (raspios_full_armhf
/release_notes.txt) to the 2021-10-30 release. But that download isn't in this
HTTP source. I think 5.4.51, which is provided in the repo, will work with
2020-08-24, though that version isn't mentioned in the release notes, because
the release notes' mentioned 2020-08-20 does have that version. The issue is
the release notes' dates don't line up with the actual downloads provided.
Strange. Whatever. Let's just try this and hope it works.
Oh, what the fuck? The dates in the folders are different? fucking hell
look at this fucking URL:
http://downloads.raspberrypi.org/raspios_full_armhf/images/
raspios_full_armhf-2020-08-24/ <- 2020-08-24
2020-08-20-raspios-buster-armhf-full.info <- WTF?????
I'm so tired and just want to read about hot cartoon characters butchering
people. Kernel 5.10.63! 2021-10-30! Of course, in the 2021-11-08 folder! I
should have known!
$ curl -O http://downloads.raspberrypi.org/raspios_full_armhf/images/\
raspios_full_armhf-2021-11-08/2021-10-30-raspios-bullseye-armhf-full.zip
$ # .zip? are you kidding me? 3.0GB??? This is gonna be an hour download...
Fucking hell. See you tomorrow.
/blah/2023-10-21.html
: fuck unrar
I run Chimera Linux, an Alpine-based operating system still in its very early
stages but stable enough that I trust it for my meager, mostly console and X11
based workflow. It can run a C compiler, so good enough for me. The only issue
is, despite being based on Alpine, a popular operating system not for desktop
but for embedded environments like containers, for which a lot of software is
packaged and available in system repositories, Chimera does not have a lot of
packages. I'm going to package UNRAR, a non-free ("freeware") tool that has no
dependencies aside from the C++ standard library, to get a feel for Alpine
packaging.
UNRAR is an almost delightful little tool with the unfortunate, heinous problem
of being non-free, and its license forbidding the use of the provided source
code for reimplementation - otherwise I would just rewrite it in sane C89
without encumbrence. But we don't need to read the source code in order to
compile the C++.
The Alpine Wiki section on Creating an Alpine package says to apk add
alpine-sdk but Chimera has no such thing so hopefully that's fine. It says to
check out the aports tree but I don't want to put my packages upstream (dealing
with large software projects is tiresome and I know Chimera is in a constant
state of flux).
I did this:
# mkdir -p /var/cache/distfiles
# chmod a+w /var/cache/distfiles
I now need abuild-keygen according to the wiki but it isn't installed.
$ apk search abuild-keygen
pulled up nothing. Nor did a package contents search. Maybe it's fine? On a
whim I searched cbuild* in the contents search and found apk:base-cbuild-progs.
# apk add base-cbuild-progs
(1/1) Installing base-cbuild-progs (0.1-r2)
OK: 2083 MiB in 896 packages
On the Chimera Linux website I found the Chimera-specific packaging stuff.
There is a cports repository with Packaging.md but it's kind of long so I'll
use it as a reference while following the less complete Alpine guide. This is
the rat bastard approach to software but I am doing this for my own uses and
for pleasure and I don't wanna spend five hours contributing to this project
right now because I am tired.
I need newapkbuild but don't have it so I'll try to find the default template
on-line or go off an existing thingy.
I found contrib/jq/template.py so I'll copy that.
pkgname = "unrar"
What's the pkgver?
$ cd /usr/local/src/unrar
-sh: 5: cd: can't cd to /usr/local/src/unrar
$ cd /usr/local/src
$ ls
$
Connection to tebibyte.media closed.
; # oops
; cd /usr/local/src/unrar
; cat version.hpp
#define RARVER_MAJOR 6
#define RARVER_MINOR 24
#define RARVER_BETA 1
#define RARVER_DAY 17
#define RARVER_MONTH 9
#define RARVER_YEAR 2023
# apk del qemu-system-x86_64
/blah/2023-10-21.html
: fuck unrar