At least 3 times in the past few days I've seen the same SELinux alert. I put the text of the details in the attached file "alerts.txt". All 3 occurrences were while using caja to rename or delete a file, though it does not happen every time I rename or delete a file in caja. These alerts confuse me. There is no directory "/memdf:"...
-bash.1[~]: cd / -bash.2[/]: ls -a . boot etc lib64 mnt root srv system-upgrade usr .. .cache home lost+found opt run sys system-upgrade-root var bin dev lib media proc sbin sysroot tmp -bash.3[/]: ls -a /memfd* ls: cannot access '/memfd*': No such file or directory -bash.4[/]:
Also, the directory name (ending with a colon?) looks fishy. Further, the filename ".nvidia_drv.XXXXXX" looks fishy (but "legal").
The instruction does not work:
-bash.4[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX (deleted) -bash: syntax error near unexpected token `(' -bash.4[/]:
-bash.5[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX /sbin/restorecon: SELinux: Could not get canonical path for /memfd:/.nvidia_drv.XXXXXX restorecon: No such file or directory. -bash.6[/]:
I gather that a directory and or file (whatever its name really is) are missing?
How do I fix this?
I see a lot of /memfd: in lsof it appears to be anonymous files (ie temp files). I am going to guess memfd is memory file descriptor, ie a temp file created in memory.
Usually they are going to not actually exist anywhere in a fs. And generally the app that opens/creates them is the app that is going to immediately use it.
if selinux is blocking it I would think it should cause some sort of issues with the owner/application using the file.
lsof | grep "/memfd:/.nvidia" will show you the owner of the specific file. For the nvidia_drv one it looks like Xorg (on my system, may Wayland if you are using that) opens it.
On mine in lsof I have hundreds using the .nvidia_drv.XXXXXX one and all have the same node in lsof so all are the same object, probably created by the display owner.
It may be that caja itself is not granted the proper selinux permissions to use that resource and is hence getting the error. Ie the error may not be that the file is missing options but that the application is not allowed access to the file.
you might try the restorecon against the caja executable itself
On Tue, Apr 13, 2021 at 12:41 PM home user mattisonw@comcast.net wrote:
At least 3 times in the past few days I've seen the same SELinux alert. I put the text of the details in the attached file "alerts.txt". All 3 occurrences were while using caja to rename or delete a file, though it does not happen every time I rename or delete a file in caja. These alerts confuse me. There is no directory "/memdf:"...
-bash.1[~]: cd / -bash.2[/]: ls -a . boot etc lib64 mnt root srv system-upgrade usr .. .cache home lost+found opt run sys system-upgrade-root var bin dev lib media proc sbin sysroot tmp -bash.3[/]: ls -a /memfd* ls: cannot access '/memfd*': No such file or directory -bash.4[/]:
Also, the directory name (ending with a colon?) looks fishy. Further, the filename ".nvidia_drv.XXXXXX" looks fishy (but "legal").
The instruction does not work:
-bash.4[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX (deleted) -bash: syntax error near unexpected token `(' -bash.4[/]:
-bash.5[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX /sbin/restorecon: SELinux: Could not get canonical path for /memfd:/.nvidia_drv.XXXXXX restorecon: No such file or directory. -bash.6[/]:
I gather that a directory and or file (whatever its name really is) are missing?
How do I fix this? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/13/21 12:48 PM, Roger Heflin wrote:
I see a lot of /memfd: in lsof it appears to be anonymous files (ie temp files). I am going to guess memfd is memory file descriptor, ie a temp file created in memory.
Usually they are going to not actually exist anywhere in a fs. And generally the app that opens/creates them is the app that is going to immediately use it.
if selinux is blocking it I would think it should cause some sort of issues with the owner/application using the file.
lsof | grep "/memfd:/.nvidia" will show you the owner of the specific file. For the nvidia_drv one it looks like Xorg (on my system, may Wayland if you are using that) opens it.
I've attached the output of "lsof | grep "/memfd:/.nvidia"". When I ran that, caja, a terminal, and xeyes were running.
On mine in lsof I have hundreds using the .nvidia_drv.XXXXXX one and all have the same node in lsof so all are the same object, probably created by the display owner.
It may be that caja itself is not granted the proper selinux permissions to use that resource and is hence getting the error. Ie the error may not be that the file is missing options but that the application is not allowed access to the file.
When I ran the renames and deletes in caja, they all worked properly even though I received the SELinux alerts in some cases. Would that have been so if caja was lacking SELinux permissions?
you might try the restorecon against the caja executable itself
On Tue, Apr 13, 2021 at 12:41 PM home user mattisonw@comcast.net wrote:
[... snip ...]
Are you running permissive or enforcing?
if permissive then it does not block anything, but says it is blocking
if enforcing it is blocking something, though it may be a pointless/useless interface feature of some sort that does not matter, and does not really affect functionality.
And it might be some sort of sub process that is failing to do something that may or may not matter.
On Tue, Apr 13, 2021 at 2:59 PM home user mattisonw@comcast.net wrote:
On 4/13/21 12:48 PM, Roger Heflin wrote:
I see a lot of /memfd: in lsof it appears to be anonymous files (ie temp files). I am going to guess memfd is memory file descriptor, ie a temp file created in memory.
Usually they are going to not actually exist anywhere in a fs. And generally the app that opens/creates them is the app that is going to immediately use it.
if selinux is blocking it I would think it should cause some sort of issues with the owner/application using the file.
lsof | grep "/memfd:/.nvidia" will show you the owner of the specific file. For the nvidia_drv one it looks like Xorg (on my system, may Wayland if you are using that) opens it.
I've attached the output of "lsof | grep "/memfd:/.nvidia"". When I ran that, caja, a terminal, and xeyes were running.
On mine in lsof I have hundreds using the .nvidia_drv.XXXXXX one and all have the same node in lsof so all are the same object, probably created by the display owner.
It may be that caja itself is not granted the proper selinux permissions to use that resource and is hence getting the error. Ie the error may not be that the file is missing options but that the application is not allowed access to the file.
When I ran the renames and deletes in caja, they all worked properly even though I received the SELinux alerts in some cases. Would that have been so if caja was lacking SELinux permissions?
you might try the restorecon against the caja executable itself
On Tue, Apr 13, 2021 at 12:41 PM home user mattisonw@comcast.net wrote:
[... snip ...]
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/13/21 2:24 PM, Roger Heflin wrote:
Are you running permissive or enforcing? > if permissive then it does not block anything, but says it is blocking
if enforcing it is blocking something, though it may be a pointless/useless interface feature of some sort that does not matter, and does not really affect functionality.
And it might be some sort of sub process that is failing to do something that may or may not matter.
When I first installed this system 8 years ago, SELinux was there by default. My knowledge of it is very high level and superficial. I don't recall ever setting anything either of those 2 ways; I'm running whatever the default is. I don't know the answer to your question, nor do I know how to find out.
I do need to find a better way to reproduce the problem and test fixes (like the restorecon command you suggested). Currently, it seems I get the problem only the first 1 or 2 times per login, per boot, or per day (I haven't yet figured out which). I also want to figure out if the problem is limited to caja, or if "files" also has the problem.
sestatus will show the current status.
if enforcing then something may not be functioning as designed.
if permissive then it will report it is blocking when it is not, and if you set it enforcing then something would probably break.
if you set it permissive at one time then it will stay set permissive.
On Tue, Apr 13, 2021 at 4:56 PM home user mattisonw@comcast.net wrote:
On 4/13/21 2:24 PM, Roger Heflin wrote:
Are you running permissive or enforcing? > if permissive then it does not block anything, but says it is blocking
if enforcing it is blocking something, though it may be a pointless/useless interface feature of some sort that does not matter, and does not really affect functionality.
And it might be some sort of sub process that is failing to do something that may or may not matter.
When I first installed this system 8 years ago, SELinux was there by default. My knowledge of it is very high level and superficial. I don't recall ever setting anything either of those 2 ways; I'm running whatever the default is. I don't know the answer to your question, nor do I know how to find out.
I do need to find a better way to reproduce the problem and test fixes (like the restorecon command you suggested). Currently, it seems I get the problem only the first 1 or 2 times per login, per boot, or per day (I haven't yet figured out which). I also want to figure out if the problem is limited to caja, or if "files" also has the problem. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 14/04/2021 01:40, home user wrote:
At least 3 times in the past few days I've seen the same SELinux alert. I put the text of the details in the attached file "alerts.txt". All 3 occurrences were while using caja to rename or delete a file, though it does not happen every time I rename or delete a file in caja. These alerts confuse me. There is no directory "/memdf:"...
-bash.1[~]: cd / -bash.2[/]: ls -a . boot etc lib64 mnt root srv system-upgrade usr .. .cache home lost+found opt run sys system-upgrade-root var bin dev lib media proc sbin sysroot tmp -bash.3[/]: ls -a /memfd* ls: cannot access '/memfd*': No such file or directory -bash.4[/]:
Also, the directory name (ending with a colon?) looks fishy. Further, the filename ".nvidia_drv.XXXXXX" looks fishy (but "legal").
The instruction does not work:
-bash.4[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX (deleted) -bash: syntax error near unexpected token `(' -bash.4[/]:
-bash.5[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX /sbin/restorecon: SELinux: Could not get canonical path for /memfd:/.nvidia_drv.XXXXXX restorecon: No such file or directory. -bash.6[/]:
I gather that a directory and or file (whatever its name really is) are missing?
memfd refers to "Memory File Descriptor". The file in question exists only in RAM and is a temporary file at that. Command such as "restorecon" are useless for this.
I'm guessing it may be caused not by caja by xeyes. But if you're not having any problems it would be something that I'd ignore. I don't know if this would apply, but when the Alert pops up there should be a button for "ignore" beside the button for "troubleshoot". If I recall correctly.
If I were having these alerts and wanted to do a little debugging I'd first run my sessions without xeyes.
I don't know how you installed your nVidia drivers. But, I would check to make sure what I had were the latest. FWIW, I use the nVidia stuff packaged by rpmfusion.
On 4/13/21 5:06 PM, Roger Heflin wrote:
sestatus will show the current status.
if enforcing then something may not be functioning as designed.
if permissive then it will report it is blocking when it is not, and if you set it enforcing then something would probably break.
if you set it permissive at one time then it will stay set permissive.
It is "enforcing":
bash.1[~]: su - Password: -bash.1[~]: sestatus -v SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33
Process contexts: Current context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Init context: system_u:system_r:init_t:s0
File contexts: Controlling terminal: unconfined_u:object_r:user_devpts_t:s0 /etc/passwd system_u:object_r:passwd_file_t:s0 /etc/shadow system_u:object_r:shadow_t:s0 /bin/bash system_u:object_r:shell_exec_t:s0 /bin/login system_u:object_r:login_exec_t:s0 /bin/sh system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0 /sbin/agetty system_u:object_r:getty_exec_t:s0 /sbin/init system_u:object_r:bin_t:s0 -> system_u:object_r:init_exec_t:s0 /usr/sbin/sshd system_u:object_r:sshd_exec_t:s0 /lib/libc.so.6 system_u:object_r:lib_t:s0 -> system_u:object_r:lib_t:s0 /lib/ld-linux.so.2 system_u:object_r:lib_t:s0 -> system_u:object_r:ld_so_t:s0 -bash.2[~]:
On Tue, Apr 13, 2021 at 4:56 PM home user mattisonw@comcast.net wrote:
On 4/13/21 2:24 PM, Roger Heflin wrote:
Are you running permissive or enforcing? > if permissive then it does not block anything, but says it is blocking
if enforcing it is blocking something, though it may be a pointless/useless interface feature of some sort that does not matter, and does not really affect functionality.
And it might be some sort of sub process that is failing to do something that may or may not matter.
When I first installed this system 8 years ago, SELinux was there by default. My knowledge of it is very high level and superficial. I don't recall ever setting anything either of those 2 ways; I'm running whatever the default is. I don't know the answer to your question, nor do I know how to find out.
I do need to find a better way to reproduce the problem and test fixes (like the restorecon command you suggested). Currently, it seems I get the problem only the first 1 or 2 times per login, per boot, or per day (I haven't yet figured out which). I also want to figure out if the problem is limited to caja, or if "files" also has the problem.
On 4/13/21 5:20 PM, Ed Greshko wrote:
Long zoom meeting done; now I'm back to this.
memfd refers to "Memory File Descriptor". The file in question exists only in RAM and is a temporary file at that. Command such as "restorecon" are useless for this.
ok.
I'm guessing it may be caused not by caja by xeyes. But if you're not having any problems it would be something that I'd ignore. I don't know if this would apply, but when the Alert pops up there should be a button for "ignore" beside the button for "troubleshoot". If I recall correctly.
You remember correctly.
If I were having these alerts and wanted to do a little debugging I'd first run my sessions without xeyes.
I don't know how you installed your nVidia drivers. But, I would check to make sure what I had were the latest. FWIW, I use the nVidia stuff packaged by rpmfusion.
I started out with the proprietary driver 8 years ago. 1 or 2 years later, as advised by this list, I switched to the kmod? package(s?) from rpmfusion. The rpmfusion stuff was installed the way members of this list instructed. I see the rpmfusion stuff patched during over half of my weekly patches.
I don't know if any of this helps, but here goes: * The problem started after upgrading to f33. * I have not noticed any problems with xeyes. * The sequence of steps leading to the alerts is: 1. Using the command line in a terminal, download a Chinese music video. The resulting file has a name made of traditional (Taiwan) Chinese characters. 2. Launch caja. 3. Use caja to rename the file to something with all ASCII characters. 4. Use caja to launch the file for viewing. I think it's launching VLC for that. 5. View the file and, using vim in a terminal, make study notes. 6. In caja, delete the file. In caja, for each file, there is a small icon, the name of the file, and meta-data for the file. In the case of video files, that icon is an image, a frame from the video. The factors that have been occurring to me are the traditional Chinese characters and the image icons. But why only the first time in a login session? That's what most puzzles me.
Tomorrow morning, I will try the no-xeyes test that you suggest.
Ignoring the problem is tempting, but I don't want to give up toooooo easily.
On 14/04/2021 11:41, home user wrote:
Tomorrow morning, I will try the no-xeyes test that you suggest.
Ignoring the problem is tempting, but I don't want to give up toooooo easily.
Well, pardon me for saying I find that last observation somewhat narrow in scope. :-) :-)
That being said....
Your AVC you posted was....
type=AVC msg=audit(1618332726.288:964): avc: denied { write } for pid=129605 co mm="gstglcontext" path=2F6D656D66643A2F2E6E76696469615F6472762E5858585858582028646 56C6574656429 dev="tmpfs" ino=1025 scontext=unconfined_u:unconfined_r:thumb_t:s0-s 0:c0.c1023 tcontext=system_u:object_r:xserver_tmpfs_t:s0 tclass=file permissive=0
Are all of your alerts of this kind? You may want to use "ausearch" with -c gstglcontext. You can narrow the window by using -ts in the ausearch command. Looking a the man page to find the options for that parameter.
That being said, gstglcontext is related to OpenGL which "is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics". The "scontext" has as part of it xserver_tmpfs_t which furthers this.
So, the next time you get this alert check out the AVC and find the process associated with pid=.
On 4/14/21 1:26 AM, Ed Greshko wrote:
On 14/04/2021 11:41, home user wrote:
Last night, in ".bash_profile", I commented out the block of code that launches xeyes, and shut down for the night.
This morning, I booted up and logged in, No xeyes. I downloaded a Chinese music video. I then launched caja. Before I tried doing anything in it, a SELinux alert appeared,
So it seems that xeyes has nothing to do with this problem.
I tried launching "files". I did not see any SELinux alerts.
Your AVC you posted was....
type=AVC msg=audit(1618332726.288:964): avc: denied { write } for pid=129605 co mm="gstglcontext" path=2F6D656D66643A2F2E6E76696469615F6472762E5858585858582028646 56C6574656429 dev="tmpfs" ino=1025 scontext=unconfined_u:unconfined_r:thumb_t:s0-s 0:c0.c1023 tcontext=system_u:object_r:xserver_tmpfs_t:s0 tclass=file permissive=0
Are all of your alerts of this kind? You may want to use "ausearch" with -c gstglcontext. You can narrow the window by using -ts in the ausearch command. Looking a the man page to find the options for that parameter.
After doing the above described test, I ran the command to get everything from the start of yesterday. I posted the results in a simple text file on the google drive. Here's the link: "https://drive.google.com/file/d/1-BSwKWu_Mi3CozfLRi2dQmzPndi3HHqj/view?usp=s..."
That being said, gstglcontext is related to OpenGL which "is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics". The "scontext" has as part of it xserver_tmpfs_t which furthers this.
So, the next time you get this alert check out the AVC and find the process associated with pid=.
I tried that using "ps -ef | grep [pid]". The only hit was the ps command itself.
I still have the SELinux alert details for the past several days. I can post anything that you want to see, if that would help.
On 15/04/2021 00:33, home user wrote:
I tried that using "ps -ef | grep [pid]". The only hit was the ps command itself.
It is not clear to me that you did this immediately after getting the alert.
According to the ausearch_out the PID is different at each instance of an alert. So, it is possible that whatever process produced the alert has exited or died after the series of alerts.
He might want to run a strace -o appname.out -f <startupappgettingtheerrorandoptions>
And then do the ausearch and we should be able to see what what the pid was doing and/or what executable it was.
On Wed, Apr 14, 2021 at 1:52 PM Ed Greshko ed.greshko@greshko.com wrote:
On 15/04/2021 00:33, home user wrote:
I tried that using "ps -ef | grep [pid]". The only hit was the ps command itself.
It is not clear to me that you did this immediately after getting the alert.
According to the ausearch_out the PID is different at each instance of an alert. So, it is possible that whatever process produced the alert has exited or died after the series of alerts.
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/14/21 12:52 PM, Ed Greshko wrote:
On 15/04/2021 00:33, home user wrote:
I tried that using "ps -ef | grep [pid]". The only hit was the ps command itself.
It is not clear to me that you did this immediately after getting the alert.
1. I launched caja from the gnome activities dash. The caja GUI displays. 2. The SELinux alert shows up. 3. I trackball over to the alert and click the Details button. 4. The Details window comes up, I trackball over to it, I make it bigger. 5. I scroll down and look for the pid. 6. I trackball over to the terminal and enter the ps command. Steps 2 thru 6 do take several seconds, maybe up to a minute. That's as "immediate" as I can do.
According to the ausearch_out the PID is different at each instance of an alert. So, it is possible that whatever process produced the alert has exited or died after the series of alerts.
I agree.
On 15/04/2021 05:06, home user wrote:
On 4/14/21 12:52 PM, Ed Greshko wrote:
On 15/04/2021 00:33, home user wrote:
I tried that using "ps -ef | grep [pid]". The only hit was the ps command itself.
It is not clear to me that you did this immediately after getting the alert.
- I launched caja from the gnome activities dash. The caja GUI displays.
- The SELinux alert shows up.
- I trackball over to the alert and click the Details button.
- The Details window comes up, I trackball over to it, I make it bigger.
- I scroll down and look for the pid.
- I trackball over to the terminal and enter the ps command.
Steps 2 thru 6 do take several seconds, maybe up to a minute. That's as "immediate" as I can do.
Is your desktop "GNOME" or "GNOME on Xorg"?
Which ever one it is, could you try switching to the other one to see if the issue continues to exist?
really just start caja from the terminal with strace -o caja.out -f `which caja`
do what you normally do and exit.
then grep pid caja.out and that will should tell you what executable that pid was and some of what it did.
That will produce an .out file that contains all of the pid's and what those pids were and some of what they did.
On Wed, Apr 14, 2021 at 4:09 PM home user mattisonw@comcast.net wrote:
On 4/14/21 1:50 PM, Roger Heflin wrote:
He might want to run a strace -o appname.out -f
<startupappgettingtheerrorandoptions>
And then do the ausearch and we should be able to see what what the pid was doing and/or what executable it was.
What options would you find most helpful? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/14/21 3:18 PM, Ed Greshko wrote:
Is your desktop "GNOME" or "GNOME on Xorg"?
The desktop menu at login has 4 GNOME entries: GNOME GNOME GNOME Classic GNOME on Xorg I usually use the first GNOME. Side question: What's the difference between the first two entries?
Which ever one it is, could you try switching to the other one to see if the issue continues to exist?
Unable to determine!
I logged out, and then logged back in without changing the desktop. I launched Files. No alert. I launched caja. No alert.
I shut down and the booted up and logged in with GNOME. I launched Files. No alert. I launched caja. No alert.
I shut down and booted up and logged in with GNOME. I launched caja. No alert.
I shut down and booted up and logged in with GNOME on Xorg. I launched caja. No alert.
Yesterday evening, I suspected that the problem can be reproduced only once per day. That's why I said last night that I would test this morning.
The above test sequence strengthens my suspicion, but does not prove, that this problem can be reproduced only once per day (not once per login session, not once per boot session). I can't (yet) rule out that the open terminal, Thunderbird, or "youtube-dl" somehow play into this.
I'm also still trying to determine whether this problem is unique to caja, or if Files has the same problem.
I'll try your suggested test again tomorrow morning.
On 4/14/21 3:46 PM, Roger Heflin wrote:
really just start caja from the terminal with strace -o caja.out -f `which caja`
do what you normally do and exit.
then grep pid caja.out and that will should tell you what executable that pid was and some of what it did.
That will produce an .out file that contains all of the pid's and what those pids were and some of what they did.
I'll try this tomorrow morning. See my reply to Ed for the explanation.
On Wed, Apr 14, 2021 at 4:09 PM home user mattisonw@comcast.net wrote:
On 4/14/21 1:50 PM, Roger Heflin wrote:
He might want to run a strace -o appname.out -f
<startupappgettingtheerrorandoptions>
And then do the ausearch and we should be able to see what what the pid was doing and/or what executable it was.
What options would you find most helpful?
On 15/04/2021 05:57, home user wrote:
Is your desktop "GNOME" or "GNOME on Xorg"?
The desktop menu at login has 4 GNOME entries: GNOME GNOME GNOME Classic GNOME on Xorg I usually use the first GNOME. Side question: What's the difference between the first two entries?
I don't know why you'd have 2. Both are probably Wayland.
So, tomorrow, start by using "GNOME on Xorg"
As far as determining if you're in a wayland or Xorg environment.
Wayland [egreshko@f33g ~]$ env | grep -i wayland XDG_SESSION_TYPE=wayland XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.3OTU10 WAYLAND_DISPLAY=wayland-0 [egreshko@f33g ~]$
Xorg [egreshko@f33g ~]$ env | grep -i wayland [egreshko@f33g ~]$
Also
Wayland earlyoom 572 1 0 06:41 ? 00:00:00 /usr/bin/earlyoom -r 0 -m 4 -M 409600 --prefer ^Web Content$ --avoid ^(dnf|packagekitd|gnome-shell|gnome-session-c|gnome-session-b|lightdm|sddm|sddm-helper|gdm|gdm-wayland-ses|gdm-session-wor|gdm-x-session|Xorg|Xwayland|systemd|systemd-logind|dbus-daemon|dbus-broker|cinnamon|cinnamon-sessio|kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session|startplasma-way|xfce4-session|mate-session|marco|lxqt-session|openbox)$ egreshko 1299 1253 0 06:42 tty2 00:00:00 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session egreshko 1432 1375 0 06:42 ? 00:00:00 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.X2CY10 -listen 4 -listen 5 -displayfd 6 -listen 7
Xorg Ony the line for earlyoom.
On 4/14/21 4:43 PM, Ed Greshko wrote:
On 15/04/2021 05:57, home user wrote:
The desktop menu at login has 4 GNOME entries: GNOME GNOME GNOME Classic GNOME on Xorg I usually use the first GNOME. Side question: What's the difference between the first two entries?
So, tomorrow, start by using "GNOME on Xorg"
As far as determining if you're in a wayland or Xorg environment.
Wayland [egreshko@f33g ~]$ env | grep -i wayland XDG_SESSION_TYPE=wayland XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.3OTU10 WAYLAND_DISPLAY=wayland-0 [egreshko@f33g ~]$
Xorg [egreshko@f33g ~]$ env | grep -i wayland [egreshko@f33g ~]$
Done as requested.
Regardless of whether I log in using the first, third, or fourth GNOME choice, I get: bash.1[~]: env | grep -i wayland bash.2[~]: I did not try GNOME Classic.
Also
Wayland earlyoom 572 1 0 06:41 ? 00:00:00 /usr/bin/earlyoom -r 0 -m 4 -M 409600 --prefer ^Web Content$ --avoid ^(dnf|packagekitd|gnome-shell|gnome-session-c|gnome-session-b|lightdm|sddm|sddm-helper|gdm|gdm-wayland-ses|gdm-session-wor|gdm-x-session|Xorg|Xwayland|systemd|systemd-logind|dbus-daemon|dbus-broker|cinnamon|cinnamon-sessio|kwin_x11|kwin_wayland|plasmashell|ksmserver|plasma_session|startplasma-way|xfce4-session|mate-session|marco|lxqt-session|openbox)$
egreshko 1299 1253 0 06:42 tty2 00:00:00 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session egreshko 1432 1375 0 06:42 ? 00:00:00 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.X2CY10 -listen 4 -listen 5 -displayfd 6 -listen 7
Xorg Ony the line for earlyoom.
What command did you use for the above? It looks like "ps" output, but when I try, I get these: bash.8[~]: ps -ef | grep -i earlyoom weilian+ 2823 2705 0 09:53 pts/0 00:00:00 grep --color=auto -i earlyoom bash.9[~]: ps -aux | grep -i earlyoom weilian+ 2829 0.0 0.0 221564 840 pts/0 S+ 09:53 0:00 grep --color=auto -i earlyoom bash.10[~]: ps -al | grep -i earlyoom bash.11[~]:
I did also try logging in to plasma with wayland. After entering my credentials, the screens went black. After 2 minutes, I hit the hard reset and rebooted.
Through 8 years of weekly patches and semi-annual upgrades, I've never done anything to block or disable wayland. Shouldn't it have been automatically installed somewhere in those 8 years? What did I do wrong or not do?
I'll report caja testing in my next message.
(responding to multiple posts)
As Ed requested, this morning I signed in to "GNOME on Xorg" first. My tests were as follows.
Test A. 1. Using the command line in a terminal, I downloaded a Chinese music video. The resulting file has a name made of traditional (Taiwan) Chinese characters. 2. I launched caja. A SELinux alert pops up. 3. I used caja to rename the file to something with all ASCII characters. A Selinux alert pops up. Steps 2 and 3 were done a few times. For step 2, the SELinux alert occurs the first time only. For step 3, the SELinux alert occurs every time.
Then Test B. 1. I did "strace -o caja.out -f /usr/bin/caja". 2. I used caja to rename a file to something with all ASCII characters. A Selinux alert pops up. 3. I closed caja by clicking the little x in the upper right corner of the GUI.
Then Test C. 1. I launched Files. 2. I used Files to rename a file to something with all ASCII characters. 3. I closed Files by clicking the little x in the upper right corner of the GUI. No SELinux alerts.
Then Test D. 1. I launched caja. 2. I used caja to rename a file to something with all ASCII characters. 3. I closed caja by clicking the little x in the upper right corner of the GUI. No SELinux alerts.
Files seems to do something that prevents any further SELinux alerts from caja for the rest of the day.
I did: bash.2[~]: su - Password: -bash.1[~]: ausearch -c gstglcontext -ts today > ausearch_Thurs.txt -bash.2[~]: vi ausearch_Thurs.txt Based on time stamps, I found that the process ID for Test B was 2636. I did: bash.17[~]: grep 2636 caja.out > grep2636.out The resulting file is over 34000 lines long. How can I pare this down? What should I put on the google drive for y'all to view?
Google drive probably. The first few lines should tell you what process it was starting.
I really usually only look at filesystem type calls as those are usually the most valuable for something like this. open, unlink (remove), stat (get info like ls shows), and say rename or renameat.
A lot of stats always fail as it is used to see if various things exist here or there.
Basic it loads an executable, lots of setup of that executable then toward the end is the real work the program does.
On a mv strace I get 117 lines with the executable and options at the top, a bunch of loading of libs and stuff for executable then 10 lines from the bottom is the actual rename, and the exit of the program.
On Thu, Apr 15, 2021 at 11:49 AM home user mattisonw@comcast.net wrote:
(responding to multiple posts)
As Ed requested, this morning I signed in to "GNOME on Xorg" first. My tests were as follows.
Test A.
- Using the command line in a terminal, I downloaded a Chinese music
video. The resulting file has a name made of traditional (Taiwan) Chinese characters. 2. I launched caja. A SELinux alert pops up. 3. I used caja to rename the file to something with all ASCII characters. A Selinux alert pops up. Steps 2 and 3 were done a few times. For step 2, the SELinux alert occurs the first time only. For step 3, the SELinux alert occurs every time.
Then Test B.
- I did "strace -o caja.out -f /usr/bin/caja".
- I used caja to rename a file to something with all ASCII characters.
A Selinux alert pops up. 3. I closed caja by clicking the little x in the upper right corner of the GUI.
Then Test C.
- I launched Files.
- I used Files to rename a file to something with all ASCII characters.
- I closed Files by clicking the little x in the upper right corner of
the GUI. No SELinux alerts.
Then Test D.
- I launched caja.
- I used caja to rename a file to something with all ASCII characters.
- I closed caja by clicking the little x in the upper right corner of
the GUI. No SELinux alerts.
Files seems to do something that prevents any further SELinux alerts from caja for the rest of the day.
I did: bash.2[~]: su - Password: -bash.1[~]: ausearch -c gstglcontext -ts today > ausearch_Thurs.txt -bash.2[~]: vi ausearch_Thurs.txt Based on time stamps, I found that the process ID for Test B was 2636. I did: bash.17[~]: grep 2636 caja.out > grep2636.out The resulting file is over 34000 lines long. How can I pare this down? What should I put on the google drive for y'all to view? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/15/21 9:48 AM, home user wrote:
Based on time stamps, I found that the process ID for Test B was 2636. I did: bash.17[~]: grep 2636 caja.out > grep2636.out The resulting file is over 34000 lines long. How can I pare this down? What should I put on the google drive for y'all to view?
The first few lines should be a bit of setup and an "exec" call. The "exec" should show what program was being called. Any further steps will depend on what that shows.
On 4/15/21 3:57 PM, Roger Heflin wrote: (also responding to Samuel)
Google drive probably. The first few lines should tell you what process it was starting.
I really usually only look at filesystem type calls as those are usually the most valuable for something like this. open, unlink (remove), stat (get info like ls shows), and say rename or renameat.
A lot of stats always fail as it is used to see if various things exist here or there.
Basic it loads an executable, lots of setup of that executable then toward the end is the real work the program does.
On a mv strace I get 117 lines with the executable and options at the top, a bunch of loading of libs and stuff for executable then 10 lines from the bottom is the actual rename, and the exit of the program.
bash.32[~]: grep 2636 caja.out > grep2636.txt bash.33[~]: grep open caja.out > grepopen.txt bash.34[~]: grep stat caja.out > grepstat.txt bash.35[~]: bash.35[~]: grep exec caja.out 2619 execve("/usr/bin/caja", ["/usr/bin/caja"], 0x7fff14191888 /* 69 vars */) = 0 2622 read(27, "2619 execve("/usr/bin/caja", [""..., 4096) = 4096 2636 execve("/usr/bin/totem-video-thumbnailer", ["/usr/bin/totem-video-thumbnailer", "-s", "128", "file:///home/bill/KhongWe"..., "/tmp/.mate_desktop_thumbnail.19V"...], 0x7ffdd556b338 /* 69 vars */ <unfinished ...> 2636 <... execve resumed>) = 0 2652 openat(AT_FDCWD, "/sys/fs/selinux/booleans/allow_execmem", O_RDONLY) = -1 ENOENT (No such file or directory) 2652 openat(AT_FDCWD, "/sys/fs/selinux/booleans/allow_execmem", O_RDONLY) = -1 ENOENT (No such file or directory) 2652 openat(AT_FDCWD, "/sys/fs/selinux/booleans/deny_execmem", O_RDONLY) = 31 bash.36[~]: bash.36[~]: grep unlink caja.out 2643 unlink("") = -1 ENOENT (No such file or directory) 2635 unlink("/tmp/.mate_desktop_thumbnail.19VW10") = 0 2635 unlink("/home/bill/.cache/thumbnails/fail/mate-thumbnail-factory/c39b432d203676f5e93a91a2d0d076d4.png.NVLR10") = -1 ENOENT (No such file or directory) bash.37[~]: bash.37[~]: grep remove caja.out 2636 stat("/usr/lib64/gstreamer-1.0/libgstremovesilence.so", {st_mode=S_IFREG|0755, st_size=28392, ...}) = 0 bash.38[~]: bash.38[~]: grep rename caja.out 2635 rename("/home/bill/KhongWeeHo.mkv", "/home/bill/KhongWeeHo_20160327.mkv" <unfinished ...> 2635 <... rename resumed>) = 0 2635 rename("/home/bill/.cache/thumbnails/fail/mate-thumbnail-factory/c39b432d203676f5e93a91a2d0d076d4.png.NVLR10", "/home/bill/.cache/thumbnails/fail/mate-thumbnail-factory/c39b432d203676f5e93a91a2d0d076d4.png") = 0 bash.39[~]:
The grep for the process ID "2636" found lines. The grep for "open" found 4665 lines. The grep for "stat" found 7449 lines.
The file caja.out is 148910 lines long.
It seems to be running /usr/bin/totem-video-thumbnailer" so would be something attempting to create a thumbnail for the file if it is a video.
It has an extension of .mkv so it thinks it is a video file or is it something else?
the command was: /usr/bin/totem-video-thumbnailer -s 128 file:///home/bill/KhongWe"..., "/tmp/.mate_desktop_thumbnail.19V"
It truncated the filenames, but you could test run the command and see what it does from the command line. The first filename is the input file, the 2nd one is the output of the thumbnail.
On Thu, Apr 15, 2021 at 9:31 PM home user mattisonw@comcast.net wrote:
On 4/15/21 8:27 PM, home user wrote:
The grep for the process ID "2636" found lines.
Correction:
The grep for the process ID "2636" found 34361 lines. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/16/21 5:41 AM, Roger Heflin wrote:
It seems to be running /usr/bin/totem-video-thumbnailer" so would be something attempting to create a thumbnail for the file if it is a video.
It has an extension of .mkv so it thinks it is a video file or is it something else?
It is a video file.
the command was: /usr/bin/totem-video-thumbnailer -s 128 file:///home/bill/KhongWe"..., "/tmp/.mate_desktop_thumbnail.19V"
It truncated the filenames, but you could test run the command and see what it does from the command line. The first filename is the input file, the 2nd one is the output of the thumbnail.
bash.2[~]: totem-video-thumbnailer KhongWeeHo_20160327.mkv KhongWeeHo_20160327.png X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 63 Current serial number in output stream: 64 bash.3[~]:
I also tried an mp4 video file that I have. Same result.
That matches what Ed had called out that it was a GL* command.
I guess that also tells you why you did not notice the failing..
given a video file and an png file to output it fails on my system also (and that is with selinux as permissive and as root, so it seems to have many issues and is simply broken in most if not all use cases), and I don't know that I have seen a video thumbnail in a while in gthumb and similar tools.
And that tool seems to be very complicated for just creating a thumbnail as it connects to X and pulseaudio and GLX, I am guessing someone took a gui app and made it work to generate one. I sure whoever decided to use this tool only knew about the this way to generate a thumbnail. And the saying goes if the only tool you have is a hammer then everything looks like a nail.
For creating a thumbnail ffmpeg and/or mplayer would seem better, but maybe that is not default on the systems. I might see if I can create a script that would get used in gthumb as this tells me why I get no thumbnails.
On Fri, Apr 16, 2021 at 10:27 AM home user mattisonw@comcast.net wrote:
On 4/16/21 5:41 AM, Roger Heflin wrote:
It seems to be running /usr/bin/totem-video-thumbnailer" so would be something attempting to create a thumbnail for the file if it is a video.
It has an extension of .mkv so it thinks it is a video file or is it something else?
It is a video file.
the command was: /usr/bin/totem-video-thumbnailer -s 128 file:///home/bill/KhongWe"..., "/tmp/.mate_desktop_thumbnail.19V"
It truncated the filenames, but you could test run the command and see what it does from the command line. The first filename is the input file, the 2nd one is the output of the thumbnail.
bash.2[~]: totem-video-thumbnailer KhongWeeHo_20160327.mkv KhongWeeHo_20160327.png X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 63 Current serial number in output stream: 64 bash.3[~]:
I also tried an mp4 video file that I have. Same result. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/16/21 10:27 AM, Roger Heflin wrote:
That matches what Ed had called out that it was a GL* command.
I guess that also tells you why you did not notice the failing..
given a video file and an png file to output it fails on my system also (and that is with selinux as permissive and as root, so it seems to have many issues and is simply broken in most if not all use cases), and I don't know that I have seen a video thumbnail in a while in gthumb and similar tools.
And that tool seems to be very complicated for just creating a thumbnail as it connects to X and pulseaudio and GLX, I am guessing someone took a gui app and made it work to generate one. I sure whoever decided to use this tool only knew about the this way to generate a thumbnail. And the saying goes if the only tool you have is a hammer then everything looks like a nail.
For creating a thumbnail ffmpeg and/or mplayer would seem better, but maybe that is not default on the systems. I might see if I can create a script that would get used in gthumb as this tells me why I get no thumbnails.
What I think you're saying, and my impression even apart from your post, is that we can't realistically solve this SELinux alert problem. This problem really has had me baffled. The SELinux alerts seem to be false alarms; caja does what I want to do, and I can do those things other ways also. So I'm inclined to go with what Ed said Tuesday:
But if you're not having any problems it would be something that I'd ignore.
For what it's worth: * I saw no SELinux alerts when trying totem-video-thumbnailer in the command line. I forgot to mention this in this morning's post. * I found this morning that SELinux alerts can show up when doing file renaming after having run Files in the same login session. So Files does not stop further caja SELinux alerts. * I patched my workstation (dnf upgrade) yesterday.
On Fri, Apr 16, 2021 at 10:27 AM home user mattisonw@comcast.net wrote:
On 4/16/21 5:41 AM, Roger Heflin wrote:
It seems to be running /usr/bin/totem-video-thumbnailer" so would be something attempting to create a thumbnail for the file if it is a video.
It has an extension of .mkv so it thinks it is a video file or is it something else?
It is a video file.
the command was: /usr/bin/totem-video-thumbnailer -s 128 file:///home/bill/KhongWe"..., "/tmp/.mate_desktop_thumbnail.19V"
It truncated the filenames, but you could test run the command and see what it does from the command line. The first filename is the input file, the 2nd one is the output of the thumbnail.
bash.2[~]: totem-video-thumbnailer KhongWeeHo_20160327.mkv KhongWeeHo_20160327.png X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 63 Current serial number in output stream: 64 bash.3[~]:
I also tried an mp4 video file that I have. Same result.
On Fri, 2021-04-16 at 11:27 -0500, Roger Heflin wrote:
given a video file and an png file to output it fails on my system also (and that is with selinux as permissive and as root, so it seems to have many issues and is simply broken in most if not all use cases), and I don't know that I have seen a video thumbnail in a while in gthumb and similar tools.
The file browsers on Gnome/MATE haven't been able to create thumbnails for video files on my computers in many years. Nothing that I tried made it work again, and I gave up long ago.
It was a handy feature being able to see some image inside of a stupidly named video file, to work out which was which.
On 4/16/21 8:51 PM, Tim via users wrote:
On Fri, 2021-04-16 at 11:27 -0500, Roger Heflin wrote:
given a video file and an png file to output it fails on my system also (and that is with selinux as permissive and as root, so it seems to have many issues and is simply broken in most if not all use cases), and I don't know that I have seen a video thumbnail in a while in gthumb and similar tools.
The file browsers on Gnome/MATE haven't been able to create thumbnails for video files on my computers in many years. Nothing that I tried made it work again, and I gave up long ago.
It was a handy feature being able to see some image inside of a stupidly named video file, to work out which was which.
My experience is that sometimes I do get images from the video, and sometimes I just get a right-pointing arrow centered in an old-fashioned CRT TV screen. I haven't been able to discern a pattern as to when I get which. I do notice that the odds of getting pictures is better when the display is in grid mode rather than list mode.
This morning, I was able to get SELinux alerts when running totem-video-thumbnailer. I submitted a bug. Here's the link: "https://bugzilla.redhat.com/show_bug.cgi?id=1951668".
The SELinux alerts stopped on Thursday April 29. That would have been when I did weekly patches ("dnf upgrade"). I also did weekly patches on Thursday, May 06. Since the alerts did not start showing up again, I'm now confident they're really fixed.
I've added a comment to "https://bugzilla.redhat.com/show_bug.cgi?id=1951668" saying what I said in the preceding paragraph of this post.
I don't know what in the patches fixed things, but this workstation is fixed.
I thank everyone who tried help. I've marked this thread SOLVED.
Bill.
I'm wondering?....the ugrade/patches fixed it?....would it have been fixed "sooner" if you had run the dnf upgrade sooner? or was it the "latest" upgrade/patch that did it?...
On Tue, May 11, 2021, 12:35 PM home user mattisonw@comcast.net wrote:
The SELinux alerts stopped on Thursday April 29. That would have been when I did weekly patches ("dnf upgrade"). I also did weekly patches on Thursday, May 06. Since the alerts did not start showing up again, I'm now confident they're really fixed.
I've added a comment to "https://bugzilla.redhat.com/show_bug.cgi?id=1951668" saying what I said in the preceding paragraph of this post.
I don't know what in the patches fixed things, but this workstation is fixed.
I thank everyone who tried help. I've marked this thread SOLVED.
Bill. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 5/11/21 2:05 PM, Eddie O'Connor wrote:
I'm wondering?....the ugrade/patches fixed it?....would it have been fixed "sooner" if you had run the dnf upgrade sooner? or was it the "latest" upgrade/patch that did it?...
On Tue, May 11, 2021, 12:35 PM home user <mattisonw@comcast.net mailto:mattisonw@comcast.net> wrote:
The SELinux alerts stopped on Thursday April 29. That would have been when I did weekly patches ("dnf upgrade"). I also did weekly patches on Thursday, May 06. Since the alerts did not start showing up again, I'm now confident they're really fixed. I've added a comment to "https://bugzilla.redhat.com/show_bug.cgi?id=1951668 <https://bugzilla.redhat.com/show_bug.cgi?id=1951668>" saying what I said in the preceding paragraph of this post. I don't know what in the patches fixed things, but this workstation is fixed. I thank everyone who tried help. I've marked this thread SOLVED. Bill.
1. before April 08, f32: no SELinux alerts. 2. April 08: upgrade from f32 to f33 (dnf system-upgrade [etc]). 3. April 08, f33: patch (dnf upgrade); dnf reported "nothing to do". 4. f33: SELinux alerts occurring. 5. April 15, f33: patch (dnf upgrade). 6. f33: SELinux alerts continue. 7. April 22, f33: patch (dnf upgrade). 8. SELinux alerts continue. 9. April 29, f33: patch (dnf upgrade). 10. f33: no more SELinux alerts. 11. May 06, f33: patch (dnf upgrade). 12. f33: Still no more SELinux alerts. Reasonable, probable, but not certain conclusions: a. The April 08 upgrade (step 2 above) introduced the problems. b. Whatever fixed the problems in f33 was released sometime between April 22 and April 29. c. Something in my April 29 f33 patching (step 9 above) fixed the problems. That's as much of an answer as I can give. This all applies to both the SELinux problems and what was addressed in my "System Failure?" thread.
On Wed, 2021-05-12 at 12:55 -0600, home user wrote:
That's as much of an answer as I can give. This all applies to both the SELinux problems and what was addressed in my "System Failure?" thread.
DNF has a history command, which shows what was installed at various stages. If you type "dnf history", you get a table of events. Then you can use "dnf info" followed by the entry number you're interested in, you'll see what packages were installed/updated that time.
-
Ed Greshko -
Eddie O'Connor -
home user -
Roger Heflin -
Samuel Sieb -
Tim