SDcard show wrong date (one month ahead)

[arno]

When mount an SD card date is wrong shown on SD-card (it is shown as to be one month ahead). Very strange.
There is already some report about here, but I don't find a bug here in launchpad.
https://www.explorelinux.com/ubuntu-wrong-date-from-sd-card-pictures/
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.12
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: user 1077 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: MATE
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2020-05-10 (197 days ago)
InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 8087:0a2b Intel Corp.
 Bus 001 Device 002: ID 04f2:b560 Chicony Electronics Co., Ltd HP HD Camera
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: HP HP EliteBook Folio G1
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-54-generic root=UUID=92c467dc-e394-4f19-a6a2-e7cf918f0ffb ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-54-generic N/A
 linux-backports-modules-5.4.0-54-generic N/A
 linux-firmware 1.187.4
Tags: focal
Uname: Linux 5.4.0-54-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 07/12/2020
dmi.bios.vendor: HP
dmi.bios.version: N91 Ver. 01.49
dmi.board.name: 8170
dmi.board.vendor: HP
dmi.board.version: KBC Version 29.73
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:bvrN91Ver.01.49:bd07/12/2020:svnHP:pnHPEliteBookFolioG1:pvr:rvnHP:rn8170:rvrKBCVersion29.73:cvnHP:ct10:cvr:
dmi.product.family: 103C_5336AN
dmi.product.name: HP EliteBook Folio G1
dmi.product.sku: V1C39EA#ABD
dmi.sys.vendor: HP
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.12
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: user 1078 F.... pulseaudio
 /dev/snd/pcmC0D0p: user 1078 F...m pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: MATE
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2020-05-10 (199 days ago)
InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
MachineType: HP HP EliteBook Folio G1
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-54-generic root=UUID=92c467dc-e394-4f19-a6a2-e7cf918f0ffb ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-54-generic N/A
 linux-backports-modules-5.4.0-54-generic N/A
 linux-firmware 1.187.4
StagingDrivers: exfat
Tags: focal staging
Uname: Linux 5.4.0-54-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 07/12/2020
dmi.bios.vendor: HP
dmi.bios.version: N91 Ver. 01.49
dmi.board.name: 8170
dmi.board.vendor: HP
dmi.board.version: KBC Version 29.73
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:bvrN91Ver.01.49:bd07/12/2020:svnHP:pnHPEliteBookFolioG1:pvr:rvnHP:rn8170:rvrKBCVersion29.73:cvnHP:ct10:cvr:
dmi.product.family: 103C_5336AN
dmi.product.name: HP EliteBook Folio G1
dmi.product.sku: V1C39EA#ABD
dmi.sys.vendor: HP

[arno (star-gmx)]

I am using Ubuntu Mate 20.04 LTS. It is seen in Caja. I found the wrong date also in terminal, doing ls -l at the mounted directory.
Very strange to change the month ...
mount:
/dev/sdb1 on /media/user/disk type exfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,namecase=0,errors=remount-ro,uhelper=udisks2)

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1905179

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[Kai-Heng Feng (kaihengfeng)]

Not seeing sdb in the logs... please re-upload the logs with SD card plugged.

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

apport information

[arno (star-gmx)]

Did it again. It seem it after that mount again 1 month ahead (additionally). Now I have dates from 2021.01.21 on the card.
Why the hell it writes to it?

apport-collect 1905179
The authorization page:
 (https://launchpad.net/+authorize-token?oauth_token=SJfk2pLQSrbRsRMfjf1p&allow_permission=DESKTOP_INTEGRATION)
should be opening in your browser. Use your browser to authorize
this program to access Launchpad on your behalf.
Waiting to hear from Launchpad about your decision...
dpkg-query: Kein Paket gefunden, das auf linux passt

Tell me what kind of log exactly do you need? How can I avoid a r/w mount?

[Kai-Heng Feng (kaihengfeng)]

Did any other OS or device use the SD card?

[arno (star-gmx)]

No. I do have windows as a second boot-option, but almost never use it. The SDcard is just in my camera.
There seems to be some thumbnail creation running. (gtk-pixbuf-thum) ?
Just try to catch something in "top"
If I plug in the card file I get a question whether to open it with shotwell - but I deny that.

That is really strange.

[arno (star-gmx)]

I just put an new/fresh SD-card to my camera, took few pictures. This time date is increased only once. It looks like that on a full filled card indexing/rewrite takes longer and so it is repeated. While on the testcard now there are only few images and date increase happens just once. But I also see a shift in 1hour.
Shifting hours can happen by BIOS/OS interactions, but for a month?

I took out the card and did 2 more pictures.
I returned to BIOS and set it to GMT. Did not boot any Windows but Ubuntu.

Again I see a shift for 1 month - so the previous pictures are now 2/2021 and the new pictures are from Jan. ?!?

The 1hour shift keeps.

[Kai-Heng Feng (kaihengfeng)]

Maybe check the date under Windows? Could the camera be the culprit?

[arno (star-gmx)]

It is not a camera or card issue (tried with another one). Under windows a new created photo shows correct date. There is write access to the card in Linux. I can see that unmount is sometimes delayed if using cards that are full of pictures.
Also I get a shift each time I add a new picture and unplug/plug the sd-card. That shift doesn't seem to happen if a) no new picture is added, b) the process of whatever it doesn is completed last time.

I did remember I once changed "timedatectl" to get it compatible to Windows. Otherwise the time has to be adjusted after each change of boot.

To make clear that this is not the issue I set it back (see below). But even after that, and even after reboot - the issue keeps same. A new created picture is shifted to January 2021 and the other pictures are inbetween moved to May 2021 - crazy shit.

Who is writing to my SD-Card and why? My suspect is a picture programm, but how to find that?
Mate is setup to do no action when mounted (so not open shotwell or caja).

~$ timedatectl
               Local time: Sa 2020-12-12 18:55:33 CET
           Universal time: Sa 2020-12-12 17:55:33 UTC
                 RTC time: Sa 2020-12-12 17:54:39
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

~$ sudo timedatectl set-local-rtc 0
[sudo] Passwort für user:
~$ timedatectl
               Local time: Sa 2020-12-12 18:56:27 CET
           Universal time: Sa 2020-12-12 17:56:27 UTC
                 RTC time: Sa 2020-12-12 17:56:27
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

[Kai-Heng Feng (kaihengfeng)]

Ok, I really don't know what happened. Let's see if systemd folks have some idea...

[arno (star-gmx)]

A friend could identify the issue and repeat that on Kubuntu 20.04. The reason seems to be the filesystem on sd-card. With FAT32 there is no problem, but bigger cards - beginning with 64GB - use exFAT. After

sudo apt-get install exfat-utils

the issue is gone :)

I see this as a bug. The filesystem is mounted although it is not properly supported. Nevertheless thanks for all at least taking notice.

[Kai-Heng Feng (kaihengfeng)]

Ok, please use kernel 5.7+ for kernel space exfat support.

For 20.04, this can be achieved by
$ sudo apt install linux-generic-hwe-20.04-edge