MX-23 beta 2 feedback thread

[andy]

Of course I will provide every info, I will be asked for. Just waiting for orders of you, real programmers. But please, do fix it.

Screenshot_20230629_085906.png

Screenshot_20230629_090051.png

Edit: My reasoning why asking to repair this bug:
For me encryption is crucial, and as I want to stay with MX Linux, I am forced to use EXT4.
But as BTRFS matures and offers nice functionality like instant snapshots, it is a welcome replacement to RSYNC.
I would like to use this nice feature, at least on my stronger machine with SSD with TBW large enough.
(in the past I have used BTRFS on LinuxMint, without encryption. After some years I have watched more closely whats going on on I/O side, and was shocked by continuous write traffic. So I stopped using BTRFS to save my SSDs. Years have passed. Then later I switched to MX-Linux, and now, after another four years, the TBW on large disks is big enough to withstand BTRFS write amplification).

[fehlix]

Of course I will provide every info, I will be asked for. Just waiting for orders of you, real programmers. But please, do fix it.

Screenshot_20230629_085906.png
Screenshot_20230629_090051.png

Thanks, yes indeed this gives us a clue.
The reason is kind of simple: MX Linux uses the /@ subvolume for root as required by timeshift (which was originally developed for Ubuntu's /@-root layout). But MX Linux is also using /@-as default mount-subvol, which Ubuntu is not using and timeshift simply assumes to always mount by default at top-subvol. We had a similare fix for non-encrypted and may need to find the place to apply this fix also for encrypted-btrfs.
You can test-breaking timeshift on Ubuntu by simply settings the default-mount subvol to /@
and Ubuntu and friends would still work, but timeshift may stop to work on btrfs.

[andy]

@fehlix ,
is this issue related?
https://github.com/linuxmint/timeshift/issues/131
edit: there is reference to issue #90, which seems exactly spot on.
https://github.com/linuxmint/timeshift/issues/90

[fehlix]

@fehlix ,
is this issue related?
https://github.com/linuxmint/timeshift/issues/131
edit: there is reference to issue #90, which seems exactly spot on.
https://github.com/linuxmint/timeshift/issues/90

Good found. Maybe someone send a MX-patch to Linux Mint.
The reason we haven't done so, is also simple: The original version we applied the default-subvol patch
was an older version. Meanwhile Linux Mint took over the maintenance and we currently using
Debian's provided version based on Linux Mint - so we may send the patch if it works to Linux Mint.

[HausiMX]

I am trying the following:
as the last line in /etc/sudoers:
%sudo ALL=(ALL:ALL) NOPASSWD: /usr/sbin/gparted
but it still asks me for the password

try this
sudo visudo
root ALL=(ALL:ALL)
%sudo ALL=(ALL:ALL) NOPASSWD: ALL

thanks for replying, but it still does not work as expected. My "workaround" is deleting my password

[Danathar]

This may be pretty esoteric, and I don't know if this is the case on the last version of MX since I'm running currently on the beta, but I enabled zram and noticed on shutdown with the live USB with persistence that an error trying to unload the zram kernel module (too early)? I have zram enabled for swap.

[dolphin_oracle]

I am trying the following:
as the last line in /etc/sudoers:
%sudo ALL=(ALL:ALL) NOPASSWD: /usr/sbin/gparted
but it still asks me for the password

gparted launches from the menu with pkexec. you could likely launch with "sudo gparted" from the cli with what you've indicated.

either way, not likely to actually be a beta issue.

[CaputAlista]

I am trying the following:
as the last line in /etc/sudoers:
%sudo ALL=(ALL:ALL) NOPASSWD: /usr/sbin/gparted
but it still asks me for the password

gparted launches from the menu with pkexec. you could likely launch with "sudo gparted" from the cli with what you've indicated.

either way, not likely to actually be a beta issue.

direct acces in kde gparted, dolphin etc
sudo pkexec env DISPLAY=$DISPLAY XAUTHORITY=$AUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true gparted

[Stevo]

I don't know if anyone has reported VLC losing hardware accelerated decoding and encoding in Bookworm, but that seems to be unavoidable with the Debian packages.

5.2.3. Limited hardware-accelerated video encoding/decoding support in VLC

The VLC video player supports hardware-accelerated video decoding and encoding via VA-API and VDPAU. However, VLC's support for VA-API is tightly related to the version of FFmpeg. Because FFmpeg was upgraded to the 5.x branch, VLC's VA-API support has been disabled. Users of GPUs with native VA-API support (e.g., Intel and AMD GPUs) may experience high CPU usage during video playback and encoding.

Users of GPUs offering native VDPAU support (e.g., NVIDIA with non-free drivers) are not affected by this issue.

Support for VA-API and VDPAU can be checked with vainfo and vdpauinfo (each provided in a Debian package of the same name).

[Eadwine Rose]

@Stevo
I reported in about Kodi a bit ago, which I found also (when googling) seemed to affect VLC. Post 54. Did include a solution that I was unable to test.

viewtopic.php?p=729379#p729379


Maybe that downgrade they mention will sort it?