Just to clarify; was the remedy more or less to do the above, without having done an apt upgrade? Another solution i might look into is doing an apt upgrade, and THEN doing the Lima driver upgrade AFTER. Theoretically, installing quake/duke should work.
Kind of the eduke32 version I build needed some includes from some **-dev packages but it seems to use statically linked libraries as it runs fine on the clean image I flashed after that. Maybe I can upload the version I compiled for the CPI, It should run out of the box. Quakespasm on the other hand uses dynamic linking for its libraries. It has a lot of build-dependencies and run-dependencies: libopusfile, libvorbisfile, libmad, libflac, libmikmod, SDL2, libgl, libc6(glibc 2.29), libgl (libgl-mesa-*) and more and each has their own deps.
I can upload the libs I unpacked but I strongly discourage from using them. I only added a new library every time quake would output a missing library error. There is a good chance that this setup runs into dependency issues when running certain applications (or I got lucky and satisfied all deps). This is a really dirty workaround for the apt issue, getting lima to survive an apt or dpkg update/install would be far better.
Disabling the GL extensions can be done with command line arguments I basically made a quake.sh with the following content:
I could also try to compile quakespasm again trying to force it to use static libraries. It would expand the executables size but should run without copying my libs.
Anyway It’s gonna take me a while to upload the files as I am away from home for work for the week and I have left my CPI at home.
Theoretically doing an apt upgrade to get all the dependencies and extensions first and then doing the Lima upgrade process (again) should set things right. I’ll see what I can do if I have time. Let me know how you go too.
Haven’t tried that yet. If mesa is the only thing causing trouble, it should work for a while. If so reinstalling the version of mesa using ninja install and mv to move the libraries after an should also work right?
so when I wanted to run an update I could just make a shellscript like this:
Would lima still work after that? If not I could “make clean”/ “make mrproper” then ./configure , make && make install (same with meson and ninja for mesa). Is there anything in the updates thats really breaking lima or is overwriting them again with the self-built mesa versions enough to restore functionality?
One thing I can see breaking are the previously mentioned dynamic libraries used to trick the gameshell into changing between FBTurbo and Lima drivers.
It may be worth using an image that hasn’t had the Mesa/Lima built yet, and trying to install everything in a less volatile location, ie not the user directory. That said, I don’t know if people use any user other than cpi anyway.
I’m curious as to what exactly does change after doing an apt, making things break.
Unless people are actively developing or using newly developed tools that depend on the latest version, I should hope that the regular “user” shouldn’t do an apt upgrade without being fully aware of what they are doing. Old/fast is sometimes better. But nonetheless, I’m just going to put a disclaimer here. Don’t do it, unless you know what you’re doing.
Ha, you’re definitely the dev kinda person who would benefit from regular apt upgrades
Back when I used to have a Linux machine as my day to day computer, I’d probably reboot it… maybe once a month? And that’s usually due to someone tripping the power or literally tripping over a power cord.
I have thought of having a version tracker/git submission but ultimately, I … was too lazy to do it. But if there’s enough demand for it, I’ll do it. Or if anyone else wants to, I sure won’t say no!
For some reason(GFW) Google and Dropbox are blocked in China.@guu’s link is the only one I can download,but pretty slow and login required,so I uploaded your image file to my own storage and share a link in case someone need it. PS
If necessary I can provide a mirror in future.
I uploaded the unpacked deb packages to my NextCloud server:
They contain all the libraries necessary to get quake running and other applications using SDL2.
If apt works for you, you should use “sudo apt install [INSERT_PACKAGENAME].deb” instead of this. The Packages needed are listed in the pastebin link.
copy the “lib”,“usr” and “etc” from this directory to the root directory (/) of your microSD. When prompted overwrite the existing files
WARNING: This might break some things. Everything I tried still worked but your mileage may vary.
This ONLY works when copying directly from a Linux desktop or another device that can mount ext4 filesystems. Using scp or other means to write the “lib” folder while the Gameshell is powered on WILL
LEAD TO A SEGFAULT OR KERNELPANIC. When using this, copy ALL the files.
leaving out some files will lead to missing dependencies. If apt did work for you before, THIS WILL PROBABLY BREAK APT, don’t use it!
My compiled Version of Quake:
And my compiled version of Duke Nukem 3D (eduke32):
Both have README.md files with installation instructions.
(These are only engine files. You still need the Quake/Duke3D game files from an original Installation of the game)
At this stage, the Lima drivers also will break with an apt upgrade. People have given steps to get around this above, but I’m honestly probably happy to have this as an internally maintained image that is incrementally upgraded and released as new images.
Since it’s mostly a static gaming device for the average consumer, apt upgrading shouldn’t need to be a day to day affair, unless something new comes out from the scene, or if someone is developing something themselves.
If it’s the former, I will add it in if it is seemingly fiddly for the average user, or particularly useful. If it’s the latter, I’ve tried to have all links and instructions easily accessible in this thread, so people can apply whatever has been mentioned onto their own image from scratch.
I’m definitively very keen in trying out and adding the quake and duke wrappers you’ve outlined above. Thanks for posting it! I know what I’m going to be doing tonight!
Yesterday I played around with apt and tried the fixes I suggested but I couldn’t get lima running again.
It says it’s using lima and so does retroarch but things are very slow.
I even cloned mesa and libdrm and did a new build but after installing it, it didn’t seem to change.
Also I started a mammoth-project of porting ArchLinuxArm to the CPI and i’m slowly making progress.
as I have no way to use the terminal on the gameshell I had to mount the SD and use qemu-arm-static and binfmt to run ARMv7 binaries and then Chroot into the image. Later after rummaging around the ClockworkOS image I was surprised to find out that this also seems to be how the devs set up ClockworkOS. Still having problems getting the xserver running but I’m making progress. When I got anyhing substantial cobbled together I open up another topic for it.
The etc/apt/sources.list file is still pointing to stretch. Given that according to a precious post, we need a newer Mesa, not found in the current stable release, we may possibly be running on a quasi Frankenstein build, similar to how you packaged your updated files.
The etc/apt/sources.list may need to be updated to bullseye.
I do remember video driver switching breaking upon doing an upgrade; buster at the time. Something probably went awry with the 00-arm-linux-gnueabihf.conf file. See below.
Were you doing an apt upgrade or apt full-upgrade? Just out of interest.
I haven’t had a look at the 00-arm-linux-gnueabihf.conf. Usually apt asks before making changes to config files.
I did an “apt upgrade” and “apt dist-upgrade” but that shouldn’t make much of a difference.
@CommanderKitler What I was thinking was re: apt full-upgrade (dist-upgrade) potentially also uninstalling packages, as opposed to just apt upgrade.
I’m guessing you’re upgrading to a stable release and not SID? Since the CPI OS comes with Stretch, and Buster is now the stable build, perhaps a full upgrade messed with something, possibly overwriting or removing it.
Re: 00-arm-linux-gnueabihf.conf, what I’m thinking is, the way the driver switched works might utilise putting each of the two drivers in temporary bak folders, shifting them in priority upon reboot. The config file need not get altered, but the makeshift directories/script might.
Realistically, nowadays I barely use the FBTurbo drivers, so would be content without the switcher. But that’s just a reflection of my own usage patterns.
@Laura Glad you sorted it out! I probably should also put some instructions, saying the *.bz2 file needs to also be decompressed. Hopefully it all runs well for you’
Yup I was upgrading to stable. I could try to replace all instances of the word “stable” with “stretch” inside /etc/apt/sources.list . That would make the OS stay at debian 9 instead of upgrading to Buster/10. If Buster is a problem, this would fix it and stretch is still supported until 2022.
The thing I find concerning is that I had lima break, not by apt updating, but by using apt to install additional packages that should not interfere with either the custom lima or mesa installation. It should not touch any of the libraries or config files used by these drivers yet it breaks them.
I don’t think that this is what is happening. The script for switching the driver is ~/launcher/Menu/GameShell/80_SETTINGS/Lima/ __init__.py
And The driver Switching part is the following:
if "modesetting" in cur_li._Value: ## enable lima
os.system("touch %s/.lima" % os.path.expanduser('~') )
ArmSystem("sudo mv /usr/lib/xorg/modules/drivers/modesetting_drv.so.lima /usr/lib/xorg/modules/drivers/modesetting_drv.so")
ArmSystem("sudo sed -i '/^#.*lima/s/^#//' /etc/ld.so.conf.d/00-arm-linux-gnueabihf.conf")
ArmSystem("sudo ldconfig")
else: #disable lima
os.system("rm %s/.lima" % os.path.expanduser('~') )
ArmSystem("sudo mv /usr/lib/xorg/modules/drivers/modesetting_drv.so /usr/lib/xorg/modules/drivers/modesetting_drv.so.lima")
ArmSystem("sudo sed -i 's/^[^#]*lima/#&/' /etc/ld.so.conf.d/00-arm-linux-gnueabihf.conf")
ArmSystem("sudo ldconfig")
pygame.time.delay(800)
os.system("sudo reboot")
It basically checks if the user has enabled modesetting/Lima, If so it creates a hidden .lima file in /home/cpi/
then it renames modesetting_drv.so.lima to modesetting_drv.so, so the OS recognizes it,
It then seems to add the /bin/lima entry to 00-arm-linux-gnueabihf.conf then waits 800ms and reboots the Gameshell. On boot The ~./profile loads ~/.bashrc loads ~/launcher/.cpirc which checks if the ~/.lima file is present. If thats the case, it runs xinit with the ~/launcher/.xorg_lima.conf
launching xorg with modesetting/lima enabled.
Neither the scripts nor the configs should be changed by the update.
My Theory:
What might be happening is that “apt upgrade” downgrades mesa to 18.6.3 and upgrades xorg so the modesetting.so.(lima) gets overwritten with a standard modesetting.so
So when it reboots it cannot run the lima driver installed, so it runs the mesa modesetting driver and uses something like kms_swrast.so . That way the lima driver stops working, the driver switch would only load the standard modesetting.so so it wouldn’t work either.
On the right there is the md5checksum of modesetting_drv.so of your custom D.E.O.T. image.
On the left a clone of that image running on my thinkpad inside a chroot environment after i did an “apt upgrade” The checksums don’t match so this file got changed via the apt update. The only file referenced in the driver/boot scripts that apt could easily change without notifying the user.
Still need to explain why the driver-switch breaks the lima driver. Maybe the modesetting_drv.so is incompatible with mesa 19.1 in both cases?
sadly backports doesn't contain mesa or xorg so using that won't work
Maybe updating to Buster and enabling backports to get mesa, libdrm and xorg. or even better, change from the stable branch to Stretch like I mentioned before and enabling stretch-backports-sloppy (bullseye packages for stretch). That way you would stay on debian 9 but could install bullseye packages with dependencies. I might try that with your image or a vanilla 0.4 image later and see if that makes any difference.
I am pretty sure that compiling the mesa or lima won’t do anything to the modesetting_drv.so, the modesetting_drv.so is from apt, so there is no lima modesetting_drv.so
