20.04 daily testing: Wifi wouldn't connect after reboot (took 2nd boot)

FYI: I was testing 20.04 daily 20200314. The Live desktop connected to my 2.4g wifi. But, after install from the Live desktop, and rebooting, it would not connect. I removed the access point from network-manager, and tried connecting anew. But, still nothing (the nm-tray icon showed ellipsis across the icon, then a balloon msg saying “disconnected.”

I rebooted, and connecting to wifi worked. So, something about that first reboot (after install) wasn’t right.

The machine is an older laptop with a Broadcom BCM4313 wifi card:

i7-2620M 2.7Ghz; 2nd gen core processor 3000 gfx; Broadcom BCM4313 (Dell Latitude E5420 laptop).

I think something changed with 20.04’s wifi recently. That previously-mentioned machine had wifi trouble installing Ubuntu-Studio & Xubuntu. They both disconnected wifi when proceeding from the “Download updates while installing; Install 3rd party” screen. I reported bug #1867465.

I’m testing another machine[1] from a similar era as the above. It has an Intel 7260 wireless card. I booted the same daily image as the previous post (20200314). Lubuntu Live desktop boots fine. But, when I connect to my wireless access point, the nm-tray icon gets stuck with the ellipsis across it. After 30-60 seconds a balloon appears saying its disconnected.

The only way I can get it to connect is to click that access point while it’s pending. That causes it to immediately give the disconnected msg. Then I click it while that balloon is still up, and I get a second balloon saying connection established.

I’ve rebooted the Live desktop 3 times, and it’s does the same thing each time.

I proceeded with installation of Lubuntu. It does the same thing after rebooting. It gets stuck on the “…” across the nm-tray icon. I have to click the access point to make it fail (before timing out). I click that same access point, it connects immediately (while the connection-lost balloon is still present).

I wonder if this (and the first post) are related to 1867465. Or, if I should open a new bug report?

[1] i5-4200M 2.5Ghz; 4th gen core processor 4600 gfx; Intel 7260 (Lenovo ThinkPad E440 20C5 laptop).

I haven’t done much testing of late, but with wifi dropping out, or not connecting after reboot, I’d expect it to impact all flavors equally.

Thanks for noting your issues @azdays15, I’ll endeavour to use some laptops for testing when I can.

My problem is: I don’t know how particular to be. I’m afraid I’ll be holding too high of a standard. People might feel it’s ok to have to click nm-tray to make it happen (or boot a second time). That’s not too bad. I could live with it.

For example, I had a worse wifi problem requiring an RJ45 to be able to load the proprietary driver for the wifi. I’m still unclear whether that’s acceptable (I could live with it. The solution isn’t as bad as what someone had to do 2 years ago when they sought help in the linked forum thread.). Or, if it should be reported as a bug (if that driver should come on the installation media).

It’s hard to know what’s being too critical versus proper advocacy for improvement.

As for how particular to be, you’ll have to wait for a developer or council member to advise (I won’t). I will however remind that we’re already feature frozen (Feb 27), very close to UI Freeze (March 19), documentation freeze (March 26) etc so there isn’t much time left to get much done.

https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule

1 Like

I opened bug #1867534 this morning. This is for the Lenovo Thinkpad E440 with Intel 7260 wireless card.

I’ll let someone decide if this is a bug, improveable, etc. I have no sense about this topic, whether it’s acceptable or should be better. I often get the feeling that wifi, video cards, etc. can be “temperamental,” and everyone’s happy if they work in some manner. (But, sometimes I get the opposite impression.).

I’m glad to be hitting these things now (even if it’s too late for 20.04). I’m planning to test Linux Lite before it’s released. It will be based upon 20.04. These things will be more in my vocabulary then (which machines have which problems). Being a one-man band, he might have some tricks up his sleeve.

Thanks, I kept that kink to the release schedule. I didn’t know there were these freezes.

But, I’m surprised the “media check” (at startup) was implemented so hastily (so late into the process, especially for an LTS). It sounds like there was no discussion about it. It doesn’t seem like much thought was put into it (it ignores “s” for large squash files. Budgie ignores it even when spinning through small files. I’m sure that’s not intentional. Just a byproduct of how it was implemented without notice?). I think it’s a good idea. But, it seems like it should have been worked on before the LTS cycle started.

That’s curious. Could you mention that on the topic on Ubuntu’s Discourse?

I think I did.

Budgie’s complete ignoring of “s” (during the faster small-file processing) is fixed. But, all the distros don’t respond to “s” while a large file is processing.

IMO, the new, non-optional media check is problematic. It basically depends upon the user sitting there watching intently. If it errors, it will pause only briefly before disappearing. A user could step away, return to see the desktop, and believe there’s no problem. (At this point, it’s basically still optional. The only people who would benefit are those who choose watch it. The rest of us have to wait for it. The message should be changed to say “Please pay attention to this at least once” because “s” doesn’t work during half the check, and if there is an error, it’s not going to tell anyone unless they pay particular attention.

For pre-release testing it’s pain. It makes it harder to multitask. You either have to wait and be fast on the “s” key. Or, wait the entire time (even though you know it’s valid). I felt like I might as well skip the command-line md5sum test (which you gave me) because I’m going to have to sit through the process anyway. But, then I have to pay attention the first time. (I can walk away from the command-line process.).

It’s just not good. It’s more like eye candy. “Look, we’re doing something to ensure integrity (have fun trying to skip, and if you care about integrity… watch carefully because… bye!)”

I think I’ve said pretty much all that in the thread you mentioned. I think it’s a great idea. But, maybe for 20.10. It needs more thought. We’ve lived with the grub route to it for 8 years? Another 6 months won’t kill anyone.