Category: Computer bits

Computer stuff

Posted on

Recent Fedora installation issues

It seems like getting Fedora going on my trusty but old computer is getting harder these days.

Getting Fedora 39 installed turnedout to be a bit of a chore. After getting Fedora 40 installed in a VM after a bit of wrangling, I thought I’d try the F39-F40 upgrade on the computer. The upgrade worked fine on the laptop, so I thought maybe the desktop would handle it ok.

Nope, not so much. While the upgrade itself went smoothly, all I got when I rebooted was a blank screen with a flashing cursor in the corner. Fortunately Ctrl-Alt-F2 got me to a console login prompt, so the system was running to some extent.

Logging in to check things out showed a ton of 

traps: drkonqi-coredum[1922] trap invalid opcode ip:7f9a6270ea9c sp:7ffc3e6b9dd8 error:0 in libQt6Core.so.6.6.2[7f9a626b0000+3e7000]

messages in the dmesg output. Looked like whatever was going on kept crashing, generating coredumps and restarting ad-nauseum.

In /var/log/messages, there were a bunch of

systemd-coredump[11667]: Process 11641 (drkonqi-coredum) of user 0 dumped core.
Module libcrypt.so.2 from rpm libxcrypt-4.4.36-5.fc40.x86_64
Module libblkid.so.1 from rpm util-linux-2.40-0.9.rc1.fc40.x86_64
Module libsasl2.so.3 from rpm cyrus-sasl-2.1.28-19.fc40.x86_64
Module libevent-2.1.so.7 from rpm libevent-2.1.12-12.fc40.x86_64
Module libunistring.so.5 from rpm libunistring-1.1-7.fc40.x86_64
Module libmount.so.1 from rpm util-linux-2.40-0.9.rc1.fc40.x86_64
Module libgmodule-2.0.so.0 from rpm glib2-2.80.0-1.fc40.x86_64
Module libssl.so.3 from rpm openssl-3.2.1-2.fc40.x86_64
Module libpsl.so.5 from rpm libpsl-0.21.5-3.fc40.x86_64
Module libssh.so.4 from rpm libssh-0.10.6-5.fc40.x86_64
Module libidn2.so.0 from rpm libidn2-2.3.7-1.fc40.x86_64
Module libnghttp2.so.14 from rpm nghttp2-1.59.0-2.fc40.x86_64
Module libffi.so.8 from rpm libffi-3.4.4-7.fc40.x86_64
Module libduktape.so.207 from rpm duktape-2.7.0-7.fc40.x86_64
Module libgio-2.0.so.0 from rpm glib2-2.80.0-1.fc40.x86_64
Module libcurl.so.4 from rpm curl-8.6.0-7.fc40.x86_64
Module libselinux.so.1 from rpm libselinux-3.6-4.fc40.x86_64
Module libpcre2-8.so.0 from rpm pcre2-10.42-2.fc40.2.x86_64
Module libicudata.so.74 from rpm icu-74.2-1.fc40.x86_64
Module libgobject-2.0.so.0 from rpm glib2-2.80.0-1.fc40.x86_64
Module libpxbackend-1.0.so from rpm libproxy-0.5.3-5.fc40.x86_64
Module libbrotlicommon.so.1 from rpm brotli-1.1.0-3.fc40.x86_64
Module libkeyutils.so.1 from rpm keyutils-1.6.3-3.fc40.x86_64
Module libkrb5support.so.0 from rpm krb5-1.21.2-5.fc40.x86_64
Module libcom_err.so.2 from rpm e2fsprogs-1.47.0-5.fc40.x86_64
Module libk5crypto.so.3 from rpm krb5-1.21.2-5.fc40.x86_64
Module libkrb5.so.3 from rpm krb5-1.21.2-5.fc40.x86_64
Module liblzma.so.5 from rpm xz-5.6.0-3.fc40.x86_64
Module liblz4.so.1 from rpm lz4-1.9.4-6.fc40.x86_64
Module libcap.so.2 from rpm libcap-2.69-3.fc40.x86_64
Module libpcre2-16.so.0 from rpm pcre2-10.42-2.fc40.2.x86_64
Module libb2.so.1 from rpm libb2-0.98.1-11.fc40.x86_64
Module libdouble-conversion.so.3 from rpm double-conversion-3.3.0-3.fc40.x86_64
Module libglib-2.0.so.0 from rpm glib2-2.80.0-1.fc40.x86_64
Module libicuuc.so.74 from rpm icu-74.2-1.fc40.x86_64
Module libicui18n.so.74 from rpm icu-74.2-1.fc40.x86_64
Module libcrypto.so.3 from rpm openssl-3.2.1-2.fc40.x86_64
Module libproxy.so.1 from rpm libproxy-0.5.3-5.fc40.x86_64
Module libz.so.1 from rpm zlib-ng-2.1.6-2.fc40.x86_64
Module libbrotlidec.so.1 from rpm brotli-1.1.0-3.fc40.x86_64
Module libgssapi_krb5.so.2 from rpm krb5-1.21.2-5.fc40.x86_64
Module libzstd.so.1 from rpm zstd-1.5.5-5.fc40.x86_64
Module libsystemd.so.0 from rpm systemd-255.4-1.fc40.x86_64
Module libQt6Core.so.6 from rpm qt6-qtbase-6.6.2-6.fc40.x86_64
Module libQt6Network.so.6 from rpm qt6-qtbase-6.6.2-6.fc40.x86_64
Module drkonqi-coredump-processor from rpm plasma-drkonqi-6.0.2-1.fc40.x86_64
Stack trace of thread 11641:
#0 0x00007f2dc4d0ea9c _ZL10aeshash128PKhmmm (libQt6Core.so.6 + 0x10ea9c)
#1 0x00007f2dc4f5e45b _ZN18QCommandLineParser9addOptionERK18QCommandLineOption (libQt6Core.so.6 + 0x35e45b)
#2 0x00007f2dc4f601f3 _ZN18QCommandLineParser13addHelpOptionEv (libQt6Core.so.6 + 0x3601f3)
#3 0x0000555ce386ea43 main (drkonqi-coredump-processor + 0x5a43)
#4 0x00007f2dc463d088 __libc_start_call_main (libc.so.6 + 0x2a088)
#5 0x00007f2dc463d14b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a14b)
#6 0x0000555ce386fff5 _start (drkonqi-coredump-processor + 0x6ff5)
#ELF object binary architecture: AMD x86-64

