[Impish Beta][arm64] installer has python traceback

Bug #1945012 reported by Taihsiang Ho
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
subiquity
Undecided
Unassigned
subiquity (Ubuntu)
Undecided
Unassigned

Bug Description

iso: impish beta http://cdimage.ubuntu.com/releases/21.10/beta/ubuntu-21.10-beta-live-server-arm64.iso
hardware: taishan2280v2 (kreiken)

== Steps to Reproduce ==
1. Boot impish beta with the iso (via vMedia of BMC)
2. subiquity shows up. Answer questions.

== Expected Result ==
I can walk through all questions

== Actual Result ==
Traceback shows up (maybe in right after answering locale or right before block device detection) and the installer prompt re-spawns.

=== message snippet from /var/log/installer/subiquity-server-debug.log.3844 of the installer shell ===

After the installer prompt re-spawned, I use "Enter shell" to dump the log shown below.

2021-09-24 19:09:59,880 INFO root:39 finish: subiquity/Meta/client_variant_POST: SUCCESS: 200 null
2021-09-24 19:09:59,881 INFO aiohttp.access:206 [24/Sep/2021:19:09:59 +0000] "POST /meta/client_variant?variant=%22server%22 HTTP/1.1" 200 195 "-" "Python/3.6 aiohttp/3.7.4.post0"
2021-09-24 19:09:59,882 INFO root:39 start: subiquity/Meta/status_GET:
2021-09-24 19:09:59,883 DEBUG root:39 start: subiquity/Locale/GET:
2021-09-24 19:09:59,883 DEBUG root:39 finish: subiquity/Locale/GET: SUCCESS: 200 "en_GB.UTF-8"
2021-09-24 19:09:59,883 INFO aiohttp.access:206 [24/Sep/2021:19:09:59 +0000] "GET /locale HTTP/1.1" 200 205 "-" "Python/3.6 aiohttp/3.7.4.post0"
2021-09-24 19:10:00,123 INFO root:39 finish: subiquity/Meta/status_GET: SUCCESS: 500 Traceback (most recent call last):
  File "/snap/subiquity/2654/lib/python3.6...
2021-09-24 19:10:00,124 DEBUG subiquity.server.server:369 request to /meta/status?cur=%22ERROR%22 crashed
Traceback (most recent call last):
  File "/snap/subiquity/2654/lib/python3.6/site-packages/subiquity/common/api/server.py", line 123, in handler
    result = await implementation(**args)
  File "/snap/subiquity/2654/lib/python3.6/site-packages/subiquity/server/server.py", line 87, in status_GET
    await self.app.state_event.wait()
  File "/snap/subiquity/2654/usr/lib/python3.6/asyncio/locks.py", line 283, in wait
    yield from fut
concurrent.futures._base.CancelledError
2021-09-24 19:10:00,124 ERROR aiohttp.server:393 Error handling request
Traceback (most recent call last):
  File "/snap/subiquity/2654/lib/python3.6/site-packages/aiohttp/web_protocol.py", line 422, in _handle_request
    resp = await self._request_handler(request)
  File "/snap/subiquity/2654/lib/python3.6/site-packages/aiohttp/web_app.py", line 499, in _handle
    resp = await handler(request)
  File "/snap/subiquity/2654/lib/python3.6/site-packages/aiohttp/web_middlewares.py", line 119, in impl
    return await handler(request)
  File "/snap/subiquity/2654/lib/python3.6/site-packages/subiquity/server/server.py", line 375, in middleware
    ErrorReportRef, report.ref())
AttributeError: 'NoneType' object has no attribute 'ref'

ProblemType: Bug
DistroRelease: Ubuntu 21.10
ProcVersionSignature: Ubuntu 5.13.0-16.16-generic 5.13.13
Uname: Linux 5.13.0-16-generic aarch64
ApportVersion: 2.20.11-0ubuntu69
Architecture: arm64
CasperMD5CheckResult: unknown
Date: Fri Sep 24 19:15:55 2021
Snap: subiquity 21.08.2 ()
Symptom: installer
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Taihsiang Ho (taihsiangho) wrote :
description: updated
Revision history for this message
Taihsiang Ho (taihsiangho) wrote :

I tried to pxe installation by following this steps https://discourse.ubuntu.com/t/netbooting-the-live-server-installer-via-uefi-pxe-on-arm-aarch64-arm64-and-x86-64-amd64/19240 and it brought up similar error.

Reproducing rate: 5 out of 5.

Revision history for this message
Taihsiang Ho (taihsiangho) wrote :

I used maas 2.9 snap (2.9.3~beta2 (9200-g.43e4a0607) to deploy the same machine, and it could successfully deploy.

Revision history for this message
Dan Bungert (dbungert) wrote :

Are you able to attach the full /var/log/installer/subiquity-server-debug.log file?

Revision history for this message
Taihsiang Ho (taihsiangho) wrote :

@dbungert did you suggest any way to pull full /var/log/installer/subiquity-server-debug.log ?

I tried scp (to copy the target to my local) and pastebinit (to upload the log file), but they both did not manage to do it. I could only remotely access the machine.

Paul White (paulw2u)
affects: ubuntu → subiquity (Ubuntu)
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Someone (tm) should try to figure out what's going on here.

Revision history for this message
Taihsiang Ho (taihsiangho) wrote :

I think I could collect the log via the console message redirection. I will update the information later on.

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1945012

tags: added: iso-testing
Revision history for this message
Dan Bungert (dbungert) wrote :

I normally copy out with scp from the installation environment to another computer, but it sounds like you tried to do something similar.

Revision history for this message
Taihsiang Ho (taihsiangho) wrote :

I did not manage to reproduce this issue with both iso (2 out of 2 passed via vMedia) and pxe (1 out of 1 passed) installation.

My hypothesis:
The boot process on the day I raised this issue at the bios stage of my machine (kreiken) is much slower than today, and it (the bios) seemed to check some usb block device several times. I did not notice this kind of usb block device bios check today. Maybe a flaky block device was re-formatted later for maas deployment or something, so subiquity is happy with the block device. Or the block device is just dead, so the block detection simply ignores to use it.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

So you're OK to close this bug? Tracebacks are bad but we can't gracefully handle all misbehaving hardware...

Changed in subiquity:
status: New → Incomplete
Changed in subiquity (Ubuntu):
status: New → Incomplete
Revision history for this message
Taihsiang Ho (taihsiangho) wrote :

Hi Michael. Yes I am OK. Thank you for your time and effort! I will re-open the issue and provide more comprehensive log files when the issue shows up again. Please feel free to close it now. Thanks!

Changed in subiquity:
status: Incomplete → Invalid
Changed in subiquity (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers