Testing 20.04 daily?

I read that 20.04 will have kernel 5.4. I’d like to test it, whether it installs.

I have a newer Ryzen 3 (Vega 3) laptop which had a problem with 5.4 in Sparky Linux’s testing branch. 5.3 installed/booted. But, when I applied updates, it gave me 5.4 which didn’t boot. (But, when I chose the original 5.3 kernel in Grub’s menu, it booted).

The problem was probably something else. But, I was thinking it might be good to see if there are any install issues on this hardware. I’ve never done this before, so I don’t now if there’s a preferred timeframe when that would be welcome? Is it too early?

[EDIT: Sorry or the “x” in the title. I had to have 15 characters. I couldn’t think of a better way.]

We’d love you to help test, the more eyes we have testing, the more issues that can be discovered pre-release, and get fixed. It’s much easier to fix things before release, than after.

I’ll provide the following link


You can navigate down to “Lubuntu Desktop amd64” yourself, where you’ll see “Link to download information” at the top and our testing checklists (install & live session currently).

The reason I didn’t provide the http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/207419/testcases link is, whilst it’s valid today, the ‘daily’ image is produced daily & when a new one is produced, that build (& thus link) will be out-of-date (the test results will still be there, but it won’t allow new entries, ISO can’t be downloaded etc).

If you’d like to record your testing, you’ll need a launchpad or Ubuntu SSO ID to login in, and you can record your hardware & what you do in comments. Any bugs or issues should be reported on launchpad, plus errors placed in the test result fields on iso.qa.ubuntu.com/qatracker/

I have a Ubuntu sso. I will look further at that page.

I just downloaded the 2020-02-08 Lubuntu image. Burned it to USB flash drive using MX Linux’s Live USB Maker (dd image mode, nothing special).

It booted to Grub, I chose the first option to start Lubuntu. It stated to do something, then stuck with a line saying:

[0.769750] pci 0000:00:00.2 AMD-Vi: Unable to write to IOMMU perf counter.

Is that the sort of info I would submit to the qatracker? Are there other things I should do (kernel parms?).

The laptop is a Ryzen 3 3200u (Radeon Vega 3 gfx). Acer Aspire 5 A515-43-R19L . You may remember the table of 20 distros I installed, showing memory usage. The laptop seemed Linux friendly.

