fsck on the next reboot in R77.30

[cciesec2006]

My R77.30 GAIA has been up for 710 days. I think if I reboot this firewall, it will take about 20 minutes for fsck to complete.

How do I determine if fsck will be performed on the next reboot on this firewall? What to look for and how to bypass it?

[Expert@nasa-lunar:0]# uptime
20:05:34 up 710 days, 16:03, 1 user, load average: 0.24, 0.22, 0.18
[Expert@nasa-lunar:0]#

TIA

[Jejerod]

How do I determine if fsck will be performed on the next reboot on this firewall? What to look for and how to bypass it?

I'd guess tune2fs should help out here. There are two values that can trigger a fsck on boot, number of mounts and time passed without a check. To look those up:

[Expert@cpmodule:0]# tune2fs -l /dev/mapper/vg_splat-lv_current | egrep -i 'check|mount'
Last mounted on:          <not available>
Default mount options:    (none)
Last mount time:          Wed Feb 20 11:26:08 2019
Mount count:              5
Maximum mount count:      27
Last checked:             Mon Nov 12 14:22:31 2018
Check interval:           15552000 (6 months)
Next check after:         Sat May 11 15:22:31 2019

Check mount count vs maximum mount count and next check after. It is possible to change the count and last check values using

tune2fs -C n

or

tune2fs -T now

respectively.

Note: I never did that in production, you should test this first on a virtual lab device or something.

[cciesec2006]

I'd guess tune2fs should help out here. There are two values that can trigger a fsck on boot, number of mounts and time passed without a check. To look those up:

[Expert@cpmodule:0]# tune2fs -l /dev/mapper/vg_splat-lv_current | egrep -i 'check|mount'
Last mounted on:          <not available>
Default mount options:    (none)
Last mount time:          Wed Feb 20 11:26:08 2019
Mount count:              5
Maximum mount count:      27
Last checked:             Mon Nov 12 14:22:31 2018
Check interval:           15552000 (6 months)
Next check after:         Sat May 11 15:22:31 2019

Check mount count vs maximum mount count and next check after. It is possible to change the count and last check values using

tune2fs -C n

or

tune2fs -T now

respectively.

Note: I never did that in production, you should test this first on a virtual lab device or something.

This is what I am seeing on my R77.30 GAIA Provider-1:

[Expert@lab-p1-mc:0]# tune2fs -l /dev/mapper/vg_splat-lv_current | egrep -i 'check|mount'
Last mounted on: <not available>
Default mount options: user_xattr acl
Last mount time: Tue Jul 17 13:25:36 2018
Mount count: 14
Maximum mount count: -1
Last checked: Tue Jan 31 13:30:07 2017
Check interval: 0 (<none>)
[Expert@lab-p1-mc:0]#

lab-p1-mc> fwm mds ver
This is Check Point Multi-Domain Security Management R77.30 - Build 004
lab-p1-mc> exit
[Expert@lab-p1-mc:0]# installed_jumbo_take
R77.30 Jumbo Hotfix Accumulator take_216 is installed, see sk106162.
[Expert@lab-p1-mc:0]#

[Bob_Zimmerman]

Based on that output, it shouldn't fsck on boot unless the box was not shut down cleanly.

Side-note: ensuring filesystem consistency on unclean shutdown is a problem which has been solved for over twenty years. I don't get how it's taking so long for companies to use the solutions which already exist. ext3 even supports full journaling, but Check Point appears to be running it in ordered data mode.

[Jejerod]

Yes, the output looks like there's no fsck based on time or mount count (R80 management has also count -1 and interval 0 as far as I've checked; at least R80.20/30 with Kernel 3.10).

/Edit: to be really really sure also check /dev/mapper/vg_splat-lv_log

[cciesec2006]

Yes, the output looks like there's no fsck based on time or mount count (R80 management has also count -1 and interval 0 as far as I've checked; at least R80.20/30 with Kernel 3.10).

/Edit: to be really really sure also check /dev/mapper/vg_splat-lv_log

All of my systems were shutdown "properly" using "/sbin/halt".

I have another system that was up for 371 days and when I reboot it yesterday, it took 30 minutes for the fsck to run:

Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/mapper/vg_splat-lv_current
/dev/mapper/vg_splat-lv_current has gone 371 days without being checked, check forced.

question is how do I avoid this prior to a reboot?