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.

[kaffeine] [Bug 479872] New: Option --lastchannel doesn't free dvb adapter after stop

[Valerio Vanni]

https://bugs.kde.org/show_bug.cgi?id=479872

Bug ID: 479872
   Summary: Option --lastchannel doesn't free dvb adapter after
stop
Classification: Applications
   Product: kaffeine
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mche...@kernel.org
  Reporter: valerio.va...@inwind.it
  Target Milestone: ---

SUMMARY
***
If I start kaffeine without options and I play a DVB channel when I click stop,
kaffeine frees immediately /dev/dvb/xxx device.
If I start kaffeine with --lastchannel and do the same (click stop),
/dev/dvb/xxx device is busy.

A child process is locking it: 

lsof finds this:
kioslave5 21356  valerio   35u  CHR 
212,3 0t01173529 /dev/dvb/adapter0/frontend0

  21356 ?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/kaffeineppPvOO.1.kioworker.socket

After some minutes, this process ends and dvb device is free an can be
rmmod-ed.

***

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian Bookworm 64 bit
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.18

-- 
You are receiving this mail because:
You are watching all bug changes.

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


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


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


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

[kaffeine] [Bug 471025] kaffeine running after closing interface

[Valerio Vanni]

https://bugs.kde.org/show_bug.cgi?id=471025

--- Comment #1 from Valerio Vanni  ---
It doesn't happen anymore on Debian 11 (kaffeine 2.0.18).

-- 
You are receiving this mail because:
You are watching all bug changes.

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.

[kaffeine] [Bug 471025] New: kaffeine running after closing interface

[Valerio Vanni]

https://bugs.kde.org/show_bug.cgi?id=471025

Bug ID: 471025
   Summary: kaffeine running after closing interface
Classification: Applications
   Product: kaffeine
   Version: 2.0.15
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mche...@kernel.org
  Reporter: valerio.va...@inwind.it
  Target Milestone: ---

Created attachment 159655
  --> https://bugs.kde.org/attachment.cgi?id=159655=edit
Console output, from command "kaffeine" to exit (before CTRL+C)

SUMMARY
***
I'm using kaffeine 2.0.15 on Debian 10. The issue appeared after update from
Debian 9, and it shows most of the times but not every time.
I use kaffeine only to watch TV with DVB-T card, I don't use it as media
player.

When I start kaffeine in the first place, it works. I watch DVB-T channels.
Then I close interface, and get no error.

Then I try to open it again, it doesn't open. I see for 3-4 seconds the
application appear on bar (nothing in desktop) and then it disappears.

Before trying to open, I find this leftover:
23939 ?Sl 0:05 /usr/bin/kaffeine
23948 ?S  0:00 file.so [kdeinit5] file
local:/run/user/1000/klauncherToADQP.1.slave-socket
local:/run/user/1000/kaffeineaTZRyV.1.slave-socket

And after trials to reopen I find additional "kaffeine" processes:
939 ?Sl 0:05 /usr/bin/kaffeine
23948 ?S  0:00 file.so [kdeinit5] file
local:/run/user/1000/klauncherToADQP.1.slave-socket
local:/run/user/1000/kaffeineaTZRyV.1.slave-socket
23979 ?Sl 0:00 /usr/bin/kaffeine
23982 ?Sl 0:00 /usr/bin/kaffeine

I I kill all processes, I can open kaffeine again and everything works.

If I try to launch kaffeine from a terminal, it's the same: it starts, but when
I close interface I find console still busy. In this case, I can terminate with
CTRL+C and get process killed (and console available again).


***


STEPS TO REPRODUCE
1. Open kaffeine
2. Open television tab and watch some channel
3. Close kaffeine from interface
4. Try to open again kaffeine

OBSERVED RESULT
Nothing happens

EXPECTED RESULT
Kaffeine opens

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian 10 64bit - kernel 5.15.114
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.54.0
Qt Version: 5.11.3

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 421795] New: DVB-T channels received on multiple frequencies

[Valerio Vanni]

https://bugs.kde.org/show_bug.cgi?id=421795

Bug ID: 421795
   Summary: DVB-T channels received on multiple frequencies
   Product: kaffeine
   Version: 2.0.5
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: mchehab+sams...@kernel.org
  Reporter: valerio.va...@inwind.it
  Target Milestone: ---

SUMMARY
In my antenna system I receive some MUX and its channels on multiple
frequencies.
This is fine, they come from different repeaters and they are redundant. If one
falls, I can see the channels from the others.
When I launch channels scan, they are all found, but then kaffeine stores them
once in channel list. Only one of the frequency (I don't know why one instead
of another: perhaps signal strength?).


STEPS TO REPRODUCE
1. Scan channels, some are on multiple frequencies
2. Add them to list

OBSERVED RESULT
Multiple channels are stored only one time. For example, I receive a MUX on 618
Mhz and on 778 Mhz: only "778" copies are stored.

EXPECTED RESULT
Both channels are stored, with a different name (channel-1, channel-2, as it
already happens for multiple lcns).


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

usb ports working only with pci=noacpi (bugzilla 94261)

[Valerio Vanni]

Here all details (dmesg, lspci etc):
https://bugzilla.kernel.org/show_bug.cgi?id=94261

The machine is:
LENOVO 90BX0018IX/Aptio CRB, BIOS O07KT49AUS 12/18/2014

OS is a Debian Wheezy amd64.

The issue is that USB ports work only starting the kernel with 
"pci=noacpi" parameter.
Without it, nothing plugged into usb ports is detected.
In particular, "lsusb" returns "unable to initialize libusb: -99".
The same happens with a 3.13.11 kernel (same config).

I've tried newer kernels (3.18.8, 3.19) and they show the same issue. With 
the difference that, with "pci=noacpi" they don't start at all.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

usb ports working only with pci=noacpi (bugzilla 94261)

[Valerio Vanni]

Here all details (dmesg, lspci etc):
https://bugzilla.kernel.org/show_bug.cgi?id=94261

The machine is:
LENOVO 90BX0018IX/Aptio CRB, BIOS O07KT49AUS 12/18/2014

OS is a Debian Wheezy amd64.

The issue is that USB ports work only starting the kernel with 
pci=noacpi parameter.
Without it, nothing plugged into usb ports is detected.
In particular, lsusb returns unable to initialize libusb: -99.
The same happens with a 3.13.11 kernel (same config).

I've tried newer kernels (3.18.8, 3.19) and they show the same issue. With 
the difference that, with pci=noacpi they don't start at all.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bug#745373: timidity-daemon: timidity daemon grabs exclusive audio access or doesn't work

[Valerio Vanni]

Package: timidity-daemon
Version: 2.13.2-40.1
Followup-For: Bug #745373

  - change the home dir of the timidity user (e.g. with usermod) to
