Bugs related to GTK+ 3.15.4: White text in Firefox, shrinking GNOME Terminals

A major GTK+ 3 update landed in Rawhide recently, and there are at least a couple of fairly prominent bugs related to it. Lots of text in the Firefox interface – on tab titles, menus, buttons, and things – is now white on grey, which is ugly-to-borderline-unreadable. Also, GNOME terminal windows are now extremely prone to shrinking when focused or unfocused, or when you create and close tabs.

Both bugs have been reported and should be addressed soon:

* Firefox white text bug
* GNOME Terminal shrink bug

so you may want to copy yourself on those bug reports to follow progress. In the meantime, you might want to drop back to GTK+ 3.15.3, or perhaps just switch to a different Terminal app and live with the white text in Firefox.

Fedora 21 package signing: no, it’s not just you

We interrupt this Rawhide blog to bring you an important message!

No, it’s not just you: there are unsigned packages in Fedora 21, and yum (and dnf and mock) are complaining about it.

Here’s what’s going on.

When we branch Branched (in this case, F21) from Rawhide, we don’t immediately enable Bodhi – that is, the process where builds have to be sent to Bodhi which sends them to updates-testing and then to stable after review. For the first few days, Branched package submission works just like Rawhide – the packager submits the build, it gets built by Koji, and it’s automatically pulled into the ‘stable’ repo at the next nightly compose. No updates-testing, no karma.

When the package submission process is working like that, package signing still won’t be 100%. We can only get package signing to 100% when the Bodhi workflow is active.

Bodhi gets turned on when we do the Alpha release freeze. Usually, that’s very soon after branching – like, a week. So there’s a slightly confused week where we do the branch and then run around updating fedora-release and mock configs and so on and the freeze hits and Bodhi gets turned on somewhere in there and after a few days it all shakes out and everything’s running smoothly.

What with Fedora.next and all, the period between Fedora 21 branching and Bodhi being turned on is getting much longer. We’re not really at a point where it makes any sense to freeze for Alpha, so Bodhi isn’t getting turned on, and that means not all packages are getting signed.

So yes, relax, it’s not just you. For right now, please use the –nogpgcheck parameter for Fedora 21 yum and dnf and mock and so forth. We’ll try to send out updates to fedora-repos and mock that will turn off gpgcheck for the next little while, until we freeze and enable Bodhi. We’re sorry for the inconvenience.

Fedora 21 / 22: The Branchening

So, today Fedora 21 branched from Rawhide, and Rawhide is now what will ultimately become Fedora 22.

For any puny weaklings who want to track Fedora 21 and not Fedora 22, I posted up a handy guide. For real men, real women, and real small furry creatures from Alpha Centauri who want to stick with Rawhide, no action is needed: just keep updating. Everyone else, your blog reading privileges are revoked.

Nightly boot.iso fails to boot

Recent nightly Rawhide boot.iso network install images are failing to boot due to a bug in util-linux. The fix has already been identified and pushed upstream, and should work its way downstream into Fedora soon. This doesn’t appear to be affecting the nightly live images.

Slightly older boot.iso images, if you have one lying around, may not suffer from that bug, but probably do suffer from this one, which is caused by metacity (the window manager used by non-live install images) failing to run due to excessive pruning of the anaconda environment. A fix for that bug was also pushed today. With any luck, once the util-linux fix comes downstream, we’ll get working nightlies again.

3.16 kernels broken on i686 up until rc2 (affects installed systems and nightly images)

There was a significant bug in all 3.16 kernels affecting the i686 architecture (32-bit Intel) only. This resulted in all sorts of breakage higher up the stack – dbus would not run, for a start, which causes many other problems. Installed systems might just limp to a console login; of nightly images, both lives and boot.iso images failed to boot fully.

The cause of this was recently identified and a fix submitted upstream. The fix has been pulled into Rawhide immediately, starting with kernel-3.16.0-0.rc2.git0.1.fc21. All 3.16 kernels prior to that should not be used on i686 machines, or you should pass the kernel parameter vdso=0 to work around the bug.

Nightly images should start working again (or, at least, not be broken by this particular bug…) starting from tomorrow, as the fixed kernel is pulled in.

Wifi, direct ADSL, cellular or Bluetooth connections broken after upgrade to NetworkManager 0.9.9.95 with dnf

