Re: Superblock last write time is in the future.
On Mon 03 Jul 2017 at 09:28:36 (-0400), Cindy-Sue Causey wrote:
> 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...........
Which filesystem does your camera use? How do you transfer the files?
What timezone do you set on the camera? Does the camera clock support
timezones?
For example:
FAT, physically via SD card, UTC, No.
That combination works for both my digital cameras.
Unknown, bluetooth, Local (automatic), Yes.
That combination doesn't work as bluetooth stamps the files with
the time of transfer, so I run a script that renames and touches
them using with the embedded UTC timestamp (the $10 mobile names
them in US format with one minute resolution so I ignore them).
Cheers,
David.
Reply to: