Geek Blight

Update

Both bugs mentioned below were closed while the issue is still present. Fortunately, there is one specific bug where this problem is being worked on: bug 1202024. I’ll keep the /etc/adjtime workaround active until that one is fixed, but it’s probably just a matter of time, as an upstream patch from Ted Tso in e2fsck has been committed and a future e2fsprogs update will probably fix the issue. The definitive solution seems to be to make e2fsprogs fix the superblock last write time without causing a full filesystem check. fsck will continue to be run twice for the root filesystem in the boot process, but that second issue will probably be handled in bug 1201979.

End of update

I hit a small Fedora bug two months ago and I wanted to post about it just in case it’s useful for somebody else. Basically, an e2fsprogs update from March 5th, 2015 made the system take much longer to boot if you’re East of GMT and keep your system clock in local time. Running systemd-analyze critical-chain should reveal the problem is systemd-fsck-root.service.

I asked about the problem in the unofficial Fedora forums and the thread is easily reachable with a web search. Reading my comments in that thread reveals the whole story. It also mentions two related bug reports in the Fedora bug tracker: bug number 1198761 and number 1201978, which I also commented on.

Long story short, Fedora will set the system clock to use local time if it detects a Windows installation in the computer, as was my case, at installation time. After the update from March 5th, fsck running from the initial RAM disk will be unaware of this and think the clock is set to UTC, adding your timezone offset to the superblock last write time to an already-local time the first time it’s run. The fact that fsck runs at this point could be the real problem and, as far as I know, is still being investigated. Later, when fsck runs a second time during the boot process to check the root filesystem, it’s aware the system clock contains the local time and then it finds the superblock write time to be in the future. Then it will spend a lot of time checking the filesystem and fixing that problem to make sure everything is alright.

The real problem is probably a combination of fsck apparently running twice and too early, and suboptimal behavior of e2fsck when fixing the superblock last write time problem. My solution leaves those issues to the Fedora people and goes for a simple workaround as I mentioned in both a bug comment and the forums thread: just include /etc/adjtime in the initial RAM disk and the lengthy filesystem check will not take place anymore.

As root, lsinitrd will allow you to check if /etc/adjtime is already included in it. If it’s not and you’re suffering this problem, create the file /etc/dracut.conf.d/adjtime.conf (the base name is up to the user) and put the following line in it:

This will make dracut (the initial RAM disk management tool in Fedora and other distributions) include the file in all future initial RAM disks, which will be generated automatically for future kernel upgrades. You probably want to fix your current initial RAM disk too. For that, simply run dracut -f and reboot.