The live CD installer should detect the presence of OpenSolaris

Bug #279065 reported by Joanmarie on 2008-10-06
Affects Status Importance Assigned to Milestone
clock-setup (Ubuntu)
Colin Watson

Bug Description

Binary package hint: ubiquity

From bug 278429:

> The desktop installer detects a dual-boot situation
> and will automatically set UTC=no

I have several systems which are dual-boot OpenSolaris/Ubuntu. I typically install OpenSolaris prior to installing Ubuntu, and UTC seems to always be set to 'yes'. So I'm guessing that dual-boot detection is failing when the other OS is OpenSolaris. It would be helpful if the live CD installer would detect the presence of OpenSolaris and set UTC=no.

(Bonus points if it could also make an entry in grub's menu.lst. ;-) But I'd be thrilled if Ubuntu would just stop stomping on my system clock without my having to edit /etc/default/rcS.)


Colin Watson (cjwatson) wrote :

OK, though this is very surprising; typically, Unix-like operating systems are happier keeping the hardware clock in UTC, since that produces much more sensible results across DST changes. (The operating system is better at managing this than the BIOS is, and trying to have both of them manage it is a recipe for confusion!)

Colin Watson (cjwatson) wrote :

If you're unfamiliar with the reasons why keeping the hardware clock in local time is a bad idea, please read:

Colin Watson (cjwatson) wrote :

Actually, while I've made the change in revision control, I'm going to have to ask for more references, because I find it very unlikely that a Unix-like system would default to keeping the hardware clock in UTC when no other operating systems are involved; it's a terrible idea for mission-critical servers, which I thought were part of Solaris' target market. Could you please supply pointers to some documentation that says that this is the default for OpenSolaris, and ideally why it's the default?

Colin thank you so much for the reference on the hardware clock! I do appreciate having the bigger picture.

As for this statement: "I find it very unlikely that a Unix-like system would default to keeping the hardware clock in UTC when no other operating systems are involved": I'm not sure I follow you. Are you saying that in a single OS install you *would* expect the hardware clock set to local time? If so, then I *believe* it's doing what you expect.

Regardless, I've been using Linux far longer than Solaris/OpenSolaris, so I'm not the best person to answer your questions. I'll ask around. In the meantime, here are the contents of my /etc/rtc_config file *on a machine where no other operating systems are involved*:


# This file (/etc/rtc_config) contains information used to manage the
# x86 real time clock hardware. The hardware is kept in
# the machine's local time for compatibility with other x86
# operating systems. This file is read by the kernel at
# boot time. It is set and updated by the /usr/sbin/rtc
# command. The 'zone_info' field designates the local
# time zone. The 'zone_lag' field indicates the number
# of seconds between local time and Greenwich Mean Time.


Hypothetically, were I to now install Ubuntu on this system, OpenSolaris presumably is not going to suddenly realize it has company and switch to UTC. In this scenario, Ubuntu would not detect the other installed operating system and setting UTC=no in /etc/default/rcS. The end result is OpenSolaris would think it's 4 hours later and will continue to think that each time it is used after having booted into Ubuntu. Hence my filing this bug.

I hope I'm making some modicum of sense. :-) And thanks again for your help -- and for responding so quickly!

Colin Watson (cjwatson) wrote :

Sorry for the multiple negatives. Actually I'm saying the exact opposite: I'm saying that I would expect a Unix-like OS to keep the hardware clock in UTC when no other operating systems are involved. At the risk of belabouring the point, Unix-like operating systems simply work better with the hardware clock in UTC; system administrators tend to find this out every six months when daylight savings time switches on or off, especially if some of their systems happen to go down during the relevant window. (Of course the use of NTP works around some of these issues.)

It seems like OpenSolaris has made a serious mistake, but thanks for the information. I've unfortunately left it a bit late to change this for Ubuntu 8.10 now, but we can do it for 9.04.

Changed in clock-setup:
assignee: nobody → kamion
importance: Undecided → Medium
milestone: none → later
status: New → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package clock-setup - 0.97ubuntu1

clock-setup (0.97ubuntu1) jaunty; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Default to for the NTP server.
    - Ask the UTC question, defaulting to true, even if we appear to be the
      only OS (unless clock-setup/utc-auto is preseeded to true).
    - Add lpia to architecture list.
    - Fix rdate-udeb dependency to include the epoch.
    - Fix handling of progress bar cancellation.
  * Apparently OpenSolaris keeps the hardware clock in local time
    (surprisingly). Assume UTC=no if Solaris is detected (LP: #279065).

clock-setup (0.97) unstable; urgency=low

  [ Updated translations ]
  * Arabic (ar.po) by Ossama M. Khayat
  * Bosnian (bs.po) by Armin Besirovic
  * Welsh (cy.po) by Jonathan Price
  * Danish (da.po)
  * Greek, Modern (1453-) (el.po)
  * Esperanto (eo.po) by Felipe Castro
  * French (fr.po) by Christian Perrier
  * Croatian (hr.po) by Josip Rodin
  * Georgian (ka.po) by Aiet Kolkhi
  * Kurdish (ku.po) by Erdal Ronahi
  * Latvian (lv.po) by Peteris Krisjanis
  * Macedonian (mk.po) by Arangel Angov
  * Portuguese (Brazil) (pt_BR.po) by Felipe Augusto van de Wiel (faw)
  * Serbian (sr.po) by Veselin Mijušković
  * Ukrainian (uk.po) by Євгеній Мещеряков
  * Wolof (wo.po) by Mouhamadou Mamoune Mbacke
  * Traditional Chinese (zh_TW.po) by Tetralet

 -- Colin Watson <email address hidden> Wed, 05 Nov 2008 12:33:19 +0000

Changed in clock-setup:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers