Since a recent update, my desktop has quit booting. I just says “Loading kernel,” with kernel number, and does nothing else. What’s worse is that I can’t even boot it from an external drive that I boot a Windows laptop with when I want to run Linux on it. The desktop doesn’t even recognize it as boot media, though it continues to work fine with the laptop.

[Sunday-afternoon update]

Patricia’s Windows 10 machine is the same MSI motherboard as mine, and I confirmed that it, too, does not recognize the external drive as bootable. I went back into Windows, and created a live-USB for Fedora, which did boot into both her machine and mine.

So, I decided to just create a new installation. I put it on a spare Samsung 250G SSD that I had. It has no problem installing it, but when I tried to boot from it, at first I couldn’t even see it in the boot menu in the BIOS. I changed from UEFI to CSM, at which point it appeared, and I made it the first boot. But when I tried to boot it, I got the same error message as when I tried to boot from the external drive. The machine continues to not recognize a Fedora boot disk as bootable.

[Bumped]

[Update Monday afternoon]

OK, after talking to MSI, I found out that I had been setting the boot order wrong, and finally got it working. I’m pretty much back to normal, except I need to clone the Samsung over to my M.2. If I didn’t keep /home on a separate drive, though, I’d be in a world of hurt.

[Bumped]

When doing an upgrade with dnf (going from 34 to 35), I’m getting a slew of transaction test errors like these:

file /usr/bin/qemu-alpha-static from install of qemu-user-static-2:6.1.0-16.fc35.x86_64 conflicts with file from package qemu-user-static-alpha-2:6.2.0-17.fc36.x86_64
file /usr/share/systemtap/tapset/qemu-alpha-static.stp from install of qemu-user-static-2:6.1.0-16.fc35.x86_64 conflicts with file from package qemu-user-static-alpha-2:6.2.0-17.fc36.x86_64
file /usr/lib64/python3.10/site-packages/pycrypto-2.6.1-py3.10.egg-info from install of python3-crypto-2.6.1-36.fc35.x86_64 conflicts with file from package python3-crypto-2.6.1-39.fc36.x86_64
file /usr/lib/udev/rename_device from install of initscripts-10.15-1.fc35.x86_64 conflicts with file from package initscripts-rename-device-10.16-3.fc36.x86_64

Anyone know what’s going on, and how to fix it?

[Update Monday morning]

OK, the problem is that I’m trying to upgrade to 35 when in fact I’m running 36. And the weird thing is that ‘uname -r’ says it’s 34, while /etc/fedora-release says it’s 36. And when I boot it, it’s using a 34 kernel. So, I decided to upgrade to 37 instead, since in actuality, other than the kernel, all my packages are 36. That upgrade went well, but I don’t know what will happen if I actually do a reboot into the new version. I’m asking people on the Fedora forum. The mystery is why it’s running on a 34 kernel.

[Bumped]

When I did the latest Fedora install, it created a home directory for me called “randsimberg.” I always name my directory “simberg,” so I did a ‘mv randsimberg simberg’. Now I can’t launch a terminal, because the bash script is looking for the “randsimberg” directory.

Fun.