Dell Optiplex 5080 SFF install issues

I have 2 issues here:

1. how do I access messages from check disk after boot, ideally a cumulative log of all boots

2. how can 20.04 require an update from 18.04

For diagnostic purposes please provide the output that you receive for the following commands (to be executed in a terminal window):

uname -a
lsb_release -crid
dmesg | grep blocks | grep files
apt list --upgradable
snap list

Manfred, as requested.

secret@mypc:~$ uname -a
Linux t5080 5.8.0-50-generic #56~20.04.1-Ubuntu SMP Mon Apr 12 21:46:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
secret@mypc:~$ lsb_release -crid
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
secret@mypc:~$ dmesg | grep blocks | grep files
secret@mypc:~$ apt list --upgradable
Listing... Done
libcaca0/focal-updates,focal-security 0.99.beta19-2.1ubuntu1.20.04.1 amd64 [upgradable from: 0.99.beta19-2.1ubuntu1]
N: There is 1 additional version. Please use the '-a' switch to see it
secret@mypc:~$ apt list --upgradable -a
Listing... Done
libcaca0/focal-updates,focal-security 0.99.beta19-2.1ubuntu1.20.04.1 amd64 [upgradable from: 0.99.beta19-2.1ubuntu1]
libcaca0/focal,now 0.99.beta19-2.1ubuntu1 amd64 [installed,upgradable to: 0.99.beta19-2.1ubuntu1.20.04.1]

secret@mypc:~$ snap list
Name Version Rev Tracking Publisher Notes
core18 20210309 1997 latest/stable canonical✓ base
gnome-3-34-1804 0+git.3556cb3 66 latest/stable/… canonical✓ -
gtk-common-themes 0.1-50-gf7627e4 1514 latest/stable/… canonical✓ -
snap-store 3.38.0-59-g494f078 518 latest/stable/… canonical✓ -
snapd 2.49.2 11588 latest/stable canonical✓ snapd
secret@mypc:~$

1. how do I access messages from check disk after boot, ideally a cumulative log of all boots
Are you referring to the message that is shown when booting, an that reads like
/dev/sda2: clean, 286631/6111232 files, 2586472/24413952 blocks ?

As far as I know this message is not stored any any file that can later be examined (for the file system check to run the hard disk partition has to be unmounted, and so there is no possibility to open a log file on this partition)

You do not need to bother about the exact text if id disappears quickly. In case that there would be an error during file system check that cannot be repaired automatically, the system would pause to show it.

2. how can 20.04 require an update from 18.04
I think this is a misinterpretation of the message.
On a standard Ubuntu 20.04 installation there are two snap files that have "18" or "1804"in their name. They have been introduced with Ubuntu 18.04 and have not received a big upgrade, and so they have kept their name.
Your system seems to be already running a fully upgraded version of 20.04 (except the single package that has been updated recently and that you have not yet installed in the newest version).

After a clean (erasing 18.04) installation of 20.04, the first boot produced one (1) check disk error.

Thereafter, each boot has messages that flash by so fast I cannot read them.

Where can I consult these messages?

By the way, the first 2 lines in /var/log/boot.log after the initial date time stamp are:
volume group ubuntu not found
cannot process volume group vgubuntu

Is this ok?

As for the Core 18 message, would a screenshot help?

I do not remember seeing this update in all prior installs of 20.04, could I be forgetting?

>Where can I consult these messages?

Is there a way to pause the screen?

"volume group ubuntu not found"
Did you select using volume groups when doing the new installation?

"Is there a way to pause the screen?"
You can try ctrl-s/ctrl-q

I selected fully encrypted drive, option LV if memory serves.

If I understand correctly, the first and only check disk error where the screen paused was auto corrected.

Thereafter, the check disk messages fly by so quickly at subsequent boots that everything is ok.

What about Core 18? Do you recommend executing this update for 20.04?

"volume group ubuntu not found"
It seems to me that something must have gone wrong when configuring LVM and disk encryption.

Maybe the commands pvdisplay, vgdisplay and lvdisplay help identifying what's wrong.

"What about Core 18? Do you recommend executing this update for 20.04?"
I do not see any pending update in your last output. Can you copy/paste the output where you see such update?

What is the output of
snap refresh --list

secret@mypc:~$ sudo pvdisplay
[sudo] password for secret:
  --- Physical volume ---
  PV Name /dev/mapper/nvme0n1p3_crypt
  VG Name vgubuntu
  PV Size <475.71 GiB / not usable 0
  Allocatable yes (but full)
  PE Size 4.00 MiB
  Total PE 121781
  Free PE 0
  Allocated PE 121781
  PV UUID qzKVd3-Uoh7-jlvz-SWt1-WDKv-tpGG-QYMe5b

secret@mypc:~$ sudo vgdisplay
  --- Volume group ---
  VG Name vgubuntu
  System ID
  Format lvm2
  Metadata Areas 1
  Metadata Sequence No 3
  VG Access read/write
  VG Status resizable
  MAX LV 0
  Cur LV 2
  Open LV 2
  Max PV 0
  Cur PV 1
  Act PV 1
  VG Size <475.71 GiB
  PE Size 4.00 MiB
  Total PE 121781
  Alloc PE / Size 121781 / <475.71 GiB
  Free PE / Size 0 / 0
  VG UUID Kb7dvd-fWXP-ZTmd-qHf7-MnZa-HhpA-nEyYjT

secret@mypc:~$ sudo lvdisplay
  --- Logical volume ---
  LV Path /dev/vgubuntu/root
  LV Name root
  VG Name vgubuntu
  LV UUID pgZ2ZQ-VUXl-opkE-l2Kx-O4fS-E7PW-JvWB7F
  LV Write Access read/write
  LV Creation host, time ubuntu, 2021-04-19 16:26:35 -0400
  LV Status available
  # open 1
  LV Size 474.75 GiB
  Current LE 121536
  Segments 1
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device 253:1

  --- Logical volume ---
  LV Path /dev/vgubuntu/swap_1
  LV Name swap_1
  VG Name vgubuntu
  LV UUID W6pENS-jN2b-draJ-HPVY-dbE2-O20y-DztCnn
  LV Write Access read/write
  LV Creation host, time ubuntu, 2021-04-19 16:26:35 -0400
  LV Status available
  # open 2
  LV Size 980.00 MiB
  Current LE 245
  Segments 1
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device 253:2

secret@mypc:~$ snap refresh --list
All snaps up to date.
secret@mypc:~$

The Core 18 pending update has disappeared. I have a screenshot of the original. I have emailed you for instructions on how to share a png file.

answers.launchpad.net does not allow image attachments.
If you have the need to post an image, you have to upload it to an image hosting service of your choice (e.g. imgbb.com, imgur.com, postimage.org, dropbox, ...) and post a link to it.

"the first 2 lines in /var/log/boot.log after the initial date time stamp are:
volume group ubuntu not found
cannot process volume group vgubuntu"

is the name mentioned in the message about volume group "ubuntu" or "vgubuntu"?

Here is the link to the screenshot of the Core 18 update which is no longer available:

https://www.dropbox.com/s/ntc3h261nl74cv4/Screenshot%20from%202021-04-19%2016-51-50.png?dl=0

ctrl-s/ctrl-q either does not work or my timing is off.

The check disk messages fly by too quickly to tell if the volume group is "ubuntu" or "vgubuntu".

The "core 18" update is already installed on your system. Look at the details of the "snap list" command, they show that version number.

And for the file system check message: if you can't pinpoint the message that is shown (might be an information message, a warning or an error), there is not much what we can do.

As already written earlier: If booting continues, then it cannot be a severe error.

What you could do is booting a live system from an installer DVD or USB stick in the "try Ubuntu without installing" mode and performing full file system checks on all file systems.

I get the following messages after booting Ubuntu 20.04.1 from a USB key:

https://www.dropbox.com/s/a04c1a2jh9vs2ln/20210422_103958.jpg?dl=0
- note the Firmware Bug

https://www.dropbox.com/s/5td1vy52q9xwh84/20210422_103426.jpg?dl=0
- that one error message is the same one I got during OS installation

The first issue looks serious.

The second is reproducible during each boot from a USB key, not hard drive.
I suspect the issue is with the USB key, but cannot prove it.

When I boot from a USB drive into trial mode and run fsck, this is the output:

ubuntu@ubuntu:~$ fsck --help

Usage:
 fsck [options] -- [fs-options] [<filesystem> ...]

Check and repair a Linux filesystem.

Options:
 -A check all filesystems
 -C [<fd>] display progress bar; file descriptor is for GUIs
 -l lock the device to guarantee exclusive access
 -M do not check mounted filesystems
 -N do not execute, just show what would be done
 -P check filesystems in parallel, including root
 -R skip root filesystem; useful only with '-A'
 -r [<fd>] report statistics for each device checked;
            file descriptor is for GUIs
 -s serialize the checking operations
 -T do not show the title on startup
 -t <type> specify filesystem types to be checked;
            <type> is allowed to be a comma-separated list
 -V explain what is being done

 -?, --help display this help
     --version display version

See the specific fsck.* commands for available fs-options.
For more details see fsck(8).
ubuntu@ubuntu:~$ fsck -A -N -r -V
fsck from util-linux 2.34
Checking all file systems.
ubuntu@ubuntu:~$

Is there some log file somewhere than contains more info?

>I suspect the issue is with the USB key, but cannot prove it.

When you pay close attention to the check disk process, near the end, a file name is displayed for much longer than any other.

This file name is ./casper/filesystem.squashfs and is clearly on the USB key.

So the check disk issue appears to be settled.

When I try the test of the previous paragraph with the newer 20.04.2.0 USB key, I get variable results:

The boot process may hang. It can hang at different stages of progress (check disk or later).

The Firmware Bug of 20.04.1 occurs in 20.04.2.0, but only lines 2 and 3.

If nothing hangs, then I can get the GUI desktop.

I am a bit lost. What is now the open question?
If you have Ubuntu already installed on the hard disk, why do you need to boot the installer from an USN stick again and again?

typo error, read USB instead of USN

The one (1), initial, at install time, check disk error appears to be generated by the USB key itself, and not the hard drive.
If you agree with the evidence presented, then the check disk aspect of this case is closed.

The Core 18 issue is also closed, as you presented previously.

The USB boot test results from the more recent 20.04.2.0 are worrisome, but presented for info only. Should I submit a separate bug report?

During all these tests, a Firmware Bug appears to be present (para 16). Should I submit a separate bug report?

You suggested a run of fsck in para 15 which was done in para 17. The results are unclear. Please clarify.

The dropbox images in comment #16 - what did you do to see this on the screen? Boot from hard disk or from the installer?
Is this repeatable?
What happens afterwards?

For a real fdisk command execution you should should give the name of the file system device and not the -N option

>The dropbox images in comment #16 - what did you do to see this on the screen?

Nothing to do, you just get these messages.

>Boot from hard disk or from the installer?

USB installer, booting into trial mode.

>Is this repeatable?

Yes.

>What happens afterwards?

The boot process continues.
In the entire boot, trial, shutdown process, you get the Firmware Bug screen at least once more.
Curiously, I cannot detect any consequences of this.
Do bear in mind this PC is currently naked, nothing installed, no current use other than testing.

>For a real fdisk ... not the -N option

In para 15, you suggest: performing full file system checks on all file systems

My understanding is that fsck is the correct command to use for this case.
To be prudent, I started with -N and then left it out. It makes no difference.
I get no visible output.
Is there a hidden log file somewhere? Please clarify.

The output that you have provided let me assume that there is something wrong with the installer iso file. Did you verify the checksum after downloading?

Is the hard disk of the PC already set up with a partition table and partitions?
If not, then there is nothing that can be fsck-ed.
Maybe I misinterpreted one of your outputs as coming from the hard disk, although it wasn't.

>Did you verify the checksum after downloading?

Of course, always, this is standard routine.
However, the evidence clearly shows a check disk error with each (of the many) boots with the USB key.

>Is the hard disk of the PC already set up with a partition table and partitions?

secret@mypc:~$ sudo fdisk -l
[sudo] password for secret:
Disk /dev/loop0: 54.98 MiB, 57626624 bytes, 112552 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop1: 64.79 MiB, 67915776 bytes, 132648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop2: 29.9 MiB, 31334400 bytes, 61200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop3: 255.58 MiB, 267980800 bytes, 523400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop4: 49.8 MiB, 52203520 bytes, 101960 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop5: 55.46 MiB, 58142720 bytes, 113560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop6: 51.4 MiB, 53522432 bytes, 104536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop7: 32.28 MiB, 33841152 bytes, 66096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/nvme0n1: 476.96 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: PM9A1 NVMe Samsung 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 22A1F0AD-05A8-41D8-BDA5-9FE866628E77

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 2549759 1499136 732M Linux filesystem
/dev/nvme0n1p3 2549760 1000214527 997664768 475.7G Linux filesystem

Disk /dev/mapper/nvme0n1p3_crypt: 475.73 GiB, 510787584000 bytes, 997632000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vgubuntu-root: 474.77 GiB, 509758930944 bytes, 995622912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vgubuntu-swap_1: 980 MiB, 1027604480 bytes, 2007040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop8: 65.1 MiB, 68259840 bytes, 133320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop9: 218.102 MiB, 229629952 bytes, 448496 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
secret@mypc:~$

The fsck command should, in theory, return results for this drive if I boot with USB into trial.

I tried to run fsck on the USB key.

The command does not appear to return output. Can you help?

sudo umount /dev/x
sudo fsck /dev/x

Look at the man pages for fsck and e2fsck
If the partition is "clean", then fsck will usually do nothing, except with the option -f

Before running anything final, please consider these results:

secret@mypc:~$ fsck --help

Usage:
 fsck [options] -- [fs-options] [<filesystem> ...]

Check and repair a Linux filesystem.

Options:
 -A check all filesystems
 -C [<fd>] display progress bar; file descriptor is for GUIs
 -l lock the device to guarantee exclusive access
 -M do not check mounted filesystems
 -N do not execute, just show what would be done
 -P check filesystems in parallel, including root
 -R skip root filesystem; useful only with '-A'
 -r [<fd>] report statistics for each device checked;
            file descriptor is for GUIs
 -s serialize the checking operations
 -T do not show the title on startup
 -t <type> specify filesystem types to be checked;
            <type> is allowed to be a comma-separated list
 -V explain what is being done

 -?, --help display this help
     --version display version

See the specific fsck.* commands for available fs-options.
For more details see fsck(8).
secret@mypc:~$ sudo umount /dev/sda1
[sudo] password for secret:
secret@mypc:~$ sudo umount /dev/sda3
secret@mypc:~$ fsck -M -N -r -V /dev/sda1
fsck from util-linux 2.34
/dev/sda1 is not mounted
[/usr/sbin/fsck.ext2 (1) -- /dev/sda1] fsck.ext2 /dev/sda1
secret@mypc:~$ fsck -M -N -r -V /dev/sda3
fsck from util-linux 2.34
/dev/sda3 is not mounted
[/usr/sbin/fsck.ext2 (1) -- /dev/sda3] fsck.ext2 /dev/sda3
secret@mypc:~$

secret@mypc:~$ e2fsck -help
e2fsck: invalid option -- 'h'
Usage: e2fsck [-panyrcdfktvDFV] [-b superblock] [-B blocksize]
  [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
  [-E extended-options] [-z undo_file] device

Emergency help:
 -p Automatic repair (no questions)
 -n Make no changes to the filesystem
 -y Assume "yes" to all questions
 -c Check for bad blocks and add them to the badblock list
 -f Force checking even if filesystem is marked clean
 -v Be verbose
 -b superblock Use alternative superblock
 -B blocksize Force blocksize when looking for superblock
 -j external_journal Set location of the external journal
 -l bad_blocks_file Add to badblocks list
 -L bad_blocks_file Set badblocks list
 -z undo_file Create an undo file
secret@mypc:~$ sudo e2fsck -n -f -v /dev/sda1
[sudo] password for secret:
e2fsck 1.45.5 (07-Jan-2020)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sda1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

/dev/sda1 contains a iso9660 file system labelled 'Ubuntu 20.04.1 LTS amd64'
secret@mypc:~$ sudo e2fsck -n -f -v /dev/sda3
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

         460 inodes used (0.06%, out of 807840)
          59 non-contiguous files (12.8%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 447/5
       81238 blocks used (2.52%, out of 3227392)
           0 bad blocks
           1 large file

         307 regular files
         144 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
         451 files
secret@mypc:~$

What would you suggest?

What was the starting point for all those fsck checks?
It is was https://www.dropbox.com/s/5td1vy52q9xwh84/20210422_103426.jpg?dl=0 then fsck most probably is the wrong tool.
In that case https://askubuntu.com/a/547369 could be the right procedure for verifying.

The starting point for all those fsck checks is the umount of the 2 devices (Ubuntu 20.04.1 LTS amd64, writeable) associated with the one USB key.

secret@mypc:~$ sudo umount /dev/sda1
[sudo] password for secret:
secret@mypc:~$ sudo umount /dev/sda3

The md5sum of the ISO was verified right after download, as per normal practice.

My understanding of the one check disk error is that it refers to the USB drive, not the hard drive. When you boot from the hard drive, you do not get this one (1) check disk error.

So the USB drive may require fixing. Do you agree?

My interpretation of your output is that there is something wrong with the contents of the USB drive. Specifically not a file system error, but something with the contents.

The fsck output talks about blocks, inodes, directory structure and reference counts, but your dropbox image clearly tells "error found in 1 files". This is different wording.

What do you receive when you mount the USB device, open a terminal window, cd into that directory and execute the command
md5sum -c md5sum.txt
see https://askubuntu.com/a/547369

./boot/grub/efi.img: FAILED

I have downloaded another copy of 20.04.1 from

http://old-releases.ubuntu.com/releases/20.04.1/

and checked the sha256sum and md5sum -c md5sum.txt and everything is ok.

As a final test, I have booted with the newly created USB key and there are no check disk errors. So I reinstalled the OS onto the hard drive.

--- *** ---

However, the Firmware Bug and TPM issues persist only with boot from the USB key, not the hard drive. Any thoughts on this.

By the way, there are 8 TPM chip error lines in
https://www.dropbox.com/s/a04c1a2jh9vs2ln/20210422_103958.jpg?dl=0

There are 8 physical cores (and 8 more HT) in this 10th Generation Intel Core i7-10700 (8-Core, 16MB Cache, 2.9GHz to 4.8GHz, 65W)

Is it possible that, upon boot, the USB key cannot handshake with the TPM chip because it is deemed not trustworthy?

That could explain the TPM messages from USB key boot.

There are no such messages from hard drive boot because it is deemed to be trustworthy.

Do you agree?

I do not have enough knowledge about TPM to give an answer

Manfred,

I would like to take this opportunity to thank you for your superlative support.

This case is now closed.