Title photo
frugal technology, simple living and guerrilla large-appliance repair

Regular blog here, 'microblog' there

Many of my traditional blog post live on this site, but a great majority of my social-style posts can be found on my much-busier microbloging site at updates.passthejoe.net. It's busier because my BlogPoster "microblogging" script generates short, Twitter-style posts from the Linux or Windows (or anywhere you can run Ruby with too many Gems) command line, uploads them to the web server and send them out on my Twitter and Mastodon feeds.

I used to post to this blog via scripts and Unix/Linux utilities (curl and Unison) that helped me mirror the files locally and on the server. Since this site recently moved hosts, none of that is set up. I'm just using SFTP and SSH to write posts and manage the site.

Disqus comments are not live just yet because I'm not sure about what I'm going to do for the domain on this site. I'll probably restore the old domain at first just to have some continuity, but for now I like using the "free" domain from this site's new host, NearlyFreeSpeech.net.

Wed, 22 Jan 2014

Fedora -- or any Linux -- with working suspend/resume is awesome

It's been a long time since those halcyon days of mid-2010 through early 2013 when I ran Debian Squeeze and Wheezy on my Lenovo G555 laptop (with AMD CPU and GPU) and had working suspend/resume.

Being able to suspend the laptop and bring it back within seconds by opening the lid changes the way I use the computer. It's pretty much a killer feature. And I've missed it terribly.

Read the rest of this post

Mon, 20 Jan 2014

I can be bought cheap, and Fedora has me locked in

It doesn't take much to buy my (operating-system) loyalty. Fedora Linux did it with a working video driver and working suspend/resume.

That and the system not blowing up and all the software I want? That's pretty much all it takes.

Sat, 18 Jan 2014

I solve the suspend/resume problem in Fedora 20

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:


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


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.

Is your Fedora update failing due to 'scriptlet' issue? Here's the quick, easy fix

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.

Fri, 17 Jan 2014

Windows 8.1 upgrade fails, kills the bootloader, but I eventually find the fix

(I used a digital camera to capture the screen images of my Windows boot failure and subsequent 8.1 upgrade failure so you can share in my pain before reading below how I fixed what Microsoft broke)

So I figured I'd upgrade the Windows 8 portion of my Windows/Fedora dual-booting (and naturally EFI-running) system to the presumably shinier, newer Windows 8.1 with the offer of an upgrade via the Microsoft Store.

Big fucking mistake.

I go into Windows 8 and do the upgrade. It tells me at some point that "there will be several reboots."

The first reboot was the last. Windows would no longer boot. (Luckily Fedora continued to boot during this whole nightmare.) When I tried to start Windows 8, I got a blue-screen error with the code 0xc000000f.

I went into Recovery Mode via the BIOS.

The automatic repair didn't work. Then I went to Advanced Options, then to the Windows command prompt, to start trying hacks.

The easy hacks didn't work.

Read the rest of this post

Buy Debian merchandise from Debian France (and it helps if you can read French)

Debian France now has an online store where they sell Debian-related merchandise: hats, shirts, even umbrellas, pocket knives and those "buff" things that losing "Survivor" contestants throw into the fire on the show's Redemption Island (which probably tells you too much about my recent TV viewing).

The currency is Euros, the language French. May the European force be with you.

Phoronix is one of my essential resources

Especially while I'm obsessed with the state of AMD video drivers, but for all Linux and much BSD news, Michael Larabel's Phoronix is an essential site that I'm looking at every day.

I honestly don't know how he keeps up the pace, but if you're looking for news on the state of AMD, Nvidia and Intel video, AMD, Intel and ARM CPUs, the Linux kernel, benchmarking of hardware and Linux and BSD distribution, plus what's going on (both in plain sight and behind the scenes) in many of the projects that make up the free-software ecosystems, Michael appears to have it covered, and for that I thank him.

Sun, 12 Jan 2014

I succeed installing AMD Catalyst in Fedora 20, and that means I don't have to dump the distro

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

Could the kernel-devel package be the thing preventing AMD's Catalyst from installing in Fedora 20?

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

Fri, 03 Jan 2014

From ReadWrite: Online Privacy: We Are The Authors Of Our Own Demise

Online Privacy: We Are The Authors Of Our Own Demise by Matt Asay. The subtitle: We used to pay with money. Now we pay with our private data. Will we regret it?