Tag Archives: Linux

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

Repair missing UEFI entry for Fedora Linux

After a windstorm led to multiple power dropouts*, I found that my computer would no longer boot to Fedora. It booted to Windows still, but wouldn’t load GRUB.

Fixing it was confusing, because it wasn’t clear where the problem was. I found lots of references to how to reinstall GRUB2 or how to regenerate a GRUB boot menu (which you can fix by booting to a live USB stick and mounting the system image or using specialized recovery tools), and lots of references to how to modify a Windows boot menu (depending on whether you are using UEFI or MBR), and so on, but the problem turned out to be that the UEFI firmware had lost the menu item, so it wouldn’t load GRUB, so GRUB couldn’t load Fedora.

This is how I added back that missing menu item:

  • Boot to a Fedora Live image off of USB in UEFI mode.
  • efibootmgr -v to see if there was actually a boot entry in the firmware for Linux. (There wasn’t. Only an entry for Windows. Which I’d managed to accidentally rename as Linux somehow, but it was pointing to the \EFI\Microsoft\Boot\bootmgfw.efi file, which is why the system was able to boot to Windows.)
  • Use the Gnome Disks tool to identify which partition on which disk has the EFI boot system.
  • Create a new entry pointing to the shim.efi in the Fedora folder.
    sudo efibootmgr -c -w -L Fedora -d /dev/sdb -p 1 -l /EFI/fedora/shim.efi
    -L is a label, which you can assign whatever you want.
    -d is the disk with the EFI partition.
    -p is the number of the EFI partition.
    Make sure you write the path to shim.efi in UNIX style (/), even though EFI stores DOS-style paths (\), or you’ll end up with it trying to point to EFIfedorashim.efi, which still won’t work!
  • efibootmgr -v again to make sure the entry is present and points to the actual file (it should point to \EFI\fedora\shim.efi now).

*I forgot that I’d left the computer on sleep mode instead of turned off all the way. After one of the outages it must have turned on — I’m not sure exactly, since I was in another room, but I came back in and it was on, stuck with the drive light active, unresponsive, while the room lights flickered repeatedly. I shut it off completely and didn’t turn it back on until the wind died down and the power settled out.

NVIDIA on Fedora 27: Bad Resolution & Painful Mouse Lag (Fixed)

I’ve been using an older NVIDIA graphics card in my Fedora Linux workstation for a long time. I finally decided to upgrade to a newer one, which meant uninstalling the legacy drivers, then installing the current NVIDIA drivers.

Using the RPMFusion packages simplified it, because I only had to do the following to uninstall the old nvidia-340xx driver and install the new one:

dnf remove xorg-x11-drv-nvidia\*
dnf install xorg-x11-drv-nvidia akmod-nvidia
reboot

(Of course, I still had to hit ESC during boot, CTRL+ALT+2 to get to a text console, and log in without access to copy/paste or windowing.)

But it didn’t work. Oh, it brought up the GDM login screen, sure, but the mouse cursor and keyboard response were so slow I could barely even click on the form. It would move normally for about a second, then simply stop for five seconds. You can’t use a computer like that. Even if it had let me log in — it didn’t — there wouldn’t have been any point.

Additionally, the resolution was slightly off, with the aspect ratio on everything stretched vertically.

And of course I couldn’t use any of the graphical utilities to adjust settings, because I couldn’t run anything graphical.

I tried all kinds of things to fix it:

  • Creating an xorg.conf file with nvidia-xconfig. (no change)
  • Manually adding an xorg.conf section setting the resolution to the monitor’s native resolution. (no change)
  • Completely reverting to Linux’s built-in nouveau drivers, uninstalling all traces of nvidia and reinstalling Xorg and mesa as suggested at RPMFusion. That made the computer work again, but 3D graphics were slow. Reinstalling the nvidia packages fresh took me back to square one.

Nothing I could find online was remotely helpful. It was all about making sure the drivers were installed correctly, which I’d done, or configuring X.org, which (a) I’d done, and (b) hadn’t made any difference. (Fortunately I had another device I could look this stuff up on!)

Finally, just as I decided to revert to nouveau again just to have a working system and table the question of 3D acceleration until later, I hit upon an idea.

Wayland, the new display framework, isn’t compatible with the official NVIDIA drivers. I hadn’t had any problems with nvidia-340xx, so I figured I’d long since disabled Wayland and forgotten, but just for kicks, I switched over to the text console and tried

ps -ef | grep -i wayland

…and found that Wayland was running!

But Fedora’s GDM is supposed to fall back to X.org when it’s not able to run (the nvidia drivers are mentioned specifically). Maybe it recognized the old driver as incompatible, but thought (wrongly) that the new one could handle it?

Fortunately, that page also offered the solution:

Edit /etc/gdm/custom.conf, and put the following line in the [daemon] section:

WaylandEnable=false

The line’s actually in there already, commented out.

Literally, the solution to the problem that had me tearing my hair out for an hour was to delete a single #.

GDM displayed correctly, mouse and keyboard responded smoothly, and I was able to log in just fine…and 3D was much faster than my old card.

Problem solved!

But only because I finally realized I needed to look for Wayland.

Solved: NVIDIA/Nouveau picture extending beyond screen

I upgraded my desktop Linux system to Fedora 21 recently, and decided instead of trying to get the proprietary NVIDIA driver working, I’d just switch back to the open-source Nouveau driver. I uninstalled every RPM that had “nvidia” in the name (I use rpmfusion to keep the installation clean), restarted, and was dismayed to see that the system decided I could only run at 800×600. I didn’t have time to fix it immediately, so I shut down and went on with my day. That evening, I started it up again ready to fix it…and was surprised to see that the resolution had been detected correctly this time.

Almost.

It wasn’t obvious at the login screen, but the picture extended just a little past the edge of the monitor. I could tell because the mouse cursor would actually move off the screen in all directions. Once I logged in, and I could look at things near the edge, it was more obvious. And if I looked closely, I could tell that a lot of things that should have been sharp pixel lines were actually antialiased.

TL;DR: It was actually a monitor setting, and apparently the proprietary driver had been overriding it. Continue reading