PDA

View Full Version : [SOLVED] systemd-fsck superblock last write time on each boot


lmcogs
15th April 2011, 11:36 PM
For the last week I am getting the following message on every boot

Failed to load SELinux policy.
%Gsystemd-fsck[373]: _Fedora-15-Alpha: Superblock last write time is in the future.
systemd-fsck[373]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
systemd-fsck[373]: _Fedora-15-Alpha: clean, 248060/14262272 files, 3298885/57020160 blocks
systemd-fsck[593]: /dev/sda1: Superblock last write time is in the future.
systemd-fsck[593]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
systemd-fsck[593]: /dev/sda1: clean, 13215/61054976 files, 183595144/244189752 blocks
systemd-fsck[686]: /home: Superblock last write time is in the future.
systemd-fsck[686]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
systemd-fsck[686]: /home: clean, 134457/28114944 files, 62700563/112428544 blocks (check in 3 mounts)
systemd-fsck[685]: /dev/sdb1: Superblock last write time is in the future.
systemd-fsck[685]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
systemd-fsck[685]: /dev/sdb1: clean, 135/1001712 files, 168613/4002185 blocks

After this I get no more on screen prompts until kde loads after 5 minutes or longer. I also have selinux=0 in grub.

Can't find any answers

DBelton
15th April 2011, 11:42 PM
do you dual boot with Windows, by chance?

If you have Fedora set where the system clock uses UTC, that causes problems if you boot windows too. Windows doesn't correctly handle the UTC time and will change your system clock to local time. Depending on where you are in the world, your time could be off by u to 24 hours.

jpollard
15th April 2011, 11:45 PM
Use "dumpe2fs -h /dev/<parition>" that it is complaining about and see what date is recorded as the last write time.

My guess is that you changed your clock from the BIOS and have something off. If the "future time" is less than a day or so, the problem should go away. If it is in the distant future then it needs to be fixed.

Dismounting the filesystem and doing a fsck on it should fix it. But if there is a conflict between your BIOS clock (such as BIOS has your date in local time, but Linux thinks it is UTM) then such things can repeat.

Especially if you use ntpdate to set your clock.

dd_wizard
16th April 2011, 12:46 AM
@DBelton: I've been using UTC on my dual boot laptop ever since I made this post (http://forums.fedoraforum.org/showpost.php?p=1441074&postcount=9). It works fine with F14 or F15 and Windows Vista.

dd_wizard

DBelton
16th April 2011, 01:01 AM
yes, dd_wizard.. using UTC does work fine if you make the registry edits on Windows, but most people don't do that. (even works fairly well on XP even though it's not supposed to)

For the most part, they have Windows set where it thinks the clock is local time, and dual boot linux and have it set so it thinks it's using UTC. Then if they both adjust the time, it gets things all wacked up.

lmcogs
16th April 2011, 11:27 AM
Thanks for replies but its a little over my head. I have seen something about this while browsing. Changed clock to localtime removing UTC but that did not seem to do anything. Everything was going well up to about week ago, boot time really great.

I have windows xp installed dual boot but rarely use it, can't remember last time.

Here's jpollard suggestion but i don't know what it means
sudo dumpe2fs -h /dev/sda1
[sudo] password for leonc15:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name: <none>
Last mounted on: /disk
Filesystem UUID: 27c1e824-fa2f-415e-8635-aad96ede5276
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61054976
Block count: 244189752
Reserved block count: 12209487
Free blocks: 60594608
Free inodes: 61041761
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Thu Aug 12 22:35:50 2010
Last mount time: Sat Apr 16 00:20:45 2011
Last write time: Sat Apr 16 00:20:45 2011
Mount count: 5
Maximum mount count: 22
Last checked: Thu Apr 14 07:02:32 2011
Check interval: 15552000 (6 months)
Next check after: Tue Oct 11 07:02:32 2011
Lifetime writes: 1838 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: ed0bbeca-ccd2-455a-9e0c-cea2a1e9a8cd
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00005607
Journal start: 0

[leonc15@localhost ~]$ sudo dumpe2fs -h /dev/sdb1
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: e698a301-56d7-47a6-89a1-094a5361d03b
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1001712
Block count: 4002185
Reserved block count: 200109
Free blocks: 3833572
Free inodes: 1001577
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 977
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8144
Inode blocks per group: 509
Filesystem created: Sat Nov 21 10:13:31 2009
Last mount time: Sat Apr 16 00:20:45 2011
Last write time: Sat Apr 16 00:20:45 2011
Mount count: 909
Maximum mount count: -1
Last checked: Sat Nov 21 10:13:31 2009
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: edcd43e1-9704-4153-8818-0d86f2b03268
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00000816
Journal start: 0

[leonc15@localhost ~]$ sudo dumpe2fs -h /dev/sdb2
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name: /home
Last mounted on: /home
Filesystem UUID: 17e013ab-a950-4398-87a0-c6aec790939e
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 28114944
Block count: 112428544
Reserved block count: 5621427
Free blocks: 49729634
Free inodes: 27980485
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 997
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Mon Feb 28 14:58:22 2011
Last mount time: Sat Apr 16 00:20:45 2011
Last write time: Sat Apr 16 00:20:45 2011
Mount count: 20
Maximum mount count: 20
Last checked: Fri Apr 8 23:46:46 2011
Check interval: 15552000 (6 months)
Next check after: Wed Oct 5 23:46:46 2011
Lifetime writes: 486 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: d7399870-2993-4353-9fc8-312a90b4b555
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0004d534
Journal start: 1

[leonc15@localhost ~]$ sudo dumpe2fs -h /dev/sdb5
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: afe7ccce-c391-464a-9217-1296cb7ac4da
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 7405568
Block count: 29611803
Reserved block count: 1480590
Free blocks: 27267897
Free inodes: 7212868
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1016
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Mar 2 22:49:48 2011
Last mount time: Tue Apr 5 11:11:53 2011
Last write time: Thu Mar 31 23:17:03 2011
Mount count: 36
Maximum mount count: -1
Last checked: Wed Mar 2 22:49:48 2011
Check interval: 0 (<none>)
Lifetime writes: 37 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: b0a45322-ebaf-4eca-907d-4c8de6b508dc
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00009365
Journal start: 0


/dev/sdb3 is windows.[COLOR="Silver"]

---------- Post added at 02:27 AM ---------- Previous post was at 02:26 AM ----------

I'm on GMT. If there was a semi solved option I would use that but I am not sure if the problem has gone entirely.
I went into Bios and the time was off by 4 hours, changed this and changed the time when booted by su system-config-date. Rebooted and the 'superblock last write time in future' was not there, so I presume this fixed this. However when I reboot the time increased by an hour. Not sure if this happens everytime so I will reboot and see next time. Also when I went into bios again the system time went back approx an hour, does not seem to save the change.

Another strange recent occurance and it may be related to systemd is that having shutdown the system seems to go into a hibernation/seep mode because it reboots itself after an hour or so. Strange! Just notice above where it says 'Post Added 2:27 am etc that is wrong it is now 11.30 am and I was fast asleep at that time

DBelton
16th April 2011, 02:13 PM
just to fill you in on how it tries to work.

If you have the "system time uses UTC" option checked:

Your time in the BIOS is set to GMT and your OS (Fedora) does the conversion to local time dependent upon what time zone location that you have set (It gets that from the location you specify in your clock settings). The time that you see when you have Fedora booted will be different from the time it shows in your BIOS settings. (Unless you are in the GMT time zone anyway, then your time zone offset is zero)

If you don't have "system time uses UTC" option checked:

Then your BIOS time is local time and your OS shows the same time as your BIOS time.

One thing that you mentioned above. You mentioned that your clock was correct, but is off after you reboot. Double check the location you have specified in your clock settings, and also, if it's changing when it goes into hibernation/sleep mode it's possible that the battery on your motherboard is getting weak. (The battery that saves your CMOS and clock information) Clock changes when powered off can be one of the first indicators you have that the battery is going bad.

lmcogs
16th April 2011, 04:55 PM
Thanks DBelton that was very clear explanation. I now have time uses UTC ticked and my time is London. Rebooted and the bios is 1 hr earlier which I think is GMT correct. Booted fine this time and Fedora clock is correct.

The booting time was slow also because of a route command (addon) in /etc/ip-up.local after setting up an init.d script to load vpn at boot. When I removed #route add -net ${NET} dev ${IFACE} and added
'route add default dev ppp0' system booted without delay. (I hope)

DBelton
17th April 2011, 04:14 AM
Are you currently using GMT or BST (British Summer Time) There is 1 hour of difference currently.

If you have it set to London as your location, then your system is using BST, and changing your local time to 1 hour from UTC (GMT).

lmcogs
17th April 2011, 08:34 AM
Yes I see. Date/Time Properties in 'system-config-date the current time set to BST and Timezone to London and UTC ticked.

DBelton
17th April 2011, 01:17 PM
Fedora should automatically adjust your local time to account for that #%$#^$@#%@#% (crappy and useless) daylight savings time, depending on the location you specify.

About the only time I even think about that daylight savings time is the very little that is done on my computers. For the rest, I just ignore the time and set my clock by the sun and moon anyway :D

Pubal Photos on Instagram - Kimje Instagram Photos - Fraccionamiento Ciudad Olmeca Photos on Instagram