/var/run/timidity where he actually has writing rights.

I've tried to change it by hand in /etc/passwd.
But it doesn't work, midi applications still require exclusive access.



I get these message  trying to start a midi application (but they are present
even when timidity works thanks to no concurrency)

Sep 25 02:07:16 newton pulseaudio[28411]: [pulseaudio] server-lookup.c: Unable
to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch
a dbus-daemon without a $DISPLAY for X11
Sep 25 02:07:16 newton pulseaudio[28411]: [pulseaudio] main.c: Unable to
contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a
dbus-daemon without a $DISPLAY for X11



-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.11 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages timidity-daemon depends on:
ii  adduser   3.113+nmu3
ii  timidity  2.13.2-40.1

timidity-daemon recommends no packages.

timidity-daemon suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725415: group pcscd doesn't exist

[Valerio Vanni]

Package: libccid
Version: 1.4.7-1
Followup-For: Bug #725415

  * What led up to the situation?
After the update from Squeeze to Wheezy, during every boot I see this message:
udevd[***]: specified group 'pcscd' unknown
The 'pcscd' group is not present in /etc/passwd, and I never removed it.

The offending rules are here (part of libccid package)
/lib/udev/rules.d/92-libccid.rules

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to purge pcscd and libccid, and then to reinstall them.

   * What was the outcome of this action?
Nothing changed, the error still shows up.

   * What outcome did you expect instead?
I hoped that was some old stale file, and thatpurging and reinstalling the
package would have solved the issue.



-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libccid depends on:
ii  libc6 2.13-38+deb7u4
ii  libusb-1.0-0  2:1.0.11-1

libccid recommends no packages.

Versions of packages libccid suggests:
pn  pcmciautils  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762501: bind9rndc: connect failed: 127.0.0.1#953: connection refused

[Valerio Vanni]

Package: bind9
Version: 1:9.8.4.dfsg.P1-6+nmu2+deb7u2
Severity: normal

   * What led up to the situation?

The error shows during the service stop (either launched by hand or when the
system shuts down)

server:~# /etc/init.d/bind9 stop
[] Stopping domain name service...: bind9rndc: connect failed:
127.0.0.1#953: connection refused
waiting for pid 2584 to die
.. ok
server:~#
It happened also in previous debian releases (I remember for sure etch and
squeeze, not sure about lenny).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

The only workaround I found is
chown root.bind /etc/bind/rdnc.key (by itself, it's bind.bind).
The permissions were 640, and I didn't change them.



-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bind9 depends on:
ii  adduser3.113+nmu3
ii  bind9utils 1:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  debconf [debconf-2.0]  1.5.49
ii  libbind9-801:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  libc6  2.13-38+deb7u4
ii  libcap21:2.22-1.2
ii  libdns88   1:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u2
ii  libisc84   1:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  libisccc80 1:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  libisccfg821:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  liblwres80 1:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  libssl1.0.01.0.1e-2+deb7u12
ii  libxml22.8.0+dfsg1-7+wheezy1
ii  lsb-base   4.1+Debian8+deb7u1
ii  net-tools  1.60-24.2
ii  netbase5.0

bind9 recommends no packages.

Versions of packages bind9 suggests:
ii  bind9-doc   1:9.8.4.dfsg.P1-6+nmu2+deb7u2
ii  dnsutils1:9.8.4.dfsg.P1-6+nmu2+deb7u2
pn  resolvconf  none
pn  ufw none

-- Configuration Files:
/etc/bind/named.conf.local changed:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include /etc/bind/zones.rfc1918;
// add entries for other zones below here
zone 0.0.127.in-addr.arpa {
type master;
file /etc/bind/db.0.0.127;
};
zone vanni.it {
type master;
notify no;
file /etc/bind/db.vanni.it;
};
zone 1.168.192.in-addr.arpa {
type master;
notify no;
file /etc/bind/db.1.168.192;
};  

/etc/bind/named.conf.options changed:
options {
directory /var/cache/bind;
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable 
// nameservers, you probably want to use them as forwarders.  
// Uncomment the following block, and insert the addresses replacing 
// the all-0's placeholder.
// forwarders {
//  0.0.0.0;
// };

//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys.  See https://www.isc.org/bind-keys

//
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
};


-- debconf information:
  bind9/different-configuration-file:
  bind9/run-resolvconf: true
  bind9/start-as-user: bind


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725415: group pcscd doesn't exist

[Valerio Vanni]

Package: libccid
Version: 1.4.7-1
Followup-For: Bug #725415

# generic CCID device (bInterfaceClass = 0x0b)
# change group from default root to pcscd
ENV{ID_USB_INTERFACES}==*:0b:*, GROUP=pcscd

Even this line? Or should I simply remove , GROUP=pcsdc



-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libccid depends on:
ii  libc6 2.13-38+deb7u4
ii  libusb-1.0-0  2:1.0.11-1

libccid recommends no packages.

Versions of packages libccid suggests:
pn  pcmciautils  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: OT ubicazione partizione root/boot

[Valerio Vanni]

Luca Costantino luca.costant...@gmail.com ha scritto nel messaggio
news:CA+vfGHZA3TGRhC2rW7v=43=z_jckv7rnqde1aavta8+1h45...@mail.gmail.com
 altrimenti c'è il tempo di spostamento della testina + tempo di seek.
 gia', e visto che il tempo di seek e' trascurabile rispetto al tempo
 di movimento del braccio, anche su tracce adiacenti, continuo a
 pensare che sia preferibile tenere li' i dati a cui si vuole accedere
 un po' piu' velocemente

E' talmente poca la roba in /boot che la differenza non è apprezzabile, 
secondo me.




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

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

Re: [OT] Una ferale notizia?

[Valerio Vanni]

Il Tue, 19 Aug 2014 23:34:30 +0200, MaX maxlinux2...@gmail.com ha
scritto:

È stato cosí anche in internet.. Linux e tutti gli altri sapori unix,

Per un attimo mi è sembrato che si parlasse di cucina ;-)



-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/knmgv9d853km0itp0mustuskg8kicqh...@4ax.com

Re: squeeze - wheezy, /var XFS, crash.

[Valerio Vanni]

Il Sat, 16 Aug 2014 11:21:19 +0200, Marco Gaiarin
marcog...@libero.it ha scritto:
Martedì ho aggiornato un server HP ProLiant ML350 G4p da squeeze a wheezy,
dove ho una serie di filesystem, in particolare ho /var separato e su XFS.

L'aggiornamento era in due tempi, ho fatto la prima parte (fino al reboot)
da remoto, quindi sono andato fisicamente sul server a fare altre cose.

