Solved: ports on ThinkPad Thunderbolt dock doesn’t work with Fedora

I got a new ThinkPad X1 Carbon laptop for work. Of course I immediately installed Fedora 28 on it. Everything seemed to work just fine. But the laptop came with a ThinkPad Thunderbolt dock and when I went to go use it, I noticed the Ethernet port didn’t work. Then I noticed the USB ports didn’t work. But at least the HDMI port worked? (Full disclosure: I didn’t try the VGA port).

It turns out the solution was really simple, but I didn’t find a simple explanation so I’m putting one here. (Comment #17 of Red Hat Buzilla #1367508 had the basic solution. I hope this post becomes a little easier to find.)

The dock uses Thunderbolt which includes some security features. A package called bolt provides a management tool for this. Happily, it’s already in the Fedora 28 repo.

First, I installed it

# dnf install bolt

Then I examined the connected device


# boltctl list
● Lenovo ThinkPad Thunderbolt 3 Dock
├─ type: peripheral
├─ name: ThinkPad Thunderbolt 3 Dock
├─ vendor: Lenovo
├─ uuid: 00cd2054-ef95-0801-ffff-ffffffffffff
├─ status: connected
│ ├─ authflags: none
│ └─ connected: Fri 29 Jun 2018 03:13:10 PM UTC
└─ stored: no

Finally, I enrolled the device

# boltctl enroll 00cd2054-ef95-0801-ffff-ffffffffffff
● Lenovo ThinkPad Thunderbolt 3 Dock
├─ type: peripheral
├─ name: ThinkPad Thunderbolt 3 Dock
├─ vendor: Lenovo
├─ uuid: 00cd2054-ef95-0801-ffff-ffffffffffff
├─ dbus path: /org/freedesktop/bolt/devices/00cd2054_ef95_0801_ffff_ffffffffffff
├─ status: authorized
│ ├─ authflags: none
│ ├─ parent: cf030000-0080-7f18-23d0-7d0ba8c14120
│ ├─ syspath: /sys/devices/pci0000:00/0000:00:1d.0/0000:05:00.0/0000:06:00.0/0000:07:00.0/domain0/0-0/0-1
│ ├─ authorized: Fri 29 Jun 2018 03:19:39 PM UTC
│ └─ connected: Fri 29 Jun 2018 03:13:10 PM UTC
└─ stored: yes
├─ when: Fri 29 Jun 2018 03:19:39 PM UTC
├─ policy: auto
└─ key: no

After that, everything worked as expected. I’d like to thank the people who did the work to discover and implement the fix. I hope this post means a little less Googling for the next person.

HP laptop keyboard won’t type on Linux

Here’s another story from my “WTF, computer?!” files (and also my “oh I’m dumb” files).

As I regularly do, I recently updated my Fedora machines. This includes the crappy HP 2000-2b30DX Notebook PC that I bought as a refurb in 2013. After dnf finished, I rebooted the laptop and put it away. Then while I was at a conference last week, my wife sent me a text telling me that she couldn’t type on it.

When I got home I took a look. Sure enough, they keyboard didn’t key. But it was weirder than that. I could type in the decryption password for the hard drive at the beginning of the boot process. And when I attached a wireless keyboard, I could type. Knowing the hardware worked, I dropped to runlevel 3. The built-in keyboard worked then.

I tried applying the latest updates, but that didn’t help. Some internet searching lead me to Freedesktop.org bug 103561. Running dnf downgrade libinput and rebooting gave me a working keyboard again. The bug is closed as NOTABUG, since the maintainers say it’s an issue in the kernel, which is fixed in the 4.13 kernel release. So I checked to see if Fedora 27, which was released last week, includes the 4.13 kernel. It does, and so does Fedora 26.

That’s when I realized I still had the kernel package excluded from dnf updates on that machine because of a previous issue where a kernel update caused the boot process to hang while/after loading the initrd. I removed the exclusion, updated the kernel, and re-updated libinput. After a reboot, the keyboard still worked. But if you’re using a kernel version from 4.9 to 4.12, libinput 1.9, and an HP device, your keyboard may not work. Update to kernel 4.13 or downgrade libinput (or replace your hardware. I would not recommend the HP 2000 Notebook. It is not good.)

Using the ASUS ZenBook for Fedora

I recently decided that I’d had enough of the refurbished laptop I bought four years ago. It’s big and heavy and slow and sometimes the fan doesn’t work. I wanted something more portable and powerful enough that I could smoothly scroll the web browser. After looking around for good Linux laptops, I settled on the ASUS ZenBook.

Installation

The laptop came with Windows 10 installed, but that’s not really my jam. I decided to boot off a Fedora 26 KDE live image first just to make sure everything worked before committing to installing. Desktop Linux has made a lot of progress over the years, but you never know which hardware might not be supported. As it turns out, that wasn’t a problem. WiFi, Bluetooth, webcam, speakers, etc all worked out of the box.

It’s almost disappointing in a sense. There used to be some challenge in getting things working, but now it’s just install and go. This is great overall, of course, because it means Linux is more accessible to new users and it’s less crap I have to deal with when I just want my damn computer to work. But there’s still a little bit of the nostalgia for the days when configuring X11 by hand was something you had to do.

Use

I’ve had the laptop for a little over a month now. I haven’t put it through quite the workout I’d hoped to, but I feel like I’ve used it enough to have an opinion at this point. Overall, I really like it. The main problem I have is that the trackpad has a middle-click, which is actually pretty nice except for when I accidentally use it. I’ve closed many a browser tab because I didn’t move my thumb far enough over. That’s probably something I can disable in the settings, but I’d rather learn my way around it.

The Bluetooth has been flaky transferring files to and from my phone. but audio is…well I’ve never found Bluetooth audio to be particularly great, but it works as well as anything else.

One other bit of trouble I’ve had is with my home WiFI. I bought a range extender so that I can use WiFi on the back deck and it to use the same SSID as the main router. The directions said you can do this, but it might cause problems. With this laptop, the WiFi connection becomes unusable after a short period of time. Turning off the range extender fixes it, and I’ve had no other problems on other networks, so I guess I know what I have to do.

One thing that really stood out to me is carrying it around in a backpack. This thing is light. I had a few brief moments of panic thinking I had left it behind. I’ve held lighter laptops, but this is a good weight. But don’t worry about the lightness, it still has plenty of electrons to have a good battery life.

Around the same time I bought this, I got a new MacBook Pro for work. When it comes to typing, I like the keyboard on the ZenBook way better than the new MacBook keyboards.

Recommendation

If you’re looking for a lightweight Linux laptop that can handle general development and desktop applications, the ASUS ZenBook is a great choice. Shameless commercialism: If you’re going to buy one, maybe use this here affiliate link? Or don’t. I won’t judge you.

KDE immediately returns to the login screen: one explanation

Earlier this week, I bought a new laptop. More on that once I’ve had a little more time to use it. But I wanted to share two things that I learned while setting it up. The first is straightforward: I really regret not putting effort into getting key configs (like users) into Ansible so that I didn’t have to do stuff by hands. The second requires some storytelling.

I installed Fedora 26 (KDE spin) and everything seemed good. I created accounts for my wife and me and then called it a night because I was tired. The next day, I wanted to get a little more configuration done, so I tried to log in. My password was accepted, but it immediately returned me to the login screen. So I logged in to a text console. That worked fine. I tried logging in to KDE as root. It worked. It had to be something about my account.

So I asked the trusty journal what was wrong. I saw messages like this:

Oct 05 18:04:44 holton sddm-helper[2770]: Starting: "/etc/X11/xinit/Xsession /usr/bin/startkde"
Oct 05 18:04:44 holton audit[2787]: AVC avc: denied { write } for pid=2787 comm="sddm-helper" name="bcotton" dev="dm-3" ino=5242881 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unco
Oct 05 18:04:44 holton sddm-helper[2787]: Could not open stderr to "/home/bcotton/.cache/xsession-errors"
Oct 05 18:04:44 holton audit[2787]: AVC avc: denied { write } for pid=2787 comm="sddm-helper" name="bcotton" dev="dm-3" ino=5242881 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unco
Oct 05 18:04:44 holton kernel: sddm-helper[2787]: segfault at 0 ip 00007fc1e8f97b1e sp 00007ffc7a29d1e0 error 4 in libc-2.25.so[7fc1e8f25000+1c7000]
Oct 05 18:04:44 holton audit[2787]: ANOM_ABEND auid=47703 uid=47703 gid=500 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=2787 comm="sddm-helper" exe="/usr/libexec/sddm-helper" sig=11 res=
Oct 05 18:04:44 holton sddm-helper[2787]: Opening the Xauthority file at "/home/bcotton/.Xauthority" failed
Oct 05 18:04:44 holton sddm-helper[2770]: pam_unix(sddm:session): session closed for user bcotton

I checked to make sure my home directory existed. It did.

I checked to make sure I could write to it. I could.

I turned off Selinux. No help.

A forum post suggested removing the sddm package and using kdm instead. It didn’t help.

I created a new user. It could log in. What was going on?

Well at one point, I noticed that when I did an ls -l on /home, my home directory showed a numeric group ID instead of a name. Ah ha! When I created the users, I used KDE’s user management GUI. It auto-created a group with a GID that matched the UID of the account. But I didn’t want that group, so I deleted it and made another group my default. But by that point, the home directory had already been created, so it was owned by the group that no longer exists.

After I changed the group ownership, it worked just fine. I should have just used the useradd command to begin with since I could have made it work the way I intended. Or I could have used a configuration management tool to do it for me. Maybe that will be my next project…

New to Fedora: wordgrinder

Do you ever wish you had a word processor that just processed words? Font selection? Pah! Styling? Just a tiny bit, please. Or maybe you read Scott Nesbitt’s article on Opensource.com and thought “I’d like to try this!” If this sounds like you, then it may interest you to know that WordGrinder is now available on Fedora 25, 26, and Rawhide.

View of WordGrinder in a terminal

WordGrinder

I should clarify that it’s only available on some architectures (x86_64, i686, aarch64, and armv7hl). WordGrinder depends on luaJIT which is only available on those platforms.

This is my first new Fedora package, and I have to say I’m kind of proud of myself. I tried to volunteer someone else for it, but he didn’t know how to build RPMs so I ended up volunteering myself. In the process, I had to patch the upstream release to build on Fedora, and then patch my patch to get it to build on Rawhide. In true Fedora fashion, I submitted my patch upstream and it was accepted. So not only did I make a new package available, but I also made an improvement to a project written in a language that I don’t know.

Yay open source!

Disappearing WiFi with rt2800pci

I recently did a routine package update on my Fedora 24 laptop. I’ve had the laptop for three years and have been running various Fedorae the whole time, so I didn’t think much of it. So it came as some surprise to me when after rebooting I could no longer connect to my WiFi network. In fact, there was no indication that any wireless networks were even available.

Since the update included a new kernel, I thought that might be the issue. Rebooting into the old kernel seemed to fix it (more on that later!), so I filed a bug, excluded kernel packages from future updates, and moved on.

But a few days later, I rebooted and my WiFi was gone again. The kernel hadn’t updated, so what could it be? I spent a lot of time flailing around until I found a “solution”. A four-year-old forum post said don’t reboot. Booting from off or suspending and resuming the laptop will cause the wireless to work again.

And it turns out, that “fixed” it for me. A few other posts seemed to suggest power management issues in the rt2800pci driver. I guess that’s what’s going on here, though I can’t figure out why I’m suddenly seeing it after so long. Seems like a weird failure mode for failing hardware.

Here’s what dmesg and the systemd journal reported:

Aug 01 14:54:24 localhost.localdomain kernel: ieee80211 phy0: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0x00000068]
Aug 01 14:54:24 localhost.localdomain kernel: ieee80211 phy0: rt2800pci_set_device_state: Error - Device failed to enter state 4 (-5)

