MX-19.2 KDE Beta 1 feedback thread

[sunrat]

according to the log, grub was not installed.

Thanks for looking. Almost at the end of the installation routine I recall text displaying "Installing GRUB" even though I unchecked the install GRUB box. It wasn't installed, but wiped out the existing GRUB.

On UEFI, GRUB comes within different players. Taking out for now secureboot's shim. The first would be the grubx64.efi GRUB loader, which is placed with a subdir on the ESP. This grubx64.efi would be register with the UEFI firmware's NVRAM-table as a valid or the first to choosen bootloader.
The grubx64-efi will load the remaining "grub-stuff" and the menu from the /boot folder on the /root (or boot partition,
What could have happed, is this: You'r default grubx64.efi was loading from /dev/sda7 and displays a nice grub menu.
When you now wipe out and reinstall on /dev/sda7 , the existing grubx64.efi loaded at boot, cannot find any grub-stuff on the new install on /dev/sda7.
You propaby just need to choose another valid grub-efi loader with the NVRAM table to get loaded.
Either by using efibootmgr or select at start up (by pressing e.g F12) another loader.

Sorry I don't understand what you mean. The pre-existing GRUB is on /dev/sda4 and was working perfectly prior to MX KDE install. I install OSs regularly and just boot to Buster on sda4 and run update-grub to include a new one in the boot menu. If I deselect "Install GRUB", the installer should not touch the ESP or NVRAM table. It obviously did as reboot brought up a GRUB prompt, not its usual boot screen.
I did fix it by booting into Buster from a REFInd flash key and reinstalling GRUB from there, but it shouldn't have been broken in the first place.

[wdscharff]

referring to my first posting.
It wasn't the Nvidia driver. After I removed the driver and restarted, unchanged behaviour: kwin_x11 generally loads one thread in idle mode with 100%.
That alone wouldn't bother me, but the processor temperature is generally higher and makes the fan run permanently.

[uncle mark]

Any chance Synaptic could be added and MX-Update call that instead of Muon?

I believe that fehlix worked on mx-updater so that if SYnaptic is on your system in place of muon, apt-notifier will call it.

You could test these changes to mx-updater by installing Synaptic yourself and removing muon - if you don't mind the risk of messing with this beta. After all, this is the testing period.

That is the way it works for me. Synaptic installed and that is what apt-updater shows.But I left Muon installed for testing purposes.

Thanks guys. You were way ahead of me, obviously.

[dolphin_oracle]

Thanks for looking. Almost at the end of the installation routine I recall text displaying "Installing GRUB" even though I unchecked the install GRUB box. It wasn't installed, but wiped out the existing GRUB.

On UEFI, GRUB comes within different players. Taking out for now secureboot's shim. The first would be the grubx64.efi GRUB loader, which is placed with a subdir on the ESP. This grubx64.efi would be register with the UEFI firmware's NVRAM-table as a valid or the first to choosen bootloader.
The grubx64-efi will load the remaining "grub-stuff" and the menu from the /boot folder on the /root (or boot partition,
What could have happed, is this: You'r default grubx64.efi was loading from /dev/sda7 and displays a nice grub menu.
When you now wipe out and reinstall on /dev/sda7 , the existing grubx64.efi loaded at boot, cannot find any grub-stuff on the new install on /dev/sda7.
You propaby just need to choose another valid grub-efi loader with the NVRAM table to get loaded.
Either by using efibootmgr or select at start up (by pressing e.g F12) another loader.

Sorry I don't understand what you mean. The pre-existing GRUB is on /dev/sda4 and was working perfectly prior to MX KDE install. I install OSs regularly and just boot to Buster on sda4 and run update-grub to include a new one in the boot menu. If I deselect "Install GRUB", the installer should not touch the ESP or NVRAM table. It obviously did as reboot brought up a GRUB prompt, not its usual boot screen.
I did fix it by booting into Buster from a REFInd flash key and reinstalling GRUB from there, but it shouldn't have been broken in the first place.

I'll look into that but if it was UEFI you could have just selected whatever EFI stub you want to boot from the system's UEFI panel. unlike mbr installs, UEFI installs won't overwrite another distro's EFI stub, but they will change the boot order.

[fehlix]

Sorry I don't understand what you mean. The pre-existing GRUB is on /dev/sda4 and was working perfectly prior to MX KDE install. I install OSs regularly and just boot to Buster on sda4 and run update-grub to include a new one in the boot menu. If I deselect "Install GRUB", the installer should not touch the ESP or NVRAM table. It obviously did as reboot brought up a GRUB prompt, not its usual boot screen.
I did fix it by booting into Buster from a REFInd flash key and reinstalling GRUB from there, but it shouldn't have been broken in the first place.

In UEFi, there is no one GRUB on /dev/xvz. You install GRUB-loader onto the ESP and the remaingin part from one ot the /boot/grub folders. And often there are more then one GRUB loader on the ESP. You need to look into the NVRAM table, this table is sometime re-orginzed the bootorder by UEFI firmaware itself. As the installer did not touch the ESP or the NVRAM table, you can tidy up ESP grub loader an NVRAM entries to avoid the reordering.

[baldyeti]

The logic changed within apt-notifer: If synaptic is installed, apt-notifier will use it. Otherwise if muon is found it will use muon.

Isn't muon supposedly obsoleted by discover ? I am certainly *not* asking for the inclusion of discover, but in an MX distro wouldn't it make more sense to just default to MXPI in the absence of synaptic ? (and not include muon either)

[dolphin_oracle]

The logic changed within apt-notifer: If synaptic is installed, apt-notifier will use it. Otherwise if muon is found it will use muon.

Isn't muon supposedly obsoleted by discover ? I am certainly *not* asking for the inclusion of discover, but in an MX distro wouldn't it make more sense to just default to MXPI in the absence of synaptic ? (and not include muon either)

muon is more a synaptic clone and has many of the features people use synaptic for.

the version of discover available in the debian repo is bad. very bad. it fails at things like installing ffmpeg for instance.

using muon/mx-pi combo gives the same feature set as on the flagship Xfce iso.

[i_ri]

Hello dolphin_oracle and everyone
First time ever pressing the power button here on an AHS version.
Started right up. Stared at an animation while the system set default for the two display monitors.
Got wireless up. posting from live MX_KDE.
Splendid.

Code: Select all

demo@mx1 
-------- 
OS: MX x86_64 
Host: HP EliteBook 8440p 
Kernel: 5.6.0-2-amd64 
Uptime: 18 mins 
Packages: 2319 (dpkg) 
Shell: bash 5.0.3 
Resolution: 1600x900, 1280x1024 
DE: Plasma 
WM: KWin 
Theme: Breeze [GTK2/3] 
Icons: breeze [GTK2/3] 
Terminal: yakuake 
CPU: Intel i5 M 560 (4) @ 2.667GHz 
GPU: Intel Core Processor 
Memory: 721MiB / 3732MiB 

next step experience the installer ... ...

[fehlix]

The logic changed within apt-notifer: If synaptic is installed, apt-notifier will use it. Otherwise if muon is found it will use muon.

Isn't muon supposedly obsoleted by discover ? I am certainly *not* asking for the inclusion of discover, but in an MX distro wouldn't it make more sense to just default to MXPI in the absence of synaptic ? (and not include muon either)

Muon is a bit closer to synaptic, where discover is kind of Gome-software Center.
For user who do not prefer to install Synaptic, we just kept Muon. Also within the right-click menu:
we have already an entry to open MXPI. I think it's a fair enough compromise.

[asqwerth]

Isn't muon supposedly obsoleted by discover ? I am certainly *not* asking for the inclusion of discover, but in an MX distro wouldn't it make more sense to just default to MXPI in the absence of synaptic ? (and not include muon either)

I tried to like Discover. You should see my posts in the dev team private board, heh.

First I didn't like it because it didn't make clear what updateable packages came from the normal repos and which from flatpaks. You could be installing updates to your flatpak runtimes (1 GB each runtime!) if your flatpak was being actively developed and followed the latest (say) Gnome versions, and wondering how come your disk space was filling up so fast.

Then I tried to give it a chance because it could handle updates and had a nice notifier icon. And it did handle updates fine if you didn't have any flatpaks to worry about.

Then I tried to change repos from within its own repo settings, and found that it was weird. While installing updates brings up a pkexec request window for root password, trying to change repo sources brought up a different authentication window (for kdesu, which I think is deprecated) and hung the program.

The final clincher: search is bad in Discover:

My post from dev board:

Argh. Discover is not very good at searching for packages.

It cannot find papirus icons in our repos, if you make a general search or search from within "Applications" category. You get lots of themes and icons that pop up. Not just papirus. I also tried "papirus-" and "papirus-icon-theme" as search terms. Doesn't help even though the latter is the proper package name.

If you search under Application Add-ons, I found an entry the first time, but I can't repeat it. It seems to categorise icons as an Add-on, and looks for it in the KDE store rather than distro repos. The search is long and trawls up lots of other themes and icons.

I installed Muon from Discover, and Muon was able to locate and install papirus from our repos immediately. I think it will be very frustrating to depend on Discover for fine-grained searches. Unless we are going to tout MXPI as the Synaptic replacement, Discover alone is inadequate.