Migrating to Gitlab & xorg errors

With the recent news of Microsoft purchasing GitHub, I’ve increasingly been wanting to try to port all of my repositories over to GitLab. And believe me, it’s super easy and totally worth it!

Once you’ve signed up for GitLab, you can click the “add project” button in the top right by the search bar. It’ll pull up a page where you can enter normal repo information, but there are also tabs that show different options:


The Import Project tab is what you want!
Gitlab’ll give you some options from there:screenshot.png

And you can choose where you’d want to import from.

I imported all my GitHub repositories, and that was great…until I realized all of the cloned repos on my laptop are still connected to GitHub. So how does that work? It’s not too hard.

Just find the repository you want pushing to Gitlab instead, and run these commands:

git remote remove origin
git remote add origin https://gitlab.com/username/projectname.git
git fetch --all

And boom! Everything is all ready to go ๐Ÿ™‚
(sourced from: https://stackoverflow.com/questions/20359936/import-an-existing-git-project-into-gitlab)

On another note, I’ve been getting odd errors in my terminal when I execute programs that require a display, like Rofi, pcmanfm, and more.

Failed to open display: (null)
Cannot open Display
And finally, even xorg errored,
xorg: giving up

After some hunting, it seems like all I had to do was reinstall xorg.

sudo apt-get install --reinstall xorg

Then a reboot fixed those errors right up ๐Ÿ™‚



Ubuntu Server and RTL8192CU driver

Sup hackers!

I finally got around to setting my server back up again with new hard drives, and this time a new operating system as well.

Jay gave me 2 server hard drives as a graduation present, as mentioned in my previous post, so I tested those and installed the one that was working into my server. Here are some fun pics:




I attempted to load Ubuntu server onto the server with a USB, but I kept getting the error linuxiso.bin is corrupt or missing.

Uh oh.

After getting nowhere researching about that, I ended up burning the Ubuntu Linux Server ISO to a DVD and installing from there, which worked splendidly. I plugged the server in and that familiar purple screen popped up asking if I wanted to install the server.

That started the process of the download, just following the instructions on what you want the hostname to be, what hard drive you want the OS to occupy, etc. I did run into errors where the OS wouldn’t install, but a quick plug into the router with an ethernet cord fixed that right up. Yay!

After that, I had the joy of figuring out the Edimax 7811Un wifi adapter again. Remember the pain from last time? Yeah, this was a completely different setup so I had to throw all that experience out the window.

I found some documentation and stack overflow posts that hinted at a git repository you had to download due to some errors in the Ubuntu drivers:



I initially followed the latter stack exchange post, but ran into some issues.

sudo apt install linux-headers-generic build-essential dkms git

git clone https://github.com/pvaret/rtl8192cu-fixes.git

So far so good…

sudo dkms add ./rtl8192cu-fixes

and finally, my first error came from this command:

sudo dkms install 8192cu/1.10

It said something along the lines of 1.10 being nonexistent. A quick cd into that directory let me know that there was an updated version, 1.11, so I used that.

sudo depmod -a

and then you were supposed to blacklist the native kernel driver with this command:

sudo cp ./rtl8192cu-fixes/blacklist-native-rtl8192.conf /etc/modprobe.d/

But after rebooting, nothing happened. It wouldn’t recognize the driver at all. After researching more and rebooting about 10 times, I still couldn’t figure it out. I followed all the instructions correctly.

And it was time for bed, so I gave it a rest.

Today, I found some sort of helpful posts, but none of them addressed why the wifi adapter wasn’t being recognized. So I put on my debugging hat and tried to poke at the issue from a different angle to see if I could get any information that way.

I poked around with lsmod | grep rtl8192cu , but that returned nothing, so I tried to activate the driver with sudo modprobe rtl8192cu , but still that did nothing.

It was literally by a chance of mistype that I discovered the errors of my ways.

lsmod | grep 8192cu returned a line that said the driver was active!

So getting rid of the rtl at the beginning was apparently the right thing to do.

That means I had the correct driver, but perhaps the older one or the kernel was overwriting it. That means I had the blacklisting done wrong, so I cd‘d into /etc/modprobe.d/ and deleted the blacklist-native-rtl8192cu.conf file.

I noticed there was a singular blacklist.conf file in there, so I sudo nanoed into that and discovered a whole list of blacklisted/ignored devices. Perfect!

Scrolling to the bottom, I added,

blacklist rtl8192cu with a comment above it telling why I was blacklisting it in case I ever needed to reference that again. After saving and quitting, I rebooted the server.

Lo and behold, the little blue blinking light on the adapter was resurrected from the dead. WOO!

But….now I had to actually get it connected to the internet. Because this was a brand new install I didn’t have nmcli on there yet, so:

sudo apt install network-manager

Then to scan the name of the edimax adapter, I did:

nmcli dev

Which showed me a short list of all the ports my server can use to connect to wifi. There were two ethernet ports, a loopback, and viola, a wifi!

It was a long device name though: wlx74da38bd6202

That was fun to type over and over.

To check the status of the adapter, I followed this series of commands:

iw wlx74da38bd6202 link :: which returned no connection.
nmcli dev wifi list :: which returned a list of the SSIDs.

To connect to the network:

nmcli dev wifi connect SSIDNAME password ACTUALPASSWORD

and with that, you should be able to ping to see whether or not you successfully connected!

I pinged, but I got the error saying Reply From < IP address >: Destination Host Unreachable

Oh no. Was something broken?
After some digging around through stack overflow again, my life was saved by a comment in this post:


in case anyone else lands here I figured it out: My Linux server was configured with an Ethernet interface with static IP (which I pulled the cable out of once wifi was working) and a Wireless interface that was actually connected. Because of the static IP the Linux server saw the Ethernet interface as still enabled even though it didn’t have a cable any more, and (I think) was trying to reply to my Wireless ping on the Ethernet interface… or something like that. Disabling the Ethernet interface fixed it, anyway! ~ Matt

Bless you, Matt.

I went through the names of the ethernet ports I saw in nmcli dev, and disabled them one by one with sudo ip link set DEVICENAME down .

After a ping once more, packets were successfully being transferred back and forth! Yayy!!

Now I can set up my SSH ports and webserver and possibly a game server for hacking this one special game if you guys are lucky…


Of HDDs, SSDs, Towers, and Crossbows

Sup nerds!

Been a while since I posted a thing. Graduation is nigh, as is my work schedule, so I haven’t had a ton of time to work on projects.

At the most recent nerd hackout with UTW, one of the nerd’s brothers gave me a tower computer! I also received old server hard drives from a fellow hacker as a grad gift. Totally awesome. ๐Ÿ˜€

Today has been the day of testing all the SSDs and hard drives I’ve had lying around, which has been a little bit of a pain.

The HDDs I’ve had some experience with.

When plugging them into the computer with my SATA cable, I checked what disks were what with:sudo fdisk -l

Then sudo fsck /dev/sdb1 . fsck returned some funky errors that I had some trouble interpreting, like ext2fs_open2: Bad magic number in super-block. I think since those HDDs/SSDs didn’t have filesystems it couldn’t find the filesystem itself, so it threw an error. I could also be wrong, but that’s my hypothesis for now.

I ended up using badblocks to check the memory integrity of the chips, and that worked very well.

sudo badblocks -v -s /dev/sdb

If that ran into errors, it asked whether or not I wanted to fix the block of memory, in which you can choose yes or no. At the very end, it returned:

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 126839/9519104 files (1.1% non-contiguous), 6480648/38072576 blocks

And running fsck on them again returned:

fsck from util-linux 2.30.1 e2fsck 1.43.5 (04-Aug-2017)
/dev/sdb1: clean, 126839/9519104 files, 6480648/38072576 blocks

So that’s good ๐Ÿ˜€

I’ve gotten 2/3 2.5″ drives tested, and once those are ready I can get the tower computer set up. Once the tower is set up, I can go ahead and check the integrity of the server hard drives that Jay gave me as a grad gift.

It’s fairly easy to check HDDs to see if they work, given that you read and research the error messages well.

I’m getting all the OSs ready to download onto the tower computer, I’ll get a post up about that soon.

Until then!


P.S. I bought a crossbow too, it should be coming in the next few days. So excited!!

ArkenPi | the revival

With all these projects I’ve accomplished over the past year, I figure I need to start a new one over the summer so I’m not bored, or embellish the ones I’ve already finished. Fouric’s project, spinal terror, is great but I’m waiting for him to get out of college classes so that we can work on the project more consistently. Starting a new project is pretty much out of the question because I am working this summer to save for college, so spending a lot of money on a new project isn’t very reasonable. I came to the conclusion that I should improve on some of my finished projects! I’m going to start with ArkenPi, since myย  binary watch is pretty fresh in my head. I need a break from that one.

ArkenPi worked great for a while but failed pretty fast.

  • The battery died super fast
  • The PiTFT screen protruded from the top of the case
  • The axes of the touchscreen were swapped
  • The USBs didn’t connect all the way, some of them worked on some of them decided not to work whenever they wanted to.
  • And the keyboard…I just don’t like the feeling of it.

All that to say, I am redoing the case and keyboard for ArkenPi!

I went and had ahead and stole the PCB from the keyboard I already had. I designed some new plastic caps, a frame, and a case for the keyboard, and I’m having Gector 3D print them for me.

screenshot (3)

Keycaps & Rods

screenshot (2)

Case, Frame, & Tab

All the ports used for USB, HDMI, audio, and the microSD card are all going to be in the top part of the case alongside the PiTFT. The battery and keyboard are going to be in the lower part of the case. I’m designing A new swivel-like hinge for the top and the bottom so the case will be able to open and close more smoothly.


It’s a work in progress and takes a lot of time, but it’s a ton of fun. I’m learning a lot of about fusion 360, and I get to use my new caliper tool! Check him out:


I also managed to figure out why the PiTFT’s axes were swapped: when I dragged my finger right, the cursor went up. When I dragged my finger down, the cursor went to the left. It was a paaain.

But! As it turns out, any Raspberry Pi OS (Jessie and higher) use the touchscreen driver libinput , whereas the PiTFT only communicates with the old touchscreen driver, evdev . All I had to do was open /usr/share/X11/xorg.conf.d/40-libinput.conf and change the line with Driver "libinput" to Driver "evdev" for the touchscreen section.

Then I ranย  sudo apt-get install xserver-xorg-input-evdev
Rebooted the Pi, and the touchscreen axes were working! Woohoo! There’s one of the big problems fixed. ๐Ÿ™‚

Happy hacking!


Schematics | spinal-terror

If you don’t understand a ton of circuit theory, have experience reading schematics, or played with a lot of circuits, then building your own schematic can seem daunting.

It was definitely daunting for me, the first time I built one. Getting used to EagleCAD, MCUs, and all the ins and outs of voltage and ground threw me for a spin a couple of times.

But once you get a few done, schematics aren’t as hard as you think. As long as you know what pins are connected to Voltage and what pins are connected to Ground, you’re all good to go.

Here are a few things I’ve learned when drawing up schematics:

  • Label all the pins. You’ll be so glad you did.
  • Pull all the pins to voltage and Ground first, so those are out of the way.
  • Schematics are meant to be pretty and easy to read, so crisscrossing a ton of wires isn’t very pretty…nor is it helpful in the process of reading it.
  • Different MCUs (microcontroller units) have different design guidelines to function. If you read the datasheet carefully, there are some rules you have to follow to get the MCU working, such as:
    • Capacitors on the outputs of pins
    • Resistors on the Reset pin
    • Clocks or oscillators on the XTAL pins
    • And much more…so take care to read through other people’s usages of microcontroller chips and what they need to work by themselves before setting up the design of your own project.
  • Make sure none of the chips need a step down voltage converter (e.g. if your power source is 5V, but the chip can only handle 3.3V)

These are all guidelines I make myself think through as I’m designing the first-blood schematic of a project – most of them save you hours of agony later on when you can’t figure out why your circuit isn’t working.

Speaking of first-blood schematics, this is the brand new schematic for Spinal-Terror, a posture sensor that fouric, gector, and I are working on:


It could stand to be a little prettier…but it works for now ๐Ÿ˜‰

I’ve been itching to work with my hands lately and Spark is taking a little bit of a break, so I’m going back to ArkenPi and giving it the upgrade it deserves. More on that later!

Happy hacking!