Re: smartctl cannot access my storage, need syntax help

[Valerio Vanni]

Il 16/01/2024 12:08, Felix Miata ha scritto:

Tom Furie composed on 2024-01-16 08:18 (UTC):


Felix Miata writes:



/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???



By having some kind of SD card slot or similar.


So this pollution only results from a USB-connected printer? IP printer
connections don't cause it too?

Yes, IP printers don't.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 12/01/2024 22:51, Valerio Vanni ha scritto:

As Max replied to that post saying that you could avoid to kill 
Kaffeine   now you can try to:


- stop Kaffeine
- rmmod the module (what happens if you force unloading: -f option)
- suspend
- resume
- modprobe the module
- play Kaffeine

but I bet you've already realized that :)


Yes, it's what I'm going to try :-)


I found another issue: kaffeine also records DVB channels.

So, if I stop play but it's recording, module cannot be removed.

In method I find a "toggle instant record", but it doesn't help because 
it changes between on and off. If it's not recording and I "toggle", 
then it starts recording and grabs device.

It doesn't seem simple to tell *if* it's recording.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 14/01/2024 05:04, Max Nikulin ha scritto:

lsof for the same process may be more informative, but currently it 
does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does 
not set the O_CLOEXEC flag for open(2) (or does not call fcntl with 
FD_CLOEXEC). As a result, file descriptors leak to spawned processes. 
I suggest to reach a community more close to kaffeine (or maybe 
baloo) developers and ask if it could be improved.


In my system baloo is disabled.


Which package does tags.so belong to in your case?

I believe you that file indexer is disabled, but some components may 
still be called for reasons unclear for me. Maybe they do something 
useful. 


tags.so belongs to baloo-kf5, but "balooctl --status" says that it's 
disabled.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 13/01/2024 16:20, Max Nikulin ha scritto:


And this is one with a --lastchannel launch:
lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> 
/dev/dvb/adapter0/frontend0


lsof for the same process may be more informative, but currently it does 
not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set 
the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). 
As a result, file descriptors leak to spawned processes. I suggest to 
reach a community more close to kaffeine (or maybe baloo) developers and 
ask if it could be improved.


In my system baloo is disabled.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 12/01/2024 21:15, Franco Martelli ha scritto:


 > Tried, it works on DVB play.
 >
 > dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Stop


As Max replied to that post saying that you could avoid to kill Kaffeine 
  now you can try to:


- stop Kaffeine
- rmmod the module (what happens if you force unloading: -f option)
- suspend
- resume
- modprobe the module
- play Kaffeine

but I bet you've already realized that :)


Yes, it's what I'm going to try :-)
Force module unloading cannot work, it requires a specific option in 
kernel config that I've never enabled.


You can also try to not remove the module and check if stop Kaffeine, 
suspend/resume, play Kaffeine is enough.


The module does not support suspend / resume at all.
If you boot the system, *don't* open kaffeine or anything, suspend and 
resume, module is already in an unworkable state.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 12/01/2024 17:24, Max Nikulin ha scritto:

On 12/01/2024 21:36, Valerio Vanni wrote:


Tried, it works on DVB play.

dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Stop


The question is if this action can be a replacement for killing kaffeine 
before unloading the dvb kernel module.


I'll try. It could make the script simpler.
If I launch kaffeine without --lastchannel, it should work. That way I'd 
have to open tv interface by hand when I start kaffeine.


What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof 
report? I still had a hope that there is a workarond against its 
annoying behavior.


This is a file descriptors list of kioslave process, with a plain launch:

lrwx-- 1 valerio valerio 64 12 gen 20.53 0 -> /dev/pts/1
lrwx-- 1 valerio valerio 64 12 gen 20.53 1 -> /dev/pts/1
lrwx-- 1 valerio valerio 64 12 gen 20.53 19 -> '/memfd:pulseaudio 
(deleted)'

lrwx-- 1 valerio valerio 64 12 gen 20.53 2 -> /dev/pts/1
lr-x-- 1 valerio valerio 64 12 gen 20.53 25 -> 
/run/user/1000/dvbpipe.m2t
l-wx-- 1 valerio valerio 64 12 gen 20.53 26 -> 
/run/user/1000/dvbpipe.m2t

lrwx-- 1 valerio valerio 64 12 gen 20.53 3 -> 'anon_inode:[eventfd]'
lr-x-- 1 valerio valerio 64 12 gen 20.53 31 -> anon_inode:inotify
lrwx-- 1 valerio valerio 64 12 gen 20.53 4 -> 'socket:[10323613]'

And this is one with a --lastchannel launch:

lr-x-- 1 valerio valerio 64 12 gen 20.52 0 -> 'pipe:[9256505]'
lrwx-- 1 valerio valerio 64 12 gen 20.52 1 -> 'socket:[71658]'
lrwx-- 1 valerio valerio 64 12 gen 20.52 19 -> '/memfd:pulseaudio 
(deleted)'

lrwx-- 1 valerio valerio 64 12 gen 20.52 2 -> 'socket:[71658]'
lr-x-- 1 valerio valerio 64 12 gen 20.52 25 -> 
/run/user/1000/dvbpipe.m2t
l-wx-- 1 valerio valerio 64 12 gen 20.52 26 -> 
/run/user/1000/dvbpipe.m2t

lrwx-- 1 valerio valerio 64 12 gen 20.52 3 -> 'anon_inode:[eventfd]'
lr-x-- 1 valerio valerio 64 12 gen 20.52 31 -> anon_inode:inotify
lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> 
/dev/dvb/adapter0/frontend0

lr-x-- 1 valerio valerio 64 12 gen 20.52 36 -> 'pipe:[9253331]'
l-wx-- 1 valerio valerio 64 12 gen 20.52 37 -> 'pipe:[9253331]'
lrwx-- 1 valerio valerio 64 12 gen 20.52 4 -> 'socket:[9247546]'
lr-x-- 1 valerio valerio 64 12 gen 20.52 48 -> anon_inode:inotify
lrwx-- 1 valerio valerio 64 12 gen 20.52 54 -> '/memfd:pulseaudio 
(deleted)'


But perhaps it says nothing new.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 12/01/2024 15:03, Franco Martelli ha scritto:

On 11/01/24 at 15:10, Valerio Vanni wrote:
Yes, I tried, but I didn't see any "stop". There is a .Quit, but for 
this I already have "kill" command and I have to start it again.


valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /


Out of curiosity could you post the output of the following command:

~$ busctl --user tree | grep mpris


Service org.mpris.kaffeine:

Another question, can Kaffeine stop the video? Do you have a "Stop" 
button  to click over?


Yes, it has play/stop button.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 12/01/2024 12:08, Valerio Vanni ha scritto:

Il 12/01/2024 03:52, Max Nikulin ha scritto:

I assume that "org/mpris/MediaPlayer2" after "/" was lost during 
copy&paste.


I don't have MediaPlayer2 there.


busctl --user introspect org.mpris.kaffeine /Player
# ...
.Stop   method    - -    -


I saw that, but I think it's for media player component of kaffeine.
With that, you could stop the play of an audio or video file.

Do you think it can also act on DVB channels?
I can give it a try.


Tried, it works on DVB play.

dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Stop


dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Play

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 12/01/2024 03:52, Max Nikulin ha scritto:

I assume that "org/mpris/MediaPlayer2" after "/" was lost during 
copy&paste.


I don't have MediaPlayer2 there.


busctl --user introspect org.mpris.kaffeine /Player
# ...
.Stop   method    - -    -


I saw that, but I think it's for media player component of kaffeine.
With that, you could stop the play of an audio or video file.

Do you think it can also act on DVB channels?
I can give it a try.

So it is baloo (former nepomuk) search framework. A crazy idea is to 
add /dev to the list of directories that should not be indexed. I 
would try to disable baloo completely to see if behavior in respect 
to rmmmod changes.


Baloo is already disabled.

Finally I am confused. If tags.so processes die after some interval of 
time, does it mean that the kernel module can be unloaded even when 
kaffeine is started with --lastchannel and enough time has passed since 
its start?


From its stop, not from its start. There are two main cases: plain 
kaffeine and lastchannel one.


I open kaffeine without options, I play a DVB channel.
kioslave process is active, but has no lock on /dev/dvb/*
I stop play and I can immediately remove module. Even if that kioslave 
process is active.



I open kaffeine with --lastchannel, and kioslave process already has a 
lock on /dev/dvb/*
I stop play and cannot remove module, it's locked from kioslave. When 
some minute has passed, kioslave disappears and I can remove module.


Now I see another case: even during channel play, some time kioslave 
process disappears. At that point, if I stop play, I can remove module.

Re: Vmware Workstation help opens abiword

[Valerio Vanni]

Il 11/01/2024 15:42, Max Nikulin ha scritto:

On 11/01/2024 20:18, Valerio Vanni wrote:

Now it's working, but I don't understand why.



Now I find this:

/usr/share/applications/mimeinfo.cache:text/html=abiword.desktop;firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;org.kde.kimagemapeditor.desktop;
/usr/share/applications/mimeinfo.cache:x-scheme-handler/http=firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;


So Abiword does not pretend to be an http: protocol handler, just an 
application supporting HTML files.



/home/valerio/.config/mimeapps.list:text/html=firefox-esr.desktop;


Likely you have changed file associations for HTML files from KDE System 
Settings. Try to move away ~/.config/mimeapps.list or comment out 
text/html entry there and Abiword should pop back.


I confirm, it does pop back.
And every change (moving file) needs logout and login to take effect.

But I remember I already had done that (change kde settings, logout, login).

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 11/01/2024 16:25, Max Nikulin ha scritto:

On 11/01/2024 21:10, Valerio Vanni wrote:

There is a .Quit, but for this I already have "kill" command and I have
to start it again.


Applications might handle D-Bus messages more gracefully than SIGINT or 
SIGTERM signals. However in the case of kaffeine it is unlikely that 
some data may be lost.


It's what I think too.


valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /


I assume that "org/mpris/MediaPlayer2" after "/" was lost during 
copy&paste.


I don't have MediaPlayer2 there.

/lib/x86_64-linux-gnu/libexec/kf5/kioslave5 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags 
local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket


So it is baloo (former nepomuk) search framework. A crazy idea is to add 
/dev to the list of directories that should not be indexed. I would try 
to disable baloo completely to see if behavior in respect to rmmmod 
changes.


I am surprised that it dies immediately if you kill kaffeine.


It seems to always die, I've never had an error during rmmod.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 11/01/2024 15:21, Valerio Vanni ha scritto:

Il 11/01/2024 04:57, Max Nikulin ha scritto:

On 10/01/2024 04:43, Valerio Vanni wrote:

Il 07/01/2024 06:44, Max Nikulin ha scritto:


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm



setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" >  $kafdis 
XDG_CURRENT_DESKTOP=KDE \

---^^^

Do you really need it?


It's all left there from when I used setpriv to launch directly 
kaffeine, before I decided to use systemd-run.
I'll try to remove it, now I checked and they are all listed in systemd 
user environment.


I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error 
"Failed to connect to bus: No medium found"

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 11/01/2024 04:57, Max Nikulin ha scritto:

On 10/01/2024 04:43, Valerio Vanni wrote:

Il 07/01/2024 06:44, Max Nikulin ha scritto:


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm



setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" >  $kafdis 
XDG_CURRENT_DESKTOP=KDE \

---^^^

Do you really need it?


It's all left there from when I used setpriv to launch directly 
kaffeine, before I decided to use systemd-run.
I'll try to remove it, now I checked and they are all listed in systemd 
user environment.



I find it not really safe to use $kafdis without quotes.


Yes, neither I liked to catch that string. But I considered it a 
temporary solution.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 11/01/2024 05:10, Max Nikulin ha scritto:

On 10/01/2024 01:59, Valerio Vanni wrote:

Il 06/01/2024 17:38, Max Nikulin ha scritto:


I would expect something like "Stop" either from /Player or from 
org.mpris.kaffeine.


I too expected something similar: stop and play (play for resume)


Have you tried "tree" and "introspect" for org.mpris.kaffeine (not 
org.kde.kaffeine)? It works for mpv:


Yes, I tried, but I didn't see any "stop". There is a .Quit, but for 
this I already have "kill" command and I have to start it again.


valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /
NAMETYPE  SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer   interface - --
.GetMachineId   method- s-
.Ping   method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv   --
.PropertiesChanged  signalsa{sv}as  --
org.freedesktop.MediaPlayer interface - --
.Identity   method- s-
.MprisVersion   method- (qq) -
.Quit   method- --




busctl --user call org.mpris.MediaPlayer2.mpv \
     /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \
     Stop


For this we don't need to look here:
"rmmod: ERROR: Module cx23885 is in use" seems enough to see that 
kernel module cannot be removed.


I am surprised by it. You have shown that kaffeine closes the device, so 
it should be possible to remove the kernel module:



Started with --lastchannel
Video stopped:
lrwx-- 1 valerio valerio 64  9 gen 19.51 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.51 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 9 -> /dev/dri/card0

no more /dev/dvb/, but still unable to remove module cx23885


My hypotheses:
- there are more kaffeine processes (ps xuwf)


No, it has only one.

- some external process is holding the device, e.g. pulseaudio or 
pipeware sound server. Tools that might help to find it: lsof or fuser 
(unsure concerning proper options)

- Some other IPC exposed by the driver and used by kaffeine.
- I have not idea if it is possible to create direct connection between 
the dvb device and the video card so that data pass without intermediate 
interaction with kaffeine.


fuser -a /dev/dvb/adapter0/demux0 shows nothing
lsof | grep /dev/dvb shows

  10315 ?S  0:00 
/lib/x86_64-linux-gnu/libexec/kf5/kioslave5 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags 
local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket


But after some minutes this process disappeared, and I could rmmod.
Perhaps with --lastchannel it's slower to release it?

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 11/01/2024 04:48, Max Nikulin ha scritto:

So your idea would be stopping and starting channel play by dbus 
messages?
I'm looking again with introspect, and I don't see anything like 
"stop" in kaffeine.


It is independent ideas:
- Do not deal with user processes in system context (like 
/usr/lib/systemd/system-sleep/ scripts)

- Try to release dvb tuner device, so module can be unloaded.

I believe, it is a bug in the cx23885 module that it can not handle 
suspend/resume (and probably hibernate/thaw).


I agree.
If cx23885 module could handle suspend/resume, we wouldn't need all this 
mess.


Since we are talking about this module, I quote from another of your 
messages:



P.S. You have explicit modprobe cx23885. Does it mean that this module is not 
autoloaded when udev discovers the device?


The module is autoloaded when system boots.
But if I (after having moved away the script from 
/usr/lib/systemd/system-sleep/)


rmmod
systemctl-suspend
resume pc

the module is not loaded.

When I used pm-suspend, remove and reload was managed from the line
SUSPEND_MODULES="cx23885" in /etc/pm/config.d/modules

And now from rmmod and modprobe in my script.
By itself... no load.

The following is related to avoiding "setpriv" in system context and 
listening for D-Bus events in user session scope:


$ dbus-monitor --system 
"type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'"


suspend:

signal time=1704679441.870349 sender=:1.6 -> destination=(null 
destination) serial=3187 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; 
member=PrepareForSleep^^^

    boolean true


resume:

signal time=1704679448.065409 sender=:1.6 -> destination=(null 
destination) serial=3233 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; member=PrepareForSleep

    boolean false

---^

A tiny python script may be more convenient than dbus-monitor and 
similar tools.


Killing and starting kaffeine in response to these signals may be a 
workaround if the application does not allow to release the device.


Not stopping playback and not releasing the device in response to the 
PrepareForSleep signal, from my point of view, is a bug in kaffeine. I 
have no idea if vlc (broken hardware acceleration in bookworm) or 
another application may be an alternative for you.


To watch television, kaffeine seems very good to me.

Re: Vmware Workstation help opens abiword

[Valerio Vanni]

Il 11/01/2024 03:33, Max Nikulin ha scritto:

On 11/01/2024 02:44, Valerio Vanni wrote:
After, guide was not showing anymore. Calling it (click on "help" on 
Vmware application) began opening Abiword.


In kde control panel -> app -> default, Firefox is set as default 
browser.


Likely when sorted by name Abiword is before Firefox and even before 
Chromium. So you you need to override defaults in a mimeapps.list either 
system-wide or user-wide.
Now it's working, but I don't understand why. When I was trying to check 
those locations, I found it working.
But it should have been something other. Perhaps something in sequence 
between uninstall abiword, reinstall abiword, modify default browser etc.


Now I find this:

/usr/share/applications/mimeinfo.cache:application/xhtml+xml=abiword.desktop;firefox-esr.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;
/usr/share/applications/mimeinfo.cache:application/xhtml_xml=google-chrome.desktop;
/usr/share/applications/mimeinfo.cache:text/html=abiword.desktop;firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;org.kde.kimagemapeditor.desktop;
/usr/share/applications/mimeinfo.cache:x-scheme-handler/http=firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;
/usr/share/applications/mimeinfo.cache:x-scheme-handler/https=firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;
grep: /etc/xdg/mimeapps.list: File o directory non esistente
/home/valerio/.config/mimeapps.list:text/html=firefox-esr.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/http=firefox-esr.desktop;kfmclient_html.desktop;abiword.desktop;google-chrome.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/https=firefox-esr.desktop;kfmclient_html.desktop;abiword.desktop;google-chrome.desktop;
/home/valerio/.config/mimeapps.list:text/html=firefox-esr.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/http=firefox-esr.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/https=firefox-esr.desktop;

I'll try to look again when I restore bullseye disk image, this upgrade 
to bookworm is only a test.

After the restore I'll find the broken "abiword instead of firefox" state.

Re: Vmware Workstation help opens abiword

[Valerio Vanni]

Il 10/01/2024 22:28, Cindy Sue Causey ha scritto:

On 1/10/24, Valerio Vanni  wrote:

The issue began after update from debian 10 to 11. And it persists in 12.

Before, Vmware Workstation help was shown in default browser (it's an
html guide).
After, guide was not showing anymore. Calling it (click on "help" on
Vmware application) began opening Abiword.

Vmware Workstation has no option "open guide with...".

In kde control panel -> app -> default, Firefox is set as default browser.

If I uninstall abiword, logoff and login to kde, guide is shown in
Firefox. If I reinstall abiword, issue comes back.

Where should I look?



Hi.. Am taking a stab at this while you're waiting for others here.
What kinds of options are you offered if you try accessing this same
via your favorite file manager?


Now I see that it' not local html pages, it's online.
I remember local pages, but perhaps it was on older versions.

Without Abiword, Firefox tries to open links such as:

docs.vmware.com/en/VMware-Workstation-Pro/17.0/context?id=IDH_MAIN
docs.vmware.com/en/VMware-Workstation-Pro/17.0/context?id=IDH_CFG_MEMORY

But then Vmware site redirect to generic page:
https://docs.vmware.com/en/VMware-Workstation-Pro/index.html
BTW this is vmware's fault, and renders guide almost useless.

But it's still interesting to know why a link is passed to abiword 
instead of default browser.

Vmware Workstation help opens abiword

[Valerio Vanni]

The issue began after update from debian 10 to 11. And it persists in 12.

Before, Vmware Workstation help was shown in default browser (it's an 
html guide).
After, guide was not showing anymore. Calling it (click on "help" on 
Vmware application) began opening Abiword.


Vmware Workstation has no option "open guide with...".

In kde control panel -> app -> default, Firefox is set as default browser.

If I uninstall abiword, logoff and login to kde, guide is shown in 
Firefox. If I reinstall abiword, issue comes back.


Where should I look?

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 08/01/2024 04:29, Max Nikulin ha scritto:

On 07/01/2024 12:44, Max Nikulin wrote:


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm


Instead of tricks with setting proper context for a process executed 
system-wide, I would consider a process running in user sessions and 
listening for D-Bus events:


So your idea would be stopping and starting channel play by dbus messages?
I'm looking again with introspect, and I don't see anything like "stop" 
in kaffeine.


$ dbus-monitor --system 
"type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'"


dbus-monitor: unable to enable new-style monitoring: 
org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 
matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 
comm="dbus-monitor --system type='signal',interface='org") 
interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error 
name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" 
(bus)". Falling back to eavesdropping.
signal time=1704679328.754948 sender=org.freedesktop.DBus -> 
destination=:1.1080 serial=2 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=NameAcquired

    string ":1.1080"
signal time=1704679441.870349 sender=:1.6 -> destination=(null 
destination) serial=3187 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; member=PrepareForSleep

    boolean true
signal time=1704679448.065409 sender=:1.6 -> destination=(null 
destination) serial=3233 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; member=PrepareForSleep

    boolean false

A tiny python script may be more convenient than dbus-monitor and 
similar tools.


It seems too complex for me.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 07/01/2024 06:44, Max Nikulin ha scritto:

It seems neither su nor sudo add process to the user context (proper 
cgroup, XDG session), so attempts to talk to the systemd user session 
through D-Bus fail.


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm

I have realized that earlier I forgot to add --user to systemd-run. To 
my surprise, it does not work if I set 
BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of 
XDG_RUNTIME_DIR. I expected that the former is required for systemd-run.


This command works from a root shell prompt, I hope it should work 
during resume as well.


It works :-)

setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \
  env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \
  systemd-run --user --slice=app.slice /usr/bin/kaffeine 
--lastchannel > /dev/null 2>&1


Even during resume it goes into right slice.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 06/01/2024 17:38, Max Nikulin ha scritto:

On 06/01/2024 00:07, Valerio Vanni wrote:


Now I'm looking: services are

├─/MainApplication
├─/Player
├─/Television
├─/TrackList
└─/org
   └─/org/kde
 └─/org/kde/kaffeine

I tried to introspect the more likely, MainApplication and Television



.RemoveProgram  method    u -    -


Do you have any idea what it should do?

I would expect something like "Stop" either from /Player or from 
org.mpris.kaffeine.


I too expected something similar: stop and play (play for resume)




If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.


Is there an action that releases the device? "ls -l /proc/PID/fd" to 
check.


What should I find here?


If no file descriptor is resolved to /dev/ (or maybe /sys) then likely 
the kernel module may be removed without killing the application.


For this we don't need to look here:
"rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel 
module cannot be removed.



Compare opened file descriptors when video is playing and when it is 
stopped.


Started with --lastchannel
Video playing:
lr-x-- 1 valerio valerio 64  9 gen 19.47 0 -> /dev/null
lrwx-- 1 valerio valerio 64  9 gen 19.47 34 -> 
/dev/dvb/adapter0/frontend0

lr-x-- 1 valerio valerio 64  9 gen 19.47 35 -> /dev/dvb/adapter0/dvr0
lr-x-- 1 valerio valerio 64  9 gen 19.47 40 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 41 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 42 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 43 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 44 -> /dev/dvb/adapter0/demux0
lrwx-- 1 valerio valerio 64  9 gen 19.47 55 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 56 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 57 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 59 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.47 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 9 -> /dev/dri/card0

Video stopped:
lrwx-- 1 valerio valerio 64  9 gen 19.51 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.51 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 9 -> /dev/dri/card0

no more /dev/dvb/, but still unable to remove module cx23885

Started without --lastchannel

Video playing:
lrwx-- 1 valerio valerio 64  9 gen 19.56 37 -> 
/dev/dvb/adapter0/frontend0

lr-x-- 1 valerio valerio 64  9 gen 19.56 43 -> /dev/dvb/adapter0/dvr0
lr-x-- 1 valerio valerio 64  9 gen 19.56 47 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 49 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 50 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 51 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 52 -> /dev/dvb/adapter0/demux0
lrwx-- 1 valerio valerio 64  9 gen 19.56 58 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 59 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 60 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.56 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 9 -> /dev/dri/card0

Video stopped:
lrwx-- 1 valerio valerio 64  9 gen 19.56 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.56 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 9 -> /dev/dri/card0

It all seems like before, but this time module can be removed.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 06/01/2024 16:19, Max Nikulin ha scritto:

On 06/01/2024 19:44, Valerio Vanni wrote:

systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \

   /usr/bin/kaffeine --lastchannel > /dev/null 2>&1


I have not figured out how to do it, but systemd-run should not use 
--uid since this way it makes the application a part of system.slice. 
Instead the application should be in app.slice that is a child of 
user@1000.service. Inspect output of systemd-cgls.


I confirm, it's under system.slice.

So systemd-run should talk to the systemd --user instance. I have tried 
to set


XDG_RUNTIME_DIR="/run/user/1000" 
BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"


in setpriv ... env, but systemd requires authentication.


I don't see authentication requests, but it still stays under system.slice.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 06/01/2024 01:04, Greg Wooledge ha scritto:

On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote:

This way works, I don't know if it has security flaws.

systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid
"$kafgid" --init-groups  --reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis
XDG_CURRENT_DESKTOP=KDE \
   /usr/bin/kaffeine --lastchannel > /dev/null 2>&1



systemd-run(1) appears to have its own --uid and --gid options.  If
you can live without supplementary groups and the variables that are
set by --reset-env, you can probably drop the setpriv part and just use
systemd-run's --uid and --gid.

On the other hand, if it ain't broke


I tried the options when I tried systemd-run, but it didn't work.
I only added them, but now I see that you have to choose: or them or 
setpriv.


Now it's:

systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \
  env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \

  /usr/bin/kaffeine --lastchannel > /dev/null 2>&1

Outcome is the same.

The only difference is that a line is added to syslog about unit creation:
Started kaffeine-resumed.service - /usr/bin/env 
XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE 
/usr/bin/kaffeine --lastchannel.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 05/01/2024 21:47, Valerio Vanni ha scritto:

Il 05/01/2024 21:24, Valerio Vanni ha scritto:

For what I've seen, the issue is that kaffeine is started in another 
unit, systemd-suspend.service instead of user@1000.service.


systemd-suspend.service is deactivated after 90 seconds from resume, 
and kaffeine is shut down some msec before.


If I use "su" method instead of "setpriv" one, kaffeine doesn't go into 
systemd-suspend.service unit, and neither to user@1000.service one.

Instead, it goes to session-c2.scope. And works.

And systemd-suspend.service is finished and deactivated at the moment of 
resume.


It seems that systemd-suspend.service wants to end as soon as possible, 
but it cannot because it has kaffeine inside.

So it waits 90 seconds, and then terminates kaffeine.


This way works, I don't know if it has security flaws.

systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid 
"$kafgid" --init-groups  --reset-env \
  env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \

  /usr/bin/kaffeine --lastchannel > /dev/null 2>&1

All is launched from systemd-run. I choosed kaffeine-resumed as unit 
name, but if you don't put any a casual name one is created.

So systemd-suspend.service unit is free and can close.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 05/01/2024 21:24, Valerio Vanni ha scritto:

For what I've seen, the issue is that kaffeine is started in another 
unit, systemd-suspend.service instead of user@1000.service.


systemd-suspend.service is deactivated after 90 seconds from resume, and 
kaffeine is shut down some msec before.


And I found now that whole script cannot continue after this "takeover": 
final "rm" commands are not run.


-
2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service  ":1.299" 
unregistered
2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: 
Could not get icon for "audio-card-analog-pci"
2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: 
QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 
134217740, major code: 15 (QueryTree), minor code: 0
2024-01-05T19:39:20.501014+01:00 newton systemd[1]: 
systemd-suspend.service: Deactivated successfully.
2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished 
systemd-suspend.service - System Suspend.
2024-01-05T19:39:20.501227+01:00 newton systemd[1]: 
systemd-suspend.service: Consumed 1min 10.023s CPU time.
2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target 
sleep.target - Sleep.
2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target 
suspend.target - Suspend.
2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target 
suspend.target - Suspend.


If I use "su" method instead of "setpriv" one, kaffeine doesn't go into 
systemd-suspend.service unit, and neither to user@1000.service one.

Instead, it goes to session-c2.scope. And works.

And systemd-suspend.service is finished and deactivated at the moment of 
resume.


It seems that systemd-suspend.service wants to end as soon as possible, 
but it cannot because it has kaffeine inside.

So it waits 90 seconds, and then terminates kaffeine.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 05/01/2024 20:47, Franco Martelli ha scritto:

On 05/01/24 at 20:01, Greg Wooledge wrote:

On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote:
    setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups 
--reset-env \

   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis
XDG_CURRENT_DESKTOP=KDE \
   /usr/bin/kaffeine --lastchannel >/dev/null 2>&1



Adding the parameter --reset-env seems to fix, kaffeine restarts.
But, after some minutes, it closes. I don't understand why.


My first guess would be that you also need $HOME to be set, or perhaps
the current working directory, or both.  --reset-env sets HOME, SHELL,
USER, LOGNAME and PATH.  That seems like a reasonable addition.

I have no idea why it crashes later.


Could it be that he doesn't run Kaffeine in the background?

...
/usr/bin/kaffeine --lastchannel >/dev/null 2>&1 &


If I add that final &, kaffeine doesn't start at all.

For what I've seen, the issue is that kaffeine is started in another 
unit, systemd-suspend.service instead of user@1000.service.


systemd-suspend.service is deactivated after 90 seconds from resume, and 
kaffeine is shut down some msec before.


And I found now that whole script cannot continue after this "takeover": 
final "rm" commands are not run.


-
2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service  ":1.299" 
unregistered
2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: 
Could not get icon for "audio-card-analog-pci"
2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: 
QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 
134217740, major code: 15 (QueryTree), minor code: 0
2024-01-05T19:39:20.501014+01:00 newton systemd[1]: 
systemd-suspend.service: Deactivated successfully.
2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished 
systemd-suspend.service - System Suspend.
2024-01-05T19:39:20.501227+01:00 newton systemd[1]: 
systemd-suspend.service: Consumed 1min 10.023s CPU time.
2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target 
sleep.target - Sleep.
2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target 
suspend.target - Suspend.
2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target 
suspend.target - Suspend.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 05/01/2024 20:10, Valerio Vanni ha scritto:


My first guess would be that you also need $HOME to be set, or perhaps
the current working directory, or both.  --reset-env sets HOME, SHELL,
USER, LOGNAME and PATH.  That seems like a reasonable addition.

I have no idea why it crashes later.


If you see my latest message, it goes in a different unit and is shut 
down at the end of resume.


Perhaps I could try to remove --reset-env and set some parameter by hand


If I remove --reset-env and set HOME, kaffeine starts.
It seems that issue was to find file in home directory.

But still in systemd-suspend.service unit.

If, in a root shell, I launch

setpriv --reuid 1000 --regid 1000 --init-groups  \
  env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 HOME=/home/valerio 
XDG_CURRENT_DESKTOP=KDE \ 

  /usr/bin/kaffeine --lastchannel > 
/home/valerio/kaffeine_log_resumed 2>&1


kaffeine starts in user@1000.service.
Also with --reset-env.

It's only during resume that it gets into systemd-suspend.service.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 05/01/2024 20:01, Greg Wooledge ha scritto:

On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote:

setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups 
--reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis
XDG_CURRENT_DESKTOP=KDE \
   /usr/bin/kaffeine --lastchannel >/dev/null 2>&1



-
Uid, gid and display are saved and restored, so it can works also for other
users and x servers.
But with setpriv kaffeine was complaining it couldn't find .config/,
database etc and so it wasn't able to start. It seems that was ignorming
original user's home and tried to access root home.

Adding the parameter --reset-env seems to fix, kaffeine restarts.
But, after some minutes, it closes. I don't understand why.


My first guess would be that you also need $HOME to be set, or perhaps
the current working directory, or both.  --reset-env sets HOME, SHELL,
USER, LOGNAME and PATH.  That seems like a reasonable addition.

I have no idea why it crashes later.


If you see my latest message, it goes in a different unit and is shut 
down at the end of resume.


Perhaps I could try to remove --reset-env and set some parameter by hand

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 05/01/2024 17:52, Valerio Vanni ha scritto:


Adding the parameter --reset-env seems to fix, kaffeine restarts.
But, after some minutes, it closes. I don't understand why.

-Kaffeine launched by hand stays up
-Kaffeine restored with "su" method stays up
-Kaffeine restored with "setpriv" method lasts only some minute


I looked better: it lasts 90 seconds.
Not from kaffeine launch, from PC resume. If I try to set a delay inside 
the script, so that kaffeine launches after 80 seconds, it starts and 
then after 10 seconds it's closed.

If I set the delay after 90 seconds, it doesn't start at all.

I tried to redirect output to a file
/usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1

The file is created and gets data, but nothing is added at the moment of 
termination.

In syslog I found these lines at that moment:

-
2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service  ":1.299" 
unregistered
2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: 
Could not get icon for "audio-card-analog-pci"
2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: 
QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 
134217740, major code: 15 (QueryTree), minor code: 0
2024-01-05T19:39:20.501014+01:00 newton systemd[1]: 
systemd-suspend.service: Deactivated successfully.
2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished 
systemd-suspend.service - System Suspend.
2024-01-05T19:39:20.501227+01:00 newton systemd[1]: 
systemd-suspend.service: Consumed 1min 10.023s CPU time.
2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target 
sleep.target - Sleep.
2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target 
suspend.target - Suspend.
2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target 
suspend.target - Suspend.
2024-01-05T19:39:20.505334+01:00 newton NetworkManager[3208]:  
[1704479960.5049] manager: sleep: wake requested (sleeping: yes 
enabled: yes)
2024-01-05T19:39:20.505722+01:00 newton ModemManager[3206]:  
[sleep-monitor-systemd] system is resuming

--

It seems that something of resume process is ending 90 seconds after 
resume. And Service ":1.299" that gets unregistered is just kaffeine.



And now I see a difference between kaffeine launched by hand and resumed 
one:


busctl --user | grep kaffeine

with manual start
--
:1.30544374 
kaffeinevalerio :1.305user@1000.service -   -
:1.30644374 
kaffeinevalerio :1.306user@1000.service -   -
:1.30744374 
kaffeinevalerio :1.307user@1000.service -   -
org.kde.kaffeine  44374 
kaffeinevalerio :1.305user@1000.service -   -
org.mpris.kaffeine44374 
kaffeinevalerio :1.305user@1000.service -   -

--

after resume
--
1.31245857 
kaffeinevalerio :1.312systemd-suspend.service -   -
:1.31345857 
kaffeinevalerio :1.313systemd-suspend.service -   -
:1.31445857 
kaffeinevalerio :1.314systemd-suspend.service -   -
org.kde.kaffeine  45857 
kaffeinevalerio :1.312systemd-suspend.service -   -
org.mpris.kaffeine45857 
kaffeinevalerio :1.312systemd-suspend.service -   -

--

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 04/01/2024 17:11, Max Nikulin ha scritto:

On 04/01/2024 22:21, Valerio Vanni wrote:

Il 04/01/2024 15:48, Max Nikulin ha scritto:


Is it really necessary to kill kaffeine or it is enough to pause or 
to stop playing? It might be possible using a D-Bus query.

[...]

If it's started normally, it's enough to stop playing
But how would you try to request it to stop?


I would play with "busctl --user", "busctl --user tree SERVICE", "busctl 
--user introspect SERVICE OBJECT" to figure out if suitable methods are 
available.


I never used busctl.

Now I'm looking: services are

├─/MainApplication
├─/Player
├─/Television
├─/TrackList
└─/org
  └─/org/kde
└─/org/kde/kaffeine

I tried to introspect the more likely, MainApplication and Television

 /MainApplication
AMETYPE  SIGNATURE RESULT/VALUE 
 FL>

org.freedesktop.DBus.Introspectable interface - -  -
.Introspect method- s  -
org.freedesktop.DBus.Peer   interface - -  -
.GetMachineId   method- s  -
.Ping   method- -  -
org.freedesktop.DBus.Properties interface - -  -
.Getmethodssv  -
.GetAll methods a{sv}  -
.Setmethodssv   -  -
.PropertiesChanged  signalsa{sv}as  -  -
org.qtproject.Qt.QApplication   interface - -  -
.aboutQtmethod- -  -
.autoSipEnabled method- b  -
.closeAllWindowsmethod- -  -
.setAutoSipEnabled  methodb -  -
.setStyleSheet  methods -  -
lines 1-17


/Television
AMETYPE  SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer   interface - --
.GetMachineId   method- s-
.Ping   method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv   --
.PropertiesChanged  signalsa{sv}as  --
org.freedesktop.MediaPlayer interface - --
.DigitPressed   methodi --
.ListProgramSchedulemethod- a(uib)   -
.PlayChannelmethods --
.PlayLastChannelmethod- --
.RemoveProgram  methodu --



If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.


Is there an action that releases the device? "ls -l /proc/PID/fd" to check.


What should I find here?


Ideally kaffeine should implement the Inhibit interface and should close 
devices on suspend or on user session switch.


Ideally...

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 04/01/2024 16:27, Greg Wooledge ha scritto:

On Thu, Jan 04, 2024 at 03:07:59PM +0100, Valerio Vanni wrote:

Il 03/01/2024 17:41, Greg Wooledge ha scritto:

The su command is not an ideal choice for this, in fact.  The setpriv(1)
command is better suited for running programs as other user accounts,
without doing crazy PAM stuff like su does.


Can you explain better?


http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html


Thank you.

Now I'm trying this way:
-
#!/bin/bash
case "$1" in
pre)
#code execution BEFORE sleeping/hibernating/suspending
kafpid=$(pgrep kaffeine)
kafuid=$(stat -c "%u" /proc/$kafpid)
kafgid=$(stat -c "%g" /proc/$kafpid)
kafdis=$(cat /proc/$kafpid/environ | tr '\0' '\n' | grep DISPLAY)

echo $kafuid > /temp/kafuid.txt
echo $kafgid > /temp/kafgid.txt
echo $kafdis > /temp/kafdis.txt

kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1)
echo $kaffeine_killed > /temp/kafstate.txt
/usr/bin/sleep 2
/usr/sbin/rmmod cx23885
;;
post)
#code execution AFTER resuming
/usr/sbin/modprobe cx23885
/usr/bin/sleep 3
kaffeine_killed=$(cat /temp/kafstate.txt)
kafuid=$(cat /temp/kafuid.txt)
kafgid=$(cat /temp/kafgid.txt)
kafdis=$(cat /temp/kafdis.txt)

if [[ $kaffeine_killed == "" ]]; then

setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups 
--reset-env \
  env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \

  /usr/bin/kaffeine --lastchannel >/dev/null 2>&1
fi

rm -f /temp/kafstate.txt
rm -f /temp/kafuid.txt
rm -f /temp/kafgid.txt
rm -f /temp/kafdis.txt
;;
esac

-
Uid, gid and display are saved and restored, so it can works also for 
other users and x servers.
But with setpriv kaffeine was complaining it couldn't find .config/, 
database etc and so it wasn't able to start. It seems that was ignorming 
original user's home and tried to access root home.


Adding the parameter --reset-env seems to fix, kaffeine restarts.
But, after some minutes, it closes. I don't understand why.

-Kaffeine launched by hand stays up
-Kaffeine restored with "su" method stays up
-Kaffeine restored with "setpriv" method lasts only some minute

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 04/01/2024 15:48, Max Nikulin ha scritto:

On 04/01/2024 21:03, Valerio Vanni wrote:

 kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1)
 echo $kaffeine_killed > /temp/kafstate.txt
 /usr/bin/sleep 2
 /usr/sbin/rmmod cx23885


Is it really necessary to kill kaffeine or it is enough to pause or to 
stop playing? It might be possible using a D-Bus query. My expectation 
is that the device should be closed.


I choosed to kill it because it seemed easier.
If it's started normally, it's enough to stop playing
But how would you try to request it to stop?

If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 03/01/2024 17:41, Greg Wooledge ha scritto:


The UID of 1000 will have to be verified, as well as the YOURUSER.
UID 1000 is what Debian uses for the initial user account that's
created during installation, but if for some reason that's not the
account who's currently logged in, then obviously this won't work.


In my case it's ok


The su command is not an ideal choice for this, in fact.  The setpriv(1)
command is better suited for running programs as other user accounts,
without doing crazy PAM stuff like su does.


Can you explain better?


It also has the advantage
of not needing a username -- it can work with just the UID.

 uid=1000 gid=1000
 setpriv --reuid "$uid" --regid "$gid" --init-groups \
   env XDG_RUNTIME_DIR=/run/user/"$uid" DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE \
   keffeine >/dev/null 2>&1 &


In a (used like a) single user system like this, I know both username 
and uid.

In a multi-user one, you have to find them. And it doesn't seem simple.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 03/01/2024 23:52, Valerio Vanni ha scritto:

Il 03/01/2024 17:18, Franco Martelli ha scritto:

On 02/01/24 at 19:15, Valerio Vanni wrote:

This way, I don't have to remember to close kaffeine before suspend.


If you have Kaffeine always running on your system you can try this 
script:


I had an idea to do a relaunch, but it's not always running.


Now I've done this, to relaunch only if it was running:

--
#!/bin/bash
case "$1" in
pre)
#code execution BEFORE sleeping/hibernating/suspending
kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1)
echo $kaffeine_killed > /temp/kafstate.txt
/usr/bin/sleep 2
/usr/sbin/rmmod cx23885
;;
post)
#code execution AFTER resuming
/usr/sbin/modprobe cx23885
/usr/bin/sleep 3
kaffeine_killed=$(cat /temp/kafstate.txt)
if [[ $kaffeine_killed == "" ]]; then
/usr/bin/su valerio -c 'XDG_RUNTIME_DIR=/run/user/1000 
DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine --lastchannel 
>/dev/null 2>&1 &'

fi
rm -f /temp/kafstate.txt
;;
esac

--

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 03/01/2024 17:18, Franco Martelli ha scritto:

On 02/01/24 at 19:15, Valerio Vanni wrote:

This way, I don't have to remember to close kaffeine before suspend.


If you have Kaffeine always running on your system you can try this script:


I had an idea to do a relaunch, but it's not always running.

In the end don't put your script in /usr/sbin or /usr/bin use 
/usr/local/bin or /usr/local/sbin instead.


I'll do :-)

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 28/12/2023 23:17, Valerio Vanni ha scritto:


I found that pm-suspend works because it unloads and reloades that module

In "/etc/pm/config.d/modules" there is

---
SUSPEND_MODULES="cx23885"
---

Now I've replicated this on systemd side with this script similar to yours:

/usr/lib/systemd/system-sleep/dvb-suspend.sh

---
#!/bin/bash
[ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885
[ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885
exit 0


Now I've made a little change:

#!/bin/bash
[ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885
[ "$1" = "pre" ] && exec /usr/sbin/tv-sleep
exit 0


and tv-sleep does:

#!/bin/bash
/usr/bin/killall kaffeine
sleep 2
/usr/sbin/rmmod cx23885


This way, I don't have to remember to close kaffeine before suspend.
At this point, there's a couple of improvements from pm-suspend method.
One is this, the other is that pm-suspend required sudo.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 29/12/2023 02:53, Max Nikulin ha scritto:


systemd-sleep(8) does not mention /etc/systemd/system-sleep/

I am a bit puzzled by the following:
https://www.freedesktop.org/software/systemd/man/latest/systemd-sleep.html

Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/
are intended for local use only and should be considered hacks. If
applications want to react to system suspend/hibernation and resume,
they should rather use the Inhibitor interface.
https://www.freedesktop.org/wiki/Software/systemd/inhibit/


From my point of view dealing with D-Bus just to unload a kernel module 
is inconvenient. It is not an application that is started before suspend 
and should be running after resume. I am curious what is the recommended 
way for this particular use case.


It seems to me something that should be done from an application.
For example, in my case kaffeine could: stop dvb stream, unload module, 
and inverse actions after resume.


But it wouldn't help: it would work only if kaffeine is open.

This kernel module is unable to be suspended and resumed regardless of 
applications.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 29/12/2023 00:12, Charles Curley ha scritto:

On Thu, 28 Dec 2023 23:17:06 +0100
Valerio Vanni  wrote:


/usr/lib/systemd/system-sleep/dvb-suspend.sh


That may work, but by putting the script in /usr/lib/systemd, you run
the risk of it being clobbered on the next update to systemd. Better to
put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride
their analogs in /usr/lib/systemd, so it should continue to work. You
may need to do a "systemctl daemon-reload".


This way it doesn't work.

I don't have an /etc/systemd/system-sleep directory. I created it by 
hand, but scripts inside are ignored.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 28/12/2023 15:48, Franco Martelli ha scritto:

Using systemctl, kernel module is broken after every suspend, even if 
kaffeine is not running.




My system, if I don't restart Picom, freeze after a resume from suspend. 
To fix it I've placed this shell script in 
"/usr/lib/systemd/system-sleep/" directory


~$ cat /usr/lib/systemd/system-sleep/00_sleep.sh


I found that pm-suspend works because it unloads and reloades that module

In "/etc/pm/config.d/modules" there is

---
SUSPEND_MODULES="cx23885"
---

Now I've replicated this on systemd side with this script similar to yours:

/usr/lib/systemd/system-sleep/dvb-suspend.sh

---
#!/bin/bash
[ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885
[ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885
exit 0
---

This way it works, both with "systemctl suspend" and from kde menu.

Re: Everything But Sound with Bookworm

[Valerio Vanni]

Il 27/12/2023 21:47, Thomas George ha scritto:

gnome setup sound output device: speakers - builtin audio

pulseaudio output device port: speakers (plugged in)


It seems you are opening three thread for the same issue: audio not 
working in bookworm.

This way, informations are dispersed.

Re: Change suspend type from kde menu

[Valerio Vanni]

Il 25/12/2023 04:25, Valerio Vanni ha scritto:
Is there any way to change the way system is suspended from kde menu and 
from power saving in kde settings?


I mean changing the command issued.

I don't know exactly what the default command is, probably systemctl.

/usr/sbin/pm-suspend works better with kernel modules, and I'd like to 
use that


It seems that kde uses "systemctl suspend": if I use it from shell, 
result is bad as if I suspend from menu.


The defective kernel module cx23885: it doesn't support suspend and resume.
It's a module for a DVB-T PCIe card.

If I'm using kaffeine to watch DVB-T channels, I have to close it before 
suspending.

If I leave it opened, kernel module comes up in a broken state.
Closing and opening again kaffeine doesn't help, I have to
-close kaffeine
-rmmod cx23885
-modprobe cx23885
-open kaffeine

This happens suspending with pm-suspend.

Using systemctl, kernel module is broken after every suspend, even if 
kaffeine is not running.

Re: No Sound With Bookworm

[Valerio Vanni]

Il 27/12/2023 02:04, Thomas George ha scritto:
> Pulseaudio Volume control shows a strong signal audio output but nothing
> reaches the speakers.
>
> This must be a well known problem but I can't find the answer.
I found the same issue. For me, the issue was that timidity-daemon was 
taking exclusive access to audio ports.

And uninstalling timidity-daemon didn't help.

Try this:
-look at control panel ->audio, see the available outputs / profiles
-find pipewire processes and kill them
-after some second, open again control panel -> audio and see if more 
profiles appear
-if they appear, try to select them. For me, it was "analog stereo 
output" profile and "line out" device. Perhaps it's not the same text, 
my install is not in english language".

Change suspend type from kde menu

[Valerio Vanni]

Is there any way to change the way system is suspended from kde menu and 
from power saving in kde settings?


I mean changing the command issued.

I don't know exactly what the default command is, probably systemctl.

/usr/sbin/pm-suspend works better with kernel modules, and I'd like to 
use that

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

With Fedora Live I could see the difference, using
# mokutil --list-sbat-revocations.

When the system is in one of these states:
-new
-reflashed
-after old clonezilla (grub entries) load
-after Fedora live load or Fedora install

This list is
sbat,1,202103218

After load of grub page of a new Clonezilla (or live Debian) the list
becomes:

sbat,1,2022052400
grub,2


In addition to firmware reflash, I found this way to restore previous 
condition:


-in bios settings, disable secure boot
-load new clonezilla live (tried with the version that updated the 
blacklist)
-open shell, and run "mokutil --set-sbat-policy delete" (with "mokutil 
--set-sbat-policy previous" nothing changes)
-reboot with same clonezilla live (it's enough to reach boot grub 
entries, the "mokutil --set-sbat-policy delete" is run at this stage, 
just as blacklist update)

-shutdown
-in bios settings, enable secure boot

But I haven't find, so far, a way to prevent blacklist update.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 11/10/2023 04:13, Max Nikulin ha scritto:

On 11/10/2023 08:46, Valerio Vanni wrote:

Now I've tried Fedora live: it doesn't act like Debian. After it,
I can still boot old Clonezilla. Not only at grub page: I can also 
load live environment.


If the Fedora image is fresh enough


Yes, it's version 38.
I add that I tried to make it resident (install on internal disk), and 
neither this way it changes anything.


It satisfies Secure Boot requirements, but it doesn't blacklist anything.
So it doesn't seem true what whas said (don't remember by who) at the 
start of this thread, that if a system supports SB blacklists older 
images for sure.


It seems a choice. A bad choice for a live environment.


then there are some patches either in Fedora or in Debian. Perhaps
the following one

https://sources.debian.org/src/shim/15.7-1/debian/patches/block-grub-sbat3-debian.patch/


> You may check changelog, closed debian bugs, messages in developer
mailing lists for the shim package (shim-signed and shim-unsigned) 
and may try to discuss the issue with shim maintainers.


With Fedora Live I could see the difference, using
# mokutil --list-sbat-revocations.

When the system is in one of these states:
-new
-reflashed
-after old clonezilla (grub entries) load
-after Fedora live load or Fedora install

This list is
sbat,1,202103218

After load of grub page of a new Clonezilla (or live Debian) the list 
becomes:


sbat,1,2022052400
grub,2

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 04/10/2023 17:11, Max Nikulin ha scritto:


from Windows update. Then I installed Windows 11 with upgrade assistant.
So far, no blacklist of old Clonezilla.

Do you mean that installing Windows 10 or 11 from scratch could behave 
differently?


I am curious if just booting a recent media published by Microsoft (not 
install, just booting till first dialog) may change secure boot keys. If 
I have got you right, Windows with all updates installed still allows to 
boot old Clonezilla.


Just booting had no effect. Even a Windows 11 complete install from 
scratch (on empty disk) does not block old Clonezilla boot.


Tried also with "get latest updates as soon as they are available" option.

I did it to exclude something not standard in OEM installation.

If firmware has the "EFI shell" option then you may try "bcfg boot 
dump -v". Unsure if it is possible to redirect output to a file.


I'll try. Is there nothing inside Linux efi tools?


Sorry, your question is unclear for me. I was trying to suggest a way to 
inspect UEFI boot variables without disturbing its state. If Linux 
images may do something with secure boot keys then I see the following 
alternatives:

- Firmware may have EFI shell boot option included
- Perhaps there are some tools for Windows


Now I have a machine again. No, there is only the entry for "EFI shell", 
but no one is included in firmware.
It wants it on a usb key, and says that you have to disable secure boot 
to make it work.


So it doesn't seem to be a good diagnostic platform for secure boot.

My idea is to load tools on old Clonezilla, to compare the condition 
between before and after new Clonezilla boot.

I cannot use a new Linux, because I would see a just changed condition.

EDIT:
Now I've tried Fedora live: it doesn't act like Debian. After it, I can 
still boot old Clonezilla. Not only at grub page: I can also load live 
environment.

This is what I expect from a live.
So I can use it to dig into secure boot keys.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 04/10/2023 17:11, Max Nikulin ha scritto:

But neither Asus (bios from start of September) nor Microsoft 
(Windows 11) do that blacklisting.


Do you mean Windows install on hard drive or Windows install image?

should be "installed"-^


Ok, "installed".

I am curious if just booting a recent media published by Microsoft (not 
install, just booting till first dialog) may change secure boot keys. If 
I have got you right, Windows with all updates installed still allows to 
boot old Clonezilla.


I'll try. Now I don't have the machine.

If firmware has the "EFI shell" option then you may try "bcfg boot 
dump -v". Unsure if it is possible to redirect output to a file.


I'll try. Is there nothing inside Linux efi tools?


Sorry, your question is unclear for me. I was trying to suggest a way to 
inspect UEFI boot variables without disturbing its state. If Linux 
images may do something with secure boot keys then I see the following 
alternatives:

- Firmware may have EFI shell boot option included
- Perhaps there are some tools for Windows


I don't know if there is an EFI shell.

For Linux, I found this (there's no version for Debian):
https://github.com/rhboot/dbxtool

But it says it was replaced by this:
https://github.com/fwupd/fwupd

I'll try.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 03/10/2023 04:01, Jeffrey Walton ha scritto:


Does it mean that you can not boot your *old* Clonezilla live after booting a 
latest Clonezilla? If so, it is better to discuss the issue with shim or grub 
developers.


Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
anymore 2.8.1-12.


I would probably bet if you booted to Windows, the OS would check the
Forbidden Signature/Secure Boot DBX and (re)apply KB5012170 [0] as
required.


No, it hasn't happen. If you read entire discussion, it hasn't happen 
nieither with Windows 10 nor Windows 11.
The only action that breaks secure boot of Clonezilla 2.8.1-12 is 
reaching the page of Grub entries in recent Clonezilla and Debian live.



So you are probably going to have to deal with this sooner rather than
later. Both OSes are going to try to update the database with
signatures of the bad grub programs. Or I would not bet against it.

Jeff

[0] 
https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15


Yes, no one can tell... but this update has more than six months.
So far it seems that Linux has a larger revocation database.

And, even if Windows would adobt this larger database, I keep on 
considering it bad in a live environment. Be it Live Windows or Live Linux.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 02/10/2023 18:45, Max Nikulin ha scritto:

At least a warning "I'm going to blacklist something, do you want to 
continue?".


It is just speculation. To show a warning you need to execute some code. 


Yes, but I would trust a code that asks before doing some potentially 
disruptive change.
I don't want to consider a live environment like a virus. I'd like to 
considere it the opposite, a "safe thing" that leaves thing untouched.


Yes, I do. My idea is to build custom image of old Clonezilla with 
EFI files signed by you own keys. The downside is that you need  to 
install your keys to every box where you are going to boot your images.


Doesn't seem practical. I am the mantainer of that disk image: I keep 
it updated, I keep it tested after updates and after modifications I 
get from applications' mantainers.


You may ask Clonezilla developers to make an image with old version and 
new grub-signed and shim-signed. I think, you even could do it yourself.


For now, it seems more practical to use old Clonezilla. I don't have 
such control on the deploying chain (i.e. what version other technician 
use), so I have to point towards compatibility.


For security: if Asus and Microsoft (usual "house owners") are happy 
with a certain blacklist, I don't feel myself culprit of "making the 
machine less secure" if i *don't load* a Linux version that blacklists 
older ones.


Don't forget that the only times I break secure boot is when I test news 
Clonezilla versions.


Now 2.8.1-12 works. It's fast, it loads without issues on the machines 
where I need it. In few words, it does its job. Perhaps it's also 
forward compatible (I didn't test with an image taken from the latest, 
for some version it was compatibile).


I still hope that performance issue is fixed in future releases, it's 
not wise taking for sure that 2.8.1-12 will work forever, on other 
machines etc. It could be that in 2 years a chipset not supported come out.


But during last week I changed my plan. Before was "start to use new 
Clonezilla as soon as it is fixed".

Now it's "Good when it's fixed, but I'll use 2.8 as long as it works".

But neither Asus (bios from start of September) nor Microsoft (Windows 
11) do that blacklisting.


Do you mean Windows install on hard drive or Windows install image?


Machine comes with Windows 10 pre installed, and then it's updated from 
Windows update. Then I installed Windows 11 with upgrade assistant.

So far, no blacklist of old Clonezilla.

Do you mean that installing Windows 10 or 11 from scratch could behave 
differently?


Notice, it is still just a hypothesis that your issues are caused by 
new keys and it has to be confirmed by comparison key lists before 
and after.


I'll try with
efibootmgr -v
when I have here another machine


This particular command lists boot entries (location of .efi file to 
boot), not secure boot keys. I mentioned it because I had an issue 
namely with boot entries. In your case they may be unaffected.


If firmware has the "EFI shell" option then you may try "bcfg boot dump 
-v". Unsure if it is possible to redirect output to a file.


I'll try. Is there nothing inside Linux efi tools?


I don't know if Clonezilla has this package installed,


Then you may try any other live image. Perhaps some of Debian live, 
grml, system rescue have necessary tools installed.


No, I want to see the condition without loading newer Linux versions.
Otherwise, I'd see the condition generated by that live.

Unless I find a "live as I like it" (meaning that doesn't alter secure 
boot).


Clonezilla come in many flavours, the main line is based on Debian 
(stable - testing) and the alternate one is based on Ubuntu (alternate 
stable - alternate testign).


I'll try also with a non related distribution, as you suggest.


I mean an image from Fedora, not Clonezilla based on Fedora.


Yes, it was clear.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 29/09/2023 05:39, Max Nikulin ha scritto:


Yes, but couldn't it add news keys without blacklisting old ones?


It is beyond my knowledge of UEFI and secure boot: specs, requirements 
from Microsoft, and state of affairs with bugs in implementations. That 
is why I am suggesting to check for discussions related to shim & grub 
and to ask people involved into their development.


I'll try. I don't feel confortable at the idea that a live environment 
could do such a change. I think that a live should not modify the 
system. Yes, *you* could do something when it's loaded, but an automatic 
(and silent) modification at grub page seems very bad.


At least a warning "I'm going to blacklist something, do you want to 
continue?".


It's like you call a technician to fix something in your house (wall 
paintings, shower, taps etc), the technician thinks that main door is 
not secure and (also without telling you) alter the door lock and you 
cannot pass anymore. Or cannot use all your keys but only some.


The technician is live key.
And coming back from houses to IT, it's related because technician often 
use live boots to diag and fix.


I see that Clonezilla and Partclone mantainers are working on the 
matter. It's not simple, since the issue happens only on some hardware.


But let's say they'll fix in some month. I'll still be worried about 
live linux environments.



Do you mean load new EFI files in old Clonezilla?


Yes, I do. My idea is to build custom image of old Clonezilla with EFI 
files signed by you own keys. The downside is that you need  to install 
your keys to every box where you are going to boot your images.


Doesn't seem practical. I am the mantainer of that disk image: I keep it 
updated, I keep it tested after updates and after modifications I get 
from applications' mantainers.
Then I distribute the image to other technician to deploy new machine 
(or reimage old ones).


I don't have all the machines in my hands. I install only some at the 
customer by myself. Others go from reseller to other technicians and are 
cloned by them with my image.

I should consider compatibility between me and them.

Consider also that these machines' life is with Windows 10. They are 
booted with Clonezilla only before the first install and if the machine 
has to be reimaged because OS is scrambled, disk is dead and replaced etc.


I understand the idea "if some key is blacklisted, it's good that this 
blacklist is enrolled to machines".
But neither Asus (bios from start of September) nor Microsoft (Windows 
11) do that blacklisting. If, say, I don't load Clonezilla at all, 
neither old nor new one, there is no blacklist and the security level is 
the same. Basically, I load new Clonezilla and get old one blacklisted.


Is that extra security level needed?


Windows works with or without secure boot, but I'd like to leave it on.
So far, no Windows update did such thing. I also tried update from 
Windows 10 to Windows 11, and nothing happened.


Notice, it is still just a hypothesis that your issues are caused by new 
keys and it has to be confirmed by comparison key lists before and after.


I'll try with
efibootmgr -v
when I have here another machine

I don't know if Clonezilla has this package installed, if not I'll try 
to carry one or more *.debs on my USB key. It's not easy to install 
thing in that environment, because it's not based on a stable version 
but on Sid.


So when you read Clonezilla changelogs you don't read "Debian 10,11 
etc", instead you find "based on Sid of a particular date".


It took many tries to carry partclone*.deb I had downloaded from deb-src 
and then recompiled with modified source to test a flag. Many tries to 
find right Debian version.


If latest installation, repair, etc. images from Microsoft do not cause 
the issue then chances that shim+grub may behave in a similar way is 
higher.


If booting grub built by Fedora or some other distribution unrelated to 
Debian, does not cause the issue then it may be Debian specific bug. Am 
I right that Clonezilla is based on Ubuntu, so may use same patches?


Clonezilla come in many flavours, the main line is based on Debian 
(stable - testing) and the alternate one is based on Ubuntu (alternate 
stable - alternate testign).


I'll try also with a non related distribution, as you suggest.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

On Thu, 28 Sep 2023 10:08:27 +0700 Max Nikulin wrote:


Thinking more, I have realized that updating secure boot keys in firmware may 
be the only way for grub to boot. You may try to search for docs and 
discussions to confirm such guess.



After a vulnerability found in shim or grub (that allows to boot malicious code 
having no proper signature) old keys used by Linux distributions are revoked, 
new ones are generated. New images signed by new keys are published.


Yes, but couldn't it add news keys without blacklisting old ones?
Remember we are talking about a live environment, not an installed one. 
This is breaking something I was sure about.
I always considered loading a live environment a safe action. I've 
always expected to find the machine as it was before, now I cannot 
expect it anymore.


Furthermore, here we are talking about a new live that prevented another 
live from booting. But it could happen that I load a live and break 
loading of resident OS. Bad result.



Perhaps loading of updated key chain might be made transient affecting current 
boot only. I have no idea what are the obstacles: it is not allowed by secure 
boot policy, it is not supported by firmware, it is unreliable due to bugs in 
firmware, or it is just not implemented in shim or grub.


It would be a better choice.


Or forget the new ones ;-)


I have never tried it, but perhaps you may enroll your own keys and rebuild old images to 
put EFI files signed by you. See "master owner keys".


Do you mean load new EFI files in old Clonezilla?


With outdated keys secure boot does not protect you. Is it Windows that 
prevents you from just turning secure boot off? I would not be surprised if 
during some update of Windows, certificate revocation list will be updated as 
well, so you would not be able to boot your old Clonezilla any more.


Windows works with or without secure boot, but I'd like to leave it on.
So far, no Windows update did such thing. I also tried update from 
Windows 10 to Windows 11, and nothing happened.


Neither latest BIOS update from Asus (released at start of this month) 
prevented anything to boot. Perhaps hardware manufacturers choose not to 
blacklist anything, and only new grubs blacklist old ones?

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

On Wed, 27 Sep 2023 22:14:57 -0400 The Wanderer  
wrote:



The failure at (3) sounds like what happened when old grub images
were blacklisted in the UEFI Revocation List dbx. Also see
.

You should probably stop doing (4).


But this way I would have to disable secure boot to load old Clonezilla.
Disable secure boot, launch clonezilla, restore image, reenable secure 
boot, start OS.


Well, why do you need to load old Clonezilla? Surely the new version of
the Clonezilla live boot environment should work just as well as the old
one?


I never found backward compatibility in Clonezilla versions, I remember 
only a forward one a couple of years ago.


The reason is that the new version doesn't work as well as the old one.
It works, but performance has dropped to the floor. Disk image creation 
is ok, image restore is too slow if destination is an NVME drive.


It's a serious difference, I'm not a maniac that crave for milliseconds.
In numbers: 2.8.1-12 restores a Windows main partition in 6-7 minutes, 
next version 3.0.x takes 1 hour and 50 minutes. Notice: same image, from 
same source to same destination.


Latest one 3.1.x are better, but they still take 70-72 minutes.

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin  wrote:
I found the issue on latest versions of Clonezilla, but then I tried 


   ^^

with plain Debian live and the behavior is the same.


Does it mean that you can not boot your *old* Clonezilla live after booting a 
latest Clonezilla? If so, it is better to discuss the issue with shim or grub 
developers.


Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot 
anymore 2.8.1-12.




1) Machine brand new: secure boot is active, Windows 10 shows it active, I can boot an old Clonezilla live (2.8.1-12) as many times as I want. 


An old image may be signed by a key later added to certificate revocation 
lists. If so, secure boot just works as it is supposed to do.


I didn't consider that... But it makes sense.


2) I boot from USB drive Debian Live 12

https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso


If it can be reproduced with a contemporary Clonezilla or e.g. a Fedora image 
then it is not a Debian issue. If it is specific to namely Debian (I am unsure 
concerning Ubuntu, Debian derivatives) then it is better to file a bug 
providing more details.


As I said, the image that is not loaded anymore is older Clonezilla.
The image that alters secure boot is newer Clonezilla, and then I found 
that newer Debian does the same.
I still haven't found an old version of Debian that cannot boot after 
newer one (but I only tried 10 live, so far).



4) I reflash BIOS, same version, and go to point 1.


How old is your BIOS? Maybe you just restore obsolete list signing of keys.


Perhaps... I have no option during reflash.

BIOS has 9 month. One month ago a new version has been released: some 
day ago I installed it but it behaves just like the previous.



I suggest to compare

efibootmgr -v

output in the state when Clonezilla may be booted and when it fails. In 
addition public keys and certificate revocation list should be compared (unsure 
concerning commands).


I'll try as soon as I have another identical machine.


My opinion is that just loading boot images without installing OS should not 
modify firmware state. In this sense it may be a bug.


Not only I didn't install any OS, I didn't boot any image. It's enough 
to reach first page (grub entries) and the damage is done.



On the other hand, forgot old images if you have secure boot enabled.


Or forget the new ones ;-)

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

Il 27/09/2023 05:22, Jeffrey Walton ha scritto:

On Tue, Sep 26, 2023 at 10:20 PM Valerio Vanni  wrote:


Motherboard is an Asus H510M-A.

I found the issue on latest versions of Clonezilla, but then I tried
with plain Debian live and the behavior is the same.

Booting a recent Debian USB key do some modification on secure boot that
prevents some older OS to boot.

The cycle is:

1) Machine brand new: secure boot is active, Windows 10 shows it active,
I can boot an old Clonezilla live (2.8.1-12) as many times as I want.

2) I boot from USB drive Debian Live 12
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso

A note: to trigger the issue, there's no need to go on and load OS. It's
enough to see the first page (that with grub entries) and then shutdown.

3) At next boots, secure boot refuses to boot from Clonezilla live
2.8.1-12. The error is
"verification failed 0x1A security violation"
Windows 10 can still start, and shows secure boot active. Only if I
disable secure boot from BIOS, I can start clonezilla.

4) I reflash BIOS, same version, and go to point 1.

Tested many times.


The failure at (3) sounds like what happened when old grub images were
blacklisted in the UEFI Revocation List dbx. Also see
<https://lwn.net/Articles/827403/>.

You should probably stop doing (4).


But this way I would have to disable secure boot to load old Clonezilla.
Disable secure boot, launch clonezilla, restore image, reenable secure 
boot, start OS.


It's more complicated.


On that machine,

Debian live boot corrupting secure boot

[Valerio Vanni]

Motherboard is an Asus H510M-A.

I found the issue on latest versions of Clonezilla, but then I tried 
with plain Debian live and the behavior is the same.


Booting a recent Debian USB key do some modification on secure boot that 
prevents some older OS to boot.


The cycle is:

1) Machine brand new: secure boot is active, Windows 10 shows it active, 
I can boot an old Clonezilla live (2.8.1-12) as many times as I want.


2) I boot from USB drive Debian Live 12
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso

A note: to trigger the issue, there's no need to go on and load OS. It's 
enough to see the first page (that with grub entries) and then shutdown.


3) At next boots, secure boot refuses to boot from Clonezilla live 
2.8.1-12. The error is

"verification failed 0x1A security violation"
Windows 10 can still start, and shows secure boot active. Only if I 
disable secure boot from BIOS, I can start clonezilla.


4) I reflash BIOS, same version, and go to point 1.

Tested many times.

Re: Software RAID10 - which two disks can fail?

[Valerio Vanni]

"Gary Dale"  ha scritto nel messaggio
news:53437300.8020...@velcom.ca

> IMHO this is a bad setup. Because you are reading and writing to
> multiple disks at at time, you may have some speed-up, but you only
> get half the total space. And you are vulnerable to some two-disk
> failures. If you went to RAID-6, you'd get the same basic performance 
> and space
> but would be immune to two-disk failures.

But RAID-5 and RAID-6 require more computational power.
RAID6 has to generate 2 parities. 




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/li0ri3$r65$1...@ger.gmane.org

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience

[Valerio Vanni]

"Brian"  ha scritto nel messaggio
news:21032014113647.c62190855...@desktop.copernicus.demon.co.uk

> For the situation when X is started with startx would 'startx & exit'
> prevent the termination of an X session even if CTRL+ALT+FN etc gets
> console access?

I've always used "startx & exit", and it works perfectly.
It doesn't prevent the termination of an X session, but if it's terminated 
you get a logon prompt as if you had just booted the machine.




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lghej2$ven$1...@ger.gmane.org