@Piotr, I've given up on this. I was less concerned about security than
I was about the user experience. If the installer knows it's going to
drop the connection, why not inform the user of this? It's really
unnerving to have your connection drop, and think there's some kind of
bug going on. It's
I appreciate everyone's time looking into this. I just wanted to add: if
it is a driver problem, and can't be any better than that, I still think
it would be friendlier if the installer informed the user that "a new
driver is available. Your connection will disconnect while this driver
is
@Steve Langasek, thank you for your time triaging that. I was thinking
the problem is that the installer doesn't handle this in a user-friendly
way. From my perspective the installer should:
1. Inform the user that it located a possibly better driver, and the
connection will drop. (In my case, I
Public bug reported:
ISO testing 20.04 Studio daily image (20200326). Booting shows an error
"/boot not found". Eventually it reaches the Grub menu. Choosing "Try"
results in "can't find vmlinuz".
I believe the first time I booted this USB stick, it hung with more of
an error before reaching the
IMPORTANT: this bug-report DIFFERS FROM #1851346 in one important way:
The INSTALLER FAILS, not merely goes slow.
ALSO, it DOESN'T MERELY FAIL. It (essentially) FAILS WITHOUT NOTICE
(unless the user is watching the the entire (and now-slow installation).
If they return from doing something else,
I experienced the same thing. However, I also experienced the installer
FAILING with a brief "oopsie" msg. When I rebooted, I was presented with
a COMMAND-LINE LOGIN PROMPT. In my case, I unchecked ALL optional
programs.
That might not be something anyone would normally do. Therefore, it
might
@corrado (msg #4), it sounds like you're using Ubuntu desktop. That
problem is different (I've experienced it too), and apparently reported
here:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1867130
You can click "affects me" on that bug. (I think Budgie's problem is
fixed. I need to
Public bug reported:
ISO testing 20.04 Kubuntu daily-image (20200324). I connect to two
access points. I want to delete one of them. I go to System
Settings->Network->Connections, right click on the unwanted wifi
connection, and choose "delete." A msg says "Failed to remove -- error
checking
** Description changed:
ISO testing 20.04 Kubuntu daily image (20200323). Something involving
Kwallet & wifi is installed differently depending on whether I take the
- path "Try it" (install from Live desktop), or "Install now."
+ path "Try Kubuntu" (install from Live desktop), or "Install
** Description changed:
ISO testing 20.04 Kubuntu daily image (20200323). Something involving
Kwallet & wifi is installed differently depending on whether I take the
path "Try it" (install from Live desktop), or "Install now."
- 1. When I install from the Live Desktop (after clicking
** Description changed:
ISO testing 20.04 Kubuntu daily image (20200323). Something involving
Kwallet & wifi is installed differently depending on whether I take the
- path "try it" (and install from Live desktop), or "install now."
+ path "Try it" (install from Live desktop), or "Install
Public bug reported:
ISO testing 20.04 Kubuntu daily image (20200323). Something involving
Kwallet & wifi is installed differently depending on whether I take the
path "try it" (and install from Live desktop), or "install now."
1. When I install from the Live Desktop (after clicking "try it,"
@Erich, sorry for replying twice. Let me put it this way. Whatever you
guys decide is fine with me.
>From the user's perspective they don't have a "hardware issue."
Everything's working. The installer tries to help the user in a way the
user isn't aware they need help. It could be very useful
@Erich, the hardware works fine except during that screen transition. If
the installer is replacing the 3rd party driver at that point, it seems
reasonable to expect some communication that the connection is going to
be dropped (maybe reconnect for the user). The user was just asked
whether to
Public bug reported:
ISO testing 20.04 Studio daily-image (20200321). In the Live desktop,
clicking the menu, and sub-menu "Audio Production," the contents are not
sorted. The other menu categories' contents are sorted.
This may be related to 186800, which I opened for Budgie. Its utilities
@Jeremy, I'm sorry I haven't returned sooner. I've been keeping an eye
on how this works (and have experienced it again today with Budgue &
Kubuntu 20200321).
Are you saying that it is downloading and installing that particular
driver when I click "continue" from the installer page saying
Public bug reported:
ISO testing 20.04 Budgie daily-image (20200321), I was looking for
gparted. I clicked on the category view, clicked on utilities. The list
of items isn't sorted.
I know Budgie is different (like a mac?). But, the other categories
seemed to be sorted. And, "utilities" is
FYI: Installing 20.04 Mate daily image (20200321), I noticed two
bluetooth icons in the task tray. That seemed similar to the accumulated
blue installer icons.
I've probably seen those bluetooth icons before and didn't think much of
it. The only reason I reported the blue installer icons was
UPDATE: I have encountered this error again (but it's different, too).
It appears the installer (when auto-resizing the existing disk,
installing "alongside,") has trouble when the disk is MBR/msdos & the
computer is UEFI-only.
Yesterday (when I first experienced the "failed to install grub"
UPDATE: This wifi behavior happens with all the Ubuntu desktop distros.
HOWEVER: I just installed 20.04 Ubuntu Server daily-image (20200320). It
did NOT have this behavior.
As I began the text-based install, I wondered how I would interrupt the
connection in order to make it work. But, it just
Additional info: I rebooted the LiveUSB, and tried installing again
using "entire disk" (instead of "alongside/resize" the first time, which
failed). It installed without error.
I can try the "alongside" again using tomorrow's daily image. Maybe it
was specific to that. (I have installed Mate's
Public bug reported:
ISO testing 20.04 Mate daily-image (20200320). The installer failed with
a msg about being unable to install grub on sda2. I didn't spend much
time memorizing the error msg because it said it would automatically
report the crash. But, that process failed saying it was unable
Public bug reported:
ISO testing 20.04 Mate daily image (20200320). When I cancel the
install, it leaves a blue cicle (white person, arms outstretched) in the
task tray. I have started the installer four times, and have four of
those in the task tray now.
Probably not a big problem. I just
Public bug reported:
ISO testing 20.04 Studio's daily image (20200319). A screen appears with
about a dozen various media/photography apps which are checkmarked. I am
invited to uncheck any or all. I unchecked all. The install fails near
the end. There is an "oopsie" msg which disappears, and the
I am able to recreate this error on a Ryzen 5/Vega 8 laptop[1]. I had to
hit the "cancel" button very fast (being disconnected from wifi seems to
help slow the Calamares process down, and make it easier to click cancel
soon enough to cause the hang.).
The machine I first reported this bug on is
Today's 20.04 Budgie daily image (20200318) recognized "s" during media
check during the small-file checks. (I think the large file check isn't
responsive to that key press. But, all the *buntu flavors act that
way.).
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Update: I installed Budgie 20200318. It didn't have this problem
reported with the 20200317. (I also installed Mate 20200318. It didn't
have a problem. Confirming Bill's comment.). It seems like this was a
one-day glitch. It's gone.
--
You received this bug notification because you are a member
UPDATE: The reported problem doesn't exist in Xubuntu's next 20200318
daily image. I haven't tested Budgie yet.
I assume this problem is gone.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867845
I had the reported behavior with today's Budgie daily image.
I tried installing today's daily image using both UEFI & CSM bios
settings. That didn't make a difference.
I have installed Xubuntu & Budgie to this laptop before. The last time
was March 3.
--
You received this bug notification
Public bug reported:
ISO testing 20.04 Xubuntu daily image 20200317. Live desktop boots. But,
clicking the icon to install does nothing. I see the usb flash drive's
activity light flicker for 5-10 seconds. But, nothing happens. I ran the
launcher command from the command line. But, no msgs were
Public bug reported:
ISO testing 20.04 Lubuntu daily image (20200317). If I click the
"Cancel" button while Calamares is starting up, displaying the "waiting
on n modules to load... 4 seconds," it hangs.
Even right-clicking the Calamares placeholder in the taskbar, and
"close" doesn't entirely
Public bug reported:
ISO testing 20.04 daily image for Budgie 20200316. During boot of
install media, the media-validation step ignores "s" to skip.
Other *buntu flavors ignore "s" during a lengthy check of a large squash
file. But, Budgie is ignoring it even as it cycles through small files.
I encountered this today on two machines.[1] In both cases I was trying
to install 20.04 Lubuntu daily image using the "alongside" option. In
both cases it failed with the error msg reported for this bug. But, when
I restarted the installer, it showed the existing partition resized, and
a new
Update: I am seeing this same mistaken external monitor on an older Dell
XPS 501X[1] laptop too. Opening any application (System Settings;
Konsole) opens the window off the right-hand side of the laptop's
screen. I have to right click the taskbar and choose to move the window
from there.
Those
This bug was reported from the Live desktop. After installing &
rebooting Lubuntu, it behaves the much the same way. Letting the wifi
connection-attempt timeout results in a "connection lost" and
"connection established" balloon msg (together on the screen).
Subsequent reboots don't seem to
Public bug reported:
ISO testing 20.04 Lubuntu daily (20200315). From the Live desktop, I
click my nm-tray access point, supply the password. nm-tray will
timeout. Trying again will timeout. What works is clicking the same
access point a couple times before it times out. This causes an
immediate
FYI: I get the same wifi-disconnect with today's Xubuntu daily image.
FWIW: I also tested today's daily image for Kubuntu, Mate & Budgie (and
Lubuntu). I didn't have this experience with them. As mentioned
previously, Lubuntu had a problem connecting to wifi after rebooting
(when install was
Public bug reported:
ISO testing 20.04 daily 20200314. On the Live desktop I connect to wifi.
When I click the install icon, and choose to install 3rd party (leaving
download while installing checked), the wifi disconnects.
I rebooted and tried again to make sure it wasn't something random. (It
Public bug reported:
Testing 20.04 daily image for Ubuntu-Budgie. I've seen this with every
daily I've tested. Click the wifi icon on the task tray. A window opens
to accept the access-point's password. The user starts typing, and
realizes nothing's happening because the cursor is somewhere else.
This may be related. I've noticed the past few days that the Ubuntu
desktop daily image is being generated even though nothing has changed.
For example, today the QA Tracker says 03-14 is available. But, zsynch
says no data is downloaded (compared to the last one I had). When I run:
strings
I've been seeing this for the past 4-6 days. I've also noticed that the
new media check (during startup) doesn't appear on the screen. It seemed
to me the shutdown msg becoming unseen happened at the same time the
media check became unseen.
In both cases, what I see is my bios's splash screen.
Update: This seems to be specific to the old Dell XPS L502X laptop. I
booted the next daily image (20200313) on a new Asus Ryzen 5/Vega 8
laptop, and Kubuntu didn't detect an external monitor. (I booted that
daily on the L502X and it again believed there is a VGA screen next to
the laptop
Public bug reported:
Testing 20.04 daily image (20200312). Booted LiveUSB to Live desktop.
Executed KSystemLog from start->applications->system. The window opened
off the right side of the screen. The only reason I saw it was because I
clicked the item on the taskbar at the bottom of the desktop.
Good news. I found the problem. It's entirely related to passphrase
length.
- If I type a passphrase less than 8 characters long: I get the behavior
I reported (it appears nothing happens, no activity indicator, no
balloon error msg, nothing in the msg tray. But, the failed connection
is saved as
FYI: I booted 20200303 Lubuntu daily on a i7-2630QM 2.0ghz; NVIDIA
GeForce GT540M 2GB; Intel Centrino 6230 (Dell XPS L502X laptop). It has
the same behavior I reported in this bug.
In an hour or two I will try 20200404. I'm hoping this is just a glitch
in the copy I have (but, I did burn it to
@Chris, can you be more specific about what you did to get the failure
balloon? Did you left click nm-tray, click the non-hidden SSID, type a
bad password?
This bug report is a little confusing because that's what I reported.
But, there's a lot of examples about it working differently if accessed
@Chris, I did add the log info in #11 (one before yours).
I do see a "connection established" balloon when I use the correct
passphrase. But, I don't see a failure balloon when I use the wrong
passphrase.
I have to believe it's something screwy with my iso, how it was burned.
Something that
I just booted Lubuntu 20200303 (same LiveUSB I've been testing
throughout all this). I started journalctl. I then clicked nm-tray,
clicked the access point, and this is what appeared:
start
Mar 04 07:02:44 lubuntu NetworkManager[1632]: [1583305364.9596] device
(wlp4s0):
I left click on nm-tray, choose my wifi access point, enter an incorrect
passphrase.
Maybe the difference is that you're using a hidden ssid, and have to go
to network connections to get the job done? I'm doing the more normal(?)
choice of available access points from nm-tray. I only right-click
FYI: I have a Ryzen 3 with intel wireless. I booted the Lubuntu 20200303
image on it. Same behavior. There's no progress or error message about
being unable to connect. I don't know why my experience is different on
3 computers than you guys'.
I've verified the iso checksum. The file-verification
@Chris, I'm not having the same experience as you. I enter an invalid
passphrase, nothing happens. No connection-lost msg. And, it saves the
failed connection. The only msg I see is when I fix the password and it
connects successfully.
It doesn't appear to be machine dependent (although, both the
@Dan, I just tried the same 20200303 Lubuntu image on a Ryzen 5 machine.
It had the same behavior as reported on the old Toshiba. I click on nm-
tray, choose my wifi access point, enter an incorrect passphrase.
Nothing happens. No message that the connection was attempted/failed.
That access point
Public bug reported:
Testing Lubuntu 20.04 (2020-03-03 daily image) I selected manual
partioning. When I clicked "next," I received a warning that no
partition was flagged ESP. When I went back to fix that, there were no
flags available named ESP. Apparently "boot" is the flag to satisfy this
Public bug reported:
Testing Lubuntu 20.04 daily image (2020-03-03).In Live desktop I clicked
nm-tray, chose a wifi access point, typed the password incorrectly. Nm-
tray silently failed. No msg that the connection failed. It also kept
that access point as a "known connection". Clicking that
Public bug reported:
Screensaver Preferences (XScreenSaver 5.42, 28-Dec-2018) shows two
grayed-out items in the list of available screensavers. These are at the
top of the list. They are named 14.0985 & 26.3163.
Clicking those items causes some errors, and a black screen. (Pressing
any key gets
UPDATE: I tested Lubuntu 20.04 daily image 20200223, and the problem
reported in this bug-report doesn't exist anymore. I have marked the
status "fix released." I assume that's the proper way to close this. (If
not, sorry.).
** Changed in: syslinux (Ubuntu)
Status: New => Fix Released
--
Public bug reported:
When choosing the first Grub option to start Lubuntu, I immediately get
the error and it hangs:
[0:nn] pci: :00:00.2 AMD-ViL Unable to write to IOMMU perf
counter.
- Choosing the Grub option to "check disc for defects," results in
the same error/hang.
-
Just another FYI. PCManFM crashed again. I was right clicking to create
a new folder. When I typed the folder name and clicked "Ok," the desktop
disappeared, and came back (I didn't have to start PCManFM from the
command line, like I have had to do in the past). But, no new folder was
created.
FYI: PCManFM hasn't crashed since I uninstalled the flatpack-installed
version of GIMP 2.10.8 (and installed a PPA served apt-get package). I
did that thinking it might fix my GIMP crashes which began with 2.10.x
(when I installed Lubuntu 18.04). It did fix that. But, I haven't had a
PCManFM crash
@Janos, I want to confirm that your experience with GIMP is backwards
from mine. I ran GIMP 2.8 the whole time I was on the older Lubuntu
(described in my first comment, 3 comments above) which PCManFM crashed
all the time. GIMP was fine for me then. When I installed Lubuntu 18.04
(fresh install)
As mentioned in the previous msg, I am stracing PCManFM (1.2.5) and it
finally crashed. Attached are the last 12k lines from strace, about 25
seconds. I CTRL-break'ed out of it within 4-10 seconds. I was a little
slow, being in the middle of the previous message, trying shift my
thoughts to what
I'm also having this problem. I reported it on Lubuntu-Users mailing
list.[1] Walter referred me to this bug report. I am running strace[2].
I am pretty darn sure this began with 17.04.[3]
I mentioned on the Lubuntu mailing list that I had developed a "feeling"
(after living with it for almost a
62 matches
Mail list logo
