Tag: fedora

Posted on

Wrestling with Fedora

TLDR

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

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.

Posted on

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.

Posted on

Upgrading Fedora sans DVD

The Fedora LiveCD image is pretty cool for new installations but as I’ve discovered, not much good for upgrading an existing Fedora. Fedora’s done away with the CD ISO images (probably a good thing, since Fedora 6 consisted of 5 CD ISO images) and only makes DVD images available now. Since my desktop doesn’t have a DVD burner or reader, I thought I was going to be stuck. After doing a bit of research and experimenting, I’ve come up with a procedure that let me upgrade my desktop from Fedora 8 Test 2 to Test 3 that seems to have worked. It’s based on this message from fedora-list.

Disclaimer: The following steps worked fine for me on my system. Since it was a relatively minor upgrade from one test version to another, I’ve encountered very little breakage (so far). You may have to adjust things a little to get it to work on yours. YMMV.

  1. Download the Fedora ISO for your architecture
  2. Mount the ISO using the loopback device:
    mount iso_filename /mnt/Fedora -t iso9660 -o loop
    replacing iso_filename with the filename of the Fedora ISO you just downloaded
  3. Create the directory /boot/Fedora and copy the contents of /mnt/Fedora/isolinux there
  4. Add the following to /etc/grub.conf (add it to the end of the file):
    title Fedora
root (hd0,0)
kernel /Fedora/vmlinuz
initrd /Fedora/initrd.img
  5. Copy the ISO image to another computer and mount it to some location as in Step 2 (I used Fedora in my home directory). I had to do this step because I couldn’t get the upgrade process to find the DVD image on the local hard drive. I think it may have had to do with the image being on an LVM partition. If you don’t have any LVM partitions, you may be able to skip this step.
  6. Create an NFS export for the mounted Fedora image you just created.
  7. Reboot and select the Fedora boot profile. If all goes well, the computer should boot up using the new Fedora image and the upgrade process should kick off.
  8. Follow the prompts to the point where it asks where the Fedora disk image is
  9. Select the NFS option and provide the host and full path information to where you mounted the ISO on the remote computer (from Step 5).
  10. At this point the upgrade should proceed as if you were upgrading from a physical DVD

If anybody knows a better way, feel free to enlighten me.