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? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw0dimwo.fsf@anar.lloke.localnet
