Plasma Discover not opening

Lubuntu Support
#1

For some reason I can’t get Discover software centre to run. This is on 20.04 LTS, not sure about how long, it’s been a while since I used it last.

From GUI it just does nothing, from terminal I get Segmentation Fault (core dumped).

I tried: sudo tail -f /var/log/syslog and got:

plasma-discover [1585]: segfault at 0 io 0000000000000000 sp 00007fff8c30ffd8 error 14 in plasma-discover[564140a65000+14000]

kernel: [2186.019115] Code: Bad RIP value.

I get the same error when running a persistent USB on the same device, a couple of weeks back it ran fine testing this. However testing on another computer plasma-discover opens correctly from the same persistent live usb.

Have tried to remove plasma-discover and then install again, but no joy.

Really could use help from someone who knows what they’re doing. Thanks

#2

Nope, can’t confirm. Perhaps your USB image is corrupted and assuming you used that to install on the system, that would make your installed system corrupted.

#3

I don’t know anything, and know a lot less than @wxl who has already provided his thoughts, but I wonder if some details of the hardware may help.

Is it a resource challenged box? ie. how much RAM do you have? do you have swap enabled?

If I use a live system on most of my boxes; the system will detect a swap partition on the disk & make use of it meaning the system performs better than a system without swap available. I test using both (swap available & no-swap), but much of my live testing is on systems I use, thus swap is found at utilized.

  • How much ram do you have?
  • Do you have swap enabled? either via swapfile? or swap partition?

What is a resource challenged box?

Very subjective, but I consider a box with 2GB of ram these days resource challenged, even consider a 4GB box resource challenged at times (esp. if gpu shares the ram), but it’ll depend what you’re doing with it, as for many tasks 4GB is fine in my experience

1 Like
#4

Thanks both for responding, the image on the usb is not likely the culprit in this case as I have used on other devices successfully, it was a different image used in the hdd install. I just wanted to try and isolate the problem, but this just made me think hardware issue at first.

I then ran in recover mode and selected dkpg, then plasma-discover actually worked successfully and installed a couple of games okay.

Restarted in normal boot mode and the issue is still there. Does that mean I need to run dpkg on the main install?

The laptop has 4gb RAM, I upgraded it from 2gb a while back. Turion 64 x2 with ATI Radeon. So is pretty old, but is doing pretty well under Lubuntu so far.

Oh just to add I don’t think I setup swap no. I don’t often use the live disk, it’s more for carry about what if scenarios.

1 Like
#5

The image could be off by one bit. That one bit of difference could be so little as to make for inexplicable problems in one case but normal behavior in another. Unless you can verify the image is correct, I still suspect this.

dpkg is the backend to apt, aptitude, Muon, Discover, Synaptic, etc. etc. etc. etc. etc. etc. etc. so I’m not sure what you mean by you “selected dpkg.”

#6

When I restarted my device I chose Advanced Options then boot in recovery mode. Then I chose DPKG - Repair Broken Packages. Then Resume Noemal Boot.

This gets plasma-discover working for me, but then when I reboot again just in normal boot it fails again.

The installation on hdd was from a different image, 20.04 and has just been upgraded over time with auto updates.

The install on my usb is 20.04.2, different download entirely. I also then downloaded again to create a second usb live disk, non persistent, but of 20.04.2. Again the same problem occurred.

I did do checksum on the last download too, so kind of hoped it would be reliable.

The niggly issues are the most frustrating I feel.

#7

I don’t know that I would call this an issue (certainly not with that adverb) since you’re the only one that’s experiencing it.

You said you did a checksum on the ISO. Did you also run on one the installation media? Downloads are one thing, but copying can cause errors, too.

#8

To be honest I can’t remember, but aren’t the two installations unrelated, different ISOs downloaded months apart?

I’ve just checked again and running in recovery mode without selecting dpkg repair works too.

I just don’t have enough experience to know where to look to troubleshoot this, beyond perhaps what was last installed before the issue occurred.

#9

Not necessarily different, no. But also, there’s another possibility: your hardware is the problem.

I’m not sure exactly what that package repair does but I imagine it’s a combination of apt install -f and perhaps dpkg configure -a. You could try running those.

Have you tried 20.10? Alternately, how does Kubuntu behave (it also has Discover)?

#10

