Cavium CRB1S device probing fails

Bug #1848345 reported by dann frazier
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
subiquity
Fix Released
Undecided
Unassigned

Bug Description

The 20191015.1 live server ISO reported a device probing failure on a Cavium/Marvell CRB1S (arm64):

 Unfortunately probing for devices to install to failed. Please report a bug
 on Launchpad, and if possible include the contents of the /var/log/installer
 directory.

Tags: iso-testing
Revision history for this message
dann frazier (dannf) wrote :
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/1848345

tags: added: iso-testing
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

can i get console on it?

it looks odd

1) networking appears to be broken, times out a lot, and fails to resolve URLs and connect to them

2) disk probing appears to time out, which is odd too.

Revision history for this message
dann frazier (dannf) wrote : Re: [Bug 1848345] Re: Cavium CRB1S device probing fails

On Wed, Oct 16, 2019 at 9:40 AM Dimitri John Ledkov
<email address hidden> wrote:
>
> can i get console on it?
>
> it looks odd
>
> 1) networking appears to be broken, times out a lot, and fails to
> resolve URLs and connect to them

One thing that maybe different about this test vs. our other ARM
server tests is that this server is in a lab behind a proxy.

> 2) disk probing appears to time out, which is odd too.

The boot media is a virtual DVD emulated by a BMC java applet running
across a VPN. This obviously adds latency, not sure if it would be the
timeout source.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Why don't you netboot instead of using DVD?

1) extract initrd & linux from the .iso

2) boot using cmdline:

ip=dhcp url=http://url-to-the-iso/that/matches/initrd/linux/filename.iso

.... or any other netbooty way (ie. uefi secureboot http boot etc)

Revision history for this message
dann frazier (dannf) wrote :

On Wed, Oct 16, 2019 at 11:00 AM Dimitri John Ledkov
<email address hidden> wrote:
>
> Why don't you netboot instead of using DVD?
>
> 1) extract initrd & linux from the .iso
>
> 2) boot using cmdline:
>
> ip=dhcp url=http://url-to-the-iso/that/matches/initrd/linux/filename.iso
>
> .... or any other netbooty way (ie. uefi secureboot http boot etc)

We created a set of test cases with mixed platform/boot method
combinations, and this one was a DVD one.

 -dann

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote : Re: [Bug 1848345] [NEW] Cavium CRB1S device probing fails

Can you run subiquity.probert in a shell and see if it completed slowly or
is really hanging?

On Thu, 17 Oct 2019, 03:10 dann frazier, <email address hidden> wrote:

> Public bug reported:
>
> The 20191015.1 live server ISO reported a device probing failure on a
> Cavium/Marvell CRB1S (arm64):
>
> Unfortunately probing for devices to install to failed. Please report a
> bug
> on Launchpad, and if possible include the contents of the
> /var/log/installer
> directory.
>
> ** Affects: subiquity
> Importance: Undecided
> Status: New
>
> ** Attachment added: "installer.tgz"
>
> https://bugs.launchpad.net/bugs/1848345/+attachment/5297504/+files/installer.tgz
>
> --
> You received this bug notification because you are subscribed to
> subiquity.
> https://bugs.launchpad.net/bugs/1848345
>
> Title:
> Cavium CRB1S device probing fails
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/subiquity/+bug/1848345/+subscriptions
>

Revision history for this message
dann frazier (dannf) wrote :

On Wed, Oct 16, 2019 at 1:45 PM Michael Hudson-Doyle
<email address hidden> wrote:
>
> Can you run subiquity.probert in a shell and see if it completed slowly or
> is really hanging?

Upon retrying, I'm unable to reproduce. At a shell, subiquity.probert took ~5s.

  -dann

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

Well the default timeout is 5s. I guess we should increase that a bit!

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

I increased the probe timeout to 15s for other reasons, so I think this should be fixed now. Please reopen if it's still a problem!

Changed in subiquity:
status: New → 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.