It's my holy grail. My holy fucking grail. Suspend/resume.

And I finally figured it out. I've seen the hints about putting a resume=/dev/??? line into the bootline in GRUB, with ??? being the location of the swap partition. I tried it, and it never seemed to work.

So I forgot about it.

Then I saw this post from Ankur Sinha that makes the same suggestion:

resume=/dev/??? in the bootline in GRUB

But what to sub in for ???? Where exactly is /swap?

My system is encrypted and using LVM, so finding /swap is not as easy as using df -h or opening up gParted.

Maybe the system itself could help me figure out where /swap lives in the LVM/encrypted world of Fedora.

I looked at the man page for swapon and soon had my answer:

$ swapon -s

That returns the following:

/dev/dm-1

So I rebooted and dropped this at the end of my bootline in GRUB:

resume=/dev/dm-1

Lo, behold and holy shit, IT WORKS!

I now have working suspend/resume in Fedora 20 -- and presumably every other Linux distribution out there.

Next step, how to modify GRUB so this persists. It's not so easy because GRUB isn't set up the same way in this Fedora U/EFI system as in other systems I've seen.

If/when I figure that out, I'll update this entry. But for now, I HAVE SUSPEND/RESUME. Couldn't be happier. (Really!)

First try at making GRUB modification permanent

I tried to get resume=/dev/dm-1 into GRUB permanently on my EFI-based Fedora system.

Here's what I did.

$ sudo gedit /etc/default/grub

I turned this line:

GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) vconsole.keymap=us rd.lvm.lv=fedora/root rd.luks.uuid=luks-f87cd0dc-c2a5-4a18-913d-b0c9d0e7d18f rhgb"

into this:

GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) vconsole.keymap=us rd.lvm.lv=fedora/root rd.luks.uuid=luks-f87cd0dc-c2a5-4a18-913d-b0c9d0e7d18f rhgb resume=/dev/dm-1"

Note the added bit at the end.

Then I rebuilt my GRUB entries:

$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

GRUB didn't look quite the same upon reboot, but my boot stanza did have resume/dev/dm-1 in it. And suspend/resume still works.

I don't know if this will persist after a kernel update (I suspect it won't), so I'll update this entry when I know more.

Update: While the simple fix below seems to have worked for me, what Fedora experts are sugggesting is slightly more complicated. Start reading here and click through to find the recommended fix. (I suspect that my solution was easier because I didn't install anything until I resolved the SE Linux problem on my system.)

Original post begins here:

It's all over the Fedora forums, mailing lists and bug trackers: A bad update is causing software updates to fail.

It has something to do with SE Linux.

I got my updates to go through and returned the box back to normal with these three commands:

# setenforce 0

# yum update

# setenforce 1

That's it. Everything is back to normal.

Thanks to the help of a few, proud Fedora users, I was able to install the AMD Catalyst 13.11 beta (version 9.95 to be exact) driver on my Xfce-running Fedora 20 system.

And thus the long local (as opposed to national) nightmare of poor video performance and a CPU running 30 to 40 degrees hotter is over.

I would love to stick around and wait for the open-source Radeon drive to get better, and I'll continue to keep an eye on it. But my test of the 3.13.rc7 Linux kernel -- which is supposed to include some key Radeon patches -- showed that it is no better on my machine than 3.12.x. That means it's not time to wait on the open driver but instead time to get serious about putting Catalyst -- direct from AMD -- on the laptop.

Today I was successful, and the CPU on my HP Pavilion g6-2210us is running at a cool 80 degrees as opposed to the not-as-cool 120 degrees under Radeon. And I can watch full-screen video in VLC (and any player other than MPlayer) without a) that video stuttering and b) both CPU cores jumping to 100 percent.

Read the rest of this post

Update: Thanks to tips from Bernhard J. Wolf, I have successfully installed the AMD Catalyst 13.11 beta driver in Fedora 20. I did not need to use Maxorete's install-file hack. When I opened the file that needed to be changed, it looked like AMD had already made the fix -- and since Catalyst did install, I can confirm that they did. Thanks, AMD! Keys to success were adding the kernel-devel package in Fedora. It probably couldn't hurt to make sure you also have kernel-headers, which I already had. Bernhard also said the installation wouldn't work with GNOME installed. GNOME, you are now history on this machine. With kernel-devel and without GNOME, the install of AMD Catalyst 13.11 beta went like butter. I will do a new post that contains all of this information, but for now I leave what I wrote earlier today in its original form below. You know, for history's sake:

Original post below (I didn't need the install-file hack)

Anybody who has read anything I've written in the past month know that the sudden absence of the AMD Catalyst driver in packaged-for-Fedora form is really chapping what's left of my Linux hide. The fact that so few seem to care is just stamping my "get out of Dodge/Fedora" ticket.

But given momentum's pull, principally the fact that I have Fedora set up the way I want it, I'd rather stay for now and move at some time in the future. When I'm ready, that is.

So I've gone against the advice I've held to since Fedora 14 crapped out on me, that advice being, Don't install Catalyst directly from AMD.

Read the rest of this post

So I finally did my FedUp upgrade from Fedora 19 to 20, and one of the things hanging me up was the AMD Catalyst driver, the packages for which come from RPM Fusion.

I should have looked into this more BEFORE I did the upgrade, because there are no kmod-catalyst packages for F20.

This has happened before. Catalyst is always behind Nvidia when it comes to RPM Fusion packages.

But according to these two threads, the maintainer of kmod-catalyst is orphaning the package, and unless someone else picks it up, there will be no new Catalyst drivers packaged as RPMs for any existing Fedora releases, including F19 and F20.

The good news for me anyway is that Fedora 20 with the 3.12.5-302.fc20.x86_64 kernel marks the first time that the AMD Radeon HD 7420G graphics chip in my HP Pavilion g6-2210us laptop has had working 3D acceleration without the proprietary Catalyst driver.

But it's not as good of video as I get with AMD Catalyst (aka fglrx if you're running a Debian-based distro).

Without Catalyst/fglrx, animations in GNOME 3 aren't as smooth, games that use 3D don't perform as well, and full-screen video in VLC stutters a bit. Again, that's better than GNOME 3 not running at all (which is what has been happening with the open Radeon driver in recent months), but I'd rather have the choice between the open Radeon and proprietary Catalyst drivers.

Oh, and my suspend/resume situation is the same. Suspend appears to work fine, but without resume (which doesn't work at all), why bother?

The laptop does run cooler with the proprietary driver, too.

Back to the point: I'm not willing to download and run AMD Catalyst directly from AMD. That's always been a prescription for endless fiddling and bricked video. I have heard good things about the open Radeon driver in the 3.13.x kernel, and I will wait for that to roll into my system before I decide whether or not to abandon Fedora for a distribution that isn't orphaning the Catalyst/fglrx driver. Among those: Debian, Ubuntu and everything derived from them.

I've always said I'd prefer to run the open driver, and there has been substantial progress in making my particular AMD video chip work better in Linux. But there needs to be just a little bit more performance. The stuttering video NEEDS TO GO.

And before this release, GNOME 3 did not work at all. It works now but is struggling. For me, that means more time running Xfce.

I'd love to see a dramatic improvement when the 3.13.x kernels come into Fedora. If that happens, all is forgiven. But if not, more than likely I'll be moving from Fedora.

Update: Full-screen video in Mplayer is much better than in VLC and GNOME's stock player. That's a workaround but not a full-blown solution.

At this moment, it looks like the AMD Catalyst driver will be disappearing from RPM Fusion. A bad day for #Fedora Linux users.

— Steven Rosenberg (@passthejoe) December 24, 2013

(Click the image above for a larger version)

After news that fedup 0.7 stood a good chance of not successfully upgrading you from Fedora 19 to 20, the project's developers swiftly pushed out fedup 0.8 to solve this and a great many other problems.

As you can see above, the change has come through to my system, and I have updated the package. No, I haven't actually run the fedup upgrade to F20, though I did use the program to bring this system from F18 to F19.

You don't want your bike chain to fall off.

It very well might if you use fedup 0.7.x to do your Fedora 19-to-20 upgrade:

Adam Williamson, who calls himself the "Fedora QA Community Monkey," writes:

I just poked it a bit and it sure seems like upgrades with fedup 0.7 to F20 are busted. They definitely worked when we tested shortly before release, though. I can only think that using fedup 0.7 against upgrade kernel/image built with fedup-dracut 0.8 doesn't work.

If you have fedup installed, you can tell your version with this:

$ yum list fedup

Here is my output of that command:

fedup.noarch 0.7.3-4.fc19 installed

According to Fedora devs and other expert types, the thing to do is wait for fedup 0.8, which will be moving onto Fedora 19 systems any day now via the usual update mechanisms.

Adam puts it this way:

So, here's the news: do your upgrades to F20 with fedup 0.8, yo. It's in updates-testing for F18 and F19 at present, but will go to stable for F19 tomorrow. If you're upgrading from F18, you'll need to pass '--nogpgcheck' to fedup, because of <https://bugzilla.redhat.com/show_bug.cgi?id=1040689>.

Failed fedup upgrades aren't fatal but also aren't fun, so it's worth the wait for a new fedup.

Later: Chris Murphy on the Fedora users mailing list suggests this command to update to fedup 0.8 right now:

$ sudo yum update fedup --enablerepo=updates-testing

Then you could run the full fedup:

$ sudo fedup --network 20

The new release of Fedora -- version 20 -- is here. Since I have a USB stick dedicated to such things, I brought down a couple of live desktops (GNOME and Xfce) to try.

All well and good, that is, but the Linux kernel shipping with F20 is the same 3.11.10 that I'm already using in F19.

But a look at the latest kernels in Fedora's Koji build system (which I recommend you visit often) -- shows that the 3.12.5 kernel is being built right now for F19 and has already been built for F20.

In my experience, a kernel shows up in your local yum update within a week after it first appears in Koji. It's not instant but does flow onto your system if you accept the update.

While on the subject of updates, the Yum Extender (aka Yumex) has proven to be a great way to maintain the packages on my Fedora system. It's quicker and better than PackageKit, and fairly equal to the Debian world's Synaptic Package Manager.

Getting back to Fedora 20, I'm not yet ready to run fedup to get the full update on my F19 system. Instead I'm waiting for the 3.13 kernels to start flowing into F19 proper.

What concerns me most is hardware compatibility, specifically display issues that keep my AMD-based laptop from resuming after suspend. I am looking to new kernels and display drivers to fix this problem. Full system upgrades are just window dressing that, in and of themselves, won't really help. That's what I'm thinking, anyway.

This handy counter tells you when It's here: