Page MenuHomeFreeBSD

bsdinstall: Set the date and time earlier
AbandonedPublic

Authored by des on Aug 20 2025, 11:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 20, 5:16 PM
Unknown Object (File)
Sun, Oct 19, 2:04 PM
Unknown Object (File)
Sat, Oct 11, 5:50 AM
Unknown Object (File)
Sat, Oct 11, 5:50 AM
Unknown Object (File)
Fri, Oct 10, 10:37 PM
Unknown Object (File)
Fri, Oct 3, 2:20 PM
Unknown Object (File)
Fri, Oct 3, 3:54 AM
Unknown Object (File)
Sat, Sep 27, 2:54 PM
Subscribers

Details

Reviewers
imp
jrtc27
Group Reviewers
Installer
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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 66392
Build 63275: arc lint + arc unit

Event Timeline

des requested review of this revision.Aug 20 2025, 11:27 PM
This revision is now accepted and ready to land.Aug 20 2025, 11:31 PM
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 requested changes to this revision.Aug 22 2025, 6:23 PM
jrtc27 added inline comments.
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).

This revision now requires changes to proceed.Aug 22 2025, 6:23 PM

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.

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?

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?

usr.sbin/bsdinstall/scripts/auto
275
  1. 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.

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.

usr.sbin/bsdinstall/scripts/auto
275

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

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.

usr.sbin/bsdinstall/scripts/auto
275

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

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.

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.