During installation bsdinstall asks (via tzsetup): > Is this machine's CMOS clock set to UTC? If it is set to local time, > or you don't know, please choose NO here! Most operating systems, except for Windows, use UTC in the hardware real-time clock by default. This question from tzsetup is presumably intended to aid in dual-boot configurations, but this represents a small fraction of FreeBSD installs. Rather than asking this question on every install just default to UTC. Users who want to dual-boot Windows can create /etc/wall_cmos_clock.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
I'm in favor of this change. I think it needs a Relnotes: yes and maybe an UPDATING entry
Relnotes: yes and maybe an UPDATING
Definitely Relnotes; not sure about UPDATING since this is only a change affecting fresh installs.
Also in favor of this, as I'm guessing that installation alongside some Windows is a marginal use-case for FreeBSD.
Why not change the text of the question to ‘are you dual booting Windows on this computer?’
If 95% (or 99% or whatever) of our users don't need this, is it worth imposing this somewhat confusing question on the rest?
I think adding a FAQ entry or similar to explain to users that are dual booting windows how to change the behavior is worth saving the time/confusion/etc.
That is a much better question although the steps needed to dual boot FreeBSD and Windows are sufficiently baroque that I'd still remove the question. In some ways it's worse if we ask "are you dual booting Windows" and then still overwrite the disk, replace EFI boot vars etc.
I'd eventually like to have an installer that can change existing partitions (to make space for FreeBSD), install an EFI boot manager, etc., and if we get there then handling /etc/wall_cmos_clock would be good to add.
All for going UTC.
We can document the registry tweak for Windows 10 and apparently 11 to make it use UTC clock, which I personally found a better approach than messing with the local clock and have two OSes try and bump it by one hour on begin or end of daylight's saving time. May need disabling to automatically adjust time zone on that other OS.
I've set that on my dual-boot (albeit Windows 10 + Linux not FreeBSD) Laptop and never bothered about clock setting again.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] "RealTimeIsUniversal"=qword:00000001
We can document the registry tweak for Windows
This looks like the preferable way to support dual-boot with Windows. I'm not sure where we would document it though, perhaps a (to be added) dual boot section in the handbook.
Arch Wiki has a pretty good page on this topic: https://wiki.archlinux.org/title/System_time
I’ve seen that number a lot, but no source for it. First, I would say that I don’t care about 99% of users for something like this, I care about 99% of *first time* users. This is confusing only the first time that you run the installer. The second time, you’re already somewhat invested in FreeBSD, the important thing is not to put people off before they even get to first boot.
My guess is that the vast majority of first-time uses are either:
- Installing in a VM.
- Installing in a spare partition on an existing machine.
We can discount the first set because they don’t run the installer, they download the VM images. If we care about people running the installer in VMs, we have ways of detecting most VMs and can skip this question there (building dual-boot VM images is sufficiently rare people can do manual things).
This suggests to me that most first-time users of the installer are people who are dual-booting Windows. Does someone have data to contradict that? Or a reasoned argument that suggests that it isn’t true? Windows still has around 90% of the desktop market share, so anyone wanting to install FreeBSD alongside their existing OS will probably be dual-booting Windows.
If we really wanted to make this user friendly, we could detect the presence of an NTFS partition and skip the question if we didn’t find one.
You have a point, but I also think that should be nuanced depending on who really uses the installer (mostly/only newcomers, or is that more balanced with experienced people?). Not conflating the two points could be possible by having two modes (one, simple, for newcomers, and one advanced).
My guess is that the vast majority of first-time uses are either:
- Installing in a VM.
- Installing in a spare partition on an existing machine.
We can discount the first set because they don’t run the installer, they download the VM images. If we care about people running the installer in VMs, we have ways of detecting most VMs and can skip this question there (building dual-boot VM images is sufficiently rare people can do manual things).
Depends on whether the VM is in the cloud (where I suspect they are likely to use pre-built images) or on their desktop, in which case they may use the installer, especially if they already have the idea of perhaps then installing the OS on a real machine if the testing period goes well.
This suggests to me that most first-time users of the installer are people who are dual-booting Windows. Does someone have data to contradict that? Or a reasoned argument that suggests that it isn’t true? Windows still has around 90% of the desktop market share, so anyone wanting to install FreeBSD alongside their existing OS will probably be dual-booting Windows.
I'm really not sure about that. With the advent of a lot of virtualization solutions, including free ones, I guess that a lot of people that are curious will first just use a VM to test FreeBSD, which can make a lot of sense to avoid any hardware compatibility problems that may occur and the hassle of hard-disks/boot reconfiguration. Because of virtualization also, I wouldn't be surprised if dual-booting is statistically becoming a thing of the past, but I don't know.
If we really wanted to make this user friendly, we could detect the presence of an NTFS partition and skip the question if we didn’t find one.
This and other arguments I have seen plead for having two installation modes (simple, advanced). I barely use the installer, but when I do, I certainly wouldn't want it to infer some behaviors based on imperfect heuristics without me being informed at the very least and, ideally, being able to immediately override its decisions.
I'm considering something like this (suggested by @jrtc27, @theraven and others):
check_win() { for disk in $(sysctl -n kern.disks); do case $disk in da*) continue ;; esac if gpart show $disk | egrep -q 'ms-basic-data|ntfs'; then return 0 fi done return 1 } skiputc= if !check_win; then skiputc=-s fi # Select timezone chroot $BSDINSTALL_CHROOT tzsetup $skiputc
Look for partition types that suggest Windows is installed, and skip the UTC question if we find none. Skip removable media, as we may be installing from a device containing an exfat or ntfs partition (e.g., via Ventoy).
re: tzsetup: Hmm.. that question isn't really user friendly. How about "Is the [system?] clock set to local time?" instead of the previous question?
LGTM about the bsdinstall change!