edit 2014-06-20: this also affects directly connected ADSL modems, cellular modems and Bluetooth connections.

Hey there, intrepid Rawhidenauts! If you use wifi edit: or an ADSL modem or cellular modem or Bluetooth connection/edit on your Rawhide system, and you did a Rawhide update with dnf which brought in NetworkManager-0.9.9.95-1.git20140609.1963adda , you may find that your wifi stopped working after the update.

What happened is that NetworkManager’s support for these types of connection got split into subpackages. The NM maintainer followed the usual packaging protocols for when a new subpackage is introduced which should be automatically added to existing installs, and if you updated with yum then you would’ve got the new subpackages installed correctly, but it seems that people who upgraded with dnf did not get them installed. The issue’s been reported as bug #1107973.

If you’re affected by this, you should install the appropriate subpackage(s) manually. The packages are NetworkManager-wifi, NetworkManager-adsl, NetworkManager-wwan, and NetworkManager-bluetooth. Run, for example,

dnf install NetworkManager-wifi

to fix things up.

Boot failures: systems / KVM guests with a single CPU core, current live installations

There seem to be two interesting failure-to-boot bugs affecting Rawhide at present, intrepid Rawhide-nauts (yes, I totally just invented that).

#1096358 involves systems newly installed from any recent (seems to be since 2014-05-07) Rawhide-based live image. These installations seem to fail to boot – in fact, fail in the bootloader – with an “unaligned pointer” error message. The grub2 maintainer is currently investigating this one. If, for some strange reason, you have an urgent need to install Rawhide right now, non-live installs don’t seem to be affected by this issue.

#1095891 seems, so far, to be affecting virtual machines assigned a single CPU core (although it’s possible it affects real hardware systems with only a single CPU core, no-one’s confirmed that yet – I need to find someone with an old enough system to check it). Such systems fail to boot, this time early in the init process – the issue appears to be in udev. To work around this problem, assign more than one CPU core to the virtual guest, or downgrade to systemd 212-2 or earlier.

Boot failures with kernels installed after grubby-8.31-1.fc21

There was a bug in grubby-8.31-1.fc21 which caused it to write invalid grub config entries. This may only affect UEFI installations. If you installed any kernels after installing that version of grubby, they will likely be unbootable. When you try and boot them you’ll see an error like this:

error: file ‘/vmlinuz-3.14.0-0.rc8.git1.1.fc21.x86_64’ not found.
error: can’t find command ‘devicetree’.
error: you need to load the kernel first.

The bug in grubby is fixed with grubby-8.32-1.fc21, but that’s not the whole story. grubby works by using the top entry in the existing grub config file as a ‘template’ for the new entry, so as long as you have a ‘bad’ entry written by 8.31 as your top entry, even the new grubby will still write broken entries. To completely resolve this issue, you’ll need to manually edit your /etc/grub2.cfg and remove all broken entries. You should still have at least one working entry – the entry for whatever kernel is still bootable. Once you remove all broken entries, things should work OK again. You can reinstall kernel packages whose entries were lost, or use grub2-mkconfig to regenerate the grub2 config file entirely.

GNOME start failure with new selinux-policy

At least for the author, with selinux-policy-3.13.1-27.fc21 , GNOME fails to start correctly if SELinux is in Enforcing mode. If SELinux is in Permissive mode it starts correctly. This denial seems most likely to be the cause of the problem.

Long-term users: check /var/run is a symlink to /run before updating to systemd 210

If your Rawhide system has been around for a while, check that /var/run is a symlink to /run before you update to systemd 210. If it isn’t, the system will likely fail to boot.

Recent Fedora installations create /var/run as a symlink to /run, but older ones didn’t (I don’t know precisely when this was changed), and it seems systemd and dbus disagree about the location of dbus’ socket: dbus thinks it should be in /var/run , and systemd thinks it should be in /run. If one’s a symlink to the other this is fine; if it isn’t, things are very much not fine.

If /var/run isn’t a symlink to /run, you can move its contents into /run and make it into one. (Even if you mess up, this isn’t terribly important, as all this stuff is supposed to be transient anyway: /run is a tmpfs. Worst you can do is break one boot.)

Bug filed upstream for systemd dbus.