Ubuntu 18.04 installer failure related time synchronization issues on a DELL server

Bug #1779757 reported by leighann
58
This bug affects 12 people
Affects Status Importance Assigned to Milestone
subiquity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Tried to install Ubuntu server on an older Dell server, but it failed. I received the exact same errors that was posted in another thread (and I don't have a way to copy the failure log) so I am copying the details from https://answers.launchpad.net/ubuntu/+question/669976.

As in the other thread, there seemed to be a time synchronization issue:

"E: Release file for http://.../InRelease is not valid yet (invalid for another 1h 59min 50s)."

However, I checked the BIOS system time - it was correct. This seems like an installer bug in 18.04 LTS. I just installed 16.04.4 without issue, and will upgrade from there.

If I had to guess where this error is coming from, I would guess that it is related to the fact that this DELL machine encodes system time as packed BCE and the 18.04 LTS Ubuntu installer is decoding it as something else? But that is just my guess

- - - - - - - -
here are additional error details (copied from +question/669976.)

- got a python traceback from curthooks.py, which seems to be called by unshare.
- highlights:

Unexpected error while running command: unshare --fork --pid -- chroot /target apt-get --quiet --option=Acquire::Languages=none --option=Dir::Etc::sourcelist=/tmp/tmpk_vnogkp/sources.list --option=Dir::Etc::sourceparts=/tmp/tmpk_vnogkp/sources.list.d update

Exit code: 100

finish: cmd-install: FAIL: curtin command install

Traceback:
  File "/usr/lib/python3/dist-packages/curtin/commands/curthooks.py", line 191, in install_kernel
    map_suffix = mapping[codename][version]
KeyError: 'bionic'

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu:
status: New → Confirmed
Revision history for this message
Rick Cano (ledsole) wrote :

Seeing this on a Dell R720

Revision history for this message
Rick Cano (ledsole) wrote :

As a workaround, I wound up setting the BIOS clock time to match UTC which is the timezone that the installer was using. I was able to complete installation that way.

Revision history for this message
Evade Flow (evadeflow) wrote :

I just encountered this same problem while trying to install Ubuntu 18.04 on a server I inherited from another team. Unfortunately, its BIOS is password-protected and nobody knows the password, so... I had to find a different workaround. It turns out that—instead of changing the BIOS to store time in UTC—you can just change the system time to the (correct) UTC time.

To do this, I just hit CTRL + ALT + F2 near the beginning of the installation to bring up a terminal prompt, and then ran:

```
$ date
Wed Nov 21 11:36:20 UTC 2018
```

Note that it was *not* 11:36 am in Greenwich when I ran this, it was 11:36 am in Detroit(!) So I simply advanced the system time 5 hours by running:

```
$ sudo date --utc --set "Wed Nov 21 16:37:00 UTC 2018"
```

This was enough to trick the installer into thinking that the system time was correct, I guess, because the installation completed without a hitch after that. (I just fixed the system time manually afterwards...)

Revision history for this message
Evade Flow (evadeflow) wrote :

Adding this comment as a Note to Self, for future reference. I just had to reinstall Ubuntu 18.04 on the same server. This time, after setting the (Linux) system time using the `date` command, I then ran:

```
$ sudo hwclock --systohc
```

so that my local change would 'back-propagate' to the H/W clock.

I'm mentioning this because my previous comment implied such a thing was impossible, due to the BIOS being password-protected with a (lost/unknown) password. But 10 seconds of Googling cleared up that misconception. And—if you find yourself in this situation—it really doesn't make sense to NOT set the H/W clock, too...

Revision history for this message
Solio Sarabia (soliosg) wrote :

Also faced this issue with 18.04.1 installer.
Setting UTC time in BIOS (8 hours ahead of my time zone) as Rick pointed out allows installer to complete.

Revision history for this message
Robert Kulagowski (rkulagow-gmail) wrote :

I'm getting the same issue installing 18.04.2 Live Server onto a Dell R330; the BIOS time is local time. I'm going to try converting BIOS time to UTC and see if that allows installation to complete.

Revision history for this message
Robert Kulagowski (rkulagow-gmail) wrote :

Ditto - when I changed my BIOS time to UTC I was able to complete the install.

Revision history for this message
Scott Stubbs (sastubbs84) wrote :

Confirming this bug is still happening, was running into the same issue. After changing bios time to match current UTC time, I was able to get version 20.04.2 working.

Revision history for this message
Gastón (givanse) wrote :

ubuntu-21.04-live-server-amd64

I had to update the BIOS time to today's time and the installation was successful after.

Paul White (paulw2u)
affects: ubuntu → subiquity (Ubuntu)
tags: added: bionic focal hirsute
Revision history for this message
asavah (irherder) wrote (last edit ):

This bug has been open for 3 and a half years ...
Today I stumbled into this when installing ubuntu 20.04.3 on a brand new supermicro x11 series server.
I wasted 3 hours of my time until I found this bug report.

Subuguity and all this snap crap is unneeded and this is kinda unacceptable.

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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