Hi folks.
Strange things happen with my ext4 lately:
- At each boot, the file system is checked.
- When I launch fsck manually it didn't found any issue.
- But tune2fs report that last checked and mount time is Sun Dec 15,
but this is incorrect.
I don’t know where to look further so I ask here for help.
Here is tune2fs report: https://pastebin.com/PZPbAuHS
# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Mon Sep 9 19:36:53 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=b3e2e027-c39d-4266-871f-22d313ac419b / ext4
defaults 1 1
UUID=E8A2-F389 /boot/efi vfat
umask=0077,shortname=winnt 0 2
UUID=bf3e9504-8000-42a1-adb4-226658ec7a5d /home ext4
defaults 1 2
UUID=f47f69e1-61f8-4024-960a-b3981d3b1d02 none swap
defaults 0 0
--
Best Regards,
Mike Gavrilov.
Maybe important:
This start happens since I upgraded motherboard to "ROG Strix X570-I
Gaming" on my previous motherboard "ROG STRIX X470-I GAMING" the
values "last checked", "mount time", "mount count" was correctly
updated and displayed. And auto-check not started each boot.
On Wed, 1 Jan 2020 at 15:58, Mikhail Gavrilov
<[email protected]> wrote:
>
> Hi folks.
>
> Strange things happen with my ext4 lately:
> - At each boot, the file system is checked.
> - When I launch fsck manually it didn't found any issue.
> - But tune2fs report that last checked and mount time is Sun Dec 15,
> but this is incorrect.
>
> I don’t know where to look further so I ask here for help.
>
>
> Here is tune2fs report: https://pastebin.com/PZPbAuHS
>
> # cat /etc/fstab
>
> #
> # /etc/fstab
> # Created by anaconda on Mon Sep 9 19:36:53 2019
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk/'.
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
> #
> # After editing this file, run 'systemctl daemon-reload' to update systemd
> # units generated from this file.
> #
> UUID=b3e2e027-c39d-4266-871f-22d313ac419b / ext4
> defaults 1 1
> UUID=E8A2-F389 /boot/efi vfat
> umask=0077,shortname=winnt 0 2
> UUID=bf3e9504-8000-42a1-adb4-226658ec7a5d /home ext4
> defaults 1 2
> UUID=f47f69e1-61f8-4024-960a-b3981d3b1d02 none swap
> defaults 0 0
>
>
> --
> Best Regards,
> Mike Gavrilov.
On Wed, Jan 01, 2020 at 03:58:25PM +0500, Mikhail Gavrilov wrote:
> Hi folks.
>
> Strange things happen with my ext4 lately:
> - At each boot, the file system is checked.
> - When I launch fsck manually it didn't found any issue.
> - But tune2fs report that last checked and mount time is Sun Dec 15,
> but this is incorrect.
The problem is casued by the fact that the mount time is incorrect,
which indicates that the system time was incorrect at the time when
the file system was mounted and when it fsck was run. Since the last
write time was in the future, this triggered "time is insane" check.
This is inconsistent with your report that started happening when you
switched to a new motherboard. That's because the real time clock is
not reporting the correct time when the system is booted. Later on,
in the boot cycle, after the root file system is checked and remounted
read-write, the system time is getting set from an internet time
server. This then causes the last write time to be ahead of the last
mount time, and "in the future" with respect to the real time clock.
Normally, the hardware clock's time gets set to match system time when
it is set from network time, or when the system is getting shut down
cleanly, but your init scripts aren't doing this properly --- or you
normally shut down your system by just flipping the power switch, and
not letting the shutdown sequence run correctly. The other possibilty
is the real time clock on your system is just completly busted
(although normally when that happens, the last mount time would be in
the 1970's.)
Running "/sbin/hwclock -w" as root may fix things; as is figuring out
why this isn't run automatically by your boot scripts. Another
workaround is to add to /etc/e2fsck.conf the following:
[options]
broken_system_lock = true
This will disable e2fsck's time checks.
Cheers,
- Ted
On Wed, 1 Jan 2020 at 19:17, Theodore Y. Ts'o <[email protected]> wrote:
>
> The problem is casued by the fact that the mount time is incorrect,
> which indicates that the system time was incorrect at the time when
> the file system was mounted and when it fsck was run. Since the last
> write time was in the future, this triggered "time is insane" check.
>
> This is inconsistent with your report that started happening when you
> switched to a new motherboard. That's because the real time clock is
> not reporting the correct time when the system is booted. Later on,
> in the boot cycle, after the root file system is checked and remounted
> read-write, the system time is getting set from an internet time
> server. This then causes the last write time to be ahead of the last
> mount time, and "in the future" with respect to the real time clock.
>
> Normally, the hardware clock's time gets set to match system time when
> it is set from network time, or when the system is getting shut down
> cleanly, but your init scripts aren't doing this properly --- or you
> normally shut down your system by just flipping the power switch, and
> not letting the shutdown sequence run correctly. The other possibilty
> is the real time clock on your system is just completly busted
> (although normally when that happens, the last mount time would be in
> the 1970's.)
>
> Running "/sbin/hwclock -w" as root may fix things; as is figuring out
> why this isn't run automatically by your boot scripts. Another
> workaround is to add to /etc/e2fsck.conf the following:
>
> [options]
> broken_system_lock = true
>
> This will disable e2fsck's time checks.
>
Thank you very much for the tip, I would never have guessed that the
cause of this issue in hwclock.
I started to watch hwclock through the motherboard BIOS and found that
hwclock resets every time after booting Linux.
Demonstration: https://youtu.be/TBrLNFbBaPo
Apparently for this reason, "hwclock -w" did not help me, workaround
with "broken_system_clock = true" is working, but I would like to fix
the root of the cause.
Who can help with this?
--
Best Regards,
Mike Gavrilov.
"hwclock -w" reset time instead of setting the right time on M/B "ROG
Strix X570-I Gaming"
Demonstration: https://youtu.be/QRB7ZLiEfrc
Some DE like GNOME has automatic time synchronization option and there
is a feeling that hardware time reset after each Linux boot.
--
Best Regards,
Mike Gavrilov.
On Thu, 2 Jan 2020 at 04:19, Mikhail Gavrilov
<[email protected]> wrote:
>
> On Wed, 1 Jan 2020 at 19:17, Theodore Y. Ts'o <[email protected]> wrote:
> >
> > The problem is casued by the fact that the mount time is incorrect,
> > which indicates that the system time was incorrect at the time when
> > the file system was mounted and when it fsck was run. Since the last
> > write time was in the future, this triggered "time is insane" check.
> >
> > This is inconsistent with your report that started happening when you
> > switched to a new motherboard. That's because the real time clock is
> > not reporting the correct time when the system is booted. Later on,
> > in the boot cycle, after the root file system is checked and remounted
> > read-write, the system time is getting set from an internet time
> > server. This then causes the last write time to be ahead of the last
> > mount time, and "in the future" with respect to the real time clock.
> >
> > Normally, the hardware clock's time gets set to match system time when
> > it is set from network time, or when the system is getting shut down
> > cleanly, but your init scripts aren't doing this properly --- or you
> > normally shut down your system by just flipping the power switch, and
> > not letting the shutdown sequence run correctly. The other possibilty
> > is the real time clock on your system is just completly busted
> > (although normally when that happens, the last mount time would be in
> > the 1970's.)
> >
> > Running "/sbin/hwclock -w" as root may fix things; as is figuring out
> > why this isn't run automatically by your boot scripts. Another
> > workaround is to add to /etc/e2fsck.conf the following:
> >
> > [options]
> > broken_system_lock = true
> >
> > This will disable e2fsck's time checks.
> >
>
> Thank you very much for the tip, I would never have guessed that the
> cause of this issue in hwclock.
> I started to watch hwclock through the motherboard BIOS and found that
> hwclock resets every time after booting Linux.
> Demonstration: https://youtu.be/TBrLNFbBaPo
> Apparently for this reason, "hwclock -w" did not help me, workaround
> with "broken_system_clock = true" is working, but I would like to fix
> the root of the cause.
> Who can help with this?
>
On Thu, 2 Jan 2020 at 16:08, Karel Zak <[email protected]> wrote:
>
> Can you try "hwclock -w -v" to get more details?
>
> For example on my workstation:
>
> # ./hwclock -w -v
> hwclock from util-linux 2.35-rc1-20-63f8
> System Time: 1577963091.683987
> Trying to open: /dev/rtc0
> Using the rtc interface to the clock.
> Last drift adjustment done at 1531914946 seconds after 1969
> Last calibration done at 1531914946 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> RTC type: 'rtc_cmos'
> Using delay: 0.500000 seconds
> missed it - 1577963091.684767 is too far past 1577963091.500000 (0.184767 > 0.001000)
> 1577963092.500000 is close enough to 1577963092.500000 (0.000000 < 0.002000)
> Set RTC to 1577963092 (1577963091 + 1; refsystime = 1577963091.000000)
> Setting Hardware Clock to 11:04:52 = 1577963092 seconds since 1969
> ioctl(RTC_SET_TIME) was successful.
> Not adjusting drift factor because the --update-drift option was not used.
> New /etc/adjtime data:
> 0.000000 1577963091 0.000000
> 1577963091
> UTC
>
# hwclock -w -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1577964536.796672
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1577950892 seconds after 1969
Last calibration done at 1577950892 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
RTC type: 'rtc_cmos'
Using delay: 0.500000 seconds
missed it - 1577964536.797135 is too far past 1577964536.500000
(0.297135 > 0.001000)
1577964537.500000 is close enough to 1577964537.500000 (0.000000 < 0.002000)
Set RTC to 1577964537 (1577964536 + 1; refsystime = 1577964536.000000)
Setting Hardware Clock to 11:28:57 = 1577964537 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because the --update-drift option was not used.
New /etc/adjtime data:
0.000000 1577964536 0.000000
1577964536
UTC
Demonstration: https://youtu.be/Yx27IH2opEc
--
Best Regards,
Mike Gavrilov.