Hopefully, this post saves someone else a little bit of time in trying to figure out what’s going on.

Changing how HTCondor is packaged in Fedora

The HTCondor grid scheduler and resource manager follows the old Linux kernel versioning scheme: for release x.y.z, if y is an even number it’s a “stable” series that get bugfixes, behavior changes and major features go on odd-numbered y. For a long time, the HTCondor packages in Fedora used the development series. However, this leads to a choice between introducing behavior changes when a new development HTCondor release comes out or pinning a Fedora release to a particular HTCondor release which means no bugfixes.

This ignores the Fedora Packaging Guidelines, too:

As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time.

Although the HTCondor developers do an excellent job of preserving backward compatibility, behavior changes can happen between x.y.1 and x.y.2. HTCondor is not a major part of Fedora, but we should still attempt to be good citizens.

After discussing the matter with upstream and the other co-maintainers, I’ve submitted a self-contained change for Fedora 25 that will

  1. Upgrade the HTCondor version to 8.6
  2. Keep HTCondor in Fedora on the stable release series going forward

Most of the bug reports against the condor-* packages have been packaging issues and not HTCondor bugs, so upstream isn’t losing a massive testing resource here. I think this will be a net benefit to Fedora since it prevents unexpected behavior changes and makes it more likely that I’ll package upstream releases as soon as they come out.