I’ll try these later as had decided to go get the 20.04.1 iso and put it on usb. This worked, Discover opens and then recommends 300 updates.

I’m wondering if the update / upgrade to 20.04.2 has something to do with it. I’d agree that it’s likely the hardware is a factor too.

#11

I’ve been testing against a fully upgraded Focal system with no problems, so I’m at 20.04.2+, really.

#12

I definitely had it working with 20.04.2 at some point, as I tested the usb install on this device. But there were some upgrades / updates recently and I did install Brackets around the same time.

Finding the what changed is likely a needle in a haystack?

Do you think I should try to install 20.04.1 and then see when it breaks again with updates and software installs?

#13

You’re saying 20.04.2 worked, so I’d start with that since it’s newer. Check the initial state. Then upgrade. Check again. And then install additional software or make additional configuration changes one step at a time. To be sure, I would make sure you reboot after every step.

With regards to Brackets, I assume you mean you installed the Snap. That could potentially be a source of problems. The one thing with unofficial Snaps is they’re in this sort of netherworld with regards to support. Upstream developers generally won’t support them because they didn’t make them. Ubuntu support will just direct you to create an issue on the Snapcrafters GitHub, leaving ultimately the few developers of the Snap to respond. Some of those Snapcraft Snaps are shotty experiments, others are completely unmaintained and forgotten.

I do not have a particularly vehement disdain for Snaps, but I do try to avoid them unless necessary. All Ubuntu flavors ship with snapd but Lubuntu is unique in that we do not ship with the core Snap. This is nice because it reduces the resource usage of snapd (which is rather ridiculously high).

#14

One last thing, which is a tangent, but worth mentioning:

Discover is a software store. It’s meant to allow people to easily find applications. It is NOT meant to provide access to all of the possible applications available. For example, most command line utilities won’t be found there.

You may want to consider Muon. It’s pre-installed on your system. It’s very similar to Synaptic if you’ve ever used that. It’s not as flashy but it does the trick. Most importantly, it shows every package in the archive.

2 Likes
#15

Thanks I will have a look at Muon. The problem is that 20.04.2 did work at some point, from usb, but I after the problem started I also created a new usb fresh and that is replicating the issue. So I might not be able to use as a starting point now.

Are all the packages in Discover snaps?

I have installed a few things using terminal and repositories, but is still pretty alien to me. I think snaps are intended for the uninitiated like myself? :slight_smile:

#16

Right, so start with 20.04.1 and follow the step wise process I suggested. Oh, and write down every step.

Most of the packages in Discover are not Snaps. Some are. Most should be Debian packages, which is what Ubuntu has run on since its inception. Discover supports Flatpaks, too. Maybe even AppImages.

Snaps, Flatpaks, and AppImages are all attempts at so-called universal packaging, which is to say they are packages which can work on any Linux distribution. For example, Red Hat distros use an RPM format whereas we use DEB. Arch has its own thing, Gentoo, too, etc. If you develop software and you want to provide packages for all the different distros, you need to create all those different package formats. It’s kind of ridiculous. Snaps work everywhere.

However, Snaps do have their quirks (as do the other universal packaging formats), too. I think we’re still a little early on in the whole universal packaging development (we meaning the Linux community in general), but the concept of having a standard isn’t a bad one.

Now whether or not that makes it easier for the user… I don’t think it makes a difference, really. Generally non-technical users want graphical interfaces. Discover is nice in that it makes things even prettier than Muon. But again, whether or not I think that either is easier than the other… I don’t think so.

I do think that both applications will be a major improvement over using the terminal to the uninitiated. Nearly any user knows how to use a search bar, click “install” to install or “remove” to remove. On the other hand, knowing the apt or snap commands to do any of those requires some experience and/or reading of the manual. The GUIs are intuitive. In that sense, they are a benefit.

3 Likes
#17

Anch’io ho lo stesso problema… Con 2 user sul portatile

#18

I have had problems with adding users before on a different laptop (18.04), but I didn’t attempt to set them up in this case. Or I don’t think I did.

#19

So this afternoon I installed 20.04.1 that worked initially but then after letting it upgrade (to 20.04.2 I checked with lsb_release -a), it rebooted and then Discover wouldn’t open again.

Think I might just see how I get on with Muon for now.

#20

What specific version is the problem for you? Also to be sure what kernel are you running?