Bug#702113: debian-installer: System time wrong if RTC in local time zone
Package: debian-installer
Version: 20130211
I wanted to test what would happen when installing Debian on a system
whose RTC is set to the local time zone instead of UTC, and the
installer cannot access an NTP server.
I assume this is a supported scenario, since the expert test-mode
installer asks about the RTC being in UTC or not as the very last
question. I became suspicious when I noticed that it was asked after
almost everything was installed: isn't the system time in the installer
potentially wrong before it knows the answer to that question?
So I tried a test install using the wheezy RC1 installer from:
http://cdimage.debian.org/cdimage/wheezy_di_rc1/i386/iso-cd/debian-wheezy-DI-rc1-i386-netinst.iso
using qemu with its option -rtc base=localtime to set the emulated RTC
to local time. I selected the text-mode expert installer in the boot
loader. Of course I answered No to the installer's final question "is
the RTC set to UTC?".
The result was that the system time in the installed system was off by
the time zone offset: two hours in the future in my case, because my
local time zone offset is UTC+2. (I naturally rebooted into the
installed system with -rtc base=localtime as well, as it would be on a
real system with a RTC that is set to local time all the time.)
This is problematic in two ways:
- The system time is wrong on the installed system, of course (and it
is not obvious where to change it such that the RTC stays in the
local time zone to accommodate other OSes).
- Even if the time is manually corrected after the first boot, the
modification times of files written by the installer are in the
future (for positive time zone offsets). Since the offset is at most
12 hours, this is usually a minor problem. But it could be confusing
when, for example, the system administrator changes some
configuration files after correcting the system time, which moves
their modification times backward. So files that were last modified
by the installer appear newer than those modified in the first few
hours after the first boot.
- In addition to file modification times, the file system metadata may
also be wrong. Just to test this, I rebooted a second time, now
without -rtc base=localtime, and fsck warned about "Superblock last
mount time is in the future (by less than a day, probably due to the
hardware clock being incorrectly set)." and the same for the "last
write time". (Perhaps it would have also warned about the filesystem
creation time, but that wasn't in the future anymore when I finally
rebooted.)
(Due to bug #702093, it is very difficult to change the system time
inside the installer even if the user notices that it is wrong, if
installing off-line or behind a firewall that blocks NTP.)
I am left wondering what the final "is the RTC set to UTC" question in
the installer actually affects, as it does not seem to fix anything
regarding the time - I cannot think of anything that would be different
had I answered Yes instead of No to that question. Should the question
be there at all?
If RTC-in-local-time is a supported scenario, as I assumed above,
shouldn't the question about it be asked at the beginning of the
installation process, e.g., before or after the NTP question? I can't
think of how the modification time in files on the installed system
would be correct unless the installer has the correct system time when
writing them...
If RTC-in-local-time is not actually a supported scenario anymore,
perhaps the final question about it could be removed entirely?
Reply to: