Installation fails if clock is in the past on ubuntu-keyring install

Bug #13881 reported by Stuart Langridge
6
Affects Status Importance Assigned to Milestone
ubuntu-keyring (Ubuntu)
Fix Released
High
Michael Vogt

Bug Description

Installing from hoary Array 6 on a brand new laptop, the installation failed
when trying to install initrd-tools. VC3 showed that the actual problem was
ubuntu-base not installing because it depends on ubuntu-keyring, and
ubuntu-keyring didn't install because the keys in it were in the future. It
turned out that the hardware clock was in the past (set to Jan 1 2004; this was
a brand new laptop, and I didn't boot the Windows XP install on it first, I just
deleted it from the Ubuntu installation screens :)) and so that's why the keys
were in the future.

This entirely breaks installation from array 6 (and possibly subsequent
installs) in the above circumstance, hence the "major" severity.

Possible fixes:
Make ubuntu-keyring more tolerant of future-signed keys, but that might be a
problem in general
*If* ubuntu-keyring fails to install because keys are in the future, check with
the user that the clock is set right, and reinstall.

I don't know whether this is actually a bug in ubuntu-keyring-udeb -- is that
what the installer uses? If it is, implementing possible fix 1 above may be
easier, since it can be implemented in the udeb only?

It's possible that if the network was working, the correct time would have been
set from an NTP server, but the network wasn't working at this point.

Revision history for this message
Matt Zimmerman (mdz) wrote :

wrong finger-macro...

Revision history for this message
Michael Vogt (mvo) wrote :

I think we should fix that by ignoring time conflicts on apt-key update.
(if Matt has no security objections, of course).

Revision history for this message
Seb Wills (sebwills) wrote :

Just to confirm that this bug is present on the hoary preview release, and
occurs even if network was present during install. I just had the same problem
installing on a new PC.

Wouldn't a better idea be to give the user the opportunity to set the clock if
it "seems likely to be wrong" (e.g. prior to, or more than 18 months beyond, the
release date)? Otherwise the files the installer creates on the disk will be
timestamped with whatever random date the BIOS has in it, which is kind of ugly.

Revision history for this message
Michael Vogt (mvo) wrote :

This bug is fixed in the current hoary version

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.