messages being dumped there (carriage returns added for clarity) over and over.

There were also a lot of SELinux errors in the message log as well

setroubleshoot[2604]: SELinux is preventing abrt-dump-journ from write access on the sock_file io.systemd.DynamicUser.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that abrt-dump-journ should be allowed write access on the io.systemd.DynamicUser sock_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'abrt-dump-journ' --raw | audit2allow -M my-abrtdumpjourn
# semodule -X 300 -i my-abrtdumpjourn.pp

Seems like there’s a lot going on here.

Since Fedora 40 is working fine on my laptop, I’m guessing that there’s something about my desktop that the Fedora binaries don’t like. I haven’t tried another distro yet so I don’t know if it’s just Fedora’s KDE Plasma, or just KDE Plasma in general that my desktop doesn’t like. I also haven’t tried Fedora Workstation yet, so I don’t know if the problem is with Fedora in general or Fedora KDE.

Still a lot of troubleshooting and digging I need to do. One of the problems I’ve run into is that the errors happen so frequently and generated coredumps get deleted so quickly that I can’t really generate useful dumps and bug reporting information.

Posted on

CPU cooler upgrade

A couple months ago, the CPU cooler (one of those closed loop liquid cooling systems) started making weird noises intermittently. Being one of the few original parts left in my computer, I figured that meant it was time for a replacement. There’s not much of a selection for LGA1366 sockets left out there, but I managed to find a NZXT Kraken 120 that worked.

Replacing the cooler was also a good opportunity to give the computer a long overdue cleaning, so out came the air compressor and out went the dust bunnies.

Inside my computer after blowing out the dust. Visible is the power s upply at the bottom, video card, hard drives and the CPU cooler.
Inside my computer after blowing the dust out.

Undoing the four screws releases the retaining ring that clamps the cooler to the CPU, and out it comes. Pretty easy.

The removed CPU cooler and very dusty radiator
The removed CPU cooler and very dusty radiator
The uncovered CPU
The uncovered CPU

After removing the retaining ring, the old thermal paste got cleaned off and fresh thermal paste was applied. The cooling block went on and the radiator was attached.

New cooling block and radiator installed
New cooling block and radiator installed

(Yes, there are two fans on either side of the radiator in a push-pull configuration.)

Unlike the original cooler, the pump for the new one looks to be embedded in the radiator. The CPU cooling block has RGB lighting on it, but my motherboard doesn’t have any headers to plug it in to, so I just zip tied the wire to the hoses to keep them out of the way. Total installation time was about 30 minutes once I figured out which bits I needed to use.

The cooler works pretty well. Under load, the CPU temperatures are about 10°C cooler than they were with the old cooler. I’m quite pleased with the way the new cooler is working.

Posted on

Wrestling with Fedora

TL;DR

Fedora 39 installer kept hanging the computer. Adding uefi="no" to a dracut config file let the install finish successfully on my BIOS-based (non-UEFI) computer.

In which I try to reinstall Fedora on my computer

The computer has been having a few strange issues recently so a few weeks ago, with Fedora 39 going into beta, I decided it was time to do a reinstall.

It turned into a several weeks long and unexpected ordeal.

The install process worked fine up until the Fedora installer was saying “Installing bootloader”, at which point the computer froze before getting to the next stage. I could reboot the computer, and Fedora would start up fine but the user accounts hadn’t been created yet so there was no way to log in.

Booting up the live image and using a chroot to create the user accounts worked, but the system was still behaving abnormally. Tried a few other Fedora versions going back all the way back to Fedora 35, but the installer would still always hang the computer at the same place, somewhere during the bootloader installation.

I ended up going to KDE Neon, and then settling on Kubuntu for a bit just to get the computer working again so I could figure out what was going on. Had no problems installing either and both of them ran fine, so that gave me some confidence that my Fedora installation issues weren’t hardware related.

Finally, going all the way back to Fedora 33, I was able to get Fedora reinstalled on the system.

Yay! Cue celebration! Now I can upgrade my way to Fedora 39!

Hold up there bubba, not so fast.

The first upgrade step (33->35) went fine up until the kernel install scripts ran, at which point the computer froze up again. All the packages had installed at this point, so I rebooted and promptly got an error because the initramfs file for the Fedora 35 kernel wasn’t there.

Frustrating, but a valuable clue. Something must be happening to cause the computer to hang before or while creating the initramfs.

Fortunately I could still boot into the Fedora 33 kernel. Kicked off another upgrade step (35-37) and again, the computer froze up when the kernel install scripts ran. Again, the initramfs for the Fedora 37 kernel hadn’t been generated.

Dracut, what you doing?

The initramfs file is generated by dracut. Booting into the Fedora 33 kernel again, I tried to manually generate the missing initramfs files (dracut --kver <kernel>). In the middle of the process, the computer froze again. Now I had my culprit, dracut. But what was different about dracut that let it work on my computer with Fedora 33, but not after that?

Going through the dracut man page, the --uefi/--no-uefi options stood out to me. The computer is BIOS-based and doesn’t have UEFI, so I gave dracut --no-uefi --kver <kernel> a try. It worked! The initramfs was generated where the computer previously froze, and rebooting into the newly generated kernel worked without any problems.

Generated a few more missing initramfs files, and those also booted up without problems.

According to the dracut.conf man page, the uefi option can be set in a config file. It’s supposed to default to “no”, but it seemed like that either wasn’t the case, or the Fedora installer sets it to “yes” somewhere. Creating a dracut config file (/etc/dracut.conf.d/00-nouefi.conf) with just uefi="no" let dracut --kver <kernel> run successfully again.

Now that I had a potential solution, I booted up the Fedora 39 beta live image again, created the /etc/dracut.conf.d/00-nouefi.conf file, and started up the installer. This time the installer made it past the point it used to freeze and finished successfully!

Woohoo! Cue celebration! Now the computer is back to running Fedora!

Posted on

New tablet

For an upcoming trip, I decided I needed a new tablet to replace the old Transformer Prime. After all this time, the battery doesn’t hold much of a charge anymore, and it’s become really slow and difficult to use.

This time, I wanted something that I could use for reading my growing e-book collection without all the distractions of extra apps on an Android or iOS tablet. I also wanted something that was e-paper/e-ink based. Looked at the Amazon Kindle tablets, but I felt they were too small. I finally settled on the reMarkable tablet.

I’ve been using it for about a week now, and it’s a pretty slick device. It’s a fairly open device which lends itself pretty well to hacking on and customizing. On the other hand, if you don’t know what you’re doing, it’s also not hard to brick. There’s a whole ecosystem of software, “paper” templates, and splash screens created by other reMarkable tablet users. There’s a wiki to collect a lot of those projects and information in one place.

I had a new mammography unit to acceptance test today, so naturally I took an x-ray image of the reMarkable.

X-ray image of the reMarkable 2 tablet. 1404x1872 pixel PNG suitable for using with the Remarkable 2.
X-ray image of the reMarkable 2 tablet. 1404×1872 pixel PNG suitable for using with the reMarkable 2.

Turning it into power-off and sleep splash screens for the reMarkable was pretty easy. Resize the image to 1404×1872 pixels, save it as an appropriately named PNG file, and copy it over to the Remarkable. Reboot and the new splash screens were there.

reMarkable tablet with an x-ray of the tablet as the power-off splash screen

The Remarkable also fits nicely into the leather sleeve I bought for the Transformer Prime.

I’ve loaded it up with EPUB books and I already have a few ideas for some paper templates to create. I’m going to enjoy using this tablet.

Update: Oh, I forgot the pen! The reMarkable Marker looks pretty simple inside. Tough to tell, but at the tip is a coil of wire and a few other bits that help to inform the digitizer in the Remarkable where the tip of the pen is. The other solid dense objects I think are the magnets used to clip the Marker to the side of the reMarkable.

reMarkable Marker pen x-ray. 1404x1872 pixel PNG suitable for using with the Remarkable 2.
reMarkable Marker pen x-ray. 1404×1872 pixel PNG suitable for using with the reMarkable 2.

Another update: Embiggened versions of the reMarkable and reMarkable Marker.

Posted on

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.