On Thu, Jul 6, 2017 at 2:56 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > 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 date >> 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 >> fine. >> >> 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 > bugs about: > > https://bugzilla.redhat.com/show_bug.cgi?id=528284 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: > > https://bugzilla.redhat.com/show_bug.cgi?id=59961 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 test. And then: a. On live installs, the command used to copy is -pogAXtlHrDx, and as -t preserves modification time which is all pretty much anything ever cares about. 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 installation. > 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 middle. -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