Probabilmente è di poco aiuto, comunque forse l'aggiornamento a Wheezy
fa qualcosa di strano sul filesystem /var.
Ricordo bene che quando ho aggiornato una macchina, qualche tempo fa,
il riavvio sembrava regolare (non è stato spento né da tasto né da
sysrq) ma poi saltava fuori un recovering journal proprio su /var.

E saltava fuori sempre, lo ricordo perché prima di aggiornare la
macchina ho fatto dei test su una copia immagine del disco.

Passato quello, però, la macchina non ha avuto problemi.


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/71suu9lnejell2j5vusmraese17hk27...@4ax.com

Re: Amd64 Fake? O.o

[Valerio Vanni]

Il Sat, 09 Aug 2014 16:14:33 +0200, Alessandro
newslet...@miriodev.net ha scritto:

  * Installazione di Debian64 (direttamente dalla iso a 64bit)

Cosa rispondono

'uname -a'
dpkg --print-architecture
dpkg --print-foreign-architecture


  * Ho installato linux-headers-3.2.0-4-686-pae necessari per alcuni
pacchetti ( ad esempio vmware tool)
  * Riavviato in linux-headers-3.2.0-4-686-pae

I comandi sopra cosa rispondono?


 e PUFF magicamente il
sistema diventa a 32bit, e nel caso in cui si installasse il kernel
a 64bit, andrebbe fatta la conversione in un sistema a 64bit

Se metti un kernel a 32 bit, il sistema non può che andare a 32 bit.
Se però è già a 64, il boot non può arrivare a termine.



-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/022gu9ldnvmsndr911nsqrv2rfnkckc...@4ax.com

Re: problemi sui log dopo aggiornamento a wheezy

[Valerio Vanni]

Piviul piv...@riminilug.it ha scritto nel messaggio
news:53e09a89.6030...@riminilug.it
 Piviul scrisse in data 05/08/2014 10:39:

 Ciao a tutti, dopo aver aggiornato un server da squeeze a wheezy
 alcuni log tra cui kern.log e syslog non vengono più aggiornati...
 come è possibile? A qualcuno viene in mente dove si possa guardare?
 Risolto... non so come mai ma non c'era alcun demone per la
 generazione dei log.

E' capitato anche a me. E' un vecchio server, vero?

Fino a Etch i demoni predefiniti erano sysklogd e klog, da Lenny in avanti 
invece è rsyslog.
Solo che durante l'aggiornamento da Etch a Lenny la transizione non viene 
fatta in automatico.
Squeeze non dice niente a riguardo, né prende iniziative.

Purtroppo durante l'aggiornamento da Squeeze a Wheezy vengono rimossi i 
due sopra ma non viene installato in automatico rsyslog. 




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

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

Re: Kernel 3.15 Fails

[Valerio Vanni]

Alessandro newslet...@miriodev.net ha scritto nel messaggio
news:53d7f874.40...@miriodev.net
 E' quello che pensavo anche io, ma...

 $ uname -a
 Linux laptop 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u1 *i686*
 GNU/Linux

Quello è un kernel (a 32 bit).

L'architettura la vedi con
dpkg --print-architecture
dpkg --print-foreign-architectures

Ma, se anche tu avessi qualche pacchetto a 64 bit, su quel kernel non 
potrebbe girare.




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

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

Re: Kernel 3.15 Fails

[Valerio Vanni]

Davide Prina davide.pr...@gmail.com ha scritto nel messaggio
news:53d7e0ce.4040...@gmail.com

 Mi sa che non è così semplice.
 Come fa un sistema a 64 bit a funzionare se c'è solo Linux a 64 e
 tutto il resto è a 32bit... anche l'architettura impostata come
 default è a 32bit... Il minimo che può fare è non partire.

Perché un kernel a 64 bit funzioni in uno spazio utente ancora a 32 è 
necessario che sia abilitato CONFIG_IA32_EMULATION. Con quest'impostazione 
non ci sono problemi.

Potrebbero essercene in prospettiva, secondo me. Se si installa software 
non pacchettizzato (installer proprietari) bisogna vedere cosa guarda 
questo. Se si limita alla versione del kernel, potrebbe installare cose a 
64 bit che poi non saranno gestite nello spazio utente. Oppure potrebbe 
rifiutare di installarsi.

 La strada più semplice e senza rischi è fare un backup e installare da
 zero una versione Debian a 64bit.

 Se invece vuoi convertire il sistema, mi sa che devi, dopo aver fatto
 il backup, fare un bel po' di passi in più... rischiando di non
 riuscire più ad avviarlo...

La probabilità è molto alta, e sono stati da cui non si torna più indietro 
(per lo meno non i comuni mortali). Secondo me la miglior cosa è fare una 
copia immagine del disco e lavorare su quella, poi quando si è messa a 
punto la procedura si passa a lavorare sull'originale (e se va storto 
qualcosa si ha l'immagine).
Io ho fatto qualche mese fa un aggiornamento Wheezy 32 - Wheezy 64, e non 
è stato per niente facile. Se avessi proceduto con leggerezza sul disco 
originale... ciao installazione!

 Non ho mai provato, ma penso che
 1) devi crearti un'architettura mista i386/amd64
 dpkg --add-architecture amd64
 2) aggiornare la lista dei pacchetti
 apt-get update
 3) installarti a 64bit le librerie principali e tutto ciò che è
 indispensabile per l'avvio: Linux, busybox, libc, ...

 Non so se il passaggio da i386 a amd64, come architettura principale,
 avviene in automatico con l'installazione dei pacchetti fondamentali o
 lo devi fare tu manualmente.

Credo che avvenga quando viene installata la versione amd64 di dpkg, ma a 
quel punto i patatrac sono ancora tutti dietro l'angolo. Il tutto si 
incarta che è una meraviglia con dipendenze non risolvibili tra programmi 
a 32, programmi a 64, librerie a 32 e librerie a 64.
Ho trovato varie guide in giro: nessuna ha funzionato seguendola alla 
lettera.
E' troppo diverso un sistema da un altro, differenti combinazioni di 
pacchetti possono generare risultati imprevedibili.

La più valida per me è stata questa:
http://nanonanonano.net/linux/debian/crossgrading

La chiave di volta per arrivare in fondo è stata un apt-get 
dist-upgrade -f al posto del consigliato apt-get install -f (che mi 
tirava via mezzo sistema).




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

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

Re: distribuzione su SSD

[Valerio Vanni]

Piviul piv...@riminilug.it ha scritto nel messaggio
news:53903379.8030...@riminilug.it
 Ciao a tutti, oramai è un annetto che mi sono convertito a debian
 testing ma mi chiedevo se era il caso di installarla anche su un
 ultrabook nel senso che ho sentito dire che i dischi SSD soffrono in
 scrittura e sulla testing tutti i giorni ci sono centinaia di MB di
 aggiornamenti... parlano di mettere la /tmp in ram, disabilitare il
 journaling...

