Testing 20.04 daily? [SOLVED]

Lubuntu Support
1

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.]

2

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

http://iso.qa.ubuntu.com/qatracker/milestones/408/builds

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 Lubuntu Desktop amd64 testcases in Focal Daily (archived) | Ubuntu QA 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 Testing tracker | Ubuntu QA…

3

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”]

4

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 …

5

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?

6

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:

http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/207419/testcases

If I drill down into the LiveCD testcase:

http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/207419/testcases/1303/results#add_result

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

7

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

8

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.).

9

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

https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/etc/crontab

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

#!/bin/sh
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
10

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

11

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.

12

I was going to try the Lubuntu daily image again. I downloaded (apparently I didn’t keep the last one, couldn’t try the zsynch command to update it.) the ISO from here:

However, when I check the MD5, it’s 175849c6d3778730244fd931d56b6c7f

That page says it should be 1a0825b62c5c6a615c8ffb65757bc914

Is that a problem? (I wish the iso was dated. Or, if there were dated pages. The way it rolls over each day to something new. I don’t know if I just happened to download & check ISOs at the time it rolled to a new day. I guess I could try the zsynch command to see if that happened?).

EDIT: I just tried the zsync commands earlier in this thread. That produced an ISO with a checksum that matches what the daily-live page says it should be.

I downloaded the ISO a couple hours ago. I must have hit the daily cutover.

13

First, zsync does the checking for you. You can pretty much guarantee you will not get a bad ISO by using zsync. On the other hand, download errors pretty much are guaranteed with normal http.

If you want to see which image you have, try strings /path/to/iso | grep Lubuntu. Within the first few results you’ll see something like:

Lubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200222)

There will be a similar looking thing at the top of /etc/apt/sources.list:

deb cdrom:[Lubuntu 20.04 LTS _Focal Fossa_ - Alpha amd64 (20200222))]/ focal main multiverse restricted universe

Also you can always compare against older hashes. There is always at least one or two older versions of the daily in the containing folder.

In your case, the 20200222 hash is the one you got. The 20200223 hash is the one you say it “should be.” If you look at the page again, you can see the last modified date on the ISO is “2020-02-23 16:49” which is naturally consistent with “20200223” and not “20200222” :rofl:

BTW you look at our wiki on testing (particularly relevant to this discussion), you’ll find the crontab for ISO building which shows the process starts at 16:49 UTC every day and (as shown on the wiki) normally takes about 90 minutes.

2 Likes
14

Today’s 20.04 image worked great. I saw the “can’t write to IOMMU” message. But, it didn’t hang there like last time (I see that msg with other distros too. I figure if it doesn’t hang, it’s all good.). The Live desktop popped up quickly on this Ryzen 3/Vega 3 laptop.

I’m very happy to see this because I’ve been nervous about 20.04 LTS not working with it. Distros like Peppermint & Linux Lite base themselves off LTS. So, that would be a big effect (for a couple years).

I’m going to pop a new drive in it, and install 20.04. But, right now it looks much better than I saw a couple weeks ago. Doesn’t look alpha (nor beta) now.

Should I close the bug report I opened previously? Is there any QA tracker stuff I should do? (I need to read the earlier posts explaining that stuff. I’m not good with “process” stuff like this.).

I’ve got a Ryzen 5/Vega 8 also. I’ll try it on that with tomorrow’s image.

15

I installed the 2020-02-23 daily image to the Ryzen 3/Vega 3 laptop. It looks great, like it’s the final release (not an unstable test image).

1. I encountered one strange thing in the Live desktop (when installing). I told it to erase the existing disk (which was formatted MBR, ext4). When I got to the point of committing changes made to the disk, it had an error saying it couldn’t partition the drive.

I rebooted, used the KDE Partition Manager to delete the existing partition. Then the install worked fine.

I tried that again. Booted the LiveUSB, started the install, chose erase entire disk. When I confirmed changes to the disk, I got the same error message:

The Installer failed to create a partition table on WDC WD50000LPLX-60ZNTT1.

Create a new partition table (type: gpt) on ‘/dev/sda’

====
Job: Create new partition table on device ‘/dev/sda’

====
Command: sfdisk /dev/sda

(Note: I don’t know why the quote markup is causing the above to be large/bolded.).

When I started to do that 2nd try, I thought that, to recreate the error I would have to delete the partition & create an MBR partition table. I thought the original state of the disk is why I got the first error. But, the disk is now GPT (from that last install). So, it seems like it can’t work with allocated partitions. I have to delete them in KDE Part. Mgr. Then the install works. It doesn’t matter if the existing partition table is MBR or GPT.

Should I open a bug report on that? (Seems like someone would have already encountered this. I read another recent post about Calamares having some issues.).

2. Inxi -Fxrz (installed with apt-get, just because I have that command memorized) shows the kernel is 5.4.0-14. The Mesa driver is 20.0.0. That’s interesting to me because MX Linux 19.1_AHS uses Mesa 19.2.1 & kernel 5.4.0-3 (and doesn’t work with Ryzen 3/3 nor 5/8).

Kubuntu 19.10 uses Mesa 19.2.8 & kernel 5.3.0-40. That works with both Ryzens.

I don’t understand how all that goes together (or, why some combos don’t).

16

I installed the 20200223 daily image to my Ryzen 5/Vega 8. I would say it worked. It was a little different experience. Not bad (compared to a black screen).

  1. I put the same drive in this laptop as I used in the Ryzen 3/3. The installer didn’t give me the option to erase disk. The only option was manual partition.

That seemed odd to me because when I installed on this same drive (on the Ryzen 3/3), even when I reinstalled over it, it gave me the “erase disk” option.

In this case (Ryzen 5/8), I went to KDE Part. Mgr, deleted the partitions from the Ryzen 3/3 install. Then, the installer gave me the erase disk option.

  1. After install, booting seemed ok. After the horizontal dots, it went to a black screen. 5 seconds later the cursor appeared in the center of the still black screen. 15 seconds later the desktop appeared.

I’m not sure what’s going on there. The Ryzen 3/3 didn’t do that. (The desktop popped up immediately.). Being a faster machine, it seems odd that it takes longer. But, I’m thankful I can install it.

I reinstalled 3-4 times, choosing auto login or not. Same behavior. (And, the installer always gave me “erase disk,” and didn’t have the error it did on the Ryzen 3/3.).

I can test this more if/when it’s desirable.

17

If it’s not relevant any longer, yes.

Yeah, known bug. Should be fixed with Calamares 3.2.19.1.

Might want to check with the Kernel Team.

Could be for several reasons, one related to the aforementioned bug report (couldn’t umount the drive because settling it didn’t work), the other a known bug due to swaps being automounted, which is a “feature” in Ubuntu.

Might have something to do with different kernel modules or perhaps different behavior of systemd. It does seem odd, and it probably is.

1 Like
18

I changed the status to “fix released.” That was the closest thing I could see to closing it. If I should do something else, please tell me.

I forgot to mention yesterday: I tried the grub menu item “check media for defects” on my Ryzen 3/3. It didn’t work. It seemed like it started to boot (shifted gears) and sat there doing nothing, black screen.

Maybe that’s not expected to work until closer to the release (because so many things are in flux every day at this stage of development)?

I’ll try the daily image again in a week or two. I’m really glad to see it work on these laptops. I was really worried there would be some new-hardware issues that would make them incompatible (and ineligible for LTS for two years).

The difference between yesterday’s image and the one I tried a couple weeks ago is like night and day. Lubuntu’s nm-tray seemed better to me than the 19.10 I looked at recently. I deliberately mangled my wireless password to see if it would save a bad session. It didn’t. (I’m not entirely sure that’s what happened with 19.10. But, it felt like it. That was strange because it felt like a driver problem. Just woudln’t connect. But, when I deleted the saved connection, then it worked. So, I assume I typed the password incorrectly and it saved it.).

19

That’s a good sign that something’s wrong with the install media. The hashing you do with the ISO tests for download errors. However, you then copy the ISO to the installation media, which introduces the possibility of copy errors. The “check media for defects” can resolve both of these but only if there are no errors within that particular piece of software. There is a method to check the installation media that you can use to confirm my assertion that your media has a copy error.

To be clear: it might be one bit of data that’s off. That wouldn’t change much and would likely result in few symptoms. You might be able to get a perfectly good install done, but under some other set of circumstances, it won’t work. Or really bizarre things (like what you mentioned) happen. Rarely are these errors because of huge swaths of corrupted data, but that doesn’t mean it’s not problematic. In fact, because things are not totally broken and seem to work in some ways is more problematic because it makes people think incorrectly that they have a perfectly good image and their problem is a problem with Lubuntu. I will say that this is one of the biggest things I’ve had to deal with in support and it really stinks.

That’s because we changed the default editor to the GNOME one. This kind of sucks, because it’s not Qt, but the user experience is great. And hopefully someone will come up with a Qt solution.

I think your assumption is correct. And your solution is the right one. It’s not a kernel issue at all.

2 Likes
20

I tried this method described on that page:

cd /media/cdrom
md5sum -c md5sum.txt | grep -v “OK$”

I had one error:

./boot/grub/efi.img: FAILED
md5sum: WARNING: 1 computed checksum did NOT match

I don’t recall what I did two weeks ago when I first tried a daily image. Maybe there was a problem in this regard. I’ve played with Linux for 20 years. I never realized there were these kinds of potential for corruption. It’s only in the past year or two I’ve bothered comparing checksums. Maybe the past 6 months I check install media for defects (because I’ve seen you stress it).

I’ll be sure to do those checks before proceeding with the next daily build in a week or two.

I thought KDE tools like that would work with LXQt(?). For example, you guys have KDE Partition Manager.

I’m running Kubuntu 19.10 right now. I’m going to use that until May or so, and hop to Linux Lite 5.0. Then figure out where to hop after that. I like hopping. You get a lot of exposure to different things. I planned to hop to Peppermint 10. Last April (2019) when I hopped to MX Linux 18.3, it was a coin toss whether to do that or Peppermint 9. I told myself I’d use MX for awhile, then Peppermint. I started to hop to Peppermint earlier this month. But, learned the lead/author/creator passed away last month. That team is struggling to fill those shoes. So, I thought I’d use the time to try something else and wait till Peppermint 11 is out, and reflects the new leadership.

That topic made me think about how the *buntu organization isn’t as prone to one person’s existence. Personally, I prefer the one-man-band distros like Peppermint & Linux Lite. I don’t like the corporate culture of *buntu (it’s like kryptonite to me). But, if someone became incapacitated, there’s a larger organization to keep it going. Most people never think about that stuff. The recent sad news at Peppermint made me think about it. We just go through life expecting tomorrow to be like today. The *buntu corporate environment is more realistic that way.