Ask Your Question

F21 fails to boot reliably with kernels >= 3.18

asked 2015-03-10 03:00:07 -0500

fat-lobyte gravatar image

updated 2015-05-30 11:18:54 -0500

mether gravatar image

Solved: upgrade to Fedora 22 with fedup.

Hi! I have a problem with my system and hope that you guys could help me.

The Problem

With recent kernel versions, sometimes the boot gets "stuck". This is occurs randomly (estimated 50% of the time). Booting without "rhgb quiet" produces the following screen: Boot screen when stuck

I assume that there isn't anything special about "Started Set Up Additional Binary Formats", because with different kernel versions/drivers the last line was something different.

The Workarounds

The strange thing is, I still have an old 3.17.4 Kernel image installed. This one boots perfectly well, 100% of time. Also, if I add "3" to the command line, boot (with >= 3.18) into text mode, log in as root and do telinit 5, the machine comes up completely fine.

Here is the journalctl -b of a randomly successful boot: There is no journal for a failed boot, I checked with journalctl --list-boots.

The System

  • Fedora 21, with the following packages installed:
  • Booting uses UEFI
  • Hardware:
    • CPU: Intel i5 4690k
    • Graphics: NVIDIA GTX 960
    • SSD: 256GB 2,5" CRUCIAL MX100 SATA III rt (Root partition drive)
    • HDD: WD 2TB WD20EZRX GP SA3 ("data" drive)
    • HDD: 250 gbSAMSUNG SP2504C
    • Mainboard: MSI Z97 PC-Mate

What I tried so far

  • Adding nomodeset as Kernel parameter: no difference
  • Adding nox2acpi as Kernel parameter: no difference
  • Changing NVIDIA drivers: This whole problem started out when I had a default install and only had "nouveau" drivers. I thought installing proprietary NVIDIA drivers (from RPMFusion) would fix the problem. I switched back and forth, and they seem to have no effect on the boot behaviour.
  • Installing different kernel versions: I tried several 3.18 versions, one 3.19 from rawhide-kernel-nodebug, and one 4.0.0rc1 from rawhide-kernel-nodebug. They all behave the same.
    • Installing self-compiled kernels with default-configs: 4.0.0rc5 fails, 3.17.8 works
  • Updating Motherboard BIOS from 4.0 -> 4.7
  • Turning off Turbo Boost Mode of the CPU
  • Running btrfs-zero-log on the root partition
  • running btrfs check --repair on the root partition
  • patching the kernel with commit 9c4f61

Update: Seeing that even self-compiled kernels behave the same way (4.0.0rc5 fails, 3.17.8 works), I would infer that:

  • Fedora Kernel Patches are not the problem
  • Fedora Kernel Config are not the problem

Also, I installed a different 3.17-version (3.17.8) from Koji, it works just as well as 3.17.4. Which leads me to believe that

  • it's not a ramdisk-issue
edit retag flag offensive close merge delete


+1 happens to me too. I'm UEFI and same behavior (before I reinstalled)

abadrinath gravatar imageabadrinath ( 2015-03-13 04:21:24 -0500 )edit

@hello After you reinstalled, was the problem solved?

fat-lobyte gravatar imagefat-lobyte ( 2015-03-18 04:00:21 -0500 )edit

The same problem :(

tim4dev gravatar imagetim4dev ( 2015-03-31 01:23:57 -0500 )edit

@tim4dev, please describe your system shortly. Do you boot with UEFI? Where is your root file system (disk type and partition type)?

fat-lobyte gravatar imagefat-lobyte ( 2015-03-31 10:24:33 -0500 )edit

I'll throw out a wild guess and say it might be the NVIDIA driver.
Boot into the system and check what kmod packages you have installed. It could be that you don't have the proper NVIDIA kernel modules installed for that specific kernel. If no pertinent kmod-nvidia package is available in your enabled repositories, try the akmod route.

ILMostro gravatar imageILMostro ( 2015-03-31 20:31:48 -0500 )edit

10 Answers

Sort by » oldest newest most voted

answered 2015-05-30 03:57:09 -0500

fat-lobyte gravatar image

Solved by upgrading my System to Fedora 22.

I used FedUp to upgrade, and the issue went away completely. The current kernel is 4.0.4 and every boot works fine.

Thanks for your thoughts and suggestions.

edit flag offensive delete link more


I could boot on fedora 22 every time without problem, then this morning I updated to kernel 4.0.6 and the issue re-appeared : boot stuck at the very begining. If I boot with kernel 4.0.5 no problem, but with the latest this old problem re-appeared.

Saule gravatar imageSaule ( 2015-07-03 06:06:49 -0500 )edit

I am currently on 4.0.8 and all of my boots work perfectly well. I think your problem is different from mine, and I suggest that you create a new question.

fat-lobyte gravatar imagefat-lobyte ( 2015-07-18 05:08:19 -0500 )edit

answered 2015-04-09 19:49:37 -0500

Jmlevick gravatar image

Hello everyone!

Recently I came across a very similar issue in my current F21 Setup (BTRFS /, UEFI Machine etc) and found out a "workaround/solution" that I describe in my question:

Could you try what I did please and tell me if your system boots afterwards? This way we could know if we're facing the same issue and then be a step closer to solve it.


edit flag offensive delete link more


Hi, thanks for the hint but that did not solve my issue.

fat-lobyte gravatar imagefat-lobyte ( 2015-04-19 18:35:51 -0500 )edit

answered 2015-03-13 04:00:23 -0500

Saule gravatar image

I had a similar problem: none of the 3.18 kernels would boot while the 3.17 always booted. The boot was stuck very early in the process, after 4 seconds more or less, and like you there was nothing in journalctl for the failed boot.

I updated the BIOS of my Asustek M4A88TD motherboard and now it worked two times in a row with the latest 3.18 kernel. I was using the original BIOS of 2010, so I flashed it with a bios update found on their site (of 2012). Updating the BIOS implies getting a ROM file (delivered in a zip) from asus, putting it on a USB, then get in the BIOS menu and use the EZ-2 flash utility that worked (the procedure described on asus support site did not work).

As a bonus, the sound works back again, since a few days it was broken (it happens sometimes when I upgrade kernels).

edit flag offensive delete link more


Thanks for the hint, I updated my Motherboard BIOS, but the problem still persists.

fat-lobyte gravatar imagefat-lobyte ( 2015-03-18 04:20:39 -0500 )edit

unfortunately the problem is not solved: the boot fails about 50% of the time. When it fails, I try again and it usually works the second time. Problem happened since kernel 3.18. My filesystems are all ext4.

Saule gravatar imageSaule ( 2015-04-24 15:51:16 -0500 )edit

answered 2015-04-07 02:40:52 -0500

johanh gravatar image

updated 2015-04-10 12:06:37 -0500

Edit: I think I have fixed the issue on my system now. I compiled a new kernel with this patch:

I have booted several times now and the problem seems to be gone. The solution was referred to here:

Sounds like I have this issue, too. There are two PCs with the issue.

The first one: Intel i5, Asrock Z68 Extreme 3 Gen 3, Samsung 840 Evo SSD 250GB, UEFI (non-secure), GPT, BTRFS root, NVIDIA 680 with Nvidia drivers. Pretty standard Fedora 21 installation except for the BTRFS root filesystem (I did save /home from a previous installation, though).

This PC has issues booting almost every time. It stops at about the same point as referred to in the first post. If you wait about 4 minutes, you get to the rescue prompt and it will often say that "mounting /sysroot failed". If you select another kernel upon boot (which one doesn't seem to matter), you have a better chance to start the system, it seems. The problem is with both 3.18 and 3.19 kernels. There is nothing in the logs indicating what is wrong.

The strange thing is that sometimes you can boot a couple of times in a row. Other times it won't boot the same kernel no matter what (I think I tried almost ten times). And then when selecting another kernel, it suddenly works. Then the next day, you can't boot the kernel that worked yesterday. I can't see a pattern here.

The second one: Intel i7, Asrock Z97 Extreme 4, Two 450 GB SAS disks in RAID 1 on LSI SAS controller, UEFI (non-secure), GPT, BTRFS root, NVIDIA 670 with Nvidia drivers. Pretty standard Fedora 21 installation, except for the BTRFS root, and with home on separate 1 GB disk. This PC has only experienced this issue a couple of times. It is not booted often, though.

Edit: No solution yet, but I highly suspect it is btrfs that is the problem here.

edit flag offensive delete link more


I could add that I upgraded to the latest BIOS (UEFI) on the motherboards, Nvidia cards and the RAID controller (on the second PC). I could not notice any difference in behavior with regards to the aforementioned issue.

johanh gravatar imagejohanh ( 2015-04-07 02:30:36 -0500 )edit

I tried setting system clock to UTC. No change. I also tried a long shot and created a new initramfs with dracut and included /etc/adjtime as suggested in some other bug reports regarding boot problems. Didn't help.

johanh gravatar imagejohanh ( 2015-04-08 01:37:12 -0500 )edit

Today the i5 computer didn't want to boot at all. Tried too many times. Ended up booting an F21 Server CD in rescue mode and running "btrfs check --repair /dev/sda4". It fixed some errors. Now after hard rebooting a few times, the system booted. I'm quite convinced it is a btrfs bug, possibly in combination with some other component and this specific setup (UEFI, SSD, Btrfs).

johanh gravatar imagejohanh ( 2015-04-08 11:53:36 -0500 )edit

Hi, which kernel did you recompile? I tried v3.19.3 with 9c4f61 cherry-picked and it did not fix my problem unfortunately. Running btrfs-zero-log also didnt help.

fat-lobyte gravatar imagefat-lobyte ( 2015-04-12 06:31:43 -0500 )edit

answered 2015-04-09 03:30:57 -0500

leaveitblank gravatar image

updated 2015-04-22 07:28:39 -0500

Like ILMostro said, it seems the Kernel Mode Driver isn't doing what it should do.

Your Log is showing: Mär 10 08:16:03 desktop-fedora.local akmods[655]: Ignoring nvidia-kmod as it failed earlier[WARNUNG] Mär 10 08:16:03 desktop-fedora.local akmods[655]: Hint: Some kmods were ignored or failed to build or install. Mär 10 08:16:03 desktop-fedora.local akmods[655]: You can try to rebuild and install them by by calling Mär 10 08:16:03 desktop-fedora.local akmods[655]: '/usr/sbin/akmods --force' as root.

I have booting problem with every 3.18 and 3.19 Kernels. EDIT: and now even with 4.0 on f22.


It seems a lot of people have problems with intel apu and ext nvidia gpu when using the open source drivers intel and nouveau.

I edited the Linux Kernel boot parameters and added: nouveau.modeset=0 rd.driver.blacklist=nouveau rd.driver.blacklist=drm video.allow_duplicates=1

My Laptop is now booting fine every time. It seems this is a larger issue within the nouveau driver.

edit flag offensive delete link more

answered 2015-03-13 18:56:42 -0500

rychrd gravatar image

updated 2015-03-14 03:52:28 -0500


same problem. My CPU is a i5-4690K too and after turning off the Turbo Mode in the UEFI BIOS settings it seems to work. The last 5 starts where succesful, after nearly every boot failed with kernel versions 3.18.x before. This would be no solution, of course, but maybe a hint ...

edit flag offensive delete link more


Thanks for the hint, but unfortunately disabling Turbo Mode did not change anything - still hangs at about the same place.

fat-lobyte gravatar imagefat-lobyte ( 2015-03-18 04:19:57 -0500 )edit

Disabling Turbo Mode also did nothing for me. The strange thing is i can anways boot into recovery mode, and enter a graphical session from there.

lacatusp gravatar imagelacatusp ( 2015-03-19 19:19:47 -0500 )edit

Curious: whats turbo mode?

abadrinath gravatar imageabadrinath ( 2015-04-03 01:07:32 -0500 )edit

@hello the newer generation of Intel i5 and i7 basically have an "auto-overclock feature". For example, mine is clocked at 3.5GHz and overclocks to 3.9 GHz when needed.

fat-lobyte gravatar imagefat-lobyte ( 2015-04-03 18:38:35 -0500 )edit

answered 2015-03-31 20:47:07 -0500

Disable akmods service

systemctl disable akmods.service
  • Uninstalll akmod-nvidia
  • Uninstall the installed kmod-nvidia package
  • Install kmod-nvidia from the upstream repo for the 3.18xxx package
  • Reboot
edit flag offensive delete link more

answered 2015-03-11 08:45:03 -0500

dejan gravatar image

I've recently asked a question that I believe is related to this: . Something is terribly wrong with latest Fedora 21 packages. Could be kernel, could be some drivers (I have nVidia too), etc... Weird thing is that I can't make my Fedora 21 box start the graphical target (in English it does not start XWindow System) straight away. Instead I had to make it start the multi-user target, and from there I start X11. This is the only way I could make graphical environment work.

edit flag offensive delete link more

answered 2015-03-30 15:39:45 -0500


Does anybody solve this issue ? I have the same problem on multiple machines. Each of them has: SSD, UEFI, Fedora 21 on Btrfs, Kernel 3.19.2 (and since around 18.x). Two are AMD (both classic: FX-8350 and APU: A10-5800K), and one is Intel (i7 Broadwell on 2015 Lenovo X1 Carbon).

Sometimes boot hangs on "Mounting /sysroot", sometimes around populating /dev... Seems random, after a kernel upgrade, the first boot seems good, but after that, it's random.

I ca't get a "good" failing journalctl, cause wrong boot doesn't (seems to) log anything.

Any clue/things I can provide to help ?

edit flag offensive delete link more



Hi, "answers" are for potential solutions. Please upvote the original question and put your (very valuable!) information there. Other than that: that's good info. I also have a btrfs file system, SSD and UEFI. I have a different graphics card. It should have to do something with SSD or UEFI boot.

fat-lobyte gravatar imagefat-lobyte ( 2015-03-31 10:23:43 -0500 )edit

Hi, ok, thanks for the advice ;-)

So, it's not a solution, but I found something which may help (or not):
- I try to boot normally, doesn't work, retry few more times, always not
- I boot in recovery, everything's ok
- In recovery, I do: "sudo dnf reinstall kernel", confirm, when done, reboot
- boot in normal mode, OK

Every time I did this when it didn't boot, the absolute next time, it always booted correctly.

Could someone try this when normal boot doesn't work ? Does it help someone to understand this a bit more ?

thequestion gravatar imagethequestion ( 2015-04-01 15:02:41 -0500 )edit

answered 2015-04-10 14:27:46 -0500

It looks like everyone here has a BTRFS root partition, maybe you're affected by the deadlock bug mentionned here :

I know I was as I had problems booting my NAS after I updated my packages this evening, problems that were solved by reverting to kernel 3.18.8.

So my proposed solution is to revert back to a kernel < 3.18.9

PS : and I don't have an Nvidia card in this NAS.

edit flag offensive delete link more

Question Tools



Asked: 2015-03-10 03:00:07 -0500

Seen: 4,059 times

Last updated: May 30 '15