diskdrake and installer create xfs, btrfs and ext4 filesystems with bogus 32 bits timestamps: Since I formatted all my partitions to install freshly Mageia 8 Beta 1, I see each boot: kernel: xfs filesystem being mounted at /home supports timestamps until 2038 (0x7fffffff) kernel: ext4 filesystem being mounted at /var supports timestamps until 2038 (0x7fffffff) This behaviour is only done by Installer and Diskdrake. Workaround: If I use an Ubuntu Installer to format the mentioned filesystem and I install later Mageia 8 without formatting I no longer see error. I suspect a wrong option use by Installer/DrakX and/or Diskdrake. Other distributions refers: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494 Mitigations: These warnings are shown since 5.4 kernels. Also, this is mitigated by the facts filesystems between now (2020-08-05) and 2038 could be replaced, disks replaced,... But I think starting today, our tools should use 64bits timestamps.
Hi, This is High priority bug for a good reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please make the status to Assigned when you are working on this. Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it. On October 1st 2020, we will drop priority to normal.
I no longer see warning with new ext4 partitions. Also, in xfs side: this is done by mkfs.xfs command. This is already upstream resolved, but not enabled by default. https://www.phoronix.com/scan.php?page=news_item&px=XFS-Linux-5.10 According to mkfs.xfs' manpage: if doing: # mkfs.xfs -m bigtime=1 /dev/sdb1 bigtime=value This option enables filesystems that can handle inode timestamps from December 1901 to July 2486, and quota timer expirations from January 1970 to July 2486. The value is either 0 to disable the feature, or 1 to enable large timestamps. If this feature is not enabled, the filesystem can only handle timestamps from December 1901 to January 2038, and quota timers from January 1970 to February 2106. By default, mkfs.xfs will not enable this feature. If the option -m crc=0 is used, the large timestamp feature is not supported and is disabled. Re-Assigning as it is not a Mageia Tools bug but in default settings of tools. This is FIXED. Need a RELEASE_NOTE entry.
Keywords: (none) => FOR_RELEASENOTES8Status: NEW => RESOLVEDSource RPM: drakxtools-18.32-1.mga8.src.rpm => xfsprogs-5.10.0-1.mga8.src.rpmStatus comment: (none) => Need an entry in Release Notes for M8.Resolution: (none) => FIXEDSummary: diskdrake and installer create xfs, btrfs and ext4 filesystems with bogus 32 bits timestamps => mkfs.xfs creates xfs filesystems with 32 bits timestamps (year 2038 issue)Assignee: mageiatools => pkg-bugs
I am not convinced this is severe enough to go into Mageia errata. 2038 is still a disks life or more away.
CC: (none) => fri
yeah, this is not an errata or relnotes issue... if not even xfs upstream is ready to flip the switch, we should not either...
Keywords: FOR_RELEASENOTES8 => (none)