[opensuse-factory] DST end switchover caused all previously mounted partitions to need fsck

older
[opensuse-factory] Zypper package...

Felix Miata

5 Nov 2017 5 Nov '17

08:49

Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM. Local time reverted to 1AM at 2AM before I proceeded with a Grub selection. Selected 42.3 in Grub and proceeded to boot. Logged in only after more than an hour passed, after 3AM local standard time. Checked to see time correct. Rebooted to get an extra SATA HD online on the main ICH8 bus. During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-( -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Richard Brown

5 Nov 5 Nov

09:17

On 5 November 2017 at 09:49, Felix Miata wrote:

...

Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

Selected 42.3 in Grub and proceeded to boot.

Logged in only after more than an hour passed, after 3AM local standard time.

Checked to see time correct.

Rebooted to get an extra SATA HD online on the main ICH8 bus.

During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

This does not seem to be a post intended to start a discussion. There seems to be nothing to discuss. There is not a single question mark in this whole post, so I assume you have no questions and are not requesting further information. If what you say here happened then what you write here should be in a bug report, not in a mailinglist post. Thank you -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

10:18

Richard Brown composed on 2017-11-05 10:17 (UTC+0100):

...

Felix Miata wrote:

...

...
Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

...

...
Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

...

...
Selected 42.3 in Grub and proceeded to boot.

...

...
Logged in only after more than an hour passed, after 3AM local standard time.

...

...
Checked to see time correct.

...

...
Rebooted to get an extra SATA HD online on the main ICH8 bus.

...

...
During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

...

This does not seem to be a post intended to start a discussion. There seems to be nothing to discuss.

So, you apparently see nothing wrong. What about others? I don't see expected behavior in the enumerated sequence of events. Any time I see disk checks on a boot following an apparently uneventful shutdown I see abnormal behavior.

...

There is not a single question mark in this whole post, so I assume you have no questions and are not requesting further information.

The question here is implicit in the peculiar sequence of events. Question mark(s) shouldn't be necessary.

...

If what you say here happened then what you write here should be in a bug report, not in a mailinglist post.

Bug reports should state a reasonable reproduction scenario, providing reasonable suspicion that a behavior that constitutes a bug exists. I have my doubts one could call a two hour period at one specific time of year reasonably reproducible. Only if others had observed similar behavior, and followed up here, might I expect a consensus to be reached, a result of discussion, that a behavior exists such as to expect anybody to act on a bug report. At this point I'd expect a fresh bug report about this to be one which would languish for many years with little or no activity. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

13:52

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-11-05 at 05:18 -0500, Felix Miata wrote:

...

Richard Brown composed on 2017-11-05 10:17 (UTC+0100):

...
Felix Miata wrote:

...
...
Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

...
...
Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

...
...
Selected 42.3 in Grub and proceeded to boot.

...
...
Logged in only after more than an hour passed, after 3AM local standard time.

...
...
Checked to see time correct.

...
...
Rebooted to get an extra SATA HD online on the main ICH8 bus.

...
...
During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

...
This does not seem to be a post intended to start a discussion. There seems to be nothing to discuss.

So, you apparently see nothing wrong. What about others? I don't see expected behavior in the enumerated sequence of events. Any time I see disk checks on a boot following an apparently uneventful shutdown I see abnormal behavior.

...
There is not a single question mark in this whole post, so I assume you have no questions and are not requesting further information.

The question here is implicit in the peculiar sequence of events. Question mark(s) shouldn't be necessary.

...
If what you say here happened then what you write here should be in a bug report, not in a mailinglist post.

Bug reports should state a reasonable reproduction scenario, providing reasonable suspicion that a behavior that constitutes a bug exists. I have my doubts one could call a two hour period at one specific time of year reasonably reproducible. Only if others had observed similar behavior, and followed up here, might I expect a consensus to be reached, a result of discussion, that a behavior exists such as to expect anybody to act on a bug report. At this point I'd expect a fresh bug report about this to be one which would languish for many years with little or no activity.

Agreed. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAln/F7AACgkQtTMYHG2NR9VSEgCaAv1+svSuXngqPlBhySNDi8pG mrQAnRgVLetWKWnJKmGV31uYpSNgYHX3 =WnYl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

martin＠pluskal.org

6 Nov 6 Nov

08:06

On Sun, 2017-11-05 at 05:18 -0500, Felix Miata wrote:

...

Richard Brown composed on 2017-11-05 10:17 (UTC+0100):

...
Felix Miata wrote:

...
Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM. Local time reverted to 1AM at 2AM before I proceeded with a Grub selection. Selected 42.3 in Grub and proceeded to boot. Logged in only after more than an hour passed, after 3AM local standard time. Checked to see time correct. Rebooted to get an extra SATA HD online on the main ICH8 bus. During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-( This does not seem to be a post intended to start a discussion. There seems to be nothing to discuss.

So, you apparently see nothing wrong. What about others? I don't see expected behavior in the enumerated sequence of events. Any time I see disk checks on a boot following an apparently uneventful shutdown I see abnormal behavior.

...
There is not a single question mark in this whole post, so I assume you have no questions and are not requesting further information.

The question here is implicit in the peculiar sequence of events. Question mark(s) shouldn't be necessary.

...
If what you say here happened then what you write here should be in a bug report, not in a mailinglist post.

Bug reports should state a reasonable reproduction scenario, providing reasonable suspicion that a behavior that constitutes a bug exists. I have my doubts one could call a two hour period at one specific time of year reasonably reproducible. Only if others had observed similar behavior, and followed up here, might I expect a consensus to be reached, a result of discussion, that a behavior exists such as to expect anybody to act on a bug report. At this point I'd expect a fresh bug report about this to be one which would languish for many years with little or no activity. Hi

May I ask what is your expectation from sending such post then? Also note that openSUSE-Factory is not platform for user support but instead for discussions about development of openSUSE:Factory/Tumbleweed/Leap. Cheers Martin

Felix Miata

08:29

martin@pluskal.org composed on 2017-11-06 09:06 (UTC+0100):

...

May I ask what is your expectation from sending such post then? Also note that openSUSE-Factory is not platform for user support but instead for discussions about development of openSUSE:Factory/Tumbleweed/Leap.

Better here for trying to generate consensus via group discussion whether a bug exists than in a bug report. As someone who used to do bug triage a lot more than any more, generating such consensus I would not classify as "support". You sound like Richard's micromanaging, looking for things to complain about, which is unfriendly, behavior tending to dissuade potential new users and devs from ever trying openSUSE if seeing stuff like this Googling. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

martin＠pluskal.org

09:44

On Mon, 2017-11-06 at 03:29 -0500, Felix Miata wrote:

...

You sound like Richard's micromanaging, looking for things to complain about, which is unfriendly, behavior tending to dissuade potential new users and devs from ever trying openSUSE if seeing stuff like this Googling. While I am not sure what you claim that Richard is micromanaging or what is relation of such micromanagement to me, I also see that you are jumping to some interesting conslusions here.

Anyways what I see as problem with message such as you sent: * Rather obscure issue is being described (non default installation scenario, presumably multi boot machine, changes in hardware configuration seem to be necessary to trigger such situation) * Described issue is of limited impact (delay in login, which will occasionally happen anyways when one is using ext* filesystems) * Unrelevant details (~8 year old Dell) * Your expectation of discussion prior to reporting bug is incorrect, by posting to ml you involve way more people than by reporting issue in bugzilla, you involve people against their will (note that this mailing list have thousands of subscribers, who will at least read title of your message before ignoring it). * I understand when newbies send such messages, but you are definitely not a newbie, thus my expectation of you are somewhere else - especially as this is not first time you are getting such feedback. Regards Martin

Karl Cheng

11:57

On 6 November 2017 at 20:44, wrote:

...

Anyways what I see as problem with message such as you sent: * Rather obscure issue is being described (non default installation scenario, presumably multi boot machine, changes in hardware configuration seem to be necessary to trigger such situation)

I don't see how this install is particularly non-representative of the typical openSUSE user, nor anything that implies that the user has set a very obscure hardware configuration.

...

* Described issue is of limited impact (delay in login, which will occasionally happen anyways when one is using ext* filesystems)

I would say being unable to use your computer for such a length of time is not of limited impact, especially if there is something important to be done at that time.

...

* Unrelevant details (~8 year old Dell) * Your expectation of discussion prior to reporting bug is incorrect, by posting to ml you involve way more people than by reporting issue in bugzilla, you involve people against their will (note that this mailing list have thousands of subscribers, who will at least read title of your message before ignoring it).

Searching for relevant issues in Bugzilla can be quite hard. This type of thing sounds like something that another person would have experienced if this is an issue with DST handling, so it would be useful to check whether someone else has experienced the problem before. Opening a bug report usually only involves those triaging for bugs, for whom it can be difficult to reproduce these problems immediately.

...

* I understand when newbies send such messages, but you are definitely not a newbie, thus my expectation of you are somewhere else - especially as this is not first time you are getting such feedback.

-- - Karl Cheng (Qantas94Heavy) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Simon Lees

7 Nov 7 Nov

03:05

On 06/11/17 22:27, Karl Cheng wrote:

...

On 6 November 2017 at 20:44, wrote:

...
Anyways what I see as problem with message such as you sent: * Rather obscure issue is being described (non default installation scenario, presumably multi boot machine, changes in hardware configuration seem to be necessary to trigger such situation)

I don't see how this install is particularly non-representative of the typical openSUSE user, nor anything that implies that the user has set a very obscure hardware configuration.

...
* Described issue is of limited impact (delay in login, which will occasionally happen anyways when one is using ext* filesystems)

I would say being unable to use your computer for such a length of time is not of limited impact, especially if there is something important to be done at that time.

...
* Unrelevant details (~8 year old Dell) * Your expectation of discussion prior to reporting bug is incorrect, by posting to ml you involve way more people than by reporting issue in bugzilla, you involve people against their will (note that this mailing list have thousands of subscribers, who will at least read title of your message before ignoring it).

Searching for relevant issues in Bugzilla can be quite hard.

Yes but if you accidentally make a duplicate its easy for us to merge them.

...

This type of thing sounds like something that another person would have experienced if this is an issue with DST handling, so it would be useful to check whether someone else has experienced the problem before.

Yes but this mailing list is for discussing the development of openSUSE not for checking has anyone ever experienced this random issue, maybe with the narrow exception of issues that may have been introduced in the last tumbleweed snapshot and that are likely to effect a large number of people. Bugzilla, google and the forums are much better places to check if anyone has ever experienced this issue, if your searching doesn't find anything and it sounds like a bug file a bug report then the right people (who may not even be on this list) can help you sort it out. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

martin＠pluskal.org

12:58

On Tue, 2017-11-07 at 13:35 +1030, Simon Lees wrote:

...

Bugzilla, google and the forums are much better places to check if anyone has ever experienced this issue, if your searching doesn't find anything and it sounds like a bug file a bug report then the right people (who may not even be on this list) can help you sort it out.

Hi That is very good point - lots of maintainers are not subscribed to this ml, so they will anyways not notice issue even thought they could easily resolve it. And even if subscribed, nothing guarantees that maintainer will allways notice such reports. Cheers M

Bernhard Voelker

5 Nov 5 Nov

11:12

On 11/05/2017 09:49 AM, Felix Miata wrote:

...

Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

Selected 42.3 in Grub and proceeded to boot.

Logged in only after more than an hour passed, after 3AM local standard time.

Checked to see time correct.

Rebooted to get an extra SATA HD online on the main ICH8 bus.

During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

I don't see a relation to a DST bug until now. Do you usually boot this PC only for DST switch checking? More important: what are the the tune2fs settings ... or better what was the output before the reboot? Maybe this was just a coincident with the 2nd reboot after the DST switch that the max number of mounts of the file systems has been reached. I admit it's probably impossible to tell now, but it would allow for a maintainer to replay the scenario. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

6 Nov 6 Nov

04:42

Bernhard Voelker composed on 2017-11-05 12:12 (UTC+0100):

...

Felix Miata wrote:

...

...
Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

...

...
Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

...

...
Selected 42.3 in Grub and proceeded to boot.

...

...
Logged in only after more than an hour passed, after 3AM local standard time.

...

...
Checked to see time correct.

...

...
Rebooted to get an extra SATA HD online on the main ICH8 bus.

...

...
During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

...

I don't see a relation to a DST bug until now. Do you usually boot this PC only for DST switch checking?

No, but I am a bit of an experimenter as opportunity presents, and was a bit bored waiting to update various clocks after the second 2AM. This multiboot (22 OS bootable on it) PC is one of my part timers, but has spent a lot of time up lately attributable to issues discussed here and on the [opensuse] list. On the 5655815 1K-block EXT4 / filesystem most booted to recently, mount count is 62, maximum mount count -1, and lifetime writes are 17 GB. Last checked is inexplicably reported as identical to its filesystem create time.

...

More important: what are the the tune2fs settings

I'm in the habit of following up mkfs.extN with 'tune2fs -c0 -i0', as most filesystems experiences a considerably above average power cycle to uptime ratio.

...

... or better what was the output before the reboot?

Output of what exactly?

...

Maybe this was just a coincident with the 2nd reboot after the DST switch that the max number of mounts of the file systems has been reached. I admit it's probably impossible to tell now, but it would allow for a maintainer to replay the scenario. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Neil Rickert

5 Nov 5 Nov

14:35

On 11/05/2017 02:49 AM, Felix Miata wrote:

...

During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

No problem here. But then I have my hardware clock set to UTC. My best guess is that your hardware clock was not updated before you rebooted, though the running system clock was updated. The effect was that your file systems all showed a file system time 1 hour in the future, and that caused the "fsck". To me, this seems like a reasonable safety check. As to why the hardware clock was not updated -- not sure, but I think it is only updated during startup, not during shutdown. Any Windows from Vista on, can use UTC for the system clock. Google for the registry changes needed. In my opinion, that's the best way to do things. I don't know about OS2, but I stopped using that long ago. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Oliver Neukum

6 Nov 6 Nov

08:25

Am Sonntag, den 05.11.2017, 03:49 -0500 schrieb Felix Miata:

...

Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

I guess we can assume that this issue does not depend on hardware.

...

Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

Which time zone? RTC running at local time or UTC?

...

Selected 42.3 in Grub and proceeded to boot.

Logged in only after more than an hour passed, after 3AM local standard time.

Firstly, bugzilla may be a better forum to file this bug, although I admit you hit a pretty unusual bug. Secondly, could you fiddle with your RTC to reproduce the issue? If we can test for this issue only once a year we have a problem.

...

Checked to see time correct.

Rebooted to get an extra SATA HD online on the main ICH8 bus.

So the issue occured only after the second reboot? The first one was normal?

...

During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

For something to be done on this bug report, it needs to be reproduced, entered into bugzilla and a manual run of fsck with full debugging output would help a lot. Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

7 Nov 7 Nov

02:29

Oliver Neukum composed on 2017-11-06 09:25 (UTC+0100): Thanks for your helpful reply!

...

Felix Miata composed:

...

...
Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

...

I guess we can assume that this issue does not depend on hardware.

...

...
Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

...

Which time zone? RTC running at local time or UTC?

Local, as all machines on LAN over which any choice is possible.

...

...
Selected 42.3 in Grub and proceeded to boot.

...

...
Logged in only after more than an hour passed, after 3AM local standard time.

...

Firstly, bugzilla may be a better forum to file this bug, although I admit you hit a pretty unusual bug.

If there even is a bug here.

...

Secondly, could you fiddle with your RTC to reproduce the issue? If we can test for this issue only once a year we have a problem.

I'm at a loss to imagine how to include any NTP server component, if it's relevant, which I would not expect given that most of the Internet and probably all public NTP servers run on UTC. OTOH, I'm having brainlock over when to boot vis a vis when to change the RTC and in which direction. Maybe this needs to wait until I can better concentrate, not too easy lately.

...

...
Checked to see time correct.

...

...
Rebooted to get an extra SATA HD online on the main ICH8 bus.

...

So the issue occured only after the second reboot? The first one was normal?

IIRC, yes.

...

...
During init, all (EXTx) partitions mounted on the previous boot required e2fsck, significantly delaying opportunity to login. :-(

...

For something to be done on this bug report, it needs to be reproduced, entered into bugzilla and a manual run of fsck with full debugging output would help a lot.

It's been a very long time since I've had debug rpms installed anywhere. Do I even have room? Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda15 5655815 3996463 1368498 75% / Which debug rpms would I need to have installed? -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Neil Rickert

03:02

On 11/06/2017 08:29 PM, Felix Miata wrote:

...

OTOH, I'm having brainlock over when to boot vis a vis when to change the RTC and in which direction. Maybe this needs to wait until I can better concentrate, not too easy lately.

Boot into your BIOS settings. Set the hardware clock back by 1 hour. Then boot into opensuse. See if it forces file checks. What you will be doing, is setting up your system so that the file system dates on boot will be 1 hour in the future. And that's very likely what happened before, as I noted in a reply yesterday. You could disconnect the network cables to avoid any NTP issues. But I don't think it actually matters. The system won't start NTP until after it has checked the file systems. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata

04:16

Neil Rickert composed on 2017-11-06 21:02 (UTC-0600): Thank you!

...

Felix Miata wrote:

...

...
OTOH, I'm having brainlock over when to boot vis a vis when to change the RTC and in which direction. Maybe this needs to wait until I can better concentrate, not too easy lately.

...

Boot into your BIOS settings. Set the hardware clock back by 1 hour. Then boot into opensuse. See if it forces file checks.

...

What you will be doing, is setting up your system so that the file system dates on boot will be 1 hour in the future. And that's very likely what happened before, as I noted in a reply yesterday.

Retarded clock and booted to 42.3/kernel 4.4.87-25, which took more than 2 minutes: # journalctl | grep rblock | grep "Nov 0" Nov 05 02:13:38 p5bse systemd-fsck[700]: h50usrlcl: Superblock last write time is in the future. Nov 05 02:13:43 p5bse systemd-fsck[697]: h50boot03: Superblock last write time is in the future. Nov 05 02:13:45 p5bse systemd-fsck[704]: os421h50: Superblock last write time is in the future. Nov 05 02:13:51 p5bse systemd-fsck[706]: os131h50: Superblock last write time is in the future. Nov 05 02:14:31 p5bse systemd-fsck[712]: h50home09: Superblock last write time is in the future. Nov 05 02:14:41 p5bse systemd-fsck[701]: h50pub11: Superblock last write time is in the future. Nov 06 21:22:07 p5bse systemd-fsck[339]: os423h50: Superblock last mount time is in the future. Nov 06 21:22:07 p5bse systemd-fsck[339]: os423h50: Superblock last write time is in the future. Nov 06 21:22:28 p5bse systemd-fsck[650]: h50home09: Superblock last mount time is in the future. Nov 06 21:22:28 p5bse systemd-fsck[650]: h50home09: Superblock last write time is in the future. Nov 06 21:22:39 p5bse systemd-fsck[646]: h50boot03: Superblock last mount time is in the future. Nov 06 21:22:39 p5bse systemd-fsck[646]: h50boot03: Superblock last write time is in the future. Nov 06 21:22:40 p5bse systemd-fsck[663]: h50usrlcl: Superblock last mount time is in the future. Nov 06 21:22:40 p5bse systemd-fsck[663]: h50usrlcl: Superblock last write time is in the future. Nov 06 21:22:48 p5bse systemd-fsck[648]: h50pub11: Superblock last mount time is in the future. Nov 06 21:22:48 p5bse systemd-fsck[648]: h50pub11: Superblock last write time is in the future. Nov 06 21:23:58 p5bse systemd-fsck[645]: os131h50: Superblock last write time is in the future. Nov 06 21:24:35 p5bse systemd-fsck[639]: os421h50: Superblock last write time is in the future. I reset the clock and rebooted, which took less than a minute, then tried again with TW20171006/4.13.4-1 last logged in 9 Oct. Boot time felt normal before and after BIOS clock change. I switched BIOS clock back to normal, booted again 2-3 times, then switched back an hour and booted again. Still no write time in the future in journal, and no apparent boot delay. I repeated the switching process with 42.2/4.4.87-18.29, with results like 42.3: # journalctl | grep rblock | grep "Nov 0" | wc -l 14 Seems like this might solve itself by the time distribution 15 is released.

...

You could disconnect the network cables to avoid any NTP issues. But I don't think it actually matters. The system won't start NTP until after it has checked the file systems.

I skipped cable disconnection. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

14:06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-06 at 21:29 -0500, Felix Miata wrote:

...

Oliver Neukum composed on 2017-11-06 09:25 (UTC+0100):

Thanks for your helpful reply!

...
Felix Miata composed:

...
...
Booted ~8 year old Dell (BIOS) PC to Grub menu prior to 2AM.

...
I guess we can assume that this issue does not depend on hardware.

...
...
Local time reverted to 1AM at 2AM before I proceeded with a Grub selection.

...
Which time zone? RTC running at local time or UTC?

Local, as all machines on LAN over which any choice is possible.

:-?

...

...
...
Selected 42.3 in Grub and proceeded to boot.

...
...
Logged in only after more than an hour passed, after 3AM local standard time.

...
Firstly, bugzilla may be a better forum to file this bug, although I admit you hit a pretty unusual bug.

If there even is a bug here.

...
Secondly, could you fiddle with your RTC to reproduce the issue? If we can test for this issue only once a year we have a problem.

I'm at a loss to imagine how to include any NTP server component, if it's relevant, which I would not expect given that most of the Internet and probably all public NTP servers run on UTC.

OTOH, I'm having brainlock over when to boot vis a vis when to change the RTC and in which direction. Maybe this needs to wait until I can better concentrate, not too easy lately.

I think you may have some confusion about time. NTP always serves UTC time, here and the other side the globe, inside your house and outside. There is no choice about this. Linux always uses internally UTC time⁽¹⁾. There is no choice about this. Linux filesystems also use UTC time, AFAIK. Linux displays to the user the time in the time zone he requests, by calculation from the UTC time and tables. Where there is choice is on the RTC time chip. This is a little CMOS chip with a dedicated battery which keeps a clock, with the purpose of setting the computer clock with correct time when it boots, without asking you or internet. This CMOS chip also holds the BIOS configuration in a little RAM, backed with that same battery. This RTC clock can hold UTC time or Local time⁽²⁾, in which case Linux has to calculate the UTC time from it and tables. The calculation is of course different at DST change: has DST already happened, or not? Impossible to know. Thus if your RTC clock holds Local time and you happened to boot the computer just in that interval it is impossible to handle correctly (the clock time that happened twice that night). A time related bug at that instant can not be handled, would be WONTFIX. Having the RTC time keep local time is not justified currently, unless you keep obsolete operating systems. Yes, Windows can keep there UTC time since Windows 7, with a little registry change⁽³⁾. Using Local time causes untold number of problems, and IIRC openSUSE devs have given up on handling it, understandably. (1) actually some other time name, but not relevant. (2) or any arbitrary time (3) https://en.opensuse.org/SDB:Configuring_the_clock#Other_OS - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloBvdcACgkQtTMYHG2NR9VGqQCcCkiL7fKYkIRYMKxH0qRbQf7v tZMAn3IWJQ0Hh/ufX3U8J4cvLQyEBRBy =gaPt -----END PGP SIGNATURE-----

Felix Miata

14:43

Carlos E. R. composed on 2017-11-07 15:06 (UTC+0100):

...

On Monday, 2017-11-06 at 21:29 -0500, Felix Miata wrote:

...

...
Local, as all machines on LAN over which any choice is possible.

...

:-?

Some STBs with LAN access offer choices, others do not.

...

Having the RTC time keep local time is not justified currently, unless you keep obsolete operating systems. Yes, Windows can keep there UTC time since Windows 7, with a little registry change⁽³⁾. Using Local time causes untold number of problems, and IIRC openSUSE devs have given up on handling it, understandably.

Virtually all machines here are multiboot. Virtually all machines here do not host exclusively Linux. Virtually all machines here in addition to Linux host: DOS and/or Windows and/or OS/2 OS/2 runs DOS here 24/7, as DOS emulators on Linux can't do what OS/2 does with DOS that I need it to do: utilize proprietary SVGA text modes. Using local time is required here to maximize consistency across LAN, and avoid compounding backup/restore system complexity. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2368

Age (days ago)

2370

Last active (days ago)

List overview

Download

18 comments

9 participants

participants (9)

Bernhard Voelker
Carlos E. R.
Felix Miata
Karl Cheng
martin＠pluskal.org
Neil Rickert
Oliver Neukum
Richard Brown
Simon Lees

[opensuse-factory] DST end switchover caused all previously mounted partitions to need fsck

tags

participants (9)