Re: Superblock last write time is in the future.
On 7/3/17, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Jul 03, 2017 at 08:25:58AM -0300, Wellington Terumi Uemura wrote:
>> Looks like people can't make up their minds, /etc/adjtime is missing
>> from initramfs.
>>
>> root@Dragon:/boot# lsinitramfs /boot/initrd.img-4.9.0-3-amd64|grep etc
>> etc
>> etc/ld.so.cache
>> etc/mtab
>> etc/ld.so.conf.d
>> etc/ld.so.conf.d/zz_i386-biarch-compat.conf
>> etc/ld.so.conf.d/libc.conf
>> etc/ld.so.conf.d/x86_64-linux-gnu.conf
>> etc/udev
>> etc/udev/udev.conf
>> etc/ld.so.conf
>> etc/fstab
>> etc/modprobe.d
>> etc/modprobe.d/cx23885.conf
>> etc/modprobe.d/amd64-microcode-blacklist.conf
>> etc/modprobe.d/sp5100_tco-blacklist.conf
>>
>> And people say that this is the problem.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1198761
>>
>> Looks like all we need to do is to add /etc/adjtime back to initramfs.
>
> Hmm, yes -- initramfs and the "up and running" OS should agree on what
> corrections to apply to the time read from the hwclock; if not, it
> sounds plausible that initramfs (who is mounting root, and thus checking
> the superblock) has a different notion of time than the OS, who has
> synced out the superblock on last shutdown.
>
> I can't work out the details, but what you say makes a lot of sense.
I don't know if this will help, but this topic is fresh in mind
because I am right in the middle of finishing out a successful (3 day
k/t dialup) debootstrap of Buster. Addressing /etc/adjtime is one of
the manual steps in the debootstrap process because that file doesn't
exist until it is manually created early on.
The process *for me* is to create a new file /etc/adjtime and add the
following 3 lines to it:
0.0 0 0.0
0
UTC
After that file is successfully saved, I next run "dpkg-reconfigure
tzdata". The package, tzdata, should be updated, should be the most
current just like any others.
That's for the settings within my desktop environment, etc. My
computers' clocks have always been set to UTC over the years after
having picked that up as a tip one time when my desktop environment's
clock kept resetting itself during every reboot.
Someone here on Debian-User was trying to fix something on their setup
a couple months ago. I couldn't (cognitively) bring the words together
to reply with a "me, too (kinda sorta)" along with providing the
details in my case.
Most of my files reflect the correct date in Thunar, Xfce4's file
manager, EXCEPT THAT.. For some reason, I have to mentally add 4 hours
to the time stamp attached to files downloaded from a Canon FS40 video
camera.
Seems like it might have been doing the same thing for a camera phone
I was using for a couple months. It was doing the same thing for
*something*, I just can't remember what.
Yes, I know it's not quite the same thing, but it does show something
is a little wonky in the time clock department.
If Debian appears to be becoming more insistent that the computer's
clock be set to universal UTC, that feels a little like what we
experienced during the last major release. I remember well the
momentary "upset" caused after that last release. As I "lurked" and
just took all the conversations in back then, it was apparent that
Debian is being developed to be more "strict", more precise, and thus
less forgiving of our old computing habits.
That UTC tip I garnered somewhere off the Net was that we're computing
in an international business and pleasure arena online. That's why
setting UTC for the most "base" of our clocks can almost become a
"critical" must-do to take part in that international arena in a
properly time synced manner. There are surely exceptions why not to go
UTC, but the rationale behind doing so made total sense to me at the
time. :)
So far, that UTC route has worked *for me* with the exception of that
Canon video camera's file time stamp anomaly...........
Just thinking out loud....... :)
Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with duct tape *
Reply to: