[IOTG][TGL] Ubuntu Desktop Iso Installer crashed while installation

Bug #1952894 reported by Sachin Mokashi
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
intel
Fix Released
Undecided
Sachin Mokashi
Lookout-canyon-series
Fix Released
Critical
Unassigned

Bug Description

I tried to install the IOTG Ubuntu Desktop iso Image alongside an already existing Generic Ubuntu 20.04 Image and am running into an installer crash.
https://ubuntu.com/download/iot/intel-iotg

The error seems to be "grub-efi-amd64-signed" package failed to install to /target/.

Attaching screenshots herewith.

Revision history for this message
Sachin Mokashi (sachinmokashi) wrote :
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Hey! hm, I would need to get a bit more information here, since it's hard to guess what happened. On what platform did you attempt the installation? What is the partition layout? How was the existing Ubuntu system installed (was it installed in Legacy BIOS mode or UEFI mode?). Was the new Intel IOTG install done in UEFI mode?

I would also love to see some logs from a failed install like that. Maybe the best way would be to perform such an install using the live-session and gathering the installer logs from there.

Thanks.

Revision history for this message
Brian Murray (brian-murray) wrote :

Specifically, /var/log/syslog from the live-session would be useful.

Changed in intel:
status: New → Incomplete
Revision history for this message
Pierre Equoy (pieq) wrote :

@Sachin, if you need help gathering the data, just let me know.

What I usually do to gather logs is, after selecting "Install Ubuntu" from the Live USB, I press Ctrl+Alt+T to open a terminal, and there I can check the logs (for instance, you can run `journalctl -f` to have a real time feedaback about what's going on on the system, or you can `tail -f /var/log/syslog` for something similar). You can also plug another USB disk and copy logs over when you hit the problem you describe.

Changed in intel:
assignee: Pierre Equoy (pieq) → SACHIN MOKASHI (sachinmokashi)
Revision history for this message
Pierre Equoy (pieq) wrote :

@Sachin, by the way, the recommended method for installing Ubuntu on boards like this is to select "Erase disk and install Ubuntu", unless you have very specific needs (for instance, you need to run Ubuntu 18.04 generic next to this 20.04-Intel version).

Revision history for this message
ethan.hsieh (ethan.hsieh) wrote :
Revision history for this message
ethan.hsieh (ethan.hsieh) wrote :
Revision history for this message
ethan.hsieh (ethan.hsieh) wrote :

I can reproduce the issue on my Aaeon UPN-EHL01.

Here is my step:
1. Install stock Ubuntu desktop 20.04 image[1] on a empty disk.

The partition layout after installation:
mmcblk0
├─mmcblk0p1
└─mmcblk0p2

2. Install intel-iotg classic sprint3 image.
[v] Install Ubuntu alongside them

The partition layout during installation:
mmcblk0 179:0 0 58.2G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /target/boot/efi
├─mmcblk0p2 179:2 0 31.7G 0 part
└─mmcblk0p3 179:3 0 26G 0 part /target

Error message:
grub-installer[23573]: info: architecture: amd64/efi
grub-installer[23659]: info: Identified partition label for /dev/mmcblk0p3: gpt
ubiquity[23570]: The following NEW packages will be installed:
ubiquity[23570]: grub-efi-amd64-bin grub-efi-amd64-signed
ubiquity[23570]: E: Unable to locate package shim-signed
grub-installer[23777]: info: Calling 'apt-install grub-efi-amd64-signed' failed

Please see comment#6 & #7 for the detailed log.

---
Board: Aaeon UPN-EHL01
BIOS: UNEHAM0D 5.19
BIOS Release Date: 09/02/2021
---
[1] Ubuntu 20.04.3 LTS, https://ubuntu.com/download/desktop

Revision history for this message
Sachin Mokashi (sachinmokashi) wrote :

@sil200 @pieq

I tried a fresh install with "Erase disk and install Ubuntu" and still able to see the Installer crash.

I have tried it on both TGL and EHL platforms and the install is being done in UEFI Mode.

Here is the syslog attached. From the syslog, I see that it is trying to install few additional packages such as grub-efi-amd64-signed, as I dont have proxies configured on my Live Image I guess it fails. Its also unable to locate shim-signed package.

Sep 7 18:52:39 ubuntu ubiquity: The following additional packages will be installed:
Sep 7 18:52:39 ubuntu ubiquity: grub-efi-amd64-bin
Sep 7 18:52:39 ubuntu ubiquity: Recommended packages:
Sep 7 18:52:39 ubuntu ubiquity: efibootmgr
Sep 7 18:52:39 ubuntu ubiquity: The following NEW packages will be installed:
Sep 7 18:52:39 ubuntu ubiquity: grub-efi-amd64-bin grub-efi-amd64-signed
Sep 7 18:52:39 ubuntu ubiquity: 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Sep 7 18:53:10 ubuntu ubiquity: Need to get 1,211 kB of archives.
Sep 7 18:53:10 ubuntu ubiquity: After this operation, 12.5 MB of additional disk space will be used.
Sep 7 18:53:10 ubuntu ubiquity: Err:1 http://security.ubuntu.com/ubuntu focal-security/main amd64 grub-efi-amd64-bin amd64 2.04-1ubuntu44.2
Sep 7 18:53:10 ubuntu ubiquity: Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::15). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::18). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::23). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80
...
Sep 7 18:53:10 ubuntu ubiquity: E: Unable to locate package shim-signed
Sep 7 18:53:10 ubuntu grub-installer: info: Calling 'apt-install grub-efi-amd64-signed' failed

Please take a look at the complete syslog for more details.

@pieq Have you tried installing the Ubuntu Live Image without network connection?

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Hey! So the reason for both these failures seems to be network connectivity related. Is the same network configuration used for both installs?

The ubiquity installer might be a bit 'dumb' regarding network connectivity detection. IIRC the only check is to see if there is network connectivity - if yes, it tries to use it whenever needed. So for instance if you don't have a NIC or the ethernet cable is unplugged (or otherwise 'unaccessible'), ubiquity will only use what's on the CD. But if there is at least a hint of an accessible network, it will most probably use it to fetch any additional packages it needs.
Has the checkbox to use updates during installation been checked for those installs?

Still trying to better understand what's going on. I just now did a test install using KVM with UEFI enabled with and without network (emulating no network card on the VM) and both installations worked fine, both clean installs and overwriting existing Ubuntu installations. I used both the Ubuntu 20.04.3 generic image and the latest Ubuntu Intel IOT candidate image.

This makes me think that the reason of these errors is simply network configuration for where devices in question. Are those connected to network but have some firewall configuration that could block access to the Ubuntu archives?
If this is the case, there's not much we can do here - we could certainly improve how Ubiquity does things, but almost completely positive regular Ubuntu would have the same issue. And this is more of an edge case, if that's what is really happening.

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Actually, scratch that, I think I see something similar now. Need to investigate further!

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Ok, confirmed that his is a real issue with the images. After some digging deep into the build logs and debian-cd I think I have found the root of the problem. I'm still testing my fix as I'm not 100% sure that this is the real issue indeed, but I think think the problem is that the SUBARCH that we decided to use for Intel IOT is 'intel-iot', and this breaks one small piece of debian-cd that was not prepared for a '-' in the SUBARCH name. All of our subarches so far were always just plain alphanum characters. This seems to be a real stupid edge case related to C marcos. Running a test build to confirm if this is really it and if I was able to fix it with my changes.

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Ok, yes, so it seems the 'intel-iot' SUBARCH was causing issues once again. I deployed two quickfixes in ubuntu-cdimage and debian-cd that should help, rebuilt the image and locked it in here:

http://cdimage.ubuntu.com/focal/daily-live/20211202.2/

Could you give it a try? This should be good for release in case it fixes the issues. It seems this issue was with us since day 0 for the intel-iot ISO images. Hopefully this is the last thing broken by the '-' in the SUBARCH name (how could anyone have known this name choice was bad?).

Revision history for this message
Pierre Equoy (pieq) wrote (last edit ):

Image: http://cdimage.ubuntu.com/focal/daily-live/20211202.2/focal-desktop-amd64+intel-iot.iso
Device: Aaeon EHL
CID: 202109-29496
Secure Boot: Enabled

Test 1: No network connection, "Erase disk and install..."
==========================================================

None of the 2 Ethernet ports are connected.

Installation type: "Erase disk and install Ubuntu"
(the previous OS installed on this device was Ubuntu Core 20 with full disk encryption, therefore I had no other option).

Installation completes and I can login.

→ OK

Test 2: Connected to the Internet, "Erase and reinstall"
========================================================

Both Ethernet ports are connected to the Internet.

Installation type: "Erase Ubuntu 20.04.3 LTS and reinstall"

Warning message:

-----
The partition tables of the following devices are changed:
MMC/SD card #1 (mmcblk0)

The following partitions are going to be formatted:
partition #2 of MMC/SD card #1 (mmcblk0) as ext4
-----

(click Continue to proceed with installation)

Installation completes and I can login.

→ OK

Test 3: Connected to the Internet, "install alongside..."
=====================================================

Both Ethernet ports are connected to the Internet.

Installation type: "Install Ubuntu 20.04.3 LTS alongside Ubuntu 20.04.3 LTS"

Leaving proposed options by default:

Ubuntu 20.04.3 LTS on /dev/mmcblk0p2 (ext4) 34.3 GB
Ubuntu on /dev/mmcblk0p3 (ext4) 27.7 GB

Changes are applied on disk using resize2fs, then the "Write the changes to disks?" pop up appears, saying:

-----
The partition tables of the following devices are changed:
MMC/SD card #1 (mmcblk0)

The following partitions are going to be formatted:
partition #3 of MMC/SD card #1 (mmcblk0) as ext4
-----

(click Continue to proceed with installation)

Installation completes. At boot time, I can select between the two Ubuntu installations, and I can log into both.

→ OK

Test 4: No network connection, "install alongside..."
=====================================================

Both Ethernet ports are connected to the Internet.

The Install window mentions: "This computer currently has Ubuntu 20.04.3 LTS and Ubuntu 20.04.3 LTS (20.04) on it. What would you like to do?"

Installation type: "Install Ubuntu alongside them"

Leaving proposed options by default:

Ubuntu 20.04.3 LTS on /dev/mmcblk0p2 (ext4) 20.3 GB
Ubuntu on /dev/mmcblk0p3 (ext4) 14.0 GB

Changes are applied on disk using resize2fs, then the "Write the changes to disks?" pop up appears, saying:

-----
The partition tables of the following devices are changed:
MMC/SD card #1 (mmcblk0)

The following partitions are going to be formatted:
partition #4 of MMC/SD card #1 (mmcblk0) as ext4
-----

(click Continue to proceed with installation)

Installation completes. At boot time, I can select between the three Ubuntu installations, and I can log into all of them.

→ OK

Pierre Equoy (pieq)
tags: added: cqa-verified
Ana Lasprilla (anamlt)
information type: Private → Public
Changed in intel:
status: Incomplete → Fix Released
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.