452: Out of range pointer error

For the last couple weeks, my computer has been up and down, spitting out an error when booting up:

452: out of range pointer: 0x100010
Backgrace (.text 0xa058 .data 0x15a6c):
Aborted. Press any key to exit.

It started happening after rebooting following an update. Internet searches I did brought up some older forum posts that pointed to grub being the cause. Since it had been several Fedora versions (before Fedora 30 I think) since I last reinstalled and the system was feeling a bit crusty, I figured I’d just start fresh with a new install.

Wrestled with getting a Fedora 37 live image to boot off, did a reinstall and updates, rebooted, and ended up with the same message. Did this a couple times and started investigating the hardware.

Several iterations of testing the DDR3 memory modules and pulling out hard drives, I managed to get my computer back up and running with 8GB less memory, two 500 GB drives and a 250 GB SSD (the original boot drive) removed. All of the memory tested fine individually but with all of them installed, memtest consistently gave errors when performing one test the 21-22 GB range. Not sure if something’s happened to one of the memory slots, but the system stayed pretty stable for a few days.

Then, after reinstalling some software, running some updates, and rebooting, the error came back.

Ugh.

At this point, rather than reinstall again, I tried reinstalling the bootloader and rebuilt the grub config file. Rebooted and the system came back up without any issues.

Still don’t know what caused the breakage, but it’s been pretty stable so far the past few days. Let’s hope it stays that way. It’s running a bit slower because now I’m back to booting off a regular hard drive (1 TB) rather than an SSD. At some point I might try to put the other 8 GB back in to see how stable the system stays. I’d been having some problems with the computer intermittently freezing up at random points, so I’ll just leave it like this for a while. The 500 GB drives will go into a couple other systems that I inherited a while back. I think one of them will be put to work in the garage, probably on the CNC mill. The other one might end up being used with the radio in the shack.

I tried to reinstall Fedora on the 250 GB SSD drive, but the install would always freeze in the middle of doing something. Even though the drive’s SMART status shows it’s fine, I suspect it has started to develop some issues somewhere.

Fedora KDE, Plasma Wayland, and Emacs

My previous attempts at using Fedora KDE with Wayland were pretty miserable, and KDE was pretty much unusable under Wayland with the nVidia drivers. Never tried it with the nouveau drivers at the time, but after dumping the nVidia drivers a while back, I thought I’d give KDE Plasma Wayland another shot.

I don’t know if Wayland support under KDE got better or if it’s because I’m not using the nVidia drivers anymore (probably both), but I’m finding Plasma is pretty snappy under Wayland.

I normally have emacs started as a systemd service (systemd --user start emacs) which runs emacs in daemon mode. Then I can just run emacsclient and have it connect to the already running emacs. One big issue I came across was not being able to run emacsclient and getting an *ERROR*: Display :0 can't be opened when I ran emacsclient -c from the command line.

The general consensus I found after searching the web for a while seemed to be that with systemd, the emacs daemon was starting before the graphical environment (Plasma), so display related environment variables weren’t available to emacs. Why this only happened with Plasma Wayland and not with Plasma X11, I don’t know.

When the emacs systemd service is enabled (systemd --user enable emacs), /usr/lib/systemd/user/emacs.service is symlinked into ~/.config/systemd/user/default.target.wants. My first attempt to fix the issue was to move emacs.service to graphical-session.target.wants, but that didn’t help.

Thinking about the apparent root cause of the issue, I found a Unix StackExchange post about how to have systemd services start in a particular order. I copied /usr/lib/systemd/user/emacs.service to ~/.config/systemd/user and linked it into graphical-session.target.wants. Then I added two lines to the [Unit] section:

Requires=plasma-kwin_wayland.service
After=plasma-kwin_wayland.service

This makes emacs.service a dependency of plasma-kwin_wayland.service and delays starting until after plasma-kwin_wayland.service has finished starting.

After rebooting and logging back in, I verified that the emacs daemon was still starting up (systemd --user status emacs) and was able to get emacsclient -c to bring up the emacs window. Everything was back to working the way I expected.

Venturing into CNC milling

About a year ago, we purchased a CNC mill (SainSmart Genmitsu PROVerXL 4030) from the local Makerspace, who had received it as a donation. It sat in the garage for most of last year as we had a lot of other things going on.

Now I’m finally getting around to checking it out, learning about how they work, and how to use them.

So far, I’ve gathered that the basic workflow goes something like this:

  1. Use some kind of design software, such as Easel, Carveco, Inkscape or some other CAD software, to create the object to mill.
  2. Convert it to something called G-Code.
  3. Preview it using something like Candle.
  4. Send the G-Code to the CNC controller (using Candle or the off-line controller).
  5. ???
  6. Profit!

I’ve turned the 4030 on, and managed to send it to a home position. It’s a bit on the loud side. The 4030 appears to be pretty much fully assembled and seems to be working. There was only one bit that came with the machine, so I’ll need to get a set of end mill bits. Whoever originally owned it also upgraded the 4030 with the aluminum T-slot spoilboard, so I’ll need to get a set of clamps that fit the T-slots. Fortunately I’ve also got the original MDF spoilboard that I can put back on in a pinch.

SpaceX Falcon Heavy USSF-67 launch

Most of the SpaceX Falcon launches we see from the house are Dragon CRS missions headed toward the ISS, so I wasn’t expecting to be able to see today’s Falcon Heavy USSF-67 launch since it was supposed to be headed to a geosynchronous orbit.

We stepped outside to have a look anyway just in case and much to my surprise, we saw the exhaust trail pretty clearly a little bit lower toward the horizon. This photo was a couple minutes after the launch and just after the side boosters separated.

Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch
Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch

Here the side boosters have begun turning back toward their landing pads while the center booster continues on.

Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch. Exhaust trail from the side boosters turning back is visible on the right
Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch. Exhaust trail from the side boosters turning back is visible on the right

The two side boosters are visible as two specks of light. After this, we could see them flash every now and then as their steering jets fired.

Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch. Exhaust trail and the two side boosters turning back is visible on the right
Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch. Exhaust trail and the two side boosters turning back is visible on the right
Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch. Exhaust trail and the two side boosters turning back is visible on the right
Exhaust trail from the SpaceX Falcon Heavy USSF-67 mission launch. Exhaust trail and the two side boosters turning back is visible on the right

This was the first time we’d seen a Falcon Heavy and the two side boosters from the house. It was pretty cool.

Christmas Nativity 2022

Christmas eve, and Mary and Joseph are settling down in the stable.

Mary and Joseph have arrived at the stable. A few shepherds are hanging around tending to their animals.
Mary and Joseph have arrived at the stable. A few shepherds are hanging around tending to their animals.

The animals are on the way in the Ark. This year, they’re joined by two Christmas lobsters. If you didn’t know that lobsters were present at the birth of Jesus, then you should watch Love Actually.

Animals on the Ark making their way to the stable. Two Christmas lobsters have joined the party.
Animals on the Ark making their way to the stable. Two Christmas lobsters have joined the party.

Christmas morning! The shepherds have come to the stable with their flock to see the new baby.

Shepherds and some of their flock gathered to see the new baby
Shepherds and some of their flock gathered to see the new baby

The wise men from the East have gathered to marvel at the new star. As usual, Lt. Cmdr. Data has joined them as their guide.

Wise men have gathered to marvel at the new star. Lt Cmdr Data guides the way with his star charts.
Wise men have gathered to marvel at the new star. Lt Cmdr Data guides the way with his star charts.

All the animals have arrived at the stable to see the new baby!

The animals, joined by the Christmas lobsters this year, have left the Ark and arrived at the stable. Some of the tree ornaments hitched a ride as the Ark passed by.
The animals, joined by the Christmas lobsters this year, have left the Ark and arrived at the stable. Some of the tree ornaments hitched a ride as the Ark passed by.