TeraByte Unlimited

My NVMe boot drive had a partition with an existing Ubuntu 18.04.5 installation.
System is UEFI.
Yesterday I created another partition and installed the just-released Ubuntu 20.04.1 to it.

I used a single partition plan. Root and everything else in the same partition.
Current versions of Ubuntu do not require a swap partition.
A swap file in root can be used instead.
I have used a swap file to simplify partition plan of my boot drive.
Also, it keeps Ubuntu neatly in a single partition.

The Ubuntu installer was directed to use newly created partition for root.
Installer was directed to put EFI boot loader in the same partition.

Install went smoothly. Boot item I created that is directed to find boot loader in /boot/grub/x86_64-efi/ boots the system very nicely, thank you very much. EFI partition has new ubuntu.002 listing.

But. During the install process the Ubuntu installer detected the existing Ubuntu 18.04.5 OS.
This has resulted in a grub splash screen appearing for a few seconds.
After it times out I see the mobo splash screen (as expected) after which the 20.04.1 login screen appears.

The grub screen reads like this:
GNU GRUB version 2.04
- Ubuntu [this is the default option that times out to desired OS boot]
- Advanced options for Ubuntu
- Ubuntu 18.04.5 LTS (18.04) (on /dev/nvme0n1p5)
- UEFI Firmware Settings

Is that what should have happened?
While it is not much of an impost to wait for a few seconds or hit enter to proceed to normal boot, is there any way of getting rid of this splash screen?

Radiogram wrote:

> While it is not much of an impost to wait for a few seconds or hit enter to
> proceed to normal boot, is there any way of getting rid of this splash
> screen?

Radiogram,

Open a Terminal
sudo nano /etc/default/grub

Change the GRUB_TIMEOUT to

GRUB_TIMEOUT=0.1

Save it

Then
sudo update-grub

Restart. Did it work?

Is your clock reading AEST in Windows?

Thanks Brian, that did the trick first time.

Re system clock: From the date of commissioning this system onwards, on the rare occasions when I dip back into Win10 I have noticed the clock is out of whack by a long way.
If I stay in Win10 long enough with internet connected the OS adjusts system clock to correct AEST time.
When returning to Ubuntu of course its clock is then wrong by a big margin.
To correct it quickly I have used:

sudo chronyd -q

Have to install chrony first, it is not natively installed.

I have seen mentions of the system clock difference between Win10 and Ubuntu 18.04 in forums or somewhere, don't recall precisely, but have never followed it up.
Thought it was another of those ne'er the twain shall meet issues.

Are you aware of a way to fix it?

Updating my mobo's UEFI 'bios' and Intel ME drivers this week didn't make any difference.

I had a look at Win10 just now.

Time given was 3:05 AM. Only 10 hours out.

In the relevant part of Win10 where time and date is adjusted time zone was:
(UTC +10:00) Canberra, Melbourne, Sydney

That's how I set it.
NFI why it goes out of whack after visits to Ubuntu.

Your Windows time is UTC due to Linux.Whenever you install a new Linux, do this from a Terminal...

timedatectl set-local-rtc 1

I plugged that command into a search engine.
Read a couple of the articles the search pulled.

One explained that maintaining the real time clock (RTC) to local time causes problems with time zone changes and daylight saving.

Sure enough, after I entered the command in terminal the system produced this notice:
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.

I think I'll leave it as:
timedatectl set-local-rtc 0

The way things are doesn't yet cause me any problems.
Today when I visited Win10 to check its time the OS reset it to correct time after a minute or so.

I appreciate that not all systems are the same.
Having the time that far out of whack would likely play havoc with your scripts.

I've used...

timedatectl set-local-rtc 1

...with dozens of Linus OS in multi-boot situations and I've never had an issue with "time". The Windows OS was the main OS.

I'm in Ubuntu for hours every day.
Win10 presently plays only a bit part in my computing needs.

You say you've never had any trouble changing Ubuntu systems to:
timedatectl set-local-rtc 1

I'll give it a shot and see how it works out.
If I get trouble, or if Ubuntu doesn't make the shift to from AEST to AEDT I know how to change it back.

Do you think chronyd -q would reset time to AEDT if required with RTC in use?