Per finire un SSD, oggi, ci vuole ben altro che una testing con i suoi 
aggiornamenti.

Ci si potrebbe provare montandolo su un server con un database bello 
carico di lavoro ;-) 




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lmpp7s$2pq$1...@ger.gmane.org

Re: distribuzione su SSD

[Valerio Vanni]

dea d...@corep.it ha scritto nel messaggio
news:20140605133322.m74...@corep.it
 Ci si potrebbe provare montandolo su un server con un database bello
 carico di lavoro ;-)

 Esistono SSD di fascia enterprise appositamente progettati per i
 server.

Certo, io dicevo che sarebbe un modo per provare a finire un SSD normale.

 Il mondo degli SSD è entrato pesantemente anche nel settore server,
 ma non penso montino le stesse celle delle versioni consumer.
 Lo penso perchè mentre nel settore consumer trovi SSD anche di
 capacità elevata, nel settore enterprise li trovi solo di capacità
 medio/bassa.

In linea di massima sì, quelli per server dovrebbero usare la tecnologia 
SLC (contro la MLC di quelli comuni): meno dati per cella ma maggiore 
affidabilità.

Poi forse hanno un sovra approvvigionamento integrato (questa è una mia 
ipotesi, non ho informazioni al riguardo).




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lmpucr$94g$1...@ger.gmane.org

Re: [PATCH 2/2] serial: core: Preserve termios c_cflag for console resume

[Valerio Vanni]

"Peter Hurley"  ha scritto nel messaggio
news:538f3150.6040...@hurleysoftware.com
> On 06/04/2014 10:22 AM, Greg Kroah-Hartman wrote:
>> Same as before, regression, or just a normal "new feature"?
>
> This was reported as a regression since 2.6.24, but that was likely
> misreported, and more likely due to a userspace update which triggers
> the bug.
>
> I would be surprised if console resume _never_ worked if the serial
> tty was opened then closed, but it probably has worked for a long
> time.

I don't know what was my initial mistake, but I realized very soon it was 
not a regression and took away the "regression" flag from bugzilla.
I tried many and many kernels and all were failing. I tried also to go 
down from 2.6.24 version, but I had to stop rather early because at some 
point the kernels were incompatible with distribution (I don't remember 
the details since I did these tests some month ago, and later I tested 
only newer kernel versions).

The patches you sent are for -next? for -rc? for stable?
Can I try them on 3.13.11? (at the moment I'm using this) 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] serial: core: Preserve termios c_cflag for console resume

[Valerio Vanni]

Peter Hurley pe...@hurleysoftware.com ha scritto nel messaggio
news:538f3150.6040...@hurleysoftware.com
 On 06/04/2014 10:22 AM, Greg Kroah-Hartman wrote:
 Same as before, regression, or just a normal new feature?

 This was reported as a regression since 2.6.24, but that was likely
 misreported, and more likely due to a userspace update which triggers
 the bug.

 I would be surprised if console resume _never_ worked if the serial
 tty was opened then closed, but it probably has worked for a long
 time.

I don't know what was my initial mistake, but I realized very soon it was 
not a regression and took away the regression flag from bugzilla.
I tried many and many kernels and all were failing. I tried also to go 
down from 2.6.24 version, but I had to stop rather early because at some 
point the kernels were incompatible with distribution (I don't remember 
the details since I did these tests some month ago, and later I tested 
only newer kernel versions).

The patches you sent are for -next? for -rc? for stable?
Can I try them on 3.13.11? (at the moment I'm using this) 



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: serial console does not wake from S3 suspend

[Valerio Vanni]

When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints a
text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with "cat txtfile > /dev/ttyS0").

Full details are here:
https://bugzilla.kernel.org/show_bug.cgi?id=69751


The problem is still present in 3.14.4, 3.15-rc7 and today's next.

I hope someone is going to look at this bug.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: serial console does not wake from S3 suspend

[Valerio Vanni]

When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints a
text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with cat txtfile  /dev/ttyS0).

Full details are here:
https://bugzilla.kernel.org/show_bug.cgi?id=69751


The problem is still present in 3.14.4, 3.15-rc7 and today's next.

I hope someone is going to look at this bug.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] RAID 1 doppia ridondanza

[Valerio Vanni]

dea d...@corep.it ha scritto nel messaggio
news:20140530093636.m63...@corep.it

 Giusto ieri mi sono arrivate le specifiche di un nuovo controller
 RAID in acquisto per un cliente (uno smartarray P4xx) e mi cade
 l'occhio sulle tipologie di RAID supportati.

 A parte i soliti, vedo un RAID 1 (seguito da una sigla molto
 esotica)... e scopro tra le specifiche trattarsi di un mirror su tre
 dischi.

Non è un semplice RAID1 + scorta?




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

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

Bug#748145: udisks: KDE device notifier does not show USB devices after umounting

[Valerio Vanni]

Package: udisks
Version: 1.0.4-7wheezy1
Severity: normal

I had opened it as Bug #745719, but so far it has been ignored.
Is it perhaps because I targeted a generic kdebase?

The issue exists in Wheezy and Jessie (Squeeze was ok).

It's described also here:
https://bugs.kde.org/show_bug.cgi?id=293906 (I took from here the udisks
target)



-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages udisks depends on:
ii  dbus   1.6.8-1+deb7u1
ii  libatasmart4   0.19-1
ii  libc6  2.13-38+deb7u1
ii  libdbus-1-31.6.8-1+deb7u1
ii  libdbus-glib-1-2   0.100.2-1
ii  libdevmapper1.02.1 2:1.02.74-8
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libgudev-1.0-0 175-7.2
ii  liblvm2app2.2  2.02.95-8
ii  libparted0debian1  2.3-12
ii  libpolkit-gobject-1-0  0.105-3
ii  libsgutils2-2  1.33-1
ii  libudev0   175-7.2
ii  udev   175-7.2

Versions of packages udisks recommends:
ii  cryptsetup-bin  2:1.4.3-4
ii  dosfstools  3.0.13-1
ii  eject   2.1.5+deb1+cvs20081104-13
ii  hdparm  9.39-1+b1
ii  ntfs-3g 1:2012.1.15AR.5-2.1
ii  policykit-1 0.105-3

Versions of packages udisks suggests:
ii  mdadm  3.2.5-5
ii  reiserfsprogs  1:3.6.21-1
ii  xfsprogs   3.1.7+b1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

[Pkg-utopia-maintainers] Bug#748145: udisks: KDE device notifier does not show USB devices after umounting

[Valerio Vanni]

Package: udisks
Version: 1.0.4-7wheezy1
Severity: normal

I had opened it as Bug #745719, but so far it has been ignored.
Is it perhaps because I targeted a generic kdebase?

The issue exists in Wheezy and Jessie (Squeeze was ok).

It's described also here:
https://bugs.kde.org/show_bug.cgi?id=293906 (I took from here the udisks
target)



-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages udisks depends on:
ii  dbus   1.6.8-1+deb7u1
ii  libatasmart4   0.19-1
ii  libc6  2.13-38+deb7u1
ii  libdbus-1-31.6.8-1+deb7u1
ii  libdbus-glib-1-2   0.100.2-1
ii  libdevmapper1.02.1 2:1.02.74-8
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libgudev-1.0-0 175-7.2
ii  liblvm2app2.2  2.02.95-8
ii  libparted0debian1  2.3-12
ii  libpolkit-gobject-1-0  0.105-3
ii  libsgutils2-2  1.33-1
ii  libudev0   175-7.2
ii  udev   175-7.2

Versions of packages udisks recommends:
ii  cryptsetup-bin  2:1.4.3-4
ii  dosfstools  3.0.13-1
ii  eject   2.1.5+deb1+cvs20081104-13
ii  hdparm  9.39-1+b1
ii  ntfs-3g 1:2012.1.15AR.5-2.1
ii  policykit-1 0.105-3

Versions of packages udisks suggests:
ii  mdadm  3.2.5-5
ii  reiserfsprogs  1:3.6.21-1
ii  xfsprogs   3.1.7+b1

-- no debconf information

___
Pkg-utopia-maintainers mailing list
Pkg-utopia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers

Bug#745719: kdebase: KDE device notifier does not reattach USB drives

[Valerio Vanni]

Package: kdebase
Followup-For: Bug #745719

I just tried Jessie, and I saw that the bug is still present in KDE 4.12.4
I updated https://bugs.kde.org/show_bug.cgi?id=293906.

Should I open a bug against udisks?



-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745719: kdebase: KDE device notifier does not reattach USB drives

[Valerio Vanni]

Package: kdebase
Followup-For: Bug #745719

I have seen this as well but I though that this was a problem in udisks or
some other system daemon.

The reason for this assessment was that the device is gone, e.g. if I check
which device is mounted while the mount is active, the same device (as in
/dev/sdXX) is no longer present when the unmount has happend.

In the kde bug report the component is identified as libsolid-udisks.



-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745719: kdebase: KDE device notifier does not reattach USB drives

[Valerio Vanni]

Package: kdebase
Followup-For: Bug #745719

I have seen this as well but I though that this was a problem in udisks or
some other system daemon.

The reason for this assessment was that the device is gone, e.g. if I check
which device is mounted while the mount is active, the same device (as in
/dev/sdXX) is no longer present when the unmount has happend.

In the kde bug report the component is identified as libsolid-udisks.



-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140506003201.8048.59125.reportbug@localhost.localdomain

Bug#745719: kdebase: KDE device notifier does not reattach USB drives

[Valerio Vanni]

Package: kdebase
Version: 5:66
Severity: normal

  * What led up to the situation?

Upgrading from Squeeze to Wheezy.

In Squeeze I found a good management of usb mass storage devices.
Clicking on the icon in the tray, it's possible to
-open the filesystem with file manager
-open it with a photo-something (I didn't try it, but it doesn't hurt)
-making it available to other application (mounting without open any software)

Then, with the eject icon, it's possible to unmount it. So far, so good, and
in Wheezy it's the same.

After the unmount, in Squeeze it's possible to reconnect the drive clicking on
the previous icons. In Wheezy, all icons disappear and you can't do anything
(until the drive has not been phisically unplugged and replugged).

The issue is documented also here
https://bugs.kde.org/show_bug.cgi?id=293906
But they say simply that it's resolved in KDE 4.10.2, a very newer version than
Wheezy's one.

   * What was the outcome of this action?

Now I have to physically unplug and replug the drive.

   * What outcome did you expect instead?

The same as in Squeeze: the possibility of reattach.



-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages kdebase depends on:
ii  kde-plasma-desktop  5:77+deb7u1

Versions of packages kdebase recommends:
ii  kde-standard  5:77+deb7u1

Versions of packages kdebase suggests:
pn  kde-l10n  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745719: kdebase: KDE device notifier does not reattach USB drives

[Valerio Vanni]

Package: kdebase
Version: 5:66
Severity: normal

  * What led up to the situation?

Upgrading from Squeeze to Wheezy.

In Squeeze I found a good management of usb mass storage devices.
Clicking on the icon in the tray, it's possible to
-open the filesystem with file manager
-open it with a photo-something (I didn't try it, but it doesn't hurt)
-making it available to other application (mounting without open any software)

Then, with the eject icon, it's possible to unmount it. So far, so good, and
in Wheezy it's the same.

After the unmount, in Squeeze it's possible to reconnect the drive clicking on
the previous icons. In Wheezy, all icons disappear and you can't do anything
(until the drive has not been phisically unplugged and replugged).

The issue is documented also here
https://bugs.kde.org/show_bug.cgi?id=293906
But they say simply that it's resolved in KDE 4.10.2, a very newer version than
Wheezy's one.

   * What was the outcome of this action?

Now I have to physically unplug and replug the drive.

   * What outcome did you expect instead?

The same as in Squeeze: the possibility of reattach.



-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages kdebase depends on:
ii  kde-plasma-desktop  5:77+deb7u1

Versions of packages kdebase recommends:
ii  kde-standard  5:77+deb7u1

Versions of packages kdebase suggests:
pn  kde-l10n  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140424122307.23388.50755.reportbug@localhost.localdomain

Bug#745373: timidity-daemon: timidity daemon grabs exclusive audio access or doesn't work

[Valerio Vanni]

Package: timidity-daemon
Version: 2.13.2-40.1
Severity: important

The issue happens loading Timidity with timidity-daemon in a pulseaudio
environment. If Timidity is loaded from the user (on a terminal inside kde
session) everything works.

With daemon it's not that it doesn't work at all: it works only with exclusive
access.
If I launch some midi application (with output to Timidity) when I've not yet
used audio, the application works. But everything other I launch, it remains
muted until i close the midi application.

On the contrary, if I launch midi applications when something other is already
using audio (i.e. a simple browser on youtube, kaffeine etc), midi output is
muted.

Purging and reinstalling timidity and timidity-daemon packages does not help.


Here I paste a syslog output triggered by a /etc/init.d/timidity restart.

