File System Check job failing during boot into freshly updated kernel

Miblo · 2016-11-27 04:12:06

I recently upgraded my /var and /home HDD (btrfs formatted) to an SSD (f2fs formatted), to go along with /boot and / on their SSD, and started to experience a problem with File System Check failing to complete for /var and /home during the boot immediately after upgrading the kernel. If I interrupt this boot with Ctrl-Alt-Del, the next boot (with File System Checks) completes correctly. This only happens after booting into a different kernel (i.e. upgraded or a different variant, e.g. linux vs linux-ck-haswell) from the previous boot. Reinstalling the same kernel doesn't yield the failure upon rebooting into that.

Before the hardware upgrade, all was fine. The only differences are the new hardware and filesystem – new f2fs SSD vs old btrfs HDD. And the difference between a successful and a failed boot is captured in this photo of a failing boot. Here there is a delay presumably due to the change in FSCK version, after which delay the boot stalls trying to start File System Check jobs on /var and /home. In a successful boot there is no delay and the File System Check jobs start without an issue.

I suppose what I'd like to understand is, what is happening during the delay at http://imgur.com/zi4FRzV after that FSCK version change, and could I make later operations (i.e. the File System Check job) wait until this stuff has completed? Essentially, if I could either make whatever is happening during that delay take the same amount of time as whatever happens at the same point during a successful boot, or make dependent operations wait until the completion of whatever is happening during the delay, my problem should be solved, right?

For reference, here's my /etc/fstab:

# 
# /etc/fstab: static file system information
#
# <file system>                                 <dir>           <type>          <options>                                       <dump>  <pass>
# /dev/sda2 LABEL=rootfs
UUID=5521cf5a-fd54-42a0-bf98-6820df1fca0b       /               f2fs            rw,relatime,background_gc=on,active_logs=6      0 1

# /dev/sda1 LABEL=boot
UUID=FD55-2211                                  /boot           vfat            rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro    0 2

# /dev/sdb1 LABEL=var
UUID=811ac8cc-5840-4e6a-865e-ff66f16c6528       /var            f2fs            rw,relatime,background_gc=on,active_logs=6      0 2

# /dev/sdb2 LABEL=home
UUID=1d2b9f25-9fa0-4f46-bc74-a371e4c0dded       /home           f2fs            rw,relatime,background_gc=on,active_logs=6      0 2

mmozeiko · 2016-11-27 07:14:28

I tell that this photo is very normal situation with f2fs. F2fs performs fsck on next boot if you use f2fs on / and kernel version/name changes. This is expected behavior. The info in image doesn't mean that boot fails. Here's the code that performs comparison between active kernel version and kernel version that was used in last f2fs mount: http://git.kernel.org/cgit/linux/kernel … unt.c#n434

The real issue is failing fsck on /var and /home, and I'm not sure why that is happening...

Last edited by mmozeiko (2016-11-27 07:14:56)

Miblo · 2016-11-27 07:47:25

Awesome, cheers again for all your help, Mārtiņš! So the workaround for now, in case someone else hits this, is to add fsck.mode=skip to the kernel options ("/boot/loader/entries/arch-ck.conf" in my case).

Arch Linux

#1 2016-11-27 04:12:06

File System Check job failing during boot into freshly updated kernel

#2 2016-11-27 07:14:28

Re: File System Check job failing during boot into freshly updated kernel

#3 2016-11-27 07:47:25

Re: File System Check job failing during boot into freshly updated kernel

Board footer