Fedora 24 upgrade

Fedora 24 was released last week, so of course I had to upgrade my machines. As has become the norm, there weren’t any serious issues, but I hit a few annoyances this time around. The first was due to packages in the RPMFusion repos not being signed. This isn’t Fedora’s fault, as RPMFusion is a completely separate project. And it was temporary: by the time I upgraded my laptop on Sunday night, the packages had all been signed.

Several packages had to be dropped by using the –allowerasing argument to dnf. Mostly these were packages installed from RPMFusion, but there were a couple of Fedora packages as well.

The biggest annoyance was that post-upgrade, I had no graphical login. I had to explicitly start the desktop manager service with:

systemctl enable kdm
systemctl start kdm

kdm had previously been enabled on both machines, but the upgrade nuked that in both cases. It looks like I’m not the only person to hit this: https://bugzilla.redhat.com/show_bug.cgi?id=1337546

And now, my traditional meaningless torrent stats!

Here’s my seeding ratios for Fedora 23:

Flavor i686 x86_64
KDE 16.2 35.6
Security 10.3 21.1
Workstation 30.9 46.7
Server 17.5 25.0

The “ratio ratio” as I call it is a comparison of seeding ratios between the two main architectures:

Flavor x86_64:i686
KDE 2.20
Security 2.05
Workstation 1.51
Server 1.43

