Hi,
As discussed at today's WG meeting, I've prepared a draft change page for reducing initial setup redundancy:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm going to send a heads-up to the Anaconda developers now (though I don't plan to join their mailing list, so hopefully they have an active list moderator). And then we will no doubt have a discussion when the change is announced on devel@. Ideally I would have prepared this earlier and had time to run it by the Anaconda developers *before* submitting, but the change proposal deadline is tomorrow, so I'm going to submit it now, even though I haven't had any feedback on it beyond approval of the general idea from the Workstation WG. Sorry for the very short notice and for delaying too long.
Everything is subject to change and nothing is set in stone.
Michael
Hi,
On 04-07-17 04:44, mcatanzaro@gnome.org wrote:
Hi,
As discussed at today's WG meeting, I've prepared a draft change page for reducing initial setup redundancy:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm going to send a heads-up to the Anaconda developers now (though I don't plan to join their mailing list, so hopefully they have an active list moderator). And then we will no doubt have a discussion when the change is announced on devel@. Ideally I would have prepared this earlier and had time to run it by the Anaconda developers *before* submitting, but the change proposal deadline is tomorrow, so I'm going to submit it now, even though I haven't had any feedback on it beyond approval of the general idea from the Workstation WG. Sorry for the very short notice and for delaying too long.
Everything is subject to change and nothing is set in stone.
Former anaconda developer here.
Thanks for the headsup on this one and great to see this happening.
"Language and Keyboard Layout "
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
IOW this really must happen inside the installer.
Regards,
Hans
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout "
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
IOW this really must happen inside the installer.
OK. We might have to remove that entire page from gnome-initial-setup then, because that page only makes sense when creating the first user, and sounds like we need it in anaconda.
Michael
Hi,
On 04-07-17 15:51, mcatanzaro@gnome.org wrote:
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout "
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
IOW this really must happen inside the installer.
OK. We might have to remove that entire page from gnome-initial-setup then, because that page only makes sense when creating the first user, and sounds like we need it in anaconda.
Well, it is useful, very useful even for the ARM images, which are distributed as pre-created file-system images to dd to an sdcard. I did not think of that when I wrote my first mail, but there are really 3 cases to consider (for workstation):
1) Live CD boot + install from livecd This will first run anaconda and then run gnome-initial-setup after rebooted into the new install
2) Pre-installed Workstation fs image on sdcard This will run gnome-initial-setup at first boot, at which time both the keyboard and timezone config screens make a ton of sense.
3) Install from netinstall image This will first run anaconda and then run gnome-initial-setup after rebooted into the new install
1 + 3 are quite alike, except that maybe some stuff can be inherited from the live environment in case 1, esp. once we have a wizard there to setup e.g. the keyboard before logging in.
But in case 2. We really have a pristine install, with no settings what-so-ever and we want gnome-initial-setup to do it all.
Regards,
Hans
On Tue, Jul 4, 2017 at 8:59 AM, Hans de Goede hdegoede@redhat.com wrote:
- Pre-installed Workstation fs image on sdcard
This will run gnome-initial-setup at first boot, at which time both the keyboard and timezone config screens make a ton of sense.
Hm yes, good point... it really is three cases, not two. This new case is an OEM install, basically. This is very important for OEMs. But we've never supported this in the past, I don't think.
I wonder how we could detect this case when running gnome-initial-setup.
Michael
----- Original Message -----
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout "
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
The timezone configuration is only needed for dual-boot installations where the BIOS is in local time instead of UTC, as I don't expect the installer to write anything but UTC dates on disk.
IOW this really must happen inside the installer.
OK. We might have to remove that entire page from gnome-initial-setup then, because that page only makes sense when creating the first user, and sounds like we need it in anaconda.
I'd still like to mention that anaconda phones home to attempt to detect the timezone without telling users about it. At least the GNOME initial setup version asks...
On Tue, Jul 4, 2017 at 8:41 AM, Bastien Nocera bnocera@redhat.com wrote:
The timezone configuration is only needed for dual-boot installations where the BIOS is in local time instead of UTC, as I don't expect the installer to write anything but UTC dates on disk.
I wonder why 20 years ago the ambiguity of timezone and DST was not written to configuration on disk, so that we could just tolerate a hwclock set to current local time?
And now I wonder why we ignore the UEFI spec which rather clearly expects the hwclock to be set to current local time, and includes timezone and DST information with GetTime() and SetTime().
Hi,
On 04-07-17 16:41, Bastien Nocera wrote:
----- Original Message -----
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout"
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
The timezone configuration is only needed for dual-boot installations where the BIOS is in local time instead of UTC, as I don't expect the installer to write anything but UTC dates on disk.
The problem is with freshly generated files, if the timezone is say CET, then those files (and also the filesystem creation timestamp in the superblock) get created at UTC+1, if then after boot the user corrects the timezone to say UTC-6 and within those 7 hours reboots the user will get a bunch of complaints from fsck and other tools about timestamps in the future. IIRC. esp. the fsck issue was nasty.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
Regards,
Hans
----- Original Message -----
Hi,
On 04-07-17 16:41, Bastien Nocera wrote:
----- Original Message -----
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout"
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
The timezone configuration is only needed for dual-boot installations where the BIOS is in local time instead of UTC, as I don't expect the installer to write anything but UTC dates on disk.
The problem is with freshly generated files, if the timezone is say CET, then those files (and also the filesystem creation timestamp in the superblock) get created at UTC+1, if then after boot the user corrects the timezone to say UTC-6 and within those 7 hours reboots the user will get a bunch of complaints from fsck and other tools about timestamps in the future. IIRC. esp. the fsck issue was nasty.
Why is the superblock creation date in local time instead of UTC?
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
Hi,
On 05-07-17 11:30, Bastien Nocera wrote:
----- Original Message -----
Hi,
On 04-07-17 16:41, Bastien Nocera wrote:
----- Original Message -----
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout"
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
The timezone configuration is only needed for dual-boot installations where the BIOS is in local time instead of UTC, as I don't expect the installer to write anything but UTC dates on disk.
The problem is with freshly generated files, if the timezone is say CET, then those files (and also the filesystem creation timestamp in the superblock) get created at UTC+1, if then after boot the user corrects the timezone to say UTC-6 and within those 7 hours reboots the user will get a bunch of complaints from fsck and other tools about timestamps in the future. IIRC. esp. the fsck issue was nasty.
Why is the superblock creation date in local time instead of UTC?
It is in UTC, but if localtime is say 5:00 and the timezone is UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone to UTC + 1 and then reboots then the superblock timestamp translates to 11:00 while localtime is still 5:xx and we get an error about the timestamp being in the future.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.
Regards,
Hans
The real question, however, Hans is: WHY do the tools care? And why do we care? There's innumerable situations where the clock couldn't become out of sync-- either forwards or backwards. Suppress the warnings and move on; is there any situation where those warnings are actually helpful or relevant beyond a "huh, my cmos battery died"?
On Jul 5, 2017, at 09:12, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 05-07-17 11:30, Bastien Nocera wrote: ----- Original Message -----
Hi,
On 04-07-17 16:41, Bastien Nocera wrote:
----- Original Message -----
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout"
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
The timezone configuration is only needed for dual-boot installations where the BIOS is in local time instead of UTC, as I don't expect the installer to write anything but UTC dates on disk.
The problem is with freshly generated files, if the timezone is say CET, then those files (and also the filesystem creation timestamp in the superblock) get created at UTC+1, if then after boot the user corrects the timezone to say UTC-6 and within those 7 hours reboots the user will get a bunch of complaints from fsck and other tools about timestamps in the future. IIRC. esp. the fsck issue was nasty.
Why is the superblock creation date in local time instead of UTC?
It is in UTC, but if localtime is say 5:00 and the timezone is UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone to UTC + 1 and then reboots then the superblock timestamp translates to 11:00 while localtime is still 5:xx and we get an error about the timestamp being in the future.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.
Regards,
Hans _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
Hi,
On 05-07-17 15:46, Eric Griffith wrote:
The real question, however, Hans is: WHY do the tools care? And why do we care? There's innumerable situations where the clock couldn't become out of sync-- either forwards or backwards. Suppress the warnings and move on; is there any situation where those warnings are actually helpful or relevant beyond a "huh, my cmos battery died"?
We care because various tools care. Why the tools care? That is a good question, you could search for past bugs about this to make an initial list of affected tools and start a discussion with the maintainers of those tools.
Regards,
Hans
On Jul 5, 2017, at 09:12, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 05-07-17 11:30, Bastien Nocera wrote: ----- Original Message -----
Hi,
On 04-07-17 16:41, Bastien Nocera wrote:
----- Original Message -----
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote: > "Language and Keyboard Layout" > > I don't see how a normal (non live) non net-install differs > from a net-install. In both cases anaconda is pretty much the > only thing which is running and as such is the best place to > ask about this. I agree that with livecds we need something > else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
> "Time and Date" > > It is important to get the timezone setup correctly *before* > running the phase of anaconda where it formats filesystems > and copies files. Otherwise various tools may complain about > timestamps in the future for files created during install > time when the timezone is later changed in such a way > that the (timezone-adjusted) time becomes earlier. > > We've had several bugs related to this in the past and > actually have moved timezone configuration up to an earlier > point in the installer because of this.
The timezone configuration is only needed for dual-boot installations where the BIOS is in local time instead of UTC, as I don't expect the installer to write anything but UTC dates on disk.
The problem is with freshly generated files, if the timezone is say CET, then those files (and also the filesystem creation timestamp in the superblock) get created at UTC+1, if then after boot the user corrects the timezone to say UTC-6 and within those 7 hours reboots the user will get a bunch of complaints from fsck and other tools about timestamps in the future. IIRC. esp. the fsck issue was nasty.
Why is the superblock creation date in local time instead of UTC?
It is in UTC, but if localtime is say 5:00 and the timezone is UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone to UTC + 1 and then reboots then the superblock timestamp translates to 11:00 while localtime is still 5:xx and we get an error about the timestamp being in the future.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.
Regards,
Hans _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Wed, Jul 5, 2017 at 7:12 AM, Hans de Goede hdegoede@redhat.com wrote:
It is in UTC, but if localtime is say 5:00 and the timezone is UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone to UTC + 1 and then reboots then the superblock timestamp translates to 11:00 while localtime is still 5:xx and we get an error about the timestamp being in the future.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.
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.
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.
Hi,
On 06-07-17 06:13, Chris Murphy wrote:
On Wed, Jul 5, 2017 at 7:12 AM, Hans de Goede hdegoede@redhat.com wrote:
It is in UTC, but if localtime is say 5:00 and the timezone is UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone to UTC + 1 and then reboots then the superblock timestamp translates to 11:00 while localtime is still 5:xx and we get an error about the timestamp being in the future.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.
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
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
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"
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 ?
Regards,
Hans
On Thu, Jul 06, 2017 at 10:56:18AM +0200, Hans de Goede wrote:
Hi,
On 06-07-17 06:13, Chris Murphy wrote:
On Wed, Jul 5, 2017 at 7:12 AM, Hans de Goede hdegoede@redhat.com wrote:
It is in UTC, but if localtime is say 5:00 and the timezone is UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone to UTC + 1 and then reboots then the superblock timestamp translates to 11:00 while localtime is still 5:xx and we get an error about the timestamp being in the future.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.
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:
In that bug report, fsck *fails*. From what Chris writes and from what I remember, this was fixed a while back, and now it'll just give a quick warning. That's not really comparable, it's unlikely that users will care.
Also various other writtenout files (config files) will have timestamps in the future too and some tools will complain about that:
In that bug report the user had the RTC in local time. That just doesn't work ;)
(And timestamps will be wrong only if a) RTC is in local time, b) the RTC is used with a different time zone that it was set with, c) there is no network connection so the system time is not fixed on the way.)
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"
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 ?
I don't have an opinion when (and if) to ask about the timezone, but it seems that people are attributing all possible problems to the wrong timezone, when in fact it should have little effect. In particular it should not have an effect on timestamps, unless you try to configure the computer with RTC in local time, which systemd warns about and which is broken.
Zbyszek
On Thu, Jul 6, 2017 at 7:17 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I don't have an opinion when (and if) to ask about the timezone, but it seems that people are attributing all possible problems to the wrong timezone, when in fact it should have little effect. In particular it should not have an effect on timestamps, unless you try to configure the computer with RTC in local time, which systemd warns about and which is broken.
UEFI spec very clearly states that the rtc is set to "current local time".
UEFI runtime service provides GetTime() which always includes TimeZone value in minutes offset from UTC, and Daylight bitmask so it is possible to unambiguously derive UTC for the purpose of setting system time.
All the kernel code I'm finding is ancient, based on EFI spec 0.92 which predates UEFI. I have no idea if it's abstracting GetTime() and SetTime() correctly. From linux/drivers/char/efirtc.c I see a reference for /proc/driver/rtc but when I cat that, there is no timezone information, and DST is binary rather than bitmask (UEFI spec has three possible states for DST, I think). So at least /proc is exporting incomplete information, and it might be true that it may not SetTime() completely either. So it's possible hwclock and systemd simply can't get the TimeZone information that's exported by UEFI runtime services GetTime().
I have installed shell.efi and it reports something rather weird, whether I boot Windows or Fedora, and the clock is definitely either local time or UTC:
Fedora has set the clock (UTC time was in fact 16:00 at the time this command was issued):
Shell> time 16:00:38 (GMT-34:07)
Windows has set the clock (local time was in fact 10:10 at the time this command was issued):
Shell> time 10:10:20 (GMT-34:07)
So what does the value in parenthesis mean? I have no idea. Not sure what list to discuss this on, it's rather off topic for this list now.
And I've also looked at grub code, as they have a date command but while it returns the day of the week (that's funny really), it doesn't return timezone or DST. But the code itself has a bunch of timezone related stuff in it, so maybe there's some other command that can dump raw UEFI GetTime() - I haven't asked on the grub list yet.
Anyway, there's enough evidence here to be suspicious we're (all of Linux not just Fedora) not doing things correctly regarding time and timezone handling on UEFI.
On Thu, Jul 06, 2017 at 10:54:50AM -0600, Chris Murphy wrote:
On Thu, Jul 6, 2017 at 7:17 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I don't have an opinion when (and if) to ask about the timezone, but it seems that people are attributing all possible problems to the wrong timezone, when in fact it should have little effect. In particular it should not have an effect on timestamps, unless you try to configure the computer with RTC in local time, which systemd warns about and which is broken.
UEFI spec very clearly states that the rtc is set to "current local time".
UEFI spec was "inspired" by Microsoft, so they repeated the same idiotic thing that windows insists on.
UEFI runtime service provides GetTime() which always includes TimeZone value in minutes offset from UTC, and Daylight bitmask so it is possible to unambiguously derive UTC for the purpose of setting system time.
Right. It's "possible", assuming that the daylight offset never changes (and it does, e.g. quite recently in Venezuela). Once the setter of the clock and the reader of the clock use different definitions, it stops being reversible. A lot of complication for little gain.
All the kernel code I'm finding is ancient, based on EFI spec 0.92 which predates UEFI. I have no idea if it's abstracting GetTime() and SetTime() correctly. From linux/drivers/char/efirtc.c I see a reference for /proc/driver/rtc but when I cat that, there is no timezone information, and DST is binary rather than bitmask (UEFI spec has three possible states for DST, I think). So at least /proc is exporting incomplete information, and it might be true that it may not SetTime() completely either. So it's possible hwclock and systemd simply can't get the TimeZone information that's exported by UEFI runtime services GetTime().
I have installed shell.efi and it reports something rather weird, whether I boot Windows or Fedora, and the clock is definitely either local time or UTC:
Fedora has set the clock (UTC time was in fact 16:00 at the time this command was issued):
Shell> time 16:00:38 (GMT-34:07)
Windows has set the clock (local time was in fact 10:10 at the time this command was issued):
Shell> time 10:10:20 (GMT-34:07)
So what does the value in parenthesis mean? I have no idea. Not sure what list to discuss this on, it's rather off topic for this list now.
And I've also looked at grub code, as they have a date command but while it returns the day of the week (that's funny really), it doesn't return timezone or DST. But the code itself has a bunch of timezone related stuff in it, so maybe there's some other command that can dump raw UEFI GetTime() - I haven't asked on the grub list yet.
Anyway, there's enough evidence here to be suspicious we're (all of Linux not just Fedora) not doing things correctly regarding time and timezone handling on UEFI.
Right. That only confirms that storing the hardware time in UTC makes a lot of sense.
Zbyszek
On Thu, Jul 6, 2017 at 12:48 PM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Jul 06, 2017 at 10:54:50AM -0600, Chris Murphy wrote:
On Thu, Jul 6, 2017 at 7:17 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I don't have an opinion when (and if) to ask about the timezone, but it seems that people are attributing all possible problems to the wrong timezone, when in fact it should have little effect. In particular it should not have an effect on timestamps, unless you try to configure the computer with RTC in local time, which systemd warns about and which is broken.
UEFI spec very clearly states that the rtc is set to "current local time".
UEFI spec was "inspired" by Microsoft, so they repeated the same idiotic thing that windows insists on.
Conjecture. It was an Intel and end user inspired spec, and now it's a multi-vendor spec. There had to be, and continues to be, consensus for the current approach to remain valid. Users become confused when their firmware settings show the clock time mismatching from the wall clock. No spec can prevent users from doing this. So the rational decision was to let them win that battle, and just unambiguously encode time so UTC could be inferred.
UEFI runtime service provides GetTime() which always includes TimeZone value in minutes offset from UTC, and Daylight bitmask so it is possible to unambiguously derive UTC for the purpose of setting system time.
Right. It's "possible", assuming that the daylight offset never changes (and it does, e.g. quite recently in Venezuela). Once the setter of the clock and the reader of the clock use different definitions, it stops being reversible. A lot of complication for little gain.
Why would the setter and reader be using different definitions? It isn't that complicated, it's a single page of text that reads unambiguously to me.
The EFI_TIME_ADJUST_DAYLIGHT bit indicates if the time is affected by daylight savings time or not. This value does not indicate that the time has been adjusted for daylight savings time. It indicates only that it should be adjusted when the EFI_TIME enters daylight savings time. If EFI_TIME_IN_DAYLIGHT is set, the time has been adjusted for daylight savings time.
In a place that does not honor DST, I'd expect Daylight is 0 (ergo both EFI_TIME_ADJUST_DAYLIGHT and EFI_TIME_IN_DAYLIGHT are 0). Arizona like Venezuala does not use DST.
Right. That only confirms that storing the hardware time in UTC makes a lot of sense.
Sounds to me like emotional attachment. But it's also provably wrong because more users are harmed by enforcing this policy in the dual boot case, than anyone is helped by it.
The spec provides unambiguous time communication, which is all any rational engineer should require. And yet so far Linux has decided to abandon the UEFI spec for ideological reasons, and allowed all of the same problems from the BIOS era to persist when there's no good reason for doing so.
On Thu, 2017-07-06 at 10:54 -0600, Chris Murphy wrote:
UEFI spec very clearly states that the rtc is set to "current local time".
Then it's a stupid spec. Just because a spec says something stupid doesn't really mean we have to do it. I don't think we're claiming anywhere that Fedora is fully in line with the UEFI spec, are we?
On Thu, Jul 6, 2017 at 2:24 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2017-07-06 at 10:54 -0600, Chris Murphy wrote:
UEFI spec very clearly states that the rtc is set to "current local time".
Then it's a stupid spec. Just because a spec says something stupid doesn't really mean we have to do it. I don't think we're claiming anywhere that Fedora is fully in line with the UEFI spec, are we?
This is so incredibly asinine. Look, you want what you want because you want it. The only possible way to win this particular bunfight is to admit the irrationality of the position. Because otherwise you have to say:
Users rebooting to Windows having fucked up time for possibly an hour until Windows resync's time and updates the clock, and then they reboot Linux and the journal log has fucked up time until chrony kicks in and updates things, IS EXACTLY WHAT WE WANT, THIS IS PERFECT.
On Thu, 2017-07-06 at 14:51 -0600, Chris Murphy wrote:
On Thu, Jul 6, 2017 at 2:24 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2017-07-06 at 10:54 -0600, Chris Murphy wrote:
UEFI spec very clearly states that the rtc is set to "current local time".
Then it's a stupid spec. Just because a spec says something stupid doesn't really mean we have to do it. I don't think we're claiming anywhere that Fedora is fully in line with the UEFI spec, are we?
This is so incredibly asinine. Look, you want what you want because you want it. The only possible way to win this particular bunfight is to admit the irrationality of the position. Because otherwise you have to say:
Users rebooting to Windows having fucked up time for possibly an hour until Windows resync's time and updates the clock, and then they reboot Linux and the journal log has fucked up time until chrony kicks in and updates things, IS EXACTLY WHAT WE WANT, THIS IS PERFECT.
Well, not really, as anaconda still keeps the system clock in local time if you install alongside Windows, AIUI. But doing it when Windows isn't involved seems pretty dumb.
On Thu, Jul 6, 2017 at 3:13 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2017-07-06 at 14:51 -0600, Chris Murphy wrote:
On Thu, Jul 6, 2017 at 2:24 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2017-07-06 at 10:54 -0600, Chris Murphy wrote:
UEFI spec very clearly states that the rtc is set to "current local time".
Then it's a stupid spec. Just because a spec says something stupid doesn't really mean we have to do it. I don't think we're claiming anywhere that Fedora is fully in line with the UEFI spec, are we?
This is so incredibly asinine. Look, you want what you want because you want it. The only possible way to win this particular bunfight is to admit the irrationality of the position. Because otherwise you have to say:
Users rebooting to Windows having fucked up time for possibly an hour until Windows resync's time and updates the clock, and then they reboot Linux and the journal log has fucked up time until chrony kicks in and updates things, IS EXACTLY WHAT WE WANT, THIS IS PERFECT.
Well, not really, as anaconda still keeps the system clock in local time if you install alongside Windows, AIUI. But doing it when Windows isn't involved seems pretty dumb.
OK well I recently did a clean install of Windows 10 and Fedora 26 and that was not my experience, and I don't have an explanation for why it's working differently for me than as intended.
In any case specs and standards involve compromise. All that matters is getting the information you need, you don't always get what you want. And here we have everything we need. What a handful of people want is immaterial. And your position upon getting what's needed but not all that's wanted is to stomp feet, complain, and do not participate. It's not a rational or technical argument.
The Linux only installation might run Windows in a VM. It'd be easy and unambiguous to pass through the host GetTime () to establish the VM's virtual RTC, so that the guest OS does not matter. I have no idea what really happens, but I'm pretty sure UTC gets passed through to the VM's clock, and now Windows always boots with the wrong time at least by default.
But I don't even know that this is intentional or an oversight. All of the tianocore edkii code is very clear as well, GetTim (), SetTime(), GetWakeupTime(), SetWakeupTime() is all expected to be in "current local time" and it's been this way since at least 2004. And also not clear is whether anyone's ever proposed a change, if a change is forthcoming in some future spec.
I do not care if the rtc encodes the time in dog time, ant time, or camel time. What matters is whether it's unambiguous. And as much of a PITA as the UEFI spec is, it is written down, and it's fairly detailed, and it's fairly unambiguous.
On Thu, Jul 6, 2017 at 10:54 AM, Chris Murphy lists@colorremedies.com wrote:
I have installed shell.efi and it reports something rather weird, whether I boot Windows or Fedora, and the clock is definitely either local time or UTC:
Fedora has set the clock (UTC time was in fact 16:00 at the time this command was issued):
Shell> time 16:00:38 (GMT-34:07)
Windows has set the clock (local time was in fact 10:10 at the time this command was issued):
Shell> time 10:10:20 (GMT-34:07)
In case someone curious steps into the steaming pile I've injected...
34h07m = 2407m = 0x07FF
And in the UEFI spec:
#define EFI_UNSPECIFIED_TIMEZONE 0x07FF
INT16 TimeZone; // -1440 to 1440 or 2047
If the value is EFI_UNSPECIFIED_TIMEZONE, then the time is interpreted as a local time.
OK so both Windows and Linux are setting the TimeZone value to local time, but only Windows is actually using local time. But neither one is actually setting the timezone offset. So there is in fact no information to use here.
And then I found this mess from 5 years ago, and then I got lost possibly due to all the gmane.org issues.
http://linux-efi.vger.kernel.narkive.com/gY1o6abi/patch-2-3-rtc-efi-add-time...
The status back then soundss like some hardware came with buggy firmware, so the EFI GetTime () was unreliable. No surprise there. But nevertheless on new hardware and Windows 10, this TimeZone variable is rendered useless near as I can tell. So we're stuck. And funny enough macOS does what we do, sets TimeZone to local time, but then sets the time to UTC. Perfect! Everyone's got exactly what they had before UEFI.
----- Original Message -----
Hi,
On 06-07-17 06:13, Chris Murphy wrote:
On Wed, Jul 5, 2017 at 7:12 AM, Hans de Goede hdegoede@redhat.com wrote:
It is in UTC, but if localtime is say 5:00 and the timezone is UTC - 5 then the superblock creation time will be 10:00 UTC
If the user then after booting the install corrects the timezone to UTC + 1 and then reboots then the superblock timestamp translates to 11:00 while localtime is still 5:xx and we get an error about the timestamp being in the future.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
If we took that approach to every problem, I'd be on the beach right now.
See above, there really is nothing else we can do here.
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
Also various other writtenout files (config files) will have timestamps in the future too and some tools will complain about that:
This is a problem that can be avoided in the installer itself.
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"
By which point we've run the timezone selection in gnome-initial-setup.
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 ?
The installer should be as short as possible, with the majority of the configuration done at first boot because it makes the installation feel streamlined and faster and makes it easier to deploy OEM installations where no assumptions are made as to the target environment.
On Thu, Jul 6, 2017 at 2:56 AM, Hans de Goede hdegoede@redhat.com 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:
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 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.
On Thu, Jul 6, 2017, at 12:22 PM, Chris Murphy wrote:
b. On ostree installations, the time for files is baked into the tree created server side,
The ostree format intentionally *doesn't* store any timestamps, aside from a single timestamp on the commit object, but that's not relevant to the file timestamps. Instead, everything in the immutable set is 0:
https://bugzilla.gnome.org/show_bug.cgi?id=720363
For /etc which is writable, see https://bugzilla.redhat.com/show_bug.cgi?id=1229160 For /var, ostree itself (almost) never touches it, we rely on systemd-tmpfiles.
One thing that's a bit relevant to this list is that it's now a bug for tools run in %post to rely on file timestamps to determine whether or not something changed. I'm not aware of anything that does today though, most things use file triggers or just run unconditionally.
On Thu, 2017-07-06 at 10:56 +0200, Hans de Goede wrote:
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"
Incorrect system time and sudden jumps in the system time (which can happen if the time is set wrong during install and corrected by NTP after install) can also cause issues with DHCP and Kerberos.
----- Original Message -----
On Thu, 2017-07-06 at 10:56 +0200, Hans de Goede wrote:
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"
Incorrect system time and sudden jumps in the system time (which can happen if the time is set wrong during install and corrected by NTP after install) can also cause issues with DHCP and Kerberos.
Which *still* aren't a problem because you'd already setup the timezone in gnome-initial-setup by the time you encountered those.
On Fri, 2017-07-07 at 04:21 -0400, Bastien Nocera wrote:
----- Original Message -----
On Thu, 2017-07-06 at 10:56 +0200, Hans de Goede wrote:
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"
Incorrect system time and sudden jumps in the system time (which can happen if the time is set wrong during install and corrected by NTP after install) can also cause issues with DHCP and Kerberos.
Which *still* aren't a problem because you'd already setup the timezone in gnome-initial-setup by the time you encountered those.
Well, probably Kerberos, but not DHCP - the first wired network connection is configured systemwide and already started by the time you hit g-i-s, I believe.
On Wed, Jul 5, 2017 at 2:31 AM, Hans de Goede hdegoede@redhat.com wrote:
The problem is with freshly generated files, if the timezone is say CET, then those files (and also the filesystem creation timestamp in the superblock) get created at UTC+1, if then after boot the user corrects the timezone to say UTC-6 and within those 7 hours reboots the user will get a bunch of complaints from fsck and other tools about timestamps in the future. IIRC. esp. the fsck issue was nasty.
Really this is a solved problem for 8 years or so now, the anaconda team has gone over this in much detail back then. We simply MUST ask for the timezone info before writing anything to disk.
*shrug* considering 90% of the rest of the world's in-use OS's do not have this requirement or problem, to me it sounds like a bug. I'll add it to my test list and see what really breaks still but I think this is specious logic at play. And in fact fsck shouldn't be run automatically anyway these days, it's archaic. Ext4, XFS, and Btrfs do log replay at mount time when needed.
And in any case, the timezone information is available via GetTime() from UEFI runtime services, but the installer not only does not use this information, still badgering the user for it, it then proceeds to overwrite the TimeZone information with UTC instead, without the user's knowledge or permission. That's very clearly data loss and creates the very condition of timezone ambiguity we had on BIOS firmware machines, that was supposed to be fixed with UEFI.
So in effect, we not only fail to ignore the UEFI spec for no technical reason, trouble the user for this information unnecessarily, we further proceed to sabotaging the attempt to make device time and location unambiguous. Time itself remains unambiguous when TimeZone is set to UTC, but now the data indicting purported physical location of the device is lost.
On Tue, 2017-07-04 at 08:51 -0500, mcatanzaro@gnome.org wrote:
On Tue, Jul 4, 2017 at 2:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Language and Keyboard Layout "
I don't see how a normal (non live) non net-install differs from a net-install. In both cases anaconda is pretty much the only thing which is running and as such is the best place to ask about this. I agree that with livecds we need something else.
It doesn't. Anaconda is the right place in both cases. But Workstation has only the live image and netinstall images, so we don't consider this case.
It also now has the OStree installer image (in both F26 and Rawhide), so remember to also consider that case (though it will usually not differ from the network installer for the purposes of this stuff).
On Tue, Jul 4, 2017 at 1:11 AM, Hans de Goede hdegoede@redhat.com wrote:
"Time and Date"
It is important to get the timezone setup correctly *before* running the phase of anaconda where it formats filesystems and copies files. Otherwise various tools may complain about timestamps in the future for files created during install time when the timezone is later changed in such a way that the (timezone-adjusted) time becomes earlier.
We've had several bugs related to this in the past and actually have moved timezone configuration up to an earlier point in the installer because of this.
IOW this really must happen inside the installer.
The filesystem (kernel code and user space tools) needs to tolerate the inevitability of time/date discrepancies. It can complain loudly when there's confusion, that's fine, but it can't faceplant. I've lost track of some of those bugs so I don't recall the specifics. But clearly computers can have a clock battery die, or even some hardware has no clock battery, and the idea such a system now can't boot, or will behave weirdly is not OK, that's a bug.
Meanwhile over on Windows and macOS since time long ago, the installer environment doesn't have a way to set time or timezone. Those installers may have a time check and tolerance, I'd sooner expect a complaint about invalid signing certificate since the payload/packages are signed. Both OS's do time/date and timezone configuration post-install.
Anyway, point is, I don't accept the assumption that the user must be troubled by this during OS installation. The installer could ensure hwclock time is the same or after install media's superblock time, and change it if it's not, and avoid bothering the user with this at this stage where a lot of hardware does not and will not have an internet connection for setting the time exactly anyway.
On Mon, Jul 03, 2017 at 09:44:31PM -0500, mcatanzaro@gnome.org wrote:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm definitely in favor of the user account changes. The current setup is confusing for non-experienced users, especially because administrator isn't checked by default. This leads to situations where only a root account is created, and if you log in to Workstation in X or (especially) Wayland as root, many things don't work in non-obvious ways. Like, the GNOME user account panel.
On Tue, 2017-07-04 at 11:21 -0400, Matthew Miller wrote:
On Mon, Jul 03, 2017 at 09:44:31PM -0500, mcatanzaro@gnome.org wrote:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm definitely in favor of the user account changes. The current setup is confusing for non-experienced users, especially because administrator isn't checked by default. This leads to situations where only a root account is created, and if you log in to Workstation in X or (especially) Wayland as root, many things don't work in non-obvious ways. Like, the GNOME user account panel.
I don't think this is possible. If you only create a root password in anaconda, this is noticed at first boot, and g-i-s runs in its pre-GDM mode and forces you to create a user account before you reach GDM.
On Wed, Jul 05, 2017 at 12:17:32PM -0700, Adam Williamson wrote:
I'm definitely in favor of the user account changes. The current setup is confusing for non-experienced users, especially because administrator isn't checked by default. This leads to situations where only a root account is created, and if you log in to Workstation in X or (especially) Wayland as root, many things don't work in non-obvious ways. Like, the GNOME user account panel.
I don't think this is possible. If you only create a root password in anaconda, this is noticed at first boot, and g-i-s runs in its pre-GDM mode and forces you to create a user account before you reach GDM.
I got a user report recently about this situation -- I'll verify. It's possible they created a non-admin user account in addition to setting the root password. However, it seems in this case they could log in as that non-admin user and unlock with the root password, right? Maybe the problem is simply insufficient warning when logging in to GNOME as root.
On Wed, 2017-07-05 at 15:29 -0400, Matthew Miller wrote:
On Wed, Jul 05, 2017 at 12:17:32PM -0700, Adam Williamson wrote:
I'm definitely in favor of the user account changes. The current setup is confusing for non-experienced users, especially because administrator isn't checked by default. This leads to situations where only a root account is created, and if you log in to Workstation in X or (especially) Wayland as root, many things don't work in non-obvious ways. Like, the GNOME user account panel.
I don't think this is possible. If you only create a root password in anaconda, this is noticed at first boot, and g-i-s runs in its pre-GDM mode and forces you to create a user account before you reach GDM.
I got a user report recently about this situation -- I'll verify. It's possible they created a non-admin user account in addition to setting the root password. However, it seems in this case they could log in as that non-admin user and unlock with the root password, right? Maybe the problem is simply insufficient warning when logging in to GNOME as root.
IIRC, gdm just doesn't *let* you log in as root at all. Are you sure this person was running GNOME? You *can* get to KDE with only a root user, I believe.
On Wed, Jul 05, 2017 at 01:23:17PM -0700, Adam Williamson wrote:
IIRC, gdm just doesn't *let* you log in as root at all. Are you sure this person was running GNOME? You *can* get to KDE with only a root user, I believe.
Yeah because the specific complaint was about the gnome user account app not running as root. Hmm.
On Wed, Jul 5, 2017 at 3:23 PM, Adam Williamson adamwill@fedoraproject.org wrote:
IIRC, gdm just doesn't *let* you log in as root at all. Are you sure this person was running GNOME? You *can* get to KDE with only a root user, I believe.
This got reverted some time ago.
Now, half the desktop will be royally broken if you log in as root, and there's no way we'd ever claim to support that. But it's unfortunately possible again.
Michael
On Wed, 2017-07-05 at 18:44 -0500, Michael Catanzaro wrote:
On Wed, Jul 5, 2017 at 3:23 PM, Adam Williamson adamwill@fedoraproject.org wrote:
IIRC, gdm just doesn't *let* you log in as root at all. Are you sure this person was running GNOME? You *can* get to KDE with only a root user, I believe.
This got reverted some time ago.
Oh, dear. Why?
On Wed, Jul 5, 2017 at 6:54 PM, Adam Williamson adamwill@fedoraproject.org wrote:
Oh, dear. Why?
Peer pressure:
https://git.gnome.org/browse/gdm/commit/data/pam-redhat?id=7dbd9d1d8b4605966...
On Wed, Jul 5, 2017 at 6:03 PM, Michael Catanzaro mike.catanzaro@gmail.com wrote:
On Wed, Jul 5, 2017 at 6:54 PM, Adam Williamson adamwill@fedoraproject.org wrote:
Oh, dear. Why?
Peer pressure:
https://git.gnome.org/browse/gdm/commit/data/pam-redhat?id=7dbd9d1d8b4605966...
Mitigate it with 'passwd -d root' ?
On Wed, Jul 05, 2017 at 07:03:20PM -0500, Michael Catanzaro wrote:
Oh, dear. Why?
Peer pressure: https://git.gnome.org/browse/gdm/commit/data/pam-redhat?id=7dbd9d1d8b4605966...
I understand the usefulness of having GDM able to support use cases where this makes sense, but I don't think we have one. Can we disable it again in Fedora, or at least give a warning message?
Long ago in BU Linux, we allowed root login but changed the background wallpaper to a warning and gave a pop-up lecture.
On Thu, Jul 6, 2017 at 8:40 AM, Matthew Miller mattdm@fedoraproject.org wrote:
I understand the usefulness of having GDM able to support use cases where this makes sense, but I don't think we have one. Can we disable it again in Fedora, or at least give a warning message?
I think we should, but that's up to halfline.
Michael
On Wed, Jul 5, 2017 at 1:17 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2017-07-04 at 11:21 -0400, Matthew Miller wrote:
On Mon, Jul 03, 2017 at 09:44:31PM -0500, mcatanzaro@gnome.org wrote:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm definitely in favor of the user account changes. The current setup is confusing for non-experienced users, especially because administrator isn't checked by default. This leads to situations where only a root account is created, and if you log in to Workstation in X or (especially) Wayland as root, many things don't work in non-obvious ways. Like, the GNOME user account panel.
I don't think this is possible. If you only create a root password in anaconda, this is noticed at first boot, and g-i-s runs in its pre-GDM mode and forces you to create a user account before you reach GDM.
There's an unfortunate conflict between wanting a disabled root user by default; and the ensuing difficulty troubleshooting boot problems because systemd demands only root can login when hitting emergency target. An account in wheel is not an option.
On Wed, Jul 05, 2017 at 02:36:39PM -0600, Chris Murphy wrote:
On Wed, Jul 5, 2017 at 1:17 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2017-07-04 at 11:21 -0400, Matthew Miller wrote:
On Mon, Jul 03, 2017 at 09:44:31PM -0500, mcatanzaro@gnome.org wrote:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm definitely in favor of the user account changes. The current setup is confusing for non-experienced users, especially because administrator isn't checked by default. This leads to situations where only a root account is created, and if you log in to Workstation in X or (especially) Wayland as root, many things don't work in non-obvious ways. Like, the GNOME user account panel.
I don't think this is possible. If you only create a root password in anaconda, this is noticed at first boot, and g-i-s runs in its pre-GDM mode and forces you to create a user account before you reach GDM.
There's an unfortunate conflict between wanting a disabled root user by default; and the ensuing difficulty troubleshooting boot problems because systemd demands only root can login when hitting emergency target. An account in wheel is not an option.
We *could* change systemd behaviour here. For example, it could detect that root account is locked and permit any user to log in. Or we could extend this, and somehow only allow users in wheel to log in. Such changes would require some new code and config, but certainly they can done, current behaviour is not set in stone.
Zbyszek
On Wed, Jul 5, 2017 at 3:22 PM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Jul 05, 2017 at 02:36:39PM -0600, Chris Murphy wrote:
On Wed, Jul 5, 2017 at 1:17 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2017-07-04 at 11:21 -0400, Matthew Miller wrote:
On Mon, Jul 03, 2017 at 09:44:31PM -0500, mcatanzaro@gnome.org wrote:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm definitely in favor of the user account changes. The current setup is confusing for non-experienced users, especially because administrator isn't checked by default. This leads to situations where only a root account is created, and if you log in to Workstation in X or (especially) Wayland as root, many things don't work in non-obvious ways. Like, the GNOME user account panel.
I don't think this is possible. If you only create a root password in anaconda, this is noticed at first boot, and g-i-s runs in its pre-GDM mode and forces you to create a user account before you reach GDM.
There's an unfortunate conflict between wanting a disabled root user by default; and the ensuing difficulty troubleshooting boot problems because systemd demands only root can login when hitting emergency target. An account in wheel is not an option.
We *could* change systemd behaviour here. For example, it could detect that root account is locked and permit any user to log in. Or we could extend this, and somehow only allow users in wheel to log in. Such changes would require some new code and config, but certainly they can done, current behaviour is not set in stone.
Very cool. I for one would really prefer to see the root user disabled by default on all Fedora media. There doesn't seem to be much of an upside for Workstation; and then for Cloud/Atomic Host, and Server, it seems an unnecessary risk. Just login as a user in wheel and sudo -i if you need root.
On Wed, Jul 05, 2017 at 04:11:55PM -0600, Chris Murphy wrote:
Very cool. I for one would really prefer to see the root user disabled by default on all Fedora media. There doesn't seem to be much of an upside for Workstation; and then for Cloud/Atomic Host, and Server, it seems an unnecessary risk. Just login as a user in wheel and sudo -i if you need root.
Yeah, Cloud follows the general convention of having the root account locked and a `fedora` user created by default with passwordless sudo access.
On 07/06/2017 07:36 AM, Matthew Miller wrote:
On Wed, Jul 05, 2017 at 04:11:55PM -0600, Chris Murphy wrote:
Very cool. I for one would really prefer to see the root user disabled by default on all Fedora media. There doesn't seem to be much of an upside for Workstation; and then for Cloud/Atomic Host, and Server, it seems an unnecessary risk. Just login as a user in wheel and sudo -i if you need root.
Yeah, Cloud follows the general convention of having the root account locked and a `fedora` user created by default with passwordless sudo access.
Which is silly and pointless, but I guess this is not the right place to complain and the ship has sailed since everyone does this now. ;(
kevin
On Mon, Jul 10, 2017 at 9:17 AM, Kevin Fenzi kevin@scrye.com wrote:
On 07/06/2017 07:36 AM, Matthew Miller wrote:
On Wed, Jul 05, 2017 at 04:11:55PM -0600, Chris Murphy wrote:
Very cool. I for one would really prefer to see the root user disabled by default on all Fedora media. There doesn't seem to be much of an upside for Workstation; and then for Cloud/Atomic Host, and Server, it seems an unnecessary risk. Just login as a user in wheel and sudo -i if you need root.
Yeah, Cloud follows the general convention of having the root account locked and a `fedora` user created by default with passwordless sudo access.
Which is silly and pointless, but I guess this is not the right place to complain and the ship has sailed since everyone does this now. ;(
I find sudo silly and pointless. Merely typing sudo to prefix every command does literally nothing but increase carpal tunnel syndrome. Every stupid mistake I've ever made, I've made with sudo in duplicate compared to just being root and not typing sudo for every damn command. What I do like about sudo is every command is logged to the journal, and with sealing enabled it's tamper proof. So why not have 'sudo -i' put me in a logged root shell?
On Wed, Jul 5, 2017 at 3:36 PM, Chris Murphy lists@colorremedies.com wrote:
There's an unfortunate conflict between wanting a disabled root user by default; and the ensuing difficulty troubleshooting boot problems because systemd demands only root can login when hitting emergency target. An account in wheel is not an option.
Yeah that is annoying. Fortunately that only happens in cases where the system is already hosed: it's not reasonable to expect users to be able to recover from an emergency prompt. Fixing systemd would be great, but is not within the scope of this change.
It needs to prompt for username and password, and accept any user in wheel.
It *also* needs to use the same keyboard layout that's configured in GNOME. (I'm not sure if it currently does or not, but I suspect not.) Otherwise, the emergency prompt is practically limited to Americans....
Michael
On Wed, 2017-07-05 at 18:43 -0500, Michael Catanzaro wrote:
It *also* needs to use the same keyboard layout that's configured in GNOME. (I'm not sure if it currently does or not, but I suspect not.)
This is...complicated, and will remain so until someone finally gets around to making console input less sucky and less completely different from graphical input.
At present, I think, it will sort of happen most of the time: the problems are cases where there just is no equivalent console layout for the X keyboard layout, and I believe when the layout is changed, before the initramfs is rebuilt (because I think we're using the initramfs at that point, and the console keyboard layout config is saved into the initramfs each time it's built).
On Mon, 2017-07-03 at 21:44 -0500, mcatanzaro@gnome.org wrote:
Hi,
As discussed at today's WG meeting, I've prepared a draft change page for reducing initial setup redundancy:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm going to send a heads-up to the Anaconda developers now (though I don't plan to join their mailing list, so hopefully they have an active list moderator). And then we will no doubt have a discussion when the change is announced on devel@. Ideally I would have prepared this earlier and had time to run it by the Anaconda developers *before* submitting, but the change proposal deadline is tomorrow, so I'm going to submit it now, even though I haven't had any feedback on it beyond approval of the general idea from the Workstation WG. Sorry for the very short notice and for delaying too long.
Everything is subject to change and nothing is set in stone.
On this topic:
"In the meantime, until we have a way to prompt users for these settings earlier than Anaconda, these panels should be removed from gnome-initial-setup, because Anaconda is clearly a better place than gnome-initial-setup for this configuration."
Does anaconda in fact configure *input methods*? If not, then this could be a problem for languages which require these (including CJK). I have noticed, for instance, that if you install in Japanese for the last few releases, the default choice on g-i-s' input screen is not the most optimal one:
https://bugzilla.gnome.org/show_bug.cgi?id=776189
If removing the screen from g-i-s means users who install in Japanese will just wind up with the 'ja' keyboard layout and no actual input method configured, this is a very poor outcome and should be avoided (to be very clear: this is not remotely a workable configuration for a Japanese user. With such a configuration it is not possible to type any Japanese characters at all.)
"We will remove the network configuration spoke from Anaconda."
Could this not be subject to the same issue as the Time and Date spoke - that it may be necessary in some circumstances to set the hostname at install time, not at first boot / first login?
On Wed, Jul 5, 2017 at 2:19 PM, Adam Williamson adamwill@fedoraproject.org wrote:
Does anaconda in fact configure *input methods*? If not, then this could be a problem for languages which require these (including CJK).
Good question. I don't know the answer. We'll need to figure this out.
Michael
On Mon, Jul 3, 2017 at 10:45 PM mcatanzaro@gnome.org wrote:
Hi,
As discussed at today's WG meeting, I've prepared a draft change page for reducing initial setup redundancy:
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
I'm going to send a heads-up to the Anaconda developers now (though I don't plan to join their mailing list, so hopefully they have an active list moderator). And then we will no doubt have a discussion when the change is announced on devel@. Ideally I would have prepared this earlier and had time to run it by the Anaconda developers *before* submitting, but the change proposal deadline is tomorrow, so I'm going to submit it now, even though I haven't had any feedback on it beyond approval of the general idea from the Workstation WG. Sorry for the very short notice and for delaying too long.
Everything is subject to change and nothing is set in stone.
Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
Just a comment about the plan to remove the Networking spoke: you're right that on the Live media, this provides only the hostname (and an incompatible approach as well), but on the (branded) netinstall, this spoke *does* include real networking information (which is necessary to configure properly if we are installing with available updates). This needs to be kept in mind.
On Mon, Jul 10, 2017 at 5:58 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Just a comment about the plan to remove the Networking spoke: you're right that on the Live media, this provides only the hostname (and an incompatible approach as well), but on the (branded) netinstall, this spoke *does* include real networking information (which is necessary to configure properly if we are installing with available updates). This needs to be kept in mind.
Yes, as mentioned in the change proposal, we need some way to distinguish between liveinst and netinstall. This is actually the part that's most hazy to me. Anyone have suggestions for how to do that?
One very simple answer is to have the first run JS program write the Anaconda configuration. That's probably the best approach, because then *none* of our changes would affect netinst. If you're doing netinst you are more likely to want to configure everything at installation time anyway.
Michael
On Mon, Jul 10, 2017 at 9:55 AM, Michael Catanzaro mike.catanzaro@gmail.com wrote:
On Mon, Jul 10, 2017 at 5:58 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Just a comment about the plan to remove the Networking spoke: you're right that on the Live media, this provides only the hostname (and an incompatible approach as well), but on the (branded) netinstall, this spoke *does* include real networking information (which is necessary to configure properly if we are installing with available updates). This needs to be kept in mind.
Yes, as mentioned in the change proposal, we need some way to distinguish between liveinst and netinstall. This is actually the part that's most hazy to me. Anyone have suggestions for how to do that?
Parse /proc/cmdline? There's a rd.live.image boot parameter for live boots.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Chris Murphy -
Colin Walters -
Eric Griffith -
Hans de Goede -
Kevin Fenzi -
Matthew Miller -
mcatanzaro＠gnome.org -
Michael Catanzaro -
Stephen Gallagher -
Zbigniew Jędrzejewski-Szmek