bsdinstall: Set the date and time earlier

[des]

Summary

Fetching distribution tarballs or packages may fail if the clock is
off by too much, so if it looks like we're preparing to download
something, run the time script early.

[des]

usr.sbin/bsdinstall/scripts/auto

273

I'm tempted to just force netconfig and time at this point (or right before asking about installation style), because doing both unconditionally saves a lot of complexity, and setting the clock isn't just necessary for downloading packages, it's also a good idea to have the correct time before we start creating files on the installed system.

[jrtc27]

usr.sbin/bsdinstall/scripts/auto

275

How can this possibly work at this point when the first two things (trimming book-keeping code) bsdinstall time does are:

chroot $BSDINSTALL_CHROOT tzsetup -s

and

TZ="${BSDINSTALL_CHROOT}/etc/localtime"

There's no chroot yet at this point, and you can't mess with the media's /etc/localtime because it's read-only. And you want to actually set the chroot's /etc/localtime, but this will skip that, so on reboot into the installed system you'll get the default (presumably UTC).

[jrtc27]

Note that I don't think the idea of setting the time early is inherently bad; in fact it makes sense to have the correct time for as much of the install as possible. But there's more work needed to be able to actually do it properly; for example, you likely need to have some kind of /etc/localtime -> /tmp/bsdinstall_etc/localtime or whatever like we do for resolv.conf, and then use *that* to populate /etc/localtime for the installed system. If that can be made to work, then I think it should be done unconditionally, otherwise it shouldn't be done at all.

[des]

usr.sbin/bsdinstall/scripts/auto

275

Believe it or not, I actually tested this, and it works just fine, because the important part is setting the clock. The timezone does not impact certificate verification.

Is there a way to tell, from within the time script, if we are pre-install or post-install?

[jrtc27]

usr.sbin/bsdinstall/scripts/auto

275

The timezone does not impact certificate verification, but I imagine that what happens is:

1. chroot $BSDINSTALL_CHROOT tzsetup -s immediately fails and spews something to the console (but immediately hidden by later bsddialog commands)
2. TZ="${BSDINSTALL_CHROOT}/etc/localtime" points at a non-existent file, but that's fine because we didn't set a timezone and /etc/localtime doesn't exist on the install media either as no timezone is configured there
3. It then goes straight onto asking you to set the date and time, but in UTC, which is not what the user would expect (and may cause further oddities on Windows dual-boot systems where the system clock is in local time rather than UTC, noting that this is one of the things that tzsetup deals with)

As a result I expect that you end up with it always behaving as if the user had selected UTC. This is a regression.

Is any of the executing-code-in-my-head above incorrect?

[jrtc27]

usr.sbin/bsdinstall/scripts/auto

275

2. TZ="${BSDINSTALL_CHROOT}/etc/localtime" points at a non-existent file, but that's fine because we didn't set a timezone and /etc/localtime doesn't exist on the install media either as no timezone is configured there

To be clear, it's only fine in the sense that it doesn't make the problem worse given step 1 already failed. If step 1 worked then this would cause further issues.

[jrtc27]

usr.sbin/bsdinstall/scripts/auto

275

Since once again you don't believe me when I leave review comments that point out what I perceive as problems, I come with receipts.

I applied the following patch to ad13dc1ece2fe4a6192bceffea4a868ba6a2e0e2 and did a fully clean buildworld/buildkernel/release build:

diff --git a/usr.sbin/bsdinstall/scripts/auto b/usr.sbin/bsdinstall/scripts/auto
index 0b47d496fdbd..4ea0ccbd4b91 100755
--- a/usr.sbin/bsdinstall/scripts/auto
+++ b/usr.sbin/bsdinstall/scripts/auto
@@ -265,6 +265,18 @@ else
 	fi
 fi
 
+#
+# If we ran netconfig just now, it means we're going to download
+# something, so we need to set the clock, or we may fail to validate
+# server certificates.
+#
+#if [ "$NETCONFIG_DONE" = yes ]; then
+	if [ -z "$BSDINSTALL_SKIP_TIME" ]; then
+		bsdinstall time
+		BSDINSTALL_SKIP_TIME=yes
+	fi
+#fi
+
 rm -f $PATH_FSTAB
 touch $PATH_FSTAB
 

(i.e. the exact diff in this review, except with the outer if commented out so I could trigger the code without needing to try and fetch distribution sets over the network, which won't work for a locally-built image from main without pain and suffering)

I then booted and proceeded through installation as normal (i.e. leaving everything as their default values, outside of things like the hostname and root password).

For point 1, I was ever so slightly wrong: the chroot ... tzsetup -s does fail, but (a) it prints the message to /tmp/bsdinstall_log not the console as that's where stderr is redirected (b) it's the tzsetup that fails not the chroot, because $BSDINSTALL_CHROOT is just /mnt by default, which always exists, but is an empty directory that's part of the root filesystem at this point, because we haven't even run partitioning yet to have anything to mount, and so there is no tzsetup in there to find. That is, the time step proceeds straight to asking the date and time, skipping tzsetup, and /tmp/bsdinstall_log contains "chroot: tzsetup: No such file or directory".

Points 2 and 3 remain true. I was never asked for the timezone during the install, the "Set Time" dialog showed the current time in UTC, and my installed system was left without an /etc/localtime, giving me UTC only.

Note that my timezone is Europe/London, which is currently BST or UTC+1, not UTC, so there is a visual difference between UTC and a system that I have configured to my local timezone.

So, please, when I tell you I think it's broken, don't just throw it back at me like this claiming you tested it when this version clearly does not work in almost exactly the ways I said it wouldn't. If you put something up for review, and explicitly ask someone for feedback, take it on board and consider the fact that it may be valid, rather than just saying it's wrong.

[des]

usr.sbin/bsdinstall/scripts/auto

275

Jessica, I never said I didn't believe you. Now please answer my question.

[jrtc27]

usr.sbin/bsdinstall/scripts/auto

275

You need to set the timezone before asking for the date and time otherwise the user is likely to get confused and put in the wrong time. Therefore the pre-install and post-install steps are entirely different things if you want to be able to set the time early. Therefore you do not need an answer to your question, you just need two different pieces of code. So your question is not relevant in my opinion.

[des]

usr.sbin/bsdinstall/scripts/auto

275

Will you please stop this one-sided feud and just answer my question?

[jrtc27]

usr.sbin/bsdinstall/scripts/auto

275

You never admitted to any wrongdoing for the way you reacted and treated me the other week, so forgive me for not having warm fuzzy feelings about interacting with you when I, after bringing myself to even engage with you again on this review, have my objections dismissed despite being legitimate. "Believe it or not, I actually tested this" is continuing that pattern, so I am offended that you want to claim innocence and that it's a one-sided attack by me on you, and the rest of that message dismisses and/or ignores a large chunk of what I actually said.

But no, I am not going to answer your question. I do not think that the right way to do it involves an answer to that question. If you want to do something else, go ahead, but I have my doubts, and you can figure it out by yourself. I don't think it's beyond you to work out how to pass information a script you're calling about when it's being called.

[des]

usr.sbin/bsdinstall/scripts/auto

275

I did not dismiss your objections. I know this code is incorrect. I did however test it, and it did achieve my initial goal of fixing the certificate validation issue. I am now trying to improve it so it achieves that goal without breaking time zone selection, and I am asking you if there is an established mechanism for telling if a script is being invoked pre- or post-installation. I don't want to reinvent something that already exists.