Rawhide Watch

Daily warnings for rawhide victims

Archive for the ‘Uncategorized’ Category

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

Posted by adamwill on June 20, 2014

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.

Posted in Uncategorized | Comments Off on Wifi, direct ADSL, cellular or Bluetooth connections broken after upgrade to NetworkManager 0.9.9.95 with dnf

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

Posted by adamwill on May 13, 2014

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.

Posted in Uncategorized | Comments Off on Boot failures: systems / KVM guests with a single CPU core, current live installations

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

Posted by adamwill on April 1, 2014

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.

Posted in Uncategorized | Comments Off on Boot failures with kernels installed after grubby-8.31-1.fc21

GNOME start failure with new selinux-policy

Posted by adamwill on February 26, 2014

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.

Posted in Uncategorized | Comments Off on GNOME start failure with new selinux-policy

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

Posted by adamwill on February 26, 2014

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.

Posted in Uncategorized | Comments Off on Long-term users: check /var/run is a symlink to /run before updating to systemd 210

Boot failures with recent Rawhide kernels

Posted by adamwill on February 4, 2014

Several people have reported that recent kernels sometimes, often or always completely fail to boot, very early in the boot process (right after the boot menu). We’re still looking into this at present, but we have a possible indication of what the problem might be right now. You may see a trace in numa stuff if you boot with earlyprintk=vga.

We’d advise Rawhide users to make sure you still have a 3.13 kernel installed, just in case you run into trouble booting 3.14 kernels.

Edit: kernel-3.14.0-0.rc1.git0.2.fc21 may well fix this. Please test it out, if you’re affected, and let us know if it doesn’t.

Posted in Uncategorized | 2 Comments »

SELinux execmem and execstack denials for everything, and GNOME not running

Posted by adamwill on December 23, 2013

So hey, this blog still exists!

For this author (AdamW), there are two major issues in Rawhide currently. SELinux appears to be denying ‘execmem’ and ‘execstack’ access to all sorts of stuff – this is affecting dhclient (stopping networking working), sshd, sssd (for those of us who use FreeIPA authentication), cups and several other things. I haven’t looked into what caused this exactly yet, but booting with enforcing=0 is likely to be a requirement for Rawhide users until it gets figured out. Bugs filed so far are #1046112 and #1045682.

Also for this author, GNOME currently fails to run at all. GDM doesn’t start, and if I boot to runlevel 3 and run startx I get an extremely broken GNOME session with Shell not running and windows all over the shop. For now, I’ve switched to Xfce. I suspect this is because about half of GNOME 3.11.3 got built before most of the desktop team left for the holidays, but again don’t have precise details yet. We may be able to get it fixed up with the help of any desktop folks who are still around.

Update on GNOME: turns out it just needs a new gsettings-desktop-schemas build. That is now in progress – grab that when it’s done, and GNOME should work again, with all other components at their latest Rawhide level.

Posted in Topical but Not Interesting Later, Uncategorized | 4 Comments »

restorecond in policycoreutils-2.0.71-6 breaks the world, how to recover

Posted by rawhidewatch on August 20, 2009

If you were running the restorecond service and upgraded to policycoreutils-2.0.71-6.fc12 then things went horribly wrong.  restorecond goes nuts and screws up labels across your filesystem.   Logins via ssh or local console breaks among other problems.

Here is how to recover:

  1. Boot into single user mode.
  2. Turn off restorecond service with chkconfig restorecond off
  3. fixfiles restore will fix labels across your entire filesystem.
  4. Reboot into the normal system.
  5. Upgrade to policycoreutils-2.0.71-7.fc12 or later.
  6. chkconfig restorecond on

In related news, you might be having problems with the restorecon command.  In the past commands like restorecon -Rv . would relabel the current directory, but now it fails silently.  dwalsh says this is a bug he intends to fix.  Until it is fixed, you must specify an absolute pathname to the restorecon command.

Posted in Uncategorized | Comments Off on restorecond in policycoreutils-2.0.71-6 breaks the world, how to recover

Blank notification area (systray) workaround

Posted by rawhidewatch on August 3, 2009

Many are experiencing a problem where the notification area (a.k.a. systray, or that place icons like nm-applet appear) being blank in rawhide.  The current workaround is to restart notification-area-applet a few times.  There is a bug report for this issue. Hopefully this will be fixed soon.  Thanks to mclasen for this tip.

Posted in Uncategorized | Comments Off on Blank notification area (systray) workaround

Unable to update to rawhide – rpmlib(PayloadIsXz)

Posted by rawhidewatch on July 31, 2009

jlaska wrote:
Trying to update your Fedora 11 (or older) system to the latest rawhide content?  You might notice a failure similar to below when attempting to upgrade using yum:

rpmlib(PayloadIsXz) <= 5.2-1 is needed by kernel-PAE-2.6.31-0.107.rc4.git3.fc12.i686 
rpmlib(PayloadIsXz) <= 5.2-1 is needed by kernel-firmware-2.6.31-0.107.rc4.git3.fc12.noarch

Turns out that rawhide packages now use XZ (the new LZMA format) as the default payload compression format.  The details of this new feature can be found on the XZRpmPayloads feature page.  Testers that install directly from Fedora 12 or rawhide should not experience problems.  However, folks upgrading from Fedora 11 or from an older rawhide may need to manually workaround this issue using the following commands:

yum --enablerepo=updates-testing update rpm

Once completed, you may continue with the rawhide upgrade:

yum --disablerepo=* --enablerepo=rawhide update

More information on upgrading to rawhide can be found on the wiki.

Happy testing!

Posted in Uncategorized | Comments Off on Unable to update to rawhide – rpmlib(PayloadIsXz)