On Thu, Jul 6, 2017 at 2:56 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
On 06-07-17 06:13, Chris Murphy wrote:
> OK so I just tested this with ext4, XFS and Btrfs in a VM. The VM
> is changed to 2018 before launching the installer.
> XFS and Btrfs have no fsck, and they have no complaint about the
> future dated superblock or file timestamps. Installed system boots
> Ext4 has an fsck triggered during startup, it complains not about
> superblock creation time, but rather last mount time which is stored
> in the superblock, and fsck fixes this, the rw mount happens and
> startup succeeds, no further errors.
Running a fsck after reboot is something users are going to file
a. The "problem" triggering the fsck is in the superblocks, it takes
literally a second to fix it no matter the size of the file system.
This is not some deep traversal.
b. If you don't like fsck at startup policy, don't use ext4, or
manually change the policy. There are two other filesystems that only
depend on log replace at mount time, there is no such thing as an
unattended offline fsck: XFS and Btrfs.
Also various other writtenout files (config files) will have
timestamps in the future too and some tools will complain about that:
Considering how typical it is for time to be off by 24 hours due to
inconsistent time and timezone handling, at a minimum failing
gracefully is necessary. The sendmail logic is absurd "modification
time in the future" != "Your build may be incomplete." It might be
incomplete even if the time weren't in the future. And in fact the
build isn't incomplete even though the file modification time is in
the future. The whole logic here is obliterated by facts, it's a bad
a. On live installs, the command used to copy is -pogAXtlHrDx, and as
-t preserves modification time which is all pretty much anything ever
b. On ostree installations, the time for files is baked into the tree
created server side, and most of the file system is read-only.
c. Netinstalls have the time already set correctly if for some reason
the clock is wrong.
d. No network, non-live, conventional rpm installation with a wrong
clock set would have files with wrong mtimes, maybe there's some rpm
option that allows the mtime for files from an RPM to inherit the
mtime of the rpm or otherwise embed the time in the rpm?
e. There is no possible way to assure that the time will be set
correctly anyway, the user is not required to enter the Date Time
spoke in the installer. And the date time is not visible in the UI for
them to even become suspicious.
Also FWIW, Btrfs encodes times with UNIX time, not UTC. I don't know
how ext4 and XFS encode time. When I use ls -l or stat, they show a
file's time in local time.
> Rolling back to the future dated superblock last mountime, and using
> boot parameter fsck.repair=skip, the fsck is not run during startup,
> file systems mount without complain, system starts up fine.
> So near as I can tell there is no problem that requires setting the
> timezone or even remotely correct date info in the installer.
That is simply not true, on ARM systems without an RTC having a
wrong date (of by a couple of years) is a big problem. Once the
date is of far enough (in either direction) SSL certificate
checks start to fail. And once that happens a lot of things break
including "dnf update"
Sounds to me time is unimportant on a platform that lacks a hw clock.
But anyway, set the system time to something sane like install media
creation time, or any timestamp of any file on that media, or the
creation time set, or the kernel build time. There are lots of
possible sources that are better than null or whatever the time is
when there's no rtc.
Obviously it being accurate is not a requirement or visually
confirming time and changing it would be a mandatory step prior to
A distro consists of many many moving pieces and quite a few of
those care about having a correct time / correct timestamps.
Given that we know that having a wrong system time at install
time is troublesome (e.g. running fsck on a big disk is not
nice) I'm wondering what are we trying to fix here ? What is
wrong with the installer showing a timezone selection screen ?
My experience with anaconda has caused me to do a complete 180 degrees
on overly complicated installers. Now I have a strong bias in favor of
dumb as rocks installers as easier to maintain, test, and use. The
resources expended on something that's used less than one time per
user per release cycle is too high, again my bias. When asking "what's
wrong with feature X" you fall into the trap of assuming it's included
shifting burden to opponents of feature sprawl. Instead I ask, what's
critically necessary? By default, do not add a feature unless it
solves some major issue, and then I apply an even stronger bias
against features that add UI. It's just a personal bias. In my long
list of features to strip out of the installer, date is maybe in the