Category Archives: Troubleshooting

Linux Ejecting DVD Drawer on Wake

At first I thought this was related to Windows losing drives on wake. It started happening around the same time, it also involved waking up from sleep, and the CD/DVD drive was disappearing in Windows along with the vanishing hard drive.

But while moving the cables fixed that problem, it didn’t fix this one.

It was only mildly annoying, especially compared to regularly losing access to a large chunk of local storage, so I figured I’d come back to it later.

Other people are seeing this too and it’s a recent bug in the Linux kernel. At least with Fedora’s rapid kernel updates I probably won’t have to wait too long between when the patch lands and when it hits my desktop. It’s been years since I compiled my own kernel, and I don’t feel like starting that up again now!

Windows Losing Drives After Sleep (Solved)

My main desktop PC dual-boots Windows 10 and Fedora Linux. I have an SSD drive for each OS, and recently added an HDD for larger shared storage. It’s worked out pretty well except for a recurring problem: Sometimes the shared drive just disappears from Windows after I wake it up from sleep mode.

I don’t mean Windows just unmounts the filesystem. I mean Windows stops seeing the hardware at all.

When that happens, it sometimes reconnects after a few minutes…and sometimes doesn’t. Which means it’s not only invisible in Windows, it doesn’t get cleaned up properly on reboot, so Linux will only access it read-only the next time I fire that up, until I get back into Windows and shut it down cleanly.

Time to get to the bottom of it. Most of what I found online boiled down to:

  • Update the SATA controller driver.
  • Update the motherboard firmware.
  • Make sure the cable connection is solid.
  • Move the cable to another connector.
  • Replace the cable.
  • Get a better drive, [brand the OP mentioned] is terrible.

Continue reading

Solved: NginX serving different localhost sites to Chromium vs. Safari or Firefox

I ran into a weird problem testing some websites on a local NginX installation on my Mac, where it was sending different sites to Firefox and Chrome for the same URL.

I’d put the server names into /etc/hosts pointing to 127.0.0.1, and I’d set up NginX with multiple server {} blocks, each with a different server_name. But while Chrome would load the individual sites for one.example.com and two.example.com, Firefox would always get the content from one.example.com.

A little more testing confirmed that all Chromium-based web browsers (I tried Edge, Opera, Brave and Vivaldi) were getting the correct sites, but Firefox and Safari were both getting the wrong server’s content.

When I compared the server blocks, I noticed that one.example.com was listening on both IPv4 and IPv6, but two.example.com was listening only on IPv4. I added the second listen directive, reloaded nginx, and voila! It worked in Firefox and Safari!

    listen 443 ssl;
    listen [::]:443 ssl;
    server_name  two.example.com;

So apparently, even though I’d only pointed two.example.com to 127.0.0.7 (IPv4), Firefox and Safari were connecting to ::1 (IPv6) instead. And since NginX had only connected one.example.com to that interface, that’s the site it loaded. It’s not clear whether Firefox and Safari are both doing something weird and Chrome isn’t, or they’re both using a MacOS system resolver and Chromium is doing its own thing.

TL;DR: If you listen to IPV6 in one localhost server {} block, listen to it in all of them!

Overload the Cores

I finally got around to trying out No Man’s Sky a few weeks ago. I started on a super-hot planet, where you need to find shelter and/or resources to recharge your suit’s hazard protection system to keep cool. Got killed a few times trying to figure out what I was doing. And after about 20 minutes, my computer spontaneously shut itself down.

I waited a few minutes to let it cool down, then tried again. Managed to figure out a bit more of what I needed to do in the game, and then the same thing happened.

Continue reading

WordPress 5.7 Upgrade Breaks Posts with Emoji in the Title?

Not sure what might be going on here, but after upgrading to WordPress 5.7, some posts started timing out. Viewing the post. Searching in the Posts interface for anything that was in the post. Trying to list posts that had its tags. I could search for it on the blog, but not in the admin area. Error logs on the web server showed a connection timeout. The only way I could find them was through the Search Regex plugin, and it turned out I could still edit the post. Though I couldn’t save any changes without getting the same timeout.

Both posts that I’d been alerted to had emoji in the title. Hmmm….

I tried removing the emoji from the title and saving it. The post loaded again! And I could search for keywords and tags that matched it!

Just for kicks, I pasted the emoji back in. Saved. No problem.

I don’t know what changed, but apparently older versions of WordPress were storing emoji in titles differently or something, and re-saving it fixes it?

Anyway, that seems to work, so I’m posting this here for anyone else with the same issue to see what worked for me.

Update: I checked another blog that updated from 5.6 to 5.7 and had emoji — in some cases the same symbols — in titles, but it wasn’t affected by the same problem. I’d guess it’s either a combination with some plugin, or something left over from the fact that this site has been updated continuously from some very old versions of WordPress.

Tracking it Down

May update: It happened again on here, possibly after the upgrade to 5.7.1. This time I decided to dig into it in more detail and checked out the database. Because this is a Very Old Blog(tm), all the post columns (among others) were still using the Latin-1 character set, even though WordPress is working in Unicode now. So MySQL thinks it has Latin-1 data, but it’s actually UTF-8.

But you can’t just change the character set on live data. If the old charset matches the data, you need to convert it. If the old charset doesn’t match, you need to not convert it. Chances are you’ll either end up with double-encoded or broken data, like I got when I tried updating a column with PhpMyAdmin (after running a backup, of course!), and it deleted everything after the first emoji in each post!

Alex King’s post on converting mysql from latin1 to utf8 helped me solve it. Basically I took a copy of the mysqldump file I’d just created, searched for latin1 in the table definitions and replaced it with utf8, and re-imported the SQL file. So far everything I’ve spot-checked looks OK! Here’s hoping this actually fixed it right this time!

Or will I need to re-do the process with utf8mb4…?