[EDIT: I remember seeing an IOMMU option in the bios. I went into the bios, and disabled it. It’s booting further now. It got some CPU lockup msgs on the screen (very slow). After about 5-10 minutes a blue screen appeared with “Lubuntu 18.10” in the center. (And, the log lines are still appearing about “watchdog: BUG: soft lockup - CPU #3 stuck for 22s [systemd-udevd:231”]

I would suggest firstly running the ‘Check disc for defects’ option first to ensure the write was perfect (maybe I’m just unlucky, but I have failures semi-regularly with this stage regardless of what box I use)

Did you try “Start Lubuntu (safe graphics)”? I would hope it would boot there, which would allow you to use ubuntu-bug to submit a bug report (by far the best way, on the hardware with the issue). The two get linked automatically if you add a bug number into the bug area on iso.qa.ubuntu.com test results.

Launchpad is used as normal for bug reporting, the ISO QA tracker is used for additional tracking on who & when it was discovered (with which daily image etc useful to pinpoint when issues occur for regressions etc).

I’ll provide http://iso.qa.ubuntu.com/qatracker/milestones/410/builds/207267/testcases/1301/results which shows some examples of what I did for some fails with the 18.04.4 image. It also shows another entry by @kc2bez who had a successful test. (FYI: there was no reason why I chose that date, it was just the first I found)

FYI: I have a text file which contains the ~17 boxes I use for QA testing, I made up my descriptions in the format is “brand model (cpu, ram, gpu)” by using data provided by lshw. I just copy the appropriate boxes line from that file into the comment line when I start a test …

Thank you for the tips.

  1. I tried “check disc for defects.” But, it gets the same immediate error. (Apparently that tool requires the same bootup that I’m not getting past. But, I will remember to try that whenever there’s a problem.).

  2. I successfully booted safemode.

From there I executed ubuntu-bug syslinux (that parm was suggested by the qatracker page). It created bug #1862527

What should I expect now? Will someone tell me when to try it again? Or, should I try again occasionally just to see what happens?

I was reading your instructions again, and it sounds like I need to do something in QA tracker (to link the bug report so there is evidence of the failed testcase)?

I don’t see anywhere to submit a failed testcase on this page:


If I drill down into the LiveCD testcase:


I see some linky text about “submit” a failed testcase. But, if I click that link, it doesn’t go anywhere.

That page has been ‘closed’, ie. a new daily has been spun so no new results can be entered for that ISO. The other thing to check is that you’re logged in (top right it says “Hello guiverc” for me showing I’m logged in - options don’t appear if it doesn’t see you logged in). The login box is to the left towards the top.

I enter my ‘box specs’ line and click the “in progress” option when I start, so if a new ISO is spun, the result I started can be edited/updated to show whatever occurred in the test.

For what to report against (esp. with regards Lubuntu components) see https://phab.lubuntu.me/w/bugs/

Any responses to you will be via your launchpad bug report. You shouldn’t expect a ‘please try again’ however it does happen on the bug report, but it could be 1 or 2 days before the ‘fix’ builds into the new daily ISO.

Re-running your testing is your choice, when you have time etc. You just use the already existing bug ID in the appropriate field if the same condition occurs again (from the bug ID, you can get a list of all ISO QA tests that reported that bug

I was definitely logged in. It must have been because I waited till the next day. (It looked like the same 0208 image was being served. But, it was technically a new day.).

To be clear: you’re referring to the QA tracker (not the bug report?).

Do things change enough that it merits trying each day’s spin? Or, would you do once a week? (Would I keep reporting those failures each time? I think you’re saying I would. I’m worried about sounding impatient.).

I’ll provide the cron details for ISO testing (it’ll give clues on when jobs are run/initiated if you’re interested)


You may already know this, but you can use zsync to update your ISO to reduce bandwidth of download, eg.

rm *.old
mv focal-desktop-amd64.iso.zsync focal-desktop-amd64.iso.zsync.old
wget http://cdimage.ubuntu.com/lubuntu/daily-live/current/focal-desktop-amd64.iso.zsync
zsync -u http://cdimage.ubuntu.com/lubuntu/daily-live/current/focal-desktop-amd64.iso  focal-desktop-amd64.iso.zsync

Yes I was talking about the iso.qa.ubuntu.com tracker

Generally no. Daily actually more precisely implies ‘interval’, early in the release cycle a new daily is spun weekly, later in the cycle it can be created multiple times a day, and it the process can be started other than the provided cron job I provided.

You can do it whenever you have time, but weekly probably makes more sense than daily.

When it comes to ‘live’ testing (where I try and use different boxes each time) I often might start opening each program on one box, end qa-test & switch to a different box with new qa-test on tracker & continue the opening programs from menu I started in prior test. (I usually use 3 boxes thus three qa-tests to complete all menu items; what I’m doing could be done on the first box, but I hope issues with different hardware will show themselves by using different boxes). In a large number of ‘live’ tests I only open random apps anyway (it takes a long time to open every app).

Yes if you get the same error again, it should be reported (at least in the “Bugs” column if not in the “Critical Bugs”. If it’s a ‘show stopper’ type bug it belongs in critical, though on subsequent reports I often drop to just reporting it in “Bugs” but it’ll depend on how serious I consider it (esp. how I think it’ll impact other users; if it’s something I think specific to my hardware setup I tend to treat lower than something that will impact all users, but that’s just me).

You’ll also note at the bottom of the page “Bugs to look for”, which are bugs reported by other ISO testers (reported on iso.qa.ubuntu.com). Test for these, as if multiple different users encounter a bug, it’ll be confirmed. Not all will be applicable, eg. in the Lubuntu live I see one that relates xfce4-settings which of course won’t impact Lubuntu. Your bug once in the tracker will appear on other testers “Bugs to look for” screens.

1 Like

Change the boot linux line. Remove splash & quiet. Maybe then you can see where it stops booting or gives errors.

Thanks. I did that. I see much more information. How can I relay that to someone? (A camera shot of the screen?). It seems like it’s in a loop. I see the same details every minute or so. It looks like it involves amdgpu. Same pattern of messages, ending with what looks like register values.

@guiverc, thanks for all the info. I need to go through that more, and apply it the next time I try the ISO. Maybe later this week, early next week. It’s a little overwhelming how the bug report connects (or not) to the qatracker, and what I should do as the failure persists. But, I wasn’t able to see the qatracker’s screens because I waited a day to try that part. So, next time I’ll try to work through what you wrote, and will post any questions I have then. (I didn’t know about zsynch. So, I’ll start with that in a few days.).

I just want to make sure this laptop works with the LTS release. It’s an Amazon Choice, best seller, etc. I think it sells a lot. I imagine it could be something people try to use Linux with. About 20 distros installed on it. But, the one problem I had was with kernel 5.4 (Sparky Linux’s rolling/test iso). Going back to 5.3 worked. So, when I saw Ubuntu chose 5.4 for 20.04 LTS… I thought “uh oh.” It’s probably unrelated. For example, the problem I’m having with the Lubuntu daily image is different than I had with Sparky when it upgrade to kernel 5.4. It booted, but wouldn’t startx. The Lubuntu daily image is wore than that. It seems like it’s stuck.