21/4/2014 03:27:55  newton  pulseaudio[7290][pulseaudio] authkey.c:
Failed to open cookie file '/etc/timidity/.pulse-cookie': File o directory non
esistente
21/4/2014 03:27:55  newton  pulseaudio[7290][pulseaudio] authkey.c:
Failed to load authorization key '/etc/timidity/.pulse-cookie': File o
directory non esistente
21/4/2014 03:27:55  newton  pulseaudio[7290][pulseaudio] client-
conf-x11.c: xcb_connection_has_error() returned true
21/4/2014 03:27:55  newton  pulseaudio[7290][autospawn] core-
util.c: Home directory /etc/timidity not ours.
21/4/2014 03:27:55  newton  pulseaudio[7290][autospawn] lock-
autospawn.c: Impossibile accedere al lock di autospawn.
21/4/2014 03:27:55  newton  pulseaudio[7290][pulseaudio] main.c:
Failed to acquire autospawn lock






-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages timidity-daemon depends on:
ii  adduser   3.113+nmu3
ii  timidity  2.13.2-40.1

timidity-daemon recommends no packages.

timidity-daemon suggests no packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Fw: serial console does not wake from S3 suspend

[Valerio Vanni]

"Valerio Vanni"  ha scritto nel messaggio
news:lg9etc$9fl$1...@ger.gmane.org
When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints
a text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with "cat txtfile > /dev/ttyS0").

Full details are here:

https://bugzilla.kernel.org/show_bug.cgi?id=69751


It's still present in 3.15-rc1 and in actual -next.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fw: serial console does not wake from S3 suspend

[Valerio Vanni]

Valerio Vanni vale...@valeriovanni.com ha scritto nel messaggio
news:lg9etc$9fl$1...@ger.gmane.org
When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints
a text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with cat txtfile  /dev/ttyS0).

Full details are here:

https://bugzilla.kernel.org/show_bug.cgi?id=69751


It's still present in 3.15-rc1 and in actual -next.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bug#743979: colord-sane: segfault libdbus-1.so.3.7.2

[Valerio Vanni]

Package: colord
Version: 0.1.21-1
Severity: normal

I find the following lines in syslog:

Apr  8 05:07:24 newton kernel: colord-sane[3654]: segfault at 0 ip b7352ac5 sp
bf8e5adc error 4 in libc-2.13.so[b72b6000+15d000]
Apr  8 05:10:17 newton kernel: colord-sane[3424]: segfault at 0 ip b7312ac5 sp
bffb043c error 4 in libc-2.13.so[b7276000+15d000]
Apr  9 00:30:41 newton kernel: colord-sane[3422]: segfault at 4 ip b716c469 sp
bfbe9d38 error 4 in libdbus-1.so.3.7.2[b7141000+49000]



-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.13.6 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages colord depends on:
ii  acl2.2.51-8
ii  adduser3.113+nmu3
ii  libc6  2.13-38+deb7u1
ii  libcolord1 0.1.21-1
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libgudev-1.0-0 175-7.2
ii  libgusb2   0.1.3-5
ii  liblcms2-2 2.2+git20110628-2.2
ii  libpolkit-gobject-1-0  0.105-3
ii  libsane1.0.22-7.4
ii  libsqlite3-0   3.7.13-1+deb7u1
ii  libusb-1.0-0   2:1.0.11-1
ii  multiarch-support  2.13-38+deb7u1
ii  policykit-10.105-3

colord recommends no packages.

colord suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739979: xorg: psmouse lost sync (worked up to Lenny)

[Valerio Vanni]

Package: xorg
Version: 1:7.7+3~deb7u1
Followup-For: Bug #739979

I add my findings.

The combination PS2 KVM switch - Vmware Workstation or Player fails also on
other new LInux distribution.
I've tested Fedora 20, Ubuntu 12.04LTS and Ubuntu 13.10.

In Debian, I can confirm that the first failing is Squeeze (Wheezy and Jessie
fail too).

For this I suspect that some change in Xorg could play a role.

I've reported a bug with VMware support, but they just gave up saying that they
didn't find anything wrong in their PS2 module.
And they think the problem could be in the operating system.

Obviously, they don't have my KVM switch to test (and neither you have it).

A thing that I can add is that a USB - PS2 converter solves the issue (and I'm
taking it as a workaround).
Not a passive one, that work only for bi-protocol mice.
An active one, that converts the protocol. It has a USB male and two PS2
females connectors, and the PC detectes the mouse as USB. Passing through the
same KVM switch.
Notice: the KVM switch it's only PS2, not combo.

The chain
PS2 mouse - PS2 KVM switch - PC fails

The chain
PS2 mouse - PS2 KVM switch - USB-PS2 converter - PC works

So, whatever bad can do  the KVM switch, it can trigger the issue only entering
as PS2.



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 30  2008 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Dec 17 21:40 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller [8086:29c2] (rev 02)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rwxr-xr-x 1 root root 1002 Apr  8 03:24 10-resolution.conf

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.13.6 (root@newton) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 
SMP Wed Mar 12 15:13:44 CET 2014

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 31231 Feb 21  2009 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 22208 Apr  9 00:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[53.888] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[53.888] X Protocol Version 11, Revision 0
[53.888] Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
[53.888] Current Operating System: Linux newton 3.13.6 #1 SMP Wed Mar 12 
15:13:44 CET 2014 i686
[53.888] Kernel command line: BOOT_IMAGE=Linux-3.13.6 ro root=801 
console=ttyS0 console=tty0
[53.888] Build Date: 17 December 2013  08:37:13PM
[53.888] xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau 
jcris...@debian.org) 
[53.888] Current version of pixman: 0.26.0
[53.888]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[53.888] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[53.888] (==) Log file: /var/log/Xorg.0.log, Time: Wed Apr  9 00:44:52 
2014
[53.955] (==) Using config directory: /etc/X11/xorg.conf.d
[53.955] (==) Using system config directory /usr/share/X11/xorg.conf.d
[54.290] (==) No Layout section.  Using the first Screen section.
[54.290] (**) |--Screen Screen0 (0)
[54.290] (**) |   |--Monitor Monitor0
[54.455] (==) Automatically adding devices
[54.455] (==) Automatically enabling devices
[54.455] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[54.455]Entry deleted from font path.
[54.455] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[54.455] (==) ModulePath set to /usr/lib/xorg/modules
[54.455] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[54.455] (II) Loader magic: 0xb776e5a0
[54.455] (II) Module ABI versions:
[54.455]X.Org ANSI C Emulation: 0.4
[54.455]X.Org Video Driver: 12.1
[54.455]X.Org XInput driver : 16.0
[54.455]X.Org Server Extension : 6.0
[54.455] (--) PCI:*(0:0:2:0) 8086:29c2:1458:d000 rev 2, Mem @ 
0xf320/524288, 0xe000/268435456, 0xf300/1048576, I/O @ 0xe200/8
[54.456] (II) 

Bug#739979: xorg: psmouse lost sync (worked up to Lenny)

[Valerio Vanni]

Package: xorg
Version: 1:7.7+3~deb7u1
Followup-For: Bug #739979

I add my findings.

The combination PS2 KVM switch - Vmware Workstation or Player fails also on
other new LInux distribution.
I've tested Fedora 20, Ubuntu 12.04LTS and Ubuntu 13.10.

In Debian, I can confirm that the first failing is Squeeze (Wheezy and Jessie
fail too).

For this I suspect that some change in Xorg could play a role.

I've reported a bug with VMware support, but they just gave up saying that they
didn't find anything wrong in their PS2 module.
And they think the problem could be in the operating system.

Obviously, they don't have my KVM switch to test (and neither you have it).

A thing that I can add is that a USB - PS2 converter solves the issue (and I'm
taking it as a workaround).
Not a passive one, that work only for bi-protocol mice.
An active one, that converts the protocol. It has a USB male and two PS2
females connectors, and the PC detectes the mouse as USB. Passing through the
same KVM switch.
Notice: the KVM switch it's only PS2, not combo.

The chain
PS2 mouse - PS2 KVM switch - PC fails

The chain
PS2 mouse - PS2 KVM switch - USB-PS2 converter - PC works

So, whatever bad can do  the KVM switch, it can trigger the issue only entering
as PS2.



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Sep 30  2008 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Dec 17 21:40 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller [8086:29c2] (rev 02)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rwxr-xr-x 1 root root 1002 Apr  8 03:24 10-resolution.conf

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.13.6 (root@newton) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 
SMP Wed Mar 12 15:13:44 CET 2014

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 31231 Feb 21  2009 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 22208 Apr  9 00:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[53.888] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[53.888] X Protocol Version 11, Revision 0
[53.888] Build Operating System: Linux 3.2.0-4-amd64 i686 Debian
[53.888] Current Operating System: Linux newton 3.13.6 #1 SMP Wed Mar 12 
15:13:44 CET 2014 i686
[53.888] Kernel command line: BOOT_IMAGE=Linux-3.13.6 ro root=801 
console=ttyS0 console=tty0
[53.888] Build Date: 17 December 2013  08:37:13PM
[53.888] xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau 
jcris...@debian.org) 
[53.888] Current version of pixman: 0.26.0
[53.888]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[53.888] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[53.888] (==) Log file: /var/log/Xorg.0.log, Time: Wed Apr  9 00:44:52 
2014
[53.955] (==) Using config directory: /etc/X11/xorg.conf.d
[53.955] (==) Using system config directory /usr/share/X11/xorg.conf.d
[54.290] (==) No Layout section.  Using the first Screen section.
[54.290] (**) |--Screen Screen0 (0)
[54.290] (**) |   |--Monitor Monitor0
[54.455] (==) Automatically adding devices
[54.455] (==) Automatically enabling devices
[54.455] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[54.455]Entry deleted from font path.
[54.455] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[54.455] (==) ModulePath set to /usr/lib/xorg/modules
[54.455] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[54.455] (II) Loader magic: 0xb776e5a0
[54.455] (II) Module ABI versions:
[54.455]X.Org ANSI C Emulation: 0.4
[54.455]X.Org Video Driver: 12.1
[54.455]X.Org XInput driver : 16.0
[54.455]X.Org Server Extension : 6.0
[54.455] (--) PCI:*(0:0:2:0) 8086:29c2:1458:d000 rev 2, Mem @ 
0xf320/524288, 0xe000/268435456, 0xf300/1048576, I/O @ 0xe200/8
[54.456] (II) 

Re: Software RAID10 - which two disks can fail?

[Valerio Vanni]

Gary Dale garyd...@velcom.ca 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: serial console does not wake from S3 suspend

[Valerio Vanni]

"Valerio Vanni"  ha scritto nel messaggio
news:lg9etc$9fl$1...@ger.gmane.org

When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints a
text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with "cat txtfile > /dev/ttyS0").

Full details are here:
https://bugzilla.kernel.org/show_bug.cgi?id=69751


The problem is still present in final 3.14 (and in linux-next).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: serial console does not wake from S3 suspend

[Valerio Vanni]

Valerio Vanni vale...@valeriovanni.com ha scritto nel messaggio
news:lg9etc$9fl$1...@ger.gmane.org

When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints a
text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with cat txtfile  /dev/ttyS0).

Full details are here:
https://bugzilla.kernel.org/show_bug.cgi?id=69751


The problem is still present in final 3.14 (and in linux-next).

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Valerio Vanni]

Brian a...@cityscape.co.uk 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

Re: Kernel bug

[Valerio Vanni]

antispammbox-debian antispammbox-deb...@yahoo.it ha scritto nel
messaggio news:4E64C9D303764F7081C01B5B3FF2118F@rx
 Allora sono quelli originali!? quelli che hò scaricato anch'io! :-)

 L'usanza per molte disto (specie RH), è quella di prendere un
 kernel e riempirlo di steroidi all'ennesima potenza.
 Alias, un kernel RH non ha più praticamente nulla di originale.

 Cosa ci butta dentro RH per stéroidarlo?


 steròidarlo!

A dirla bene, sarà steroidàrlo. 




-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lf257q$25r$1...@ger.gmane.org

Bug#739979: xorg: psmouse lost sync (worked up to Lenny)

[Valerio Vanni]

Package: xorg
Version: 1:7.7+3~deb7u1
Severity: important

   * What led up to the situation?
A role in this issue is played by the presence of a KVM switch. If I bypass the
switch and connect the mouse directly to the PC, the issue doesn't happen.
Note: the issue does not happen when I switch PCs. I can leave the KVM pointed
on a PC (without switching to others) and it happens the same.
Another role is played by VMWare Player. The problem happens very rarely if I
don't open VMWare player.
When I use it, the problem happens very frequently. Some times even more time
in a minute, making all unusable. In particular, it seems to happen during the
phase of grabbing / ungrabbing of the pointer by Player window. It's less
frequent (but it happens) if Player windows is set to full screen. The worst
(issue almost sure) is when the Player window is resized.

The issue: the mouse starts suddenly to jump everywhere, the pc speakers make a
repeated beep and then the pointer remains stuck.

At this point, in dmesg I find
24/2/2014 13:53:08  newton  kernel  [  260.365208] psmouse serio1: Wheel
Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.

And it's left in that state forever: the only way for me to unlock it is to
CTRL+ALT+Fx an then rmmod psmouse modprobe psmouse.
At this point I find in dmesg
24/2/2014 13:58:22  newton  kernel  [  574.212905] input: ImExPS/2 Logitech
Wheel Mouse as /devices/platform/i8042/serio1/input/input7
and when I come back to graphical environment the mouse is working again.

But then I go inside VMWare Player window and... often it crashes.
I think it's a hardware-related bug, but not that it's a hardware fault,
because:
-All Windows machine are working correctly
-Debian system up to Lenny (in particular I've had Woody - Sarge - Etch) work
correctly.

The problem showed up after the upgrade from Lenny to Squeeze.
I've tried updating from Squeeze to Wheezy, and the issue remained.
I've tried a fresh Wheezy install, and the issue is still present.
I've tried updating Wheezy to Jessie: always the same.

So I think there is some difference from Lenny to Squeeze that triggers the
issue.
Now I'm on the clean install of Wheezy. Standard kernel 3.2.0-4-686-pae, no
backport, no old package.
I report the bug from here because I think it can be useful to have a more
standard environment.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
-I've tried changing proto parameter in psmouse (through a created
/etc/modprobe.d/mouse.conf) but without success. Even proto=bare does not help.
-I've tried many kernels, even vanilla: no difference
-I've tried this patch to psmouse-base.c: http://lkml.org/lkml/2005/11/9/47.
This seems to help but only in the reaction to the problem. With this patch I
wait some second and the mouse is working again. The advantage is that I don't
have to go to text console and rmmod+modprobe psmouse), but the problem is
triggered with the same frequency.



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Feb 21 23:31 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Dec 17 21:40 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller [8086:29c2] (rev 02)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1002 Feb 21 23:44 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Section Monitor
Identifier   Monitor0
HorizSync   30-90
VertRefresh 50-160
VendorName   Philips
ModelName109B
Modeline 800x600_56.20   36.00  800 824 896 1024  600 601 603 625 
+hsync +vsync
Modeline 1024x768_60.00   65.00  1024 1048 1184 1344  768 771 777 806 
-hsync -vsync
Modeline 1280x1024_75.00  138.75  1280 1312 1448 1728  1024 1027 1034 
1072 -hsync +vsync
#   Modeline 1280x1024_85.00  159.50  1280 1376 1512 1744  1024 1027 1034 
1078 -hsync +vsync
Option PreferredMode 1280x1024_75.00
EndSection  

Section Screen
   Identifier  Screen0
   Device  Card'
   Monitor Monitor0
   DefaultDepth24
   SubSection Display
   Depth   16
   Modes   1280x1024 1024x768 800x600 640x480
   EndSubSection
   SubSection Display
   Depth   24
   Modes   1280x1024 1024x768 800x600 640x480
   EndSubSection
EndSection

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2

Bug#739979: xorg: psmouse lost sync (worked up to Lenny)

[Valerio Vanni]

Package: xorg
Version: 1:7.7+3~deb7u1
Severity: important

   * What led up to the situation?
A role in this issue is played by the presence of a KVM switch. If I bypass the
switch and connect the mouse directly to the PC, the issue doesn't happen.
Note: the issue does not happen when I switch PCs. I can leave the KVM pointed
on a PC (without switching to others) and it happens the same.
Another role is played by VMWare Player. The problem happens very rarely if I
don't open VMWare player.
When I use it, the problem happens very frequently. Some times even more time
in a minute, making all unusable. In particular, it seems to happen during the
phase of grabbing / ungrabbing of the pointer by Player window. It's less
frequent (but it happens) if Player windows is set to full screen. The worst
(issue almost sure) is when the Player window is resized.

The issue: the mouse starts suddenly to jump everywhere, the pc speakers make a
repeated beep and then the pointer remains stuck.

At this point, in dmesg I find
24/2/2014 13:53:08  newton  kernel  [  260.365208] psmouse serio1: Wheel
Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.

And it's left in that state forever: the only way for me to unlock it is to
CTRL+ALT+Fx an then rmmod psmouse modprobe psmouse.
At this point I find in dmesg
24/2/2014 13:58:22  newton  kernel  [  574.212905] input: ImExPS/2 Logitech
Wheel Mouse as /devices/platform/i8042/serio1/input/input7
and when I come back to graphical environment the mouse is working again.

But then I go inside VMWare Player window and... often it crashes.
I think it's a hardware-related bug, but not that it's a hardware fault,
because:
-All Windows machine are working correctly
-Debian system up to Lenny (in particular I've had Woody - Sarge - Etch) work
correctly.

The problem showed up after the upgrade from Lenny to Squeeze.
I've tried updating from Squeeze to Wheezy, and the issue remained.
I've tried a fresh Wheezy install, and the issue is still present.
I've tried updating Wheezy to Jessie: always the same.

So I think there is some difference from Lenny to Squeeze that triggers the
issue.
Now I'm on the clean install of Wheezy. Standard kernel 3.2.0-4-686-pae, no
backport, no old package.
I report the bug from here because I think it can be useful to have a more
standard environment.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
-I've tried changing proto parameter in psmouse (through a created
/etc/modprobe.d/mouse.conf) but without success. Even proto=bare does not help.
-I've tried many kernels, even vanilla: no difference
-I've tried this patch to psmouse-base.c: http://lkml.org/lkml/2005/11/9/47.
This seems to help but only in the reaction to the problem. With this patch I
wait some second and the mouse is working again. The advantage is that I don't
have to go to text console and rmmod+modprobe psmouse), but the problem is
triggered with the same frequency.



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Feb 21 23:31 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2027892 Dec 17 21:40 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express 
Integrated Graphics Controller [8086:29c2] (rev 02)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1002 Feb 21 23:44 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Section Monitor
Identifier   Monitor0
HorizSync   30-90
VertRefresh 50-160
VendorName   Philips
ModelName109B
Modeline 800x600_56.20   36.00  800 824 896 1024  600 601 603 625 
+hsync +vsync
Modeline 1024x768_60.00   65.00  1024 1048 1184 1344  768 771 777 806 
-hsync -vsync
Modeline 1280x1024_75.00  138.75  1280 1312 1448 1728  1024 1027 1034 
1072 -hsync +vsync
#   Modeline 1280x1024_85.00  159.50  1280 1376 1512 1744  1024 1027 1034 
1078 -hsync +vsync
Option PreferredMode 1280x1024_75.00
EndSection  

Section Screen
   Identifier  Screen0
   Device  Card'
   Monitor Monitor0
   DefaultDepth24
   SubSection Display
   Depth   16
   Modes   1280x1024 1024x768 800x600 640x480
   EndSubSection
   SubSection Display
   Depth   24
   Modes   1280x1024 1024x768 800x600 640x480
   EndSubSection
EndSection

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.54-2