• Esse quam videri.


  • Archives

  • Control Room

  • Categories

Note for Fedora 16 early testers.

If you’re like me and you couldn’t wait to see Fedora 16 in its pre-release state, you take on the risk of any pre-release. Sometimes things are broken, or break during the fixing process, with the goal of making everything more awesome in its final form. Today I ran into such a problem, and I wanted to share it. Hopefully this problem should be fixed in the final release; I’ve already filed a bug for this issue and it’s been resolved in a later package.

Currently the Fedora 16 updates-testing version of selinux-policy* packages is 3.10.0-43.fc16. This policy doesn’t adequately cover some file locations used by systemd to handle passphrases on LUKS encrypted file systems. If you use encrypted file systems (at least as provided by the Fedora installer) and usually type your passphrase during the boot process, you’ll probably be affected. The plymouth loader won’t get the request to display the passphrase, and you won’t be able to enter it. So systemd will timeout waiting for the ability to mount those file systems, and your boot will fail with a maintenance prompt.

If you want to get past this problem, provide your root password and then enter the following commands:

systemctl start local-fs.target
systemctl default

This will present the necessary prompt at the console (once per file system), and then try to boot to the default target again. To fix the problem, once you’ve booted successfully, downgrade the affected packages:

yum downgrade selinux-policy\*

That should get you back the 3.10.0-40.fc16 packages, which don’t encompass checks on the affected systemd files and therefore don’t produce the errors.

As I mentioned, this has already been fixed and new testing updates should be out shortly. I wanted to make this particular problem visible since it does actually prevent booting an installable configuration right now, since I know many intrepid testers may run across this blog on our Planet.

4 Comments

  1. Adam Williamson said,

    October 20, 2011 @ 2:07 pm

    I would guess a simpler workaround would be to boot with ‘enforcing=0′ as a kernel parameter.

  2. Carlos (casep) Sepulveda said,

    October 20, 2011 @ 2:48 pm

    Thanks! I was about to update my system :)

  3. steve v said,

    October 20, 2011 @ 6:46 pm

    Cheers, same here!

  4. Joao Verissimo said,

    October 20, 2011 @ 11:32 pm

    Thank you! Had to reinstall and have been too afraid to update… :) Great that it’s fixed!

RSS feed for comments on this post

© 2002-2014 Paul W. Frields License: CC BY-SA 3.0. Some rights reserved. -- Copyright notice by Blog Copyright

%d bloggers like this: