Good Morning from my Robotics Lab! This is Shadow_8472 and today I am pressing on towards my very own Nextcloud deployment beyond a proof of concept. Let’s get started!
Preparing an Account
Last week, I learned that Rootless Podman comes with certain challenges when trying to access a network drive. ButtonMash’s Rocky 8 Linux hard drive is tiny, so I don’t want to use it for storage. That leaves my retired laptop, “RedLaptop” for the job.
I use dedicated user accounts to isolate processes. The first order of business was to create a new account and log in through the Cockpit web interface. I had a bit of trouble when the underlying SSH couldn’t connect because Debian doesn’t like capital letters in its usernames, but the nonexistent, capital-containing username was flushed out while diagnosing user groups per advice on Discord. The account was additionally locked to prevent normal logins via password.
Preparing Containers
I’ve been developing a couple scripts for running Nextcloud on ButtonMash in a pod, so I copied them and the secrets directory (password storage) over to RedLaptop and tried them out. Errors galore! I downloaded the Nextcloud and MariaDB container images, but the older version of Podman (3.0.1 on Debian vs. 4.4.1 on Rocky 8) meant missing features – namely Podman secrets and mounting volumes on pod creation.
The secrets were easy to revert. I just had to remove the –secret flags and reinstate the passwords in surrounded by quotation marks. Unlike best practices in later versions, volumes mounted nicely into their respective containers. I double checked one with
podman inspect <container ID> | grep -i volume
and found references to the correct volume.
New Territory
At long last, I made it to the Nextcloud installation screen where I need to make an admin account. From here on, all I know comes from the little scouting I did way back by using an SQLite database hosted offered from the Nextcloud container as opposed to a more capable one.
I got an error about failing to connect to the database. I found a username with a capitalization error and I didn’t actually have a named database created within MariaDB’s container. But even with both of those fixed, I kept getting kicked back to Nextcloud’s create-an-admin screen.
And here my research for the week runs out of time. MariaDB’s log shows two errors I suspect to be the root issue:
<timestamp> 0 [Warning] mariadbd: io_uring_queue_init() failed with errno 1 <timestamp> 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
Takeaway
I so want to be done with this project. That is all.
Final Question
I am left without a solution for now. For all I know, it may be low RAM, which I’m already maxed out on for my model of laptop – meaning I’d need to start over again with something else. If anyone has any ideas, I’d be happy to hear about them in the comments below or on my Socials.
Good Morning from my Robotics Lab! This is Shadow_8472 and today it’s bully or be bullied as I take another swing at getting my Nextcloud instance even partially usable. Let’s get started!
If there’s one long term project of mine that just loves humiliating me, it’s getting Nextcloud operational. My eventual goal is to have it running in a rootless Podman container with a way to quickly move it to an auxiliary server. My strategy thus far has been to prepare three Podman volumes hosted on GoldenOakLibry (NAS) over NFS while accounting for the speed needs of the MariaDB and Nextcloud volumes with an SSD and vs the capacity needs of the PhotoTrunk volume with a RAID 5 array of HDD’s.
NAS: Network Attached Storage
NFS: Network File System
SSD: Solid State Drive
HDD: Hard Disk Drive
Lowering Expectations
I’ve lost count of how many times NFS has given me grief on this project, so I eliminated it. I moved the SSD from where it was on GoldenOakLibry to ButtonMash, my main server computer. I added it to /etc/fstab – bricking Rocky Linux. ButtonMash is dual booted, so I booted to Debian for repairs.
Rocky’s installation system uses an LVM2 format, which Debian can’t read by default. An LVM2 package exists, and I installed it. LVM2 partitions show up in lsblk as sub-partitions of an actual partition, and it is these sub-partitions that get mounted, for example:
sudo mount /dev/rl_buttonmash/root /mnt/temp
to mount the sub-partition that shows up as rl_buttonmash-root. While I did explore for a quick fix, it’s a very good thing when each side of a dual booted machine can repair the other. Mounting a file system is a very important tool in that kit.
Upon closer inspection, a contributing factor to bricking Rocky was the root account being locked. The computer booted into an emergency mode and got stuck in a loop ending with “Press ENTER to continue…” Unlocking it didn’t get me anywhere when I looked at the logs per the loop’s recommendation, but the command lsblk -f clued me in that I was mounting the drive using the wrong file system type, an error which was soon remedied after I discovered it.
Project Impossible
The move hardly seemed to fix anything as hoped. I didn’t solve much. I kept getting NFS related errors when trying to run the pod, even after moving to a new mountpoint I’d never touched with NFS automounts. I even tried mounting the volumes using hard links pointed at the mounted “data drive” and I still couldn’t get a working Nextcloud instance. Somewhere in my shambling among the apparently limited content available regarding this topic online, I found the following warning on Oracle’s Podman documentation:
Caution: When containers are run by users without root permissions, Podman lacks the necessary permissions to access network shares and mounted volumes. If you intend to run containers as a standard user, only configure directory locations on local file systems [1].
Rootless Podman lacks network share permissions. OK, so NFS out unless I can selectively give Podman network permission without going full root. Until then, Podman is limited to the local disk, and if I’m understanding this warning correctly, mounted drives are also off the table. My plans for a Photo Trunk upgrade may be grounded indefinitely, and with ButtonMash’s Rocky drive being only 60GB, I’m not looking to burden it with anything resembling bulk storage.
Takeaway
The next logical innovation would be to rebuild the project on a computer with more storage. Barring a full makeover of ButtonMash, I do have my Red Laptop as an auxiliary server. I made a new account, but in all reality, this inspiration came after my research cutoff. It’s a project for another week once again.
Final Question
My project directory is messy with scripts to the point where I started a README file. Have you ever had a project so involved as to need one?
I look forward to hearing about it in the comments below or on my Socials.
Good Morning from my Robotics Lab! This is Shadow_8472 with another installment of How I would Relearn Linux, a series where I drop tips about the lessons I’ve learned writing about Linux. Let’s get started!
Document Your Work
This blog has been invaluable to my self-studies of Linux. The weekly push has been vital to keeping my various projects alive. If I were relearning Linux, I would highly recommend blogging as one thing I got right early on.
At the same time, another medium might be right for you. The Linux community self-propagates through everything else from videos and books to forums and chat rooms. A private journal would not be inappropriate – as a matter of fact, if I were relearning Linux, I would write for a few months directly into a word processor and buffer it on a hard drive while I research a host, domain name, and blogging software. Whatever you medium or two are suitable to your talents will provide you a resource to look back on later.
Audience and Frequency
Let’s take a closer look at my own blog as an example, Let’s Build Robotics With Shadow_8472. My content is online for the world to see, but my primary audience is myself as I write. I’m of course excited to talk about my projects, but if I cared about having a constant stream of fans jabbering away about me, I would have either paid closer attention to audience building or given up long ago. My main purpose is to give myself a regular push to learn.
The one piece of advice I’ve followed closely is consistency. I’ve posted Mondays at noon (Pacific) with few accidental exceptions since learning to schedule posts. Not every post is my proudest work, but that’s OK. Progress is slow with projects outside familiar parts of my niche. When projects turn out to be much bigger than I judged, I can talk about what’s not working, call it “Part 1,” and hope someone has a solution. If all else fails, I’ve afforded myself the flexibility to switch to a smaller topic when I burn out. It will be there in a month when I return.
Takeaway
This blog remains one of the most important pillars of my continuing to develop my Linux skills. I would totally recommend something similar for anyone looking to learn a technology skill.
Final Question
How do you record your long-term progress?
I look forward hearing your answers in the comments below or on my Socials.
Good Morning from my Robotics Lab! This is Shadow_8472 and today with a continuation of my project involving the open source game Space Nerds in Space. Let’s get started!
Previously
Two weeks ago, I found Bodhi Linux, a low-weight Linux distribution based off Ubuntu. I used it to compile and run [poorly] a game called Space Nerds in Space (SNIS) on an aged system from a church office.
My Own Space Nerds Distro
I had it all figured out until I had a brilliant idea just minutes before I was sitting down to pen last week’s post. I’d carefully researched and ordered a set of thumb drives to host enough Bodhi installations for a full SNIS bridge on a keyring. I’d have spent a paragraph comparing and contrasting the merits of uniquely colored sticks vs. sticks with both A and C connectors vs. low profile sticks, and a sentence or two about not getting so low a capacity that the case and connector are the major contributing factors to the price (low profile/64 GB, by the way). My project was done except for one small idea: use Ventoy.
Sooner or later, I will update my SNIS bridge, and I’d just as soon maintain a master copy and propagate changes over to the other chips –slim operating system and all– as a bootable .iso disk image. SNIS does not need persistence, so it should be more than happy running out of a live image.
The catch point from last week was in remastering Bodhi. Its official tool doesn’t work in the current version, and so was omitted. I was learning Linux Live Kit and working with its dependencies, but I ran out of time. The afternoon after posting, I coaxed Linux Live Kit into producing an unoptimized image, but I ran out of space on the stick I was working with.
I want to squeeze as much performance out of as little computer for this project as possible. From tests last time, my weak link was memory on the graphics card. Well, how nice would it be if this hypothetical Linux distro didn’t waste system resources on such things as a full desktop environment? I’m comfortable enough on the command line. Assuming I can bully the game into running from the command line, it shouldn’t be difficult to boot straight into the game. If I’m clever, I can have the live distro self-assign a static IP based on a text file sitting beside its .ISO so a router isn’t even strictly needed to play.
Debian/Cage
But I’m dreaming months in advance, and I know it. I made an attempt to slim down Bodhi before switching to Debian 11, the latest version of Debian without a desktop environment (installing over the same small 8GB USB stick from last time). Upon request of various error messages while recompiling SNIS, I had to add packages for git, make, and wget, tools that commonly come with more fleshed out Linux installations.
In the spirit of forward compatibility, I explored Wayland compositors and found one called Cage. Cage will display a single window in full screen and close when no longer needed. It’s perfect for my application… It isn’t in the repository for Debian 11. Debian 12: yes. I went through the effort to try compiling it, made some decent progress while learning about other compilation tools (through downloading/compiling them, naturally), but slammed into a wall of dependencies trying to arrange for a library dependency of something. I got farther with Debian 12, but SNIS wasn’t happy running in Wayland. Furthermore, testing with SuperTuxKart told me I was having issues with keyboard/mouse inputs making it through to programs running in Cage. I eventually scrapped Debian for the short term and went back to Bodhi.
Why just SNIS?
I’ve spent a lot of effort focused on SNIS, but I’ll expand my potential audience if I include a number of open source games. SuperTuxKart (STK) is also ton of fun and has a lower burrier to entry. While it would be nice to compile the latest version of everything each maintenance cycle, some version of STK is in most every major Linux repository.
I spent some time researching other FOSS multiplayer LAN games for Linux without persistence. I found that I had underestimated the trope of “aim gun, shoot enemies.” I’m not opposed to the first or second person shooter genre on principle, but I did narrow my search to exclude graphic violence and the couple horror offerings I also found. I also came across an instance of a game where the engine was open source, but the art, level layouts, characters, and other assets were of mixed licensing that don’t fit with my vision for this project.
Takeaway
I went in another full circle this week. I’ve had some great ideas, but if I expect to have something to show on this project before I lose motivation, I’ll have to arrange my inspirations on a roadmap. For now, I need to focus on learning at least one Linux remastering tool, and game selection/kiosk mode can wait for later.
Final Question
Digging through a freeware list, I found another couple games I’ve played and had a good time with and a few more I’d be willing to try out. What free and open source games would you play at a party?
Good Morning from my Robotics Lab! This is Shadow_8472, and today I am starting a new series where I drop a beginner-level tip whenever I have a project change direction last minute. Let’s get started!
Multiboot USB
The biggest barrier to entry for installing Linux is creating your first installation media and booting to it. These days, it looks like downloading a program like either Rufus or Balena Etcher and burning a USB thumb drive with a 1 to 4 GB .ISO file, almost always turning the rest of your 8 to 64 GB USB drive into dead weight. If you intend to continue exploring Linux, it’s easy to get in the habit, and soon you will have a collection of spent USB drives mucking up your search for the one drive you saved to transfer text files or pictures.
The solution is to get a large USB and multiboot it using a utility like Ventoy or YUMI. My experience was with installing Ventoy from Linux, and it was as simple as creating any other USB-based bootable media. Since then, whenever I am instructed to “burn” a .ISO file to disk, I just copy it to Ventoy and it shows up.
What’s more is while I was researching for this post, I learned that it even comes with a Windows installer. As usual, be sure to offload any files you wish to keep as they will be lost while setting up Ventoy.
Takeaway
I consider my Ventoy USB to be the most useful tool in my possession. I highly recommend it for anyone learning Linux.
Final Question
With the entire array of Linux distributions to try out, which ones do you keep around on your master USB drive?
I look forward hearing your answers in the comments below or on my Socials.
Good Morning from my Robotics Lab! This is Shadow_8472 and today I am working on one of my smaller dream projects: a bridge simulator. Let’s get started!
Space Nerds In Space (SNIS) is a LAN game for Linux available as source code hosted on GitHub [1,2]. In it, you and several friends take on the roles of a starship bridge crew manning your stations and going on sci-fi adventures in deep space.
LAN: Local Area Network
I have access to an old church office computer with Windows XP installed. I’m gonna try running it on there. The main site [1] recommends against trying anything less powerful than a Raspberry Pi 4B, but I want an idea of how low the game can go. I’ve set my expectation to “This computer has absolutely no business running this game.”
In old or low-end machines, the weight of an operating system often becomes a significant contribution to resource consumption. At the same time, both low-overhead distros I’ve worked with before (Tiny/Micro Core and Puppy) have specialized package managers, and I’m not up to a self-guided crash course on repositories this week.
My first thought was that I’d prefer access to AUR for an “one-click install,” like how I cheesed it into working on Manjaro. I located an 8GB thumb drive, but the old church computer didn’t appear to be a fan of booting Manjaro. Instead, I researched low-overhead distros which could cleanly install packages from apt. I came across DebianDog Linux which sounded perfect until I learned development had stopped and shelved the idea as a backup plan. Puppy –as I learned– already has the means to use .deb files, so I stashed that as another backup plan in my recent experiences with Puppy, it has to be told to connect each boot.
AUR: Arch User Repository
Bodhi Linux
Further research found me Bodhi Linux, an Ubuntu derivative with downloads as light as 747MB and RAM requirements well under a gigabyte. Its native apt support means access to a large selection of standard packages, which will come in handy when compiling software.
I found my way onto the Bodhi Linux Discord server, where I reported the Arch logo of all things showing up in the installer. After I provided a screenshot from a staged second installation, we figured it was a bug with the installer Bodhi borrows from Ubuntu.
My installation was a success. I found the Moksha desktop maintained in-house [4] to be surprisingly polished, but a bit too flashy for my needs. Were I moving into it as a daily driver, I’d be disabling the animated taskbar icons. The terminal visual bell would also have to go, as I about hear sirens whenever I trip it – and I trip it frequently with my liberal use of tab to complete. I did –however– get around to removing Chromium.
Installing Space Nerds
This was neither my first attempt compiling SNIS nor my first time getting a product out the end, but it was my first time successfully doing so manually. I installed git and cloned the SNIS repository. I passed up my previous attempt by using util/install_dependencies as opposed to finding/installing dependencies manually. My first attempt at opening the compiled program I was… met with a solid green window and the computer crashing hard. I never figured out why, but on attempts where that didn’t happen, I had to wait through a 5 minute, 30-40 second loading screen where I realized later how lucky my second attempt was to have not ended in a massive flicker between black and the desktop – and this second attempt ended in a display of erroneously rendered polygons after a few minutes of play.
I inquired as to SNIS’ minimum system requirements on GitHub [2] and smcameron, the game’s creator, kindly helped me get it “working.” You can read the full discussion here: https://github.com/smcameron/space-nerds-in-space/discussions/333, but to summarize: I provided a number of logs documenting various error states and we figured my graphics card was running out of memory, as I didn’t get a light show when using lower resolution planetary textures.
Takeaway
This computer has no business running SNIS, yet it runs – if only barely. My fun this week was in coaxing this game to running on such an outdated system.
Final Question
What is your go-to low-overhead Linux distribution?
I look forward hearing your answers in the comments below or on my Socials.
Good Morning from my Robotics Lab! This is shadow_8472 and today I am exploring the feasibility of running SimCity on Linux. Let’s get started!
Short Answer
SimCity 3000 Unlimited refused to run for me. I suspect DRM. I tried the earlier SimCity3000 (1999) on PopOS, EndeavourOS, and Linux Mint through Lutris with progressively worse results. Of note: I found it important to enable dgvoodoo2.
DRM: Digital Rights Management
Have fun. Good luck. You’ll need it.
My Attempts at SimCity3000 Unlimited
While digging through Garage Space, I happened across a copy of SimCity3000 Unlimited. This city building game of yesteryear puts you in the role of mayor and city planner of a city. You must balance zoning, manage public streets, power, and water service, clean up after disasters, and more as you fight to keep your budget in the black. The case says it’s for Windows 95/98, but I remember it running at least as recently as XP.
Gaming on Linux has a fascinating history. In short: the userbase will sometimes “cheat” Windows games into running through the WINE compatibility layer, though it doesn’t always work. Lutris is a multi-game launcher that makes WINE a lot more approachable. I figured there would be no harm in popping the CD in a drive and trying it out. Like all my previous attempts to install a game manually in WINE, I had little-to-no luck.
My efforts were soon split multiple directions. DosBox is a DOS virtual machine. I found a fork called DosBox-X, which claims to run Windows programs up through the 3.x era as they’re basically just fancied up DOS applications. Windows 95 made some major additions, but was still built on DOS until XP dropped it as a base. Consequently, if our Windows 95/98 CD’s/product keys were to show up, they could be installed into DosBox-X and we could again play our period games.
Garage Space was not so kind. With help, I located a bucket each of 3.25” floppies and CD’s. A further CD binder turned up full of drivers, but no Windows 9X install disks. In one of these caches, the original SimCity3000 turned up.
My Attempts at SimCity3000
This earlier version of Maxis’ once flagship game installed nicely on Derpy Chips running PopOS, but failed miserably at anything past the main menu until I turned on dgvoodoo2 under Lutris’s “Runner options” under the game’s configuration popup. I found it very playable, but sound effects were only in my left speaker channel and I got a nasty buzzing sound in the right speaker/headphone if I turned off the music the way I preferred to play.
Moving on, I attempted a more advanced installation on my Upstairs Workstation, where I created and mounted a disk image on my hard drive. This configuration had a better response time, while still requiring the actual CD to be mounted. Unfortunately, there was a serious graphical issue that affected the main menu, all textual popup boxes except the No-CD notification, and the in-game sidebar sub-menus. It’s like animation layers render black instead of clear. The main menu and text boxes mostly look strange, but are perfectly usable. On the other hand, the in-game sub-menus render as black bars and only show their buttons when hovered over. This arrangement might work for someone who is desperate.
Additionally, I tested SimCity on my father’s computer running Linux Mint. The game would not even install to the prefix; a usable, but slightly graphically glitched launcher was all I got. No matter what I tried on any system, I could not improve its respective base issue. In a last-ditch effort to get it working for my father’s computer, I attempted to copy over my WINE prefix from Derpy, but when I found its debug and pasted a prominent error into a search, I learned how WINE’s Intel integrated graphics support is incomplete and unlikely to ever see completion.
Takeaway
This is a progress report. At present, I believe my issues have to do with AMD vs. NVIDIA vs. integrated graphics. I don’t know if I will follow up or not. The main conversation online around SimCity3000 and WINE is focused around the edition from GoodOldGames. The Unlimited edition on CD has practically zero heartbeat – probably because its DRM is incompatible with WINE, like many games not on lists maintained by Lutris or PlayOnLinux (another WINE tool I tried out, but didn’t remember while weaving my narrative). I also learned of a Linux port of SimCity3000 [and Unlimited] by Loki Games through a script for getting it to run on “modern” versions of Linux as of a few years ago, but it went bankrupt reportedly due to piracy.
Running Windows games on Linux is a puzzle. Your particular one may come pre-solved or there might be pieces entirely missing. I am very proud of my first-ever successful “manual” install, even if I used a tool and it still isn’t perfect.
Final Question
Do you know of a good place to learn WINE? Have you had any success playing SimCity on a Linux system?
I look forward to hearing from you in the comments below or on my Socials.
Good Morning from my Robotics Lab! This is Shadow_8472, and today I am offloading Space Engineers from Manjaro to EndeavourOS. Let’s get started!
Short Answer
I used Glorious Eggroll’s community version of Proton [1], but the AI update this past week and now requires a blank registry key or two added to its prefix. See the section titled “GAME UPDATE!!!” down below.
EDIT 4-18-2023: The development team just released a Hotfix in update 1.202.067 fixing the issue. 2/3 of my post is out of date only 14 hours after publication.
Background
This is a follow up/update to both last week –where I finish moving into a new EndeavourOS installation– and a post I wrote on January 18, 2021 [2], where I installed Space Engineers on Manjaro Linux and go into some detail about WINE, Proton, and the lengthy struggle I went through to install it there without fully understanding what I was doing. In case the specifics help anyone, I am running Space Engineers 1.201.014 default (Most Wanted update) on Glorious Eggroll GE-Proton7-54 on EndeavourOS with an Nvidia Geforce 970 graphics card.
I know what I’m doing a little better this time around. I even got it working first try. But that doesn’t mean I understand how everything works inside. There was an update to Space Engineers some time after my 2021 post that introduced a bug related to the audio system that would crash the game after anywhere between 5 minutes to 2 hours (ballpark average of half an hour). I was never able to diagnose it beyond a since-forgotten Discord post noting that the crash is an audio-related bug, and that it can be fixed by ripping open the .exe to kill the sound system. I happen to like sounds, so I accepted it until I gradually stopped playing.
The Dotnet Tradeoff
In more recent days, a member of the community going by G3ckobot on the developers’ Discord (Keen Software House) identified this crash as related to dotnet48, which I was quite possibly using as it showed up in a guide I linked to on GitHub I tried to follow. In my new installation, I went straight for Glorious Eggroll, and while the trade-off, as G3ckobot put it, is worse performance, the improved stability using the default wine-mono is worth it. He also suggested disabling progression in world settings to fix some lag related to the “G menu” for selecting blocks for your hotbar.
Crashes aren’t the only change I’ve noticed improvements with. The main menu plays videos like it’s supposed to. “Inventory Full” doesn’t self-overlap or cut off. Even “Exit to Windows” doesn’t throw a crash anymore. On the topic of miscellaneous bugs, there’s a new hint of static sometimes when I finish welding something.
A Note About Ship Blueprints
I’ve had one long-term goal while playing Space Engineers, and that is to perform a grand tour of the Solar System map before doing much else. I want to visit every planetary body once – even if just for a touch and go. My first attempt had a worker ship I was quite fond of designing, so I went to fetch it from my old save.
Like with any long-file path file transfer, my first move was to explore the destination directory.
When I navigated to the counterpart on Manjaro, I found myself in the exact, same place. I even made a file using the touch command in one place and it showed up in the other! A closer inspection of my file path showed that ~/.steam/steam is actually a symbolic link. Symbolic links have no concept of being mounted into another file system, so when I followed it, I landed right back in EndeavourOS’s copy of Space Engineers. It pointed to /home/shadow/.local/share/Steam, which I had to manually follow. I had to look around to find ../steamuser/Application\ Data/SpaceEngineers/, but in the end, it imported just fine.
GAME UPDATE!!!
The AI update arrived this week, and my installation broke after I was all but done writing.
Missing prerequisites There is missing required C++ package. You have to accept elevation dialogs from the Steam to install prerequisites.
Within 20 minutes, I was the first one reporting it on Discord. The server went into a flurry of activity as community members pooled skills over the next four hours. A few facts were soon apparent: there are a lot of C++ packages, no logs were of help narrowing down the missing one, beta builds were working fine with Proton right up until the update dropped. I was busy with more important matters for most of it, but by the time I came back, user opekope2 posted [3]:
HERE'S THE WORKAROUND 1. Install and run protontricks 2. Navigate to SE > default prefix > regedit 3. Under HKLM\SOFTWARE\Classes\Installer\Dependencies, create Microsoft.VS.VC_RuntimeAdditionalVSU_amd64,v14
Community consensus was that an unused dependency was listed last-minute –perhaps accidentally– that wasn’t commonly included in Proton. Since the dependency isn’t actually called, it’s OK to add a fake entry in the prefix’s registry. How to get that fake entry in there can get tricky.
How to use Winetricks instead of Protrontricks
Protontricks is a version of Winetricks geared for managing Proton prefixes instead of Wine prefixes. Protontricks is in AUR but didn’t feel like installing anything from there properly. Instead, I made a symbolic link from ~/.wine to my Proton prefix and told Winetricks to load the “default” prefix. Note: I heard good things about Proton Experimental, so I switched to it from Glorious Eggroll.
AUR: Arch User Repository
cd ~ mv .wine .wineDISABLED ln -s .steam/steam/steamapps/compatdata/244850/pfx .wine cd .wine
Errors about .wine and “No such file or directory” can be ignored. It just means you don’t already have a default Wine prefix. If you get an error when trying to cd into .wine, that means you will have to find where Steam puts games on your distribution and change your file path accordingly.
If everything is good so far, It is a very good idea to back up your prefix if you aren’t working with a clean one or wish not to redownload it.
cp ~/Full/Proton/Path ~/.SEbackup
Ensure both Space Engineers and Steam are closed. Start Winetricks. Select “Select the default wineprefix.” The link you created and tested earlier will fool Winetricks into looking at Space Engineers’ prefix. Click OK.
Next, select “Run regedit” and hit OK.
Navigate in the registry editor to HKEY_LOCAL_MACHINE\Software\Classes\Installer\Dependencies.
You the Classes folder is long. Once you scroll down to Installer and find Dependencies, you should see two keys with the folder icon (my screenshot already has the extra key). Bring up your context menu and make a New Key and name it Microsoft.VS.VC_RuntimeAdditionalVSU_amd64,v14. Do not worry about adding a value.
Space Engineers should start up now, but you may have to try a few times before you start/load a game. My record is 4. After you confirm Space Engineers is working, be sure to remove ~/.wine link and replace your original default wine prefix if you had one before!
rm .wine mv .wineDISABLED .wine
Takeaway
I’m no stranger to easy projects expanding on me, but this was dramatic! I tried to keep up with developments in this story until the night before publication. Opekope2’s original workaround post is pinned and has been edited to include instructions for importing two keys* that will do the same job as editing the registry manually as demonstrated. As a personal experiment starting around the time this goes live, I’m adding the other key manually. I don’t expect anything to change, but as opekope2 pointed out to me, “Because that’s how it is on Windows,” [3].
* Microsoft.VS.VC_RuntimeAdditionalVSU_amd64,v14 and Microsoft.VS.VC_RuntimeMinimumVSU_amd64,v14
Final Question
Have you gotten whatever latest update of Space Engineers running on Linux? If not, I highly recommend you engage with the community on Discord [3].
As always, I look forward to hearing about your experience.
Good Morning from my Robotics Lab! This is Shadow_8472 and today I am fixing/installing NVIDIA drivers on my Upstairs Workstation’s EndeavourOS installation. Let’s get started!
Short Answer
EndeavourOS has an NVIDIA installation script in the repository. It worked beautifully with my GTX 970, but I gather I am on the older side.
To my readers installing NVIDIA: I bid you good luck and look forward to hearing about your experience. I found precious few relevant search results about this topic aside from EndeavourOS’s admittedly confusing site, and my hope is that I’ve pointed you in the correct direction. If that doesn’t work, I have another of their articles in my Works Cited.
For my regular readers: wow. I don’t have many first attempt projects. Granted, this is technically a well-researched second attempt. One draft only had 100 words between title, introduction, and delivery (down to 75 in this cut, according to LibreOffice Writer). For now, I am thankful I didn’t have to learn what all the hype is about firsthand over installing NVIDIA on Arch .
EndeavourOS went on very smoothly earlier this year until after I installed Steam. My boot sequence would then stop updating where it normally hands over operations to the graphical server. The community helped me trace the problem to repository-installed drivers. I had to use the camera from the lab’s photo booth for pictures of TTY terminals. I let the project go dormant for a month while I focused on Nextcloud, but then Manjaro filled up its hard drive again while updating, and I was out of stuff to offload. (After I finished research this week, I installed Filelight and noticed several unused Proton versions taking up space.)
Listed in EndeavourOS’ features is “Nvidia installer.”
“A terminal-operated app that lets you easily install the right Nvidia driver and/or hybrid set-up required for your machine” [2]
Every other item on this feature list came pre-installed. Over the course of a couple late-night hours, I learned first about an older script called nvidia-intro. It reportedly works with cards made around 2010 and newer, such as the GeForce 930 [3]. I bounced around among what forum offerings my search turned up before settling on the link I shared from the start. Once installed, it was completely automatic. It needed a root password for installation proper, but the script itself does not run as root.
Takeaway
Normally, I would have combined this and next week’s similarly short topic since I am again working on my Upstairs Workstation. However, thinking about it from the perspective of someone searching online for help, it makes the most sense to split them.
Final Question
Have you done battle to install video drivers? I would like to hear about it in the comments below or on my socials.
[2] B. Poerwoatmodjo, J. Kamprad, and Manuel, EndeavourOS, “Welcome to EndeavourOS”endeavouros.com, [Online]. Available: https://endeavouros.com [Accessed April 10, 2023].
Good Morning from my Robotics Lab! This is Shadow_8472, with a stubborn-project update. Let’s get started!
Nextcloud as a project comes with a lot of strings and hooks. Every time I sit down to work on it, the feature creep closes in: multiple volumes for speed and capacity, MariaDB container so SQLite doesn’t choke serving clients, a pod for MariaDB to live in alongside Nextcloud, Redis for RAM caching (Out of my scope, but worth a mention), Ansible Vault for password management (automation tool I’d need a month to learn), podman secrets, Philomena image board software – not to mention the volumes I learned about the other week! As noted in previously, the container I’m using from docker.io can take care of itself, but it will work a lot better with even a few of these things.
In my ideal configuration, all my containers’ persistent data lives on GoldenOakLibry so my old, red laptop can take over on critical Podman containers when ButtonMash is booted to Debian for photo scanning duty. The big, hanging question then is if GoldenOakLibry’s internal HDD’s absolutely need to spin up to serve shares hosted on NAS volumes mounted from an external SSD.
HDD: Hard Disk Drive NAS: Network Attached Storage SSD: Solid State Drive
My initial tests involved verifying that a drive could be mounted externally, then rebooting the NAS. I was expecting either a 1 or a 50 second wait, but instead I kept hitting “Stale file handle” errors when I tried mounting the external share. My second round of trials a week or two later exhausted search pages worth of results to learn how NFS shares change a few invisible details when restarted. Either something wasn’t ready when needed during boot, or my client just needs a while to refresh those details. It works in the long run, and external shares are not dependent on internal disk spinup. Time to move on.
Having solved the last known problem, I started layering the bits I had solved while frustrated with the USB share. I prepared three Podman volumes: two for Nextcloud prioritizing high-capacity and speed, respectively, and one for an SQL database. A pod housing MariaDB (the SQL database) and Nextcloud containers mounts these volumes (!). Podman secrets safely injects the database password so MariaDB and Nextcloud can work together – not strictly necessary for my application, but a good habit to get in in case I go in the direction of creating images from existing containers. Once the cloud is running, I want to try adding an image board to view the pictures.
(!) NFS –as it turns out– does not appreciate a number of the acrobatics rootless Podman performs with Namespaces. I don’t have the specifics memorized, but when Podman makes a container, the host’s user ID is mapped to root within that container. Podman then assigns variations of the host’s user ID to non-root users within the container as defined by a namespace. The NFS protocol wasn’t designed with namespaces in mind. To NFS, it looks like you’re trying to access another user’s files – possibly without permission. While this reportedly doesn’t stop rootless Podman from working well over NFS over normal circumstances, there are a bunch of search results talking about the snag when working with container images over NFS. Based off my experiences for this post, the same appears to hold true for volumes.
Takeaway
As much as I wanted this to be the last installment, this issue is a post in and of itself, and I’m getting burned out again over trying to come back to it. I’ll try coming back to this in around a month or so.
Final Question
Have you successfully used Podman volumes over NFS? Please, do tell me all about it in the comments below or on my Socials.
