QPC: All platforms are unstable #2121

Willsparker · 2021-04-13T08:47:08Z

Ref: https://ci.adoptopenjdk.net/job/QEMUPlaybookCheck/229/

With the latest QPC run, all platforms have failed to some degree. 4 have failed due calling buildJDK.sh in an incorrect way (incorrect as of #1962 ).

The risc-v platform is still blocked by #1483

And the arm32 platform seems to be running out of space during the playbook execution.

The text was updated successfully, but these errors were encountered:

Willsparker · 2021-04-13T10:15:21Z

Changes made to qemuPlaybookCheck.sh have been made to use the correct arguments (willsparker/2123_1). Testing on QPC at: https://ci.adoptopenjdk.net/job/QEMUPlaybookCheck/230/

Willsparker · 2021-04-15T09:18:20Z

The above PR should fix the buildJDK.sh issues. Once this has been merged, I'll look at running the arm32 box, to determine if there's still issues with the space.

Willsparker · 2021-04-27T08:53:19Z

The PR to fix the arguments has been merged, and it appears to be working on all platforms. For the S390x and ppc64le architectures, the linux.sh script fails for JDK8, as it is unable to find JDK7 on the machines (as Zulu-7 is not installed). I thought that they were meant to default then to using JDK8, but apparently not. This is not the case for JDK11, where I have had the build start on both machines (though currently, I've only managed a QPC run that had ppc64le fail (maybe due to the wrong version of gcc..?), and s390x that core dumped (maybe due to a bad jdk-10 install..?))

I'm going to look into that platform-specific-configuration script, to see if it's meant to set the boot jdk to the build jdk in cases wehre the boot jdk can't be found. If it isn't, I'll look into install zulu-7 on those platforms.

sxa · 2021-04-27T09:05:25Z

It can always be overriden with JDK7_BOOT_DIR if needed, but I know we've tried to let the autodetection work.
My preference is for it not to fall back if possible, since you then run the risk of being unsure whether from one build to the next it's used a JDK7 or JDK8 as the boot JDK. Our "real" CentOS/RHEL7 ppc64le and s390x build machines all use a true JDK7.

Willsparker · 2021-04-29T08:10:01Z

Okay! Thanks for the guidance. Looks like I'll have to adapt the Zulu-7 ansible task to include those platforms :-)

EDIT: Turns out no, this can't be done (see: https://adoptium.slack.com/archives/C53GHCXL4/p1619777906294700). Best case is having those platforms use JDK-8 to build

Willsparker · 2021-05-10T08:37:07Z

With #2176 (comment) , I think the last part of fixing the non RISC-V platforms is to figure out how to extend the build images, as they run out of space halfway through a build.

Willsparker · 2021-05-13T08:59:30Z

QEMU qcow2 images can be resized easily enough with
qemu-img resize $IMG +10G (if you wanted to add 10GB to it).
However, the partitions still need to be extended, which will be specific to the platform, and is likely to be a massive pain. Helpfully, I think all of the platforms that fail due to disk issues will fail in the build. Therefore, we could mount it as a new partition and just build on that one if it's that difficult.

EDIT: AH hang on, I've already documented all of this. Okay, just going to extend them by 10GB, and create a new partition on /home/linux that will have that extra 10GB. This method should be fine for all images that don't have a swap partitions. I'll create backups of the current images, just in case :-)

Willsparker · 2021-05-17T10:42:58Z

List of what I did to extend each of the images. After extending partitions, I'll re-compress the image with xz -z, and move the images into /home/jenkins/qemu_base_images/resized_images/, that way we still have backups of the old images

Debian10.aarch64.dsk :
Image is qcow2, so extend by running qemu img resize $IMAGE +10G

When logging into the machine, it automatically extended the root partition, which was lovely to see. So that has 25GB on it now.

Debian11.riscv.dsk:
qcow2 image, so same command as above.
This one has 10GB mounted on the root partition, and 5GB on /home/linux. So, I'll delete the /home/linux partition and create a new one in the same place, of size 15GB:

root@debian:~# lsblk
NAME   MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda    254:0    0  25G  0 disk 
|-vda1 254:1    0  10G  0 part /
`-vda2 254:2    0   5G  0 part /home/linux
root@debian:~# fdisk /dev/vda
Command (m for help): d
Partition number (1,2, default 2): 2

Partition 2 has been deleted.

Command (m for help): n
Partition number (2-128, default 2): 2
First sector (20971393-52428766, default 20971520): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (20971520-52428766, default 52428766): 

Created a new partition 2 of type 'Linux filesystem' and of size 15 GiB.
Partition #2 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: Y

The signature will be removed by a write command.
Command (m for help): w
The partition table has been altered.
Syncing disks.

root@debian:~# lsblk
NAME   MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda    254:0    0  25G  0 disk 
|-vda1 254:1    0  10G  0 part /
`-vda2 254:2    0  15G  0 part /home/linux

Debian8.Arm32.dsk:
Still a qcow2 image, so, as above

This ones a bit different, there's a lot more partitions:

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    254:0    0   30G  0 disk 
├─vda1 254:1    0  243M  0 part /boot
├─vda2 254:2    0  5.3G  0 part /
├─vda3 254:3    0    1K  0 part 
├─vda5 254:5    0  502M  0 part [SWAP]
└─vda6 254:6    0   14G  0 part /home

Unfortunately, I can't seem to find a way of extending the root partition, without the following error / issue on startup

[  155.371104] FS-Cache: Netfs 'nfs' registered for caching
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot into default mode.
[  155.698568] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Give root password for maintenance
(or type Control-D to continue):

I tried removing partitions 2-6, and recreating the / and /home partition, but the same issue occurs. I tried just removing the second and third partition, and it caused the rest of them to disappear as well. I'm going to skip this one for now, in the hopes that somebody else knows how to do this ( @sxa ...? 👀 )

Willsparker · 2021-05-18T11:00:17Z

Ubuntu1804.arm64.dsk:

The disk format is raw. I was able to extend it with qemu-img resize <> +10G though, and it is showing up in lsblk:

NAME                             MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                              252:0    0   30G  0 disk 
├─vda1                           252:1    0  512M  0 part /boot/efi
└─vda2                           252:2    0 19.5G  0 part 
  ├─ubuntu--18--arm64--vg-root   253:0    0 18.6G  0 lvm  /
  └─ubuntu--18--arm64--vg-swap_1 253:1    0  976M  0 lvm  [SWAP]

However, whenever I run any fdisk commands, I get
GPT PMBR size mismatch (41943039 != 62914559) will be corrected by w(rite)., which fails when I exit, with fdisk: failed to write disklabel: Invalid argument. For some reason, fdisk can't fix this, but parted can. Running parted -l will prompt a fix/ignore check. After this, I followed the instructions from this link - created a new partition with fdisk (called /dev/vda3) with the remaining space, created the physical volume pvcreate /dev/vda3, extended the volume group with vgextend /dev/ubuntu-18-arm64-vg /dev/vda3. From there, I extended the LV that was needed lvextend +2568 /dev/ubuntu-18-arm64-vg/root and resized it to the file system : resize2fs /dev/ubuntu-18-arm64-vg/root.
The result is:

root@ubuntu-18-arm64:~# lsblk
NAME                             MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                              252:0    0   30G  0 disk 
├─vda1                           252:1    0  512M  0 part /boot/efi
├─vda2                           252:2    0 19.5G  0 part 
│ ├─ubuntu--18--arm64--vg-root   253:0    0 28.6G  0 lvm  /
│ └─ubuntu--18--arm64--vg-swap_1 253:1    0  976M  0 lvm  [SWAP]
└─vda3                           252:3    0   10G  0 part 
  └─ubuntu--18--arm64--vg-root   253:0    0 28.6G  0 lvm  /

Which looks alright to me 👍

Ubuntu18.ppc64le.dsk:

Also uses LVM, and a raw disk image, so I'll do the same process as before, hopefully. Initial lsblk shows (after extending the disk):

NAME                 MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                    8:0    0   25G  0 disk 
├─sda1                 8:1    0    7M  0 part 
└─sda2                 8:2    0   15G  0 part 
  ├─linux--vg-root   253:0    0 14.3G  0 lvm  /
  └─linux--vg-swap_1 253:1    0  676M  0 lvm  [SWAP]
sr0                   11:0    1 1024M  0 rom

I wonder if sr0 there is going to cause issues ..
Nope, didn't seem to. Having followed the same instructions as before (and instructions on how to extend the LVM here):

root@linux:~# lsblk
NAME                 MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                    8:0    0   25G  0 disk 
├─sda1                 8:1    0    7M  0 part 
├─sda2                 8:2    0   15G  0 part 
│ ├─linux--vg-root   253:0    0 24.3G  0 lvm  /
│ └─linux--vg-swap_1 253:1    0  676M  0 lvm  [SWAP]
└─sda3                 8:3    0   10G  0 part 
  └─linux--vg-root   253:0    0 24.3G  0 lvm  /
sr0                   11:0    1 1024M  0 rom

Ubuntu18.S390x.dsk :

This one is a QCOW2 image, so same command as all of them. This one is also LVM, but for some reason, didn't require parted -l.

root@ubuntu:~# lsblk
NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                   252:0    0   25G  0 disk 
└─vda1                252:1    0   15G  0 part 
  ├─ubuntu--vg-root   253:0    0   14G  0 lvm  /
  └─ubuntu--vg-swap_1 253:1    0  964M  0 lvm  [SWAP]

After the same above process:

NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                   252:0    0   25G  0 disk 
├─vda1                252:1    0   15G  0 part 
│ ├─ubuntu--vg-root   253:0    0 24.1G  0 lvm  /
│ └─ubuntu--vg-swap_1 253:1    0  964M  0 lvm  [SWAP]
└─vda2                252:2    0   10G  0 part 
  └─ubuntu--vg-root   253:0    0 24.1G  0 lvm  /

I'm glad I/whoever setup the Ubuntu Images, had the foresight to make the partitions LVM :-)

Willsparker · 2021-05-19T08:40:09Z

With all but the Debian.ARM32 image extended, I'll swap the original images with the resized images to test on the vagrant server. I'm aware that now QPC can run on build-equinix-ubuntu2004-armv8-1, so I'll quickly reconfigure the job to just use the infra-ibmcloud-vagrant* machines for the time being. If all goes well, I'll move the images over :-)

See:
QPC#264

EDIT: Looks like the Debian ones failed - it looks like debian10/aarch64 didn't boot in time, and something else wrong with debian11/riscv64. Not too worried about RISCV, as it is currently running fine in QPC#263

Willsparker · 2021-05-20T07:52:15Z

Nope, I messed up the RISCV one - this happened 3 times now:

08:46:58 /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

08:46:59 /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

08:47:00 mkdir: cannot create directory '.ssh': Permission denied

I would assume in the process of extending the partition, the Linux user no longer owns their own home directory. Redid that, and tested here: QPC#267

It still looks like the Debian10/aarch64 one isn't booting in time. I'll try a local test where I extend the boot time to 180s, to see if this fixes it.

Bright side, both Ubuntu18/ppc64le and Ubuntu18/aarch64 seem to be fine after the image resize, in QPC#264- ppc64le actually passed, and aarch64 failed the test, though it was able to fully complete a build, which is nice.

Ubuntu18/s390x appears to be failing on apt-get upgrade :

Processing triggers for initramfs-tools (0.130ubuntu3.12) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-74-generic
Using config file '/etc/zipl.conf'
Run /lib/s390-tools/zipl_helper.device-mapper /boot
Error: Unsupported setup: Directory '/boot' is located on a multi-target device-mapper device
Error: Script could not determine target parameters
run-parts: /etc/initramfs/post-update.d//zz-zipl exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 linux-firmware
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Presumably this is an issue with the root file system now being on a several partitions. Interesting that this wasn't an issue with the other Ubuntu machines. I could apt hold the linux-firmware and initramfs-tools packages to 'fix' the issue, but that feels wrong ...

Haroon-Khel · 2021-06-22T10:34:41Z

Latest failures/instabilities

ppc64le ubuntu18 - fails in the test stage. Looks like the test script needs to be updated to support the new name of the tests repo

00:17:27 TESTDIR: /home/linux/testLocation/openjdk-tests is invalid. Please use --testdir|-t to set valid TESTDIR under aqa-tests. Default value current dir (pwd) is used if not provided.
00:17:32 /home/linux/openjdk-infrastructure/ansible/pbTestScripts/testJDK.sh: line 15: cd: /home/linux/testLocation/openjdk-tests/TKG: No such file or directory
00:17:32 + grep -q 'FAILED: 0' /home/vagrant1/workspace/QEMUPlaybookCheck/ARCHITECTURE/ppc64le/OS/ubuntu18/label/vagrant/ansible/pbTestScripts/qemu_pbCheck/logFiles/UBUNTU18.PPC64LE.test_log
00:17:32 + echo TEST FAILED

s390x ubuntu18 - fails when ansible tries running apt-get upgrade, https://ci.adoptopenjdk.net/job/QEMUPlaybookCheck/272/ARCHITECTURE=s390x,OS=ubuntu18,label=vagrant/consoleFull

12:07:41 TASK [Common : Run apt-get upgrade] ********************************************
12:43:05 fatal: [localhost]: FAILED! => {"changed": false, "msg": "'/usr/bin/apt-get upgrade --with-new-pkgs ' failed: E: Sub-process /usr/bin/dpkg returned an error code (1)\n", "rc": 100, "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nCalculating upgrade...\nThe following NEW packages will be installed:\n  distro-info gcc-11-base libgcc-s1 libnetplan0 linux-headers-4.15.0-144\n  linux-headers-4.15.0-144-generic linux-image-4.15.0-144-generic\n  linux-modules-4.15.0-144-generic linux-modules-extra-4.15.0-144-generic\nThe following packages will be upgraded:\n  accountsservice apt apt-utils base-files bind9 bind9-doc bind9-host\n  bind9utils bsdutils busybox-initramfs busybox-static ca-certificates dbus\n  distro-info-data dmeventd dmsetup dnsutils e2fsprogs fdisk file\n  friendly-recovery gcc-8-base initramfs-tools initramfs-tools-...

aarch64 ubuntu18 - disconnected during build stage, playbook passes without error

01:01:35 Connection to localhost closed by remote host.

aarch64 debian10 - Connection reset by peer

12:01:00 TASK [Gathering Facts] *********************************************************
12:01:00 fatal: [localhost]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: kex_exchange_identification: read: Connection reset by peer\r\nConnection reset by 127.0.0.1 port 10020", "unreachable": true}

arm32 debian8 - Fails to download GCC 7.5 binary. URL is invalid

14:15:17 TASK [gcc_7 : Download AdoptOpenJDK gcc-7.5.0 binary] **************************
14:15:35 fatal: [localhost]: FAILED! => {"changed": false, "dest": "/tmp/ansible-adoptopenjdk-gcc-7.tar.xz", "elapsed": 6, "msg": "Request failed", "response": "HTTP Error 404: Not Found", "status_code": 404, "url": "https://ci.adoptopenjdk.net/userContent/gcc/gcc750+ccache.armv7l.tar.xz"}
14:15:35

riscv seems to be successful in its playbook run

sxa · 2021-06-22T10:48:35Z

Looks like the test script needs to be updated to support the new name of the tests repo

Hmmm all requests to the old repo should redirect so there may be another underlying issue there ...

Haroon-Khel · 2021-06-22T11:00:46Z

Hmmm all requests to the old repo should redirect so there may be another underlying issue there ...

I received this error in my own time when I was running some tests using the tests repo. This error would pop up when using the ./get.sh script. I noticed that I had only began to hit this error when the repo name changed from openjdk-tests to aqa-tests. I was using a local copy of the tests repo that I had cloned before the name change. I found that changing the folder name to aqa-tests, from openjdk-tests solved it. Ive put in the pr #2230, ill be testing it to see if it solves it

sxa · 2021-06-22T11:03:58Z

arm32 debian8 - Fails to download GCC 7.5 binary. URL is invalid

That looks from the log as though the job was tested using a fork of the repository that doesn't have this change in it: https://github.com/adoptium/infrastructure/pull/2201/files

Haroon-Khel · 2021-06-22T11:07:02Z

That looks from the log as though the job was tested using a fork of the repository that doesn't have this change in it: https://github.com/adoptium/infrastructure/pull/2201/files

Possibly. I was testing this pr, #2203 (I shouldve just tested the playbook run in hindsight since the changes only affect mac), at the time. Ill run a new job on master

Haroon-Khel · 2022-12-20T11:41:09Z

As of 19/12/22 the failing builds are

aarch64 deb10

23:03:53 TASK [Common : Allow https apt sources] ****************************************
23:04:36 [WARNING]: Updating cache and auto-installing missing dependency: python-apt
23:04:36 fatal: [localhost]: FAILED! => {"changed": false, "cmd": "apt-get update", "msg": "E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'\nE: Repository 'http://deb.debian.org/debian buster-updates InRelease' changed its 'Suite' value from 'stable-updates' to 'oldstable-updates'", "rc": 100, "stderr": "E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'\nE: Repository 'http://deb.debian.org/debian buster-updates InRelease' changed its 'Suite' value from 'stable-updates' to 'oldstable-updates'\n", "stderr_lines": ["E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'", "E: Repository 'http://deb.debian.org/debian buster-updates InRelease' changed its 'Suite' value from 'stable-updates' to 'oldstable-updates'"], "stdout": "Get:1 http://deb.debian.org/debian buster InRelease [122 kB]\nGet:2 http://deb.debian.org/debian buster-updates InRelease [56.6 kB]\nGet:3 http://deb.debian.org/debian buster-backports InRelease [51.4 kB]\nGet:4 http://security.debian.org/ buster/updates InRelease [34.8 kB]\nGet:5 http://deb.debian.org/debian buster-backports/main Sources [456 kB]\nGet:6 http://deb.debian.org/debian buster-backports/main arm64 Packages [482 kB]\nGet:7 http://deb.debian.org/debian buster-backports/main Translation-en [411 kB]\nGet:8 http://security.debian.org/ buster/updates/main Sources [285 kB]\nGet:9 http://security.debian.org/ buster/updates/main arm64 Packages [403 kB]\nGet:10 http://security.debian.org/ buster/updates/main Translation-en [223 kB]\nReading package lists...\n", "stdout_lines": ["Get:1 http://deb.debian.org/debian buster InRelease [122 kB]", "Get:2 http://deb.debian.org/debian buster-updates InRelease [56.6 kB]", "Get:3 http://deb.debian.org/debian buster-backports InRelease [51.4 kB]", "Get:4 http://security.debian.org/ buster/updates InRelease [34.8 kB]", "Get:5 http://deb.debian.org/debian buster-backports/main Sources [456 kB]", "Get:6 http://deb.debian.org/debian buster-backports/main arm64 Packages [482 kB]", "Get:7 http://deb.debian.org/debian buster-backports/main Translation-en [411 kB]", "Get:8 http://security.debian.org/ buster/updates/main Sources [285 kB]", "Get:9 http://security.debian.org/ buster/updates/main arm64 Packages [403 kB]", "Get:10 http://security.debian.org/ buster/updates/main Translation-en [223 kB]", "Reading package lists..."]}

s390x ubuntu18

23:06:25 TASK [Common : Run apt-get upgrade] ********************************************
...
 "Error: Unsupported setup: Directory '/boot' is located on a multi-target device-mapper device",

riscv deb11

23:08:13 TASK [Common : Allow https apt sources] ****************************************
23:08:34 fatal: [localhost]: FAILED! => {"cache_update_time": 1598344993, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"      install 'apt-transport-https'' failed: E: Failed to fetch http://deb.debian.org/debian-ports/pool/main/a/apt/apt-transport-https_2.1.10_all.deb  404  Not Found [IP: 199.232.10.132 80]\nE: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?\n

arm32 deb8
Failed to install the following package for what looked to be a dependency reason:

failed: [localhost] (item=flex)
failed: [localhost] (item=g++)
failed: [localhost] (item=gcc)
failed: [localhost] (item=gettext)
failed: [localhost] (item=libexpat1-dev)
failed: [localhost] (item=libcups2-dev)
failed: [localhost] (item=libfreetype6-dev)
failed: [localhost] (item=libfontconfig1-dev)
failed: [localhost] (item=libgmp3-dev)
failed: [localhost] (item=libmpfr-dev)
failed: [localhost] (item=systemtap-sdt-dev)

Haroon-Khel · 2022-12-22T13:05:05Z

Using QEMU playbook check in github workflows. It can do all but riscv #2861

sxa · 2023-01-30T13:48:24Z

As of 19/12/22 the failing builds are

aarch64 deb10

23:03:53 TASK [Common : Allow https apt sources] ****************************************
23:04:36 [WARNING]: Updating cache and auto-installing missing dependency: python-apt
23:04:36 fatal: [localhost]: FAILED! => {"changed": false, "cmd": "apt-get update", "msg": "E: Repository http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'

That one will be from Debian 10 going out of support, so we should either have something in the playbooks to update the apt repo reference. See https://wiki.debian.org/DebianOldStable for background.

s390x ubuntu18

23:06:25 TASK [Common : Run apt-get upgrade] ********************************************
...
 "Error: Unsupported setup: Directory '/boot' is located on a multi-target device-mapper device",

@Willsparker Have you hit this one before?

riscv deb11

23:08:13 TASK [Common : Allow https apt sources] ****************************************
23:08:34 fatal: [localhost]: FAILED! => {"cache_update_time": 1598344993, "cache_updated": false, "changed": false, "msg": "'/usr/bin/apt-get -y -o \"Dpkg::Options::=--force-confdef\" -o \"Dpkg::Options::=--force-confold\"      install 'apt-transport-https'' failed: E: Failed to fetch http://deb.debian.org/debian-ports/pool/main/a/apt/apt-transport-https_2.1.10_all.deb  404  Not Found [IP: 199.232.10.132 80]

That's slightly odd and suggests that apt-get update has not been able to complete successfully since the directory mentioned there does have version 2.5.5 of the package in place.

arm32 deb8 Failed to install the following package for what looked to be a dependency reason:
failed: [localhost] (item=flex)
failed: [localhost] (item=g++)

May just be because Debian8 is ancient (although it might be interesting to see if we can point directly at the correct repo from archive.debian.org). However we should probably check what the latest Raspbian image is and go with that (and possibly add a recent Ubuntu since that is become more common on the platform) EDIT: Current is based on Debian 11 (Bullseye) with kernel 5.15, the "legacy" image is Debian 10 (Buster) with kernel 5.10) Reference

Willsparker self-assigned this Apr 13, 2021

Willsparker added pbTests bug labels Apr 13, 2021

Willsparker mentioned this issue Apr 13, 2021

Ansible request for RISC-V support #2123

Closed

Willsparker mentioned this issue Apr 15, 2021

pbTests: Fixup buildJDK arguments in QPC & export buildJDK vars #2132

Merged

5 tasks

Willsparker mentioned this issue May 7, 2021

pbTests: Add logic to buildJDK.sh to set JDK_BOOT_DIR #2176

Closed

karianna added this to the May 2021 milestone May 18, 2021

Willsparker mentioned this issue May 20, 2021

pbTests: Increase QPC.sh sleep time #2190

Merged

5 tasks

sxa mentioned this issue Jun 21, 2021

QEMU jobs are unstable/failing #2228

Closed

Haroon-Khel modified the milestones: May 2021, June 2021 Jun 21, 2021

Haroon-Khel mentioned this issue Jun 22, 2021

pbTests: Change any occurrence of openjdk-tests to aqa-tests in the test script #2230

Merged

5 tasks

sxa added this to the 2022-10 (October) milestone Sep 7, 2022

sxa mentioned this issue Sep 7, 2022

Ansible request for GCC on Ubuntu/arm32 #2735

Closed

sxa mentioned this issue Oct 6, 2022

Many centos7_docker_image_updater failures #2760

Closed

sxa modified the milestones: 2022-10 (October), 2022-11 (November) Oct 18, 2022

sxa mentioned this issue Nov 17, 2022

Feature: add timeout in job "QEMUPlaybookCheck" #2821

Open

sxa modified the milestones: 2022-11 (November), 2022-12 (December) Dec 1, 2022

sxa modified the milestones: 2022-12 (December), 2023-02 (February) Jan 27, 2023

Haroon-Khel modified the milestones: 2023-02 (February), 2023-03 (March) Mar 2, 2023

Haroon-Khel modified the milestones: 2023-03 (March), 2023-04 (April) Mar 29, 2023

sxa modified the milestones: 2023-04 (April), 2023-05 (May) May 16, 2023

sxa modified the milestones: 2023-05 (May), 2023-06 (June) Jun 6, 2023

sxa modified the milestones: 2023-06 (June), 2023-08 (August) Jul 7, 2023

sxa modified the milestones: 2023-08 (August), 2023-11 (November) Sep 22, 2023

sxa mentioned this issue Nov 6, 2023

[ansible] Add Ubuntu 20.04 linux-riscv64 image #3240

Merged

6 tasks

sxa modified the milestones: 2023-11 (November), 2024-01 (January) Jan 3, 2024

sxa modified the milestones: 2024-01 (January), Backlog Feb 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

QPC: All platforms are unstable #2121

QPC: All platforms are unstable #2121

Willsparker commented Apr 13, 2021

Willsparker commented Apr 13, 2021

Willsparker commented Apr 15, 2021

Willsparker commented Apr 27, 2021

sxa commented Apr 27, 2021

Willsparker commented Apr 29, 2021 •

edited

Loading

Willsparker commented May 10, 2021

Willsparker commented May 13, 2021 •

edited

Loading

Willsparker commented May 17, 2021

Willsparker commented May 18, 2021 •

edited

Loading

Willsparker commented May 19, 2021 •

edited

Loading

Willsparker commented May 20, 2021 •

edited

Loading

Haroon-Khel commented Jun 22, 2021

sxa commented Jun 22, 2021

Haroon-Khel commented Jun 22, 2021 •

edited

Loading

sxa commented Jun 22, 2021

Haroon-Khel commented Jun 22, 2021

Haroon-Khel commented Dec 20, 2022

Haroon-Khel commented Dec 22, 2022 •

edited

Loading

sxa commented Jan 30, 2023 •

edited

Loading

QPC: All platforms are unstable #2121

QPC: All platforms are unstable #2121

Comments

Willsparker commented Apr 13, 2021

Willsparker commented Apr 13, 2021

Willsparker commented Apr 15, 2021

Willsparker commented Apr 27, 2021

sxa commented Apr 27, 2021

Willsparker commented Apr 29, 2021 • edited Loading

Willsparker commented May 10, 2021

Willsparker commented May 13, 2021 • edited Loading

Willsparker commented May 17, 2021

Willsparker commented May 18, 2021 • edited Loading

Willsparker commented May 19, 2021 • edited Loading

Willsparker commented May 20, 2021 • edited Loading

Haroon-Khel commented Jun 22, 2021

sxa commented Jun 22, 2021

Haroon-Khel commented Jun 22, 2021 • edited Loading

sxa commented Jun 22, 2021

Haroon-Khel commented Jun 22, 2021

Haroon-Khel commented Dec 20, 2022

Haroon-Khel commented Dec 22, 2022 • edited Loading

sxa commented Jan 30, 2023 • edited Loading

Willsparker commented Apr 29, 2021 •

edited

Loading

Willsparker commented May 13, 2021 •

edited

Loading

Willsparker commented May 18, 2021 •

edited

Loading

Willsparker commented May 19, 2021 •

edited

Loading

Willsparker commented May 20, 2021 •

edited

Loading

Haroon-Khel commented Jun 22, 2021 •

edited

Loading

Haroon-Khel commented Dec 22, 2022 •

edited

Loading

sxa commented Jan 30, 2023 •

edited

Loading