So what does all of this tell us? Nothing, of course. Just because someone downloads a torrent that doesn’t mean they use it. Still, if we pretend that it’s a proxy for usage, all of the seeding ratios are higher than on the last release day. That tells me that Fedora is becoming more popular (yay!). 64-bit architectures are continuing to be a larger portion of the pie, as well.

Now that I’m starting to build a record of these, I can start reporting trends with the Fedora 25 release.

I support Software Freedom Conservancy

If you’ve read this blog for any length of time, you know that free and open source software is important to me. It’s important to Software Freedom Conservancy as well. Conservancy is a 501(c)(3) organization dedicated to supporting software projects.

Conservancy provides a lot of services to member projects, including financial and administrivia. Conservancy also provides license enforcement services, including support of a high-profile suit against VMWare. Although Conservancy uses litigation as a last resort, it’s sometimes necessary. However, this has lead to some corporate sponsors pulling their funding.

In order to continue their efforts, Conservancy is moving to an individual-supporter model. I first became a Conservancy supporter last year, and when it’s shortly time to renew my support, I will contribute double. Free and open source software is important to my personal and professional lives, and the services Conservancy provide to projects is invaluable.

If you use computers at all, a Conservancy project is probably an important part of your daily life. Please join me in supporting the Software Freedom Conservancy with a tax-deductible* donation today.

*Consult your tax professional to see if donations are tax-deductible in your jurisdiction.

Upgrading to Fedora 23 and some meaningless torrent stats

Since Fedora 23 was released yesterday, I went ahead and upgraded my desktop over lunch. The process was mostly painless. I followed the instructions for using dnf in Fedora Magazine, but hit a small snag: a few of the packages blocked on requirements. So I removed an old kernel-devel package and gstreamer-plugins-ugly. But I still got this:

package kf5-kdesu-5.15.0-2.fc23.x86_64 requires kf5-filesystem >= 5.15.0, but none of the providers can be installed.

That’s not great, because you can’t remove that package without also removing KDE Plasma. Taking the –best off of the dnf invocation fixed it, without any weird upgrade issues (the –best option supposedly cancels the download if a package can’t be upgraded, but everything seems good after the fact).

Since I don’t have any great tales of technical prowess to share, I thought I’d comment on the torrents. Measuring usage of an open source operating system is a really tricky thing, so I thought I might see what the torrents tell us. Keep in mind that torrents are probably a terrible way of measuring popularity, too. I’m just going to assume that most people who torrent ISOs are only torrenting the ones they actually use (instead of me, where I torrent several just to be a good citizen).

Here’s my seeding ratios for Fedora 22:

Flavor i686 x86_64
KDE 16.1 32.9
Security 8.02 13.6
Workstation 24.8 31.2
Server 10.3 15

The “ratio ratio” as I call it is a comparison of seeding ratios between the two main architectures:

Flavor x86_64:i686
KDE 2.04
Security 1.70
Workstation 1.26
Server 1.46

So what does all of this tell us? Apart from “absolutely nothing!”, it says that KDE users install on x86_64 way more than on i686. Workstation is still really popular on 32-bit machines and overall. The first 32 hours of seeding for Fedora 23 show similar patterns. Yay?