Carlos E. R. wrote:
On 2023-01-26 19:31, Patrick Shanahan wrote:
Many people have been doing that, uninstall-reinstall for years and years.
Can't say I'm one of them.
but you have heard of many people uninstall/reinstall as a solutin?
Not exactly, but maybe I'm not moving in the right circles :-)
Overall, I don't subscribe to such band-aid "solutions", especially not when it ought to be easy to diagnose the problem. (sound is hardly black magic any more).
Google it.
That presumes I am interested :-)
Examples:
SuSE 9.3, from 2005 ... almost twenty years old. Seriously?
openSUSE 12.3 - 8 years old?
Instead of trawling through the archives of time, maybe post some config data and some dmesg output (related to your sound module).
On Fri, Jan 27, 2023 at 11:24 AM Per Jessen per@jessen.ch wrote:
Overall, I don't subscribe to such band-aid "solutions", especially not when it ought to be easy to diagnose the problem. (sound is hardly black magic any more).
It most certainly is for anyone who does not spend their lifetime maintaining Linux sound stack. Even a simple task such as choosing an output device could be really daunting (I was immensely surprised when I plugged in headphones and lo and behold - I got a popup asking whether I have headphones, microphones or both. Without this question I would not even know where to start).
And it is not really limited to Linux. As soon as you have any issue in Windows the only recommendation you get is reinstalling drivers or management programs.
So yes, starting YaST is probably the most simple practical workaround. While I have seen many requests for some output related to sound problems on this list, I do not remember any actual solution based on the provided output (and I have a feeling that requesters did not really know what to do with it anyway). I do not count blanket "remove pulse and install pipewire" as "solution".
Andrei Borzenkov wrote:
On Fri, Jan 27, 2023 at 11:24 AM Per Jessen per@jessen.ch wrote:
Overall, I don't subscribe to such band-aid "solutions", especially not when it ought to be easy to diagnose the problem. (sound is hardly black magic any more).
It most certainly is for anyone who does not spend their lifetime maintaining Linux sound stack.
To the user, yes, many things are certainly black magic :-)
I merely meant to say that help can be found, certainly in the majority of cases.
On 2023-01-27 09:52, Andrei Borzenkov wrote:
On Fri, Jan 27, 2023 at 11:24 AM Per Jessen per@jessen.ch wrote:
Overall, I don't subscribe to such band-aid "solutions", especially not when it ought to be easy to diagnose the problem. (sound is hardly black magic any more).
It most certainly is for anyone who does not spend their lifetime maintaining Linux sound stack. Even a simple task such as choosing an output device could be really daunting (I was immensely surprised when I plugged in headphones and lo and behold - I got a popup asking whether I have headphones, microphones or both. Without this question I would not even know where to start).
And it is not really limited to Linux. As soon as you have any issue in Windows the only recommendation you get is reinstalling drivers or management programs.
So yes, starting YaST is probably the most simple practical workaround. While I have seen many requests for some output related to sound problems on this list, I do not remember any actual solution based on the provided output (and I have a feeling that requesters did not really know what to do with it anyway). I do not count blanket "remove pulse and install pipewire" as "solution".
Thanks.
You nailed it.
So, my question is, if yast sound will go missing in the future (thinking of Leap, me), can someone find out what magic yast does so that we can replicate in the command line?
I do not want a solution for my sound. I wanted it this summer, now it is magically working again (as has been working for many years, it is an old machine, after all)
Hello,
In the Message;
Subject : Re: sound issue (was: Dropping yast2-sound) Message-ID : CAA91j0W6JRZSSK_Yvp7UYV4-fixWsfBoTRkKD+J9Y4Om7GoscQ@mail.gmail.com Date & Time: Fri, 27 Jan 2023 11:52:42 +0300
[AB] == Andrei Borzenkov arvidjaar@gmail.com has written:
[...] AB> I was immensely surprised when I plugged in headphones and lo and AB> behold - I got a popup asking whether I have headphones, microphones AB> or both. Without this question I would not even know where to AB> start). [...]
Just a question.
Are you talking about this phenomenon as after the device settings in the pavucontrol?
Regards & Good Night.
--- ┏━━┓彡 野宮 賢 mail-to: m.nomiya+suse @ gmail.com ┃＼／彡 ┗━━┛ "Bill! You married with Computer. Not with Me!" "No..., with money."
On 2023-01-27 09:18, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-01-26 19:31, Patrick Shanahan wrote:
Many people have been doing that, uninstall-reinstall for years and years.
Can't say I'm one of them.
but you have heard of many people uninstall/reinstall as a solutin?
Not exactly, but maybe I'm not moving in the right circles :-)
Overall, I don't subscribe to such band-aid "solutions", especially not when it ought to be easy to diagnose the problem. (sound is hardly black magic any more).
It was never easy. I remember threads going on for a month or so not finding the solution - except tell yast to reinstall.
We tried this summer with my machine, nothing worked. The only thing I did not try was to switch to the new pipewire. It was far easier to tell yast to reinstall.
Google it.
That presumes I am interested :-)
Examples:
SuSE 9.3, from 2005 ... almost twenty years old. Seriously?
Yes, seriously. It was a quick search. I have seen similar dozen of times over the years.
The search is simply to prove that it is a known method to cure sound problems in *SUSE.
Myself, this summer.
openSUSE 12.3 - 8 years old?
Instead of trawling through the archives of time, maybe post some config data and some dmesg output (related to your sound module).
I did that, this summer.
No solution found, except to change to pipewire, way more time consuming. Now the machine has been updated to 15.4 and magically works again.
Carlos E. R. wrote:
On 2023-01-27 09:18, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-01-26 19:31, Patrick Shanahan wrote:
Many people have been doing that, uninstall-reinstall for years and years.
Can't say I'm one of them.
but you have heard of many people uninstall/reinstall as a solutin?
Not exactly, but maybe I'm not moving in the right circles :-)
Overall, I don't subscribe to such band-aid "solutions", especially not when it ought to be easy to diagnose the problem. (sound is hardly black magic any more).
It was never easy. I remember threads going on for a month or so not finding the solution - except tell yast to reinstall.
We tried this summer with my machine, nothing worked. The only thing I did not try was to switch to the new pipewire. It was far easier to tell yast to reinstall.
I guess that option will be gone soon ....
Examples:
SuSE 9.3, from 2005 ... almost twenty years old. Seriously?
Yes, seriously.
You misunderstand - I meant "seriously, you are presenting a 17 year old example of why something remains a problem today".
The search is simply to prove that it is a known method to cure sound problems in *SUSE.
I'm sorry, but two ancient exceptions really prove very little. IMHO.
No solution found, except to change to pipewire, way more time consuming. Now the machine has been updated to 15.4 and magically works again.
Good stuff.
On 2023-01-27 12:49, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-01-27 09:18, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-01-26 19:31, Patrick Shanahan wrote:
> Many people have been doing that, uninstall-reinstall for years > and years.
Can't say I'm one of them.
but you have heard of many people uninstall/reinstall as a solutin?
Not exactly, but maybe I'm not moving in the right circles :-)
Overall, I don't subscribe to such band-aid "solutions", especially not when it ought to be easy to diagnose the problem. (sound is hardly black magic any more).
It was never easy. I remember threads going on for a month or so not finding the solution - except tell yast to reinstall.
We tried this summer with my machine, nothing worked. The only thing I did not try was to switch to the new pipewire. It was far easier to tell yast to reinstall.
I guess that option will be gone soon ....
Examples:
SuSE 9.3, from 2005 ... almost twenty years old. Seriously?
Yes, seriously.
You misunderstand - I meant "seriously, you are presenting a 17 year old example of why something remains a problem today".
The search is simply to prove that it is a known method to cure sound problems in *SUSE.
I'm sorry, but two ancient exceptions really prove very little. IMHO.
No solution found, except to change to pipewire, way more time consuming. Now the machine has been updated to 15.4 and magically works again.
Good stuff.
So, if it were not for yast trick, I would have been 8 months without sound. Very nice, yes.
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included. I started with SuSE with version 5.2 after wrestling with Slackware on 3.5-inch floppies and Red Hat, mostly because of Yast. SuSE's support of Nvidia graphics and Buslogic SCSI controllers also helped.
Regards, Lew
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
On 2023-01-27 18:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
Yes, functionality (modules) being removed every few months.
After researching different flavors of Linux back in the mid 90’s I went with S.u.S.E. And stayed with openSUSE primarily because of YaST.
Ken Schneider
On Jan 27, 2023, at 1:10 PM, Carlos E. R. robin.listas@telefonica.net wrote:
On 2023-01-27 18:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
Yes, functionality (modules) being removed every few months.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 1/27/2023 1:20 PM, kschneider bout-tyme.net wrote:
After researching different flavors of Linux back in the mid 90’s I went with S.u.S.E. And stayed with openSUSE primarily because of YaST.
Ken Schneider
Without YAST or a similar in function and relatively easy to use tool, one big reason for using openSUSE or any SUSE at all no longer exists.
joe a.
Carlos E. R. wrote:
On 2023-01-27 18:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
Yes, functionality (modules) being removed every few months.
Please stop spreading FUD. It really is not useful.
I did wonder about what I use YaST for, so speaking purely for myself:
* installation * iSCSI configuration * repo management
There is something about printers as well, but I forget what it is, maybe listening to CUPS broadcasts?
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
Regards, Lew
* Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
On 1/27/23 12:58, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
Skys have been falling with increasing frequency these daze.
This is within the context of the announcement of NIS being dropped. That and the upcoming ALP change has many people feeling a bit nervous, I'm sure. Forward thinking is nice, but not at the expense of legacy users.
BTW, I just had audio go away on a 15.4 desktop just a couple of days ago where it was working before. I didn't take the time to troubleshoot it then, but I'm not looking forward to it. I'll try yast2 next week, I guess.
Regards, Lew
* Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 17:12]:
On 1/27/23 12:58, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
Skys have been falling with increasing frequency these daze.
This is within the context of the announcement of NIS being dropped. That and the upcoming ALP change has many people feeling a bit nervous, I'm sure. Forward thinking is nice, but not at the expense of legacy users.
BTW, I just had audio go away on a 15.4 desktop just a couple of days ago where it was working before. I didn't take the time to troubleshoot it then, but I'm not looking forward to it. I'll try yast2 next week, I guess.
cautionly awaiting changes before making assumptions and allegations for things not happening. anyway, prefer tumbleweed and none of the projected changes seem related. I have a tumbleweed test system continually updated (dup) that I have not rebooted for >120 days still performing it's usual duties w/o a problem. but I must remember as I am constantly reminded that tumbleweed is highly unstable and a testing distro for leap. :)
but it is not. it is solid and dependable but does require a little love and kindness, which from list ramblings is not necessary for leap.
On 1/27/23 15:18, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 17:12]:
On 1/27/23 12:58, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote: > Soon yast will cease to exist, and there will be no more reason to > choose openSUSE. +1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
Skys have been falling with increasing frequency these daze.
This is within the context of the announcement of NIS being dropped. That and the upcoming ALP change has many people feeling a bit nervous, I'm sure. Forward thinking is nice, but not at the expense of legacy users.
BTW, I just had audio go away on a 15.4 desktop just a couple of days ago where it was working before. I didn't take the time to troubleshoot it then, but I'm not looking forward to it. I'll try yast2 next week, I guess.
cautionly awaiting changes before making assumptions and allegations for things not happening. anyway, prefer tumbleweed and none of the projected changes seem related. I have a tumbleweed test system continually updated (dup) that I have not rebooted for >120 days still performing it's usual duties w/o a problem. but I must remember as I am constantly reminded that tumbleweed is highly unstable and a testing distro for leap. :)
but it is not. it is solid and dependable but does require a little love and kindness, which from list ramblings is not necessary for leap.
Would you install and fully support a few dozen workstations and servers, some with almost a petabyte of RAID-6 storage, with Tumbleweed?
Regards, Lew
* Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 18:35]:
On 1/27/23 15:18, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 17:12]:
On 1/27/23 12:58, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
> On 1/27/23 04:05, Carlos E. R. wrote: > > Soon yast will cease to exist, and there will be no more reason to > > choose openSUSE. > +1 > > I've known Ubuntu and RHEL admins who switched to openSUSE > only because of Yast. Myself included. and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
Skys have been falling with increasing frequency these daze.
This is within the context of the announcement of NIS being dropped. That and the upcoming ALP change has many people feeling a bit nervous, I'm sure. Forward thinking is nice, but not at the expense of legacy users.
BTW, I just had audio go away on a 15.4 desktop just a couple of days ago where it was working before. I didn't take the time to troubleshoot it then, but I'm not looking forward to it. I'll try yast2 next week, I guess.
cautionly awaiting changes before making assumptions and allegations for things not happening. anyway, prefer tumbleweed and none of the projected changes seem related. I have a tumbleweed test system continually updated (dup) that I have not rebooted for >120 days still performing it's usual duties w/o a problem. but I must remember as I am constantly reminded that tumbleweed is highly unstable and a testing distro for leap. :)
but it is not. it is solid and dependable but does require a little love and kindness, which from list ramblings is not necessary for leap.
Would you install and fully support a few dozen workstations and servers, some with almost a petabyte of RAID-6 storage, with Tumbleweed?
probably out of my league :)
On 2023-01-28 00:18, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 17:12]:
On 1/27/23 12:58, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote: > Soon yast will cease to exist, and there will be no more reason to > choose openSUSE. +1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
Skys have been falling with increasing frequency these daze.
This is within the context of the announcement of NIS being dropped. That and the upcoming ALP change has many people feeling a bit nervous, I'm sure. Forward thinking is nice, but not at the expense of legacy users.
BTW, I just had audio go away on a 15.4 desktop just a couple of days ago where it was working before. I didn't take the time to troubleshoot it then, but I'm not looking forward to it. I'll try yast2 next week, I guess.
cautionly awaiting changes before making assumptions and allegations for things not happening. anyway, prefer tumbleweed and none of the projected changes seem related. I have a tumbleweed test system continually updated (dup) that I have not rebooted for >120 days
Then you are not updating it. You are still running 120 days old software. Of course you see no problems.
On 2023-01-27 23:10, Lew Wolfgang wrote:
On 1/27/23 12:58, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
Skys have been falling with increasing frequency these daze.
This is within the context of the announcement of NIS being dropped. That and the upcoming ALP change has many people feeling a bit nervous, I'm sure. Forward thinking is nice, but not at the expense of legacy users.
BTW, I just had audio go away on a 15.4 desktop just a couple of days ago where it was working before. I didn't take the time to troubleshoot it then, but I'm not looking forward to it. I'll try yast2 next week, I guess.
Try:
yast sound remove && yast2 sound add
in a terminal as root. Just curious. ;-)
I lost sound on a Lenovo Thinkpad P15 Gen 2 with Leap 15.4 after an update a month ago. I finally found my particular solution:
hwinfo -- sound told me I had two sound cards:
Model: "Intel Tiger Lake-H HD Audio Controller"
and
Model: "nVidia Audio device"
needing kernel modules:
snd_hda_intel
and
snd_sof_pci_intel_tgl
It seems the update a month ago had dropped these kernel modules.
I have now used yast2 software management to search for the kernel that provides these. It was kernel 5.14.21-150400.24.28-default I have added that kernel back to /boot/, rebooted and sound is back.
uname -a says I am using 5.14.21-150400.24.41-default
Even though /boot/ shows, dated today:
initrd-> initrd-5.14.21-150400.24.28-default
and
vmlinuz-> vmlinuz-5.14.21-150400.24.28-default
grub2 has today's date on it as well.
Carlos' solution below to remove and re-add sound did not work for me.
Hope this helps others with this problem.
On 1/27/23 20:13, Carlos E. R. wrote:
On 2023-01-27 23:10, Lew Wolfgang wrote:
On 1/27/23 12:58, Patrick Shanahan wrote:
- Lew Wolfgang wolfgang@sweet-haven.com [01-27-23 14:21]:
On 1/27/23 09:34, Per Jessen wrote:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote: > Soon yast will cease to exist, and there will be no more reason to > choose openSUSE. +1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
No, of course not. I was just substantiating Carlos' statement. But its contraction, however small, is cause for concern.
I believe it was announced that yast-sound was being dropped but no other. of course, we have to allow for chicken-little and the sky falling.
Skys have been falling with increasing frequency these daze.
This is within the context of the announcement of NIS being dropped. That and the upcoming ALP change has many people feeling a bit nervous, I'm sure. Forward thinking is nice, but not at the expense of legacy users.
BTW, I just had audio go away on a 15.4 desktop just a couple of days ago where it was working before. I didn't take the time to troubleshoot it then, but I'm not looking forward to it. I'll try yast2 next week, I guess.
Try:
yast sound remove && yast2 sound add
in a terminal as root. Just curious. ;-)
On 2023-02-01 10:42, Allen Wilkinson wrote:
I lost sound on a Lenovo Thinkpad P15 Gen 2 with Leap 15.4 after an update a month ago. I finally found my particular solution:
hwinfo -- sound told me I had two sound cards:
Model: "Intel Tiger Lake-H HD Audio Controller"
and
Model: "nVidia Audio device"
needing kernel modules:
snd_hda_intel
and
snd_sof_pci_intel_tgl
It seems the update a month ago had dropped these kernel modules.
My guess is they were moved to a related package. I don't see how to find that out, locate failed for me.
In any case, you should report in Bugzilla, that package should have been recommended and automatically installed for you.
I have now used yast2 software management to search for the kernel that provides these. It was kernel 5.14.21-150400.24.28-default I have added that kernel back to /boot/, rebooted and sound is back.
uname -a says I am using 5.14.21-150400.24.41-default
Even though /boot/ shows, dated today:
initrd-> initrd-5.14.21-150400.24.28-default
and
vmlinuz-> vmlinuz-5.14.21-150400.24.28-default
grub2 has today's date on it as well.
Carlos' solution below to remove and re-add sound did not work for me.
No, of course, if the module is gone it will not work.
Allen Wilkinson wrote:
snd_hda_intel and snd_sof_pci_intel_tgl
It seems the update a month ago had dropped these kernel modules.
I took a look at the kernel updates (http://download.opensuse.org/update/leap/15.4/sle/x86_64/)
kernel-default-5.14.21-150400.24.41.1.x86_64.rpm kernel-default-5.14.21-150400.24.38.1.x86_64.rpm kernel-default-5.14.21-150400.24.28.1.x86_64.rpm kernel-default-5.14.21-150400.24.21.2.x86_64.rpm kernel-default-5.14.21-150400.24.33.2.x86_64.rpm kernel-default-5.14.21-150400.24.18.1.x86_64.rpm
All of them have those modules:
per@localhost:~/gg> find * -type f -name snd-sof-pci-intel-tgl* 24.18/lib/modules/5.14.21-150400.24.18-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.21/lib/modules/5.14.21-150400.24.21-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.28/lib/modules/5.14.21-150400.24.28-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.33/lib/modules/5.14.21-150400.24.33-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.38/lib/modules/5.14.21-150400.24.38-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.41/lib/modules/5.14.21-150400.24.41-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst
per@localhost:~/gg> find * -type f -name snd-hda-intel* 24.18/lib/modules/5.14.21-150400.24.18-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.21/lib/modules/5.14.21-150400.24.21-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.28/lib/modules/5.14.21-150400.24.28-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.33/lib/modules/5.14.21-150400.24.33-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.38/lib/modules/5.14.21-150400.24.38-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.41/lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst
On 2023-02-01 12:07, Per Jessen wrote:
Allen Wilkinson wrote:
snd_hda_intel and snd_sof_pci_intel_tgl
It seems the update a month ago had dropped these kernel modules.
I took a look at the kernel updates (http://download.opensuse.org/update/leap/15.4/sle/x86_64/)
kernel-default-5.14.21-150400.24.41.1.x86_64.rpm kernel-default-5.14.21-150400.24.38.1.x86_64.rpm kernel-default-5.14.21-150400.24.28.1.x86_64.rpm kernel-default-5.14.21-150400.24.21.2.x86_64.rpm kernel-default-5.14.21-150400.24.33.2.x86_64.rpm kernel-default-5.14.21-150400.24.18.1.x86_64.rpm
All of them have those modules:
per@localhost:~/gg> find * -type f -name snd-sof-pci-intel-tgl* 24.18/lib/modules/5.14.21-150400.24.18-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.21/lib/modules/5.14.21-150400.24.21-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.28/lib/modules/5.14.21-150400.24.28-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.33/lib/modules/5.14.21-150400.24.33-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.38/lib/modules/5.14.21-150400.24.38-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst 24.41/lib/modules/5.14.21-150400.24.41-default/kernel/sound/soc/sof/intel/snd-sof-pci-intel-tgl.ko.zst
per@localhost:~/gg> find * -type f -name snd-hda-intel* 24.18/lib/modules/5.14.21-150400.24.18-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.21/lib/modules/5.14.21-150400.24.21-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.28/lib/modules/5.14.21-150400.24.28-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.33/lib/modules/5.14.21-150400.24.33-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.38/lib/modules/5.14.21-150400.24.38-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst 24.41/lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst
Why can't I locate them with locate?
cer@Elesar:~> locate snd-sof-pci-intel-tgl.ko.zst cer@Elesar:~> locate snd-hda-intel.ko.zst cer@Elesar:~>
Carlos E. R. wrote:
Why can't I locate them with locate?
Maybe a configuration issue? Can you find other kernel modules with 'locate'? I don't use locate, I'm not familiar with the configuration.
Carlos E. R. wrote:
Why can't I locate them with locate?
Either you have something in your conf (/etc/updatedb.conf) or your systemd update timer (mlocate.timer, /usr/lib/systemd/system/mlocate.timer) is out of order. I have TW, so it might be different on the Leap.
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
Why can't I locate them with locate?
Either you have something in your conf (/etc/updatedb.conf) or your systemd update timer (mlocate.timer, /usr/lib/systemd/system/mlocate.timer) is out of order. I have TW, so it might be different on the Leap.
It is recent.
cer@Elesar:~> l /var/lib/mlocate/mlocate.db -rw-r--r-- 1 nobody nobody 12713990 Feb 1 13:14 /var/lib/mlocate/mlocate.db cer@Elesar:~>
cer@Elesar:~> cat /etc/updatedb.conf # /etc/updatedb.conf: config file for mlocate
# This file sets variables that are used by updatedb. # For more info, see the updatedb.conf(5) manpage.
# Filesystems that are pruned from updatedb database PRUNEFS="9p afs anon_inodefs auto autofs bdev binfmt binfmt_misc ceph fuse.ceph cgroup cifs coda configfs cramfs cpuset debugfs devfs devpts devtmps ecryptfs eventpollfs exofs futexfs ftpfs fuse fusectl gfs gfs2 gpfs hostfs hugetlbfs inotifyfs iso9660 jffs2 lustre misc mqueue ncpfs nfs NFS nfs4 nfsd nnpfs ocfs ocfs2 pipefs proc ramfs rpc_pipefs securityfs selinuxfs sfs shfs smbfs sockfs spufs sshfs subfs supermount sysfs tmpfs ubifs udf usbfs vboxsf vperfctrfs"
# Paths which are pruned from updatedb database PRUNEPATHS="/tmp /var/tmp /var/cache /var/lock /var/run /var/spool /mnt /cdrom /usr/tmp /proc /media /sys /.snapshots /var/run/media /other /data"
# Folder names that are pruned from updatedb database PRUNENAMES = ".git .hg .svn .bzr .arch-ids {arch} CVS"
# Skip bind mounts. # DISABLED for bnc#994663 and to avoid btrfs subvolume issues PRUNE_BIND_MOUNTS="no" cer@Elesar:~>
I don't see why, unless the user "nobody" doesn't have permission to see modules. :-?
Yes, that is. Ridiculous.
Elesar:~ # time updatedb && locate snd-hda-intel.ko.zst
real 0m2.756s user 0m0.239s sys 0m0.713s /lib/modules/5.14.21-150400.24.38-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst /lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst Elesar:~ #
Elesar:~ # uname -a Linux Elesar 5.14.21-150400.24.41-default #1 SMP PREEMPT_DYNAMIC Fri Jan 13 08:55:22 UTC 2023 (1d4442d) x86_64 x86_64 x86_64 GNU/Linux Elesar:~ # rpm -qf /lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst kernel-default-5.14.21-150400.24.41.1.x86_64 Elesar:~ #
Elesar:~ # su - nobody nobody@Elesar:~> l /lib total 5020 drwxr-xr-x 10 root root 4096 Jan 31 14:43 ./ drwxr-xr-x 25 root root 4096 Dec 27 18:38 ../ drwxr-xr-x 2 root root 4096 Dec 27 19:03 apparmor/ -rwxr-xr-x 1 root root 82 Aug 23 2021 cpp* ...
nobody@Elesar:~> l /lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst -rw-r--r-- 1 root root 38245 Jan 16 13:48 /lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst nobody@Elesar:~>
Well, no, user nobody can list the module. Why can't "locate"?
Maybe because my "/usr" is a different partition in this machine? But it is not in my main machine at home.
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
Why can't I locate them with locate?
Either you have something in your conf (/etc/updatedb.conf) or your systemd update timer (mlocate.timer, /usr/lib/systemd/system/mlocate.timer) is out of order. I have TW, so it might be different on the Leap.
It is recent.
cer@Elesar:~> l /var/lib/mlocate/mlocate.db -rw-r--r-- 1 nobody nobody 12713990 Feb 1 13:14 /var/lib/mlocate/mlocate.db cer@Elesar:~>
cer@Elesar:~> cat /etc/updatedb.conf # /etc/updatedb.conf: config file for mlocate
# This file sets variables that are used by updatedb. # For more info, see the updatedb.conf(5) manpage.
# Filesystems that are pruned from updatedb database PRUNEFS="9p afs anon_inodefs auto autofs bdev binfmt binfmt_misc ceph fuse.ceph cgroup cifs coda configfs cramfs cpuset debugfs devfs devpts devtmps ecryptfs eventpollfs exofs futexfs ftpfs fuse fusectl gfs gfs2 gpfs hostfs hugetlbfs inotifyfs iso9660 jffs2 lustre misc mqueue ncpfs nfs NFS nfs4 nfsd nnpfs ocfs ocfs2 pipefs proc ramfs rpc_pipefs securityfs selinuxfs sfs shfs smbfs sockfs spufs sshfs subfs supermount sysfs tmpfs ubifs udf usbfs vboxsf vperfctrfs"
# Paths which are pruned from updatedb database PRUNEPATHS="/tmp /var/tmp /var/cache /var/lock /var/run /var/spool /mnt /cdrom /usr/tmp /proc /media /sys /.snapshots /var/run/media /other /data"
# Folder names that are pruned from updatedb database PRUNENAMES = ".git .hg .svn .bzr .arch-ids {arch} CVS"
# Skip bind mounts. # DISABLED for bnc#994663 and to avoid btrfs subvolume issues PRUNE_BIND_MOUNTS="no" cer@Elesar:~>
I don't see why, unless the user "nobody" doesn't have permission to see modules. :-?
Yes, that is. Ridiculous.
Elesar:~ # time updatedb && locate snd-hda-intel.ko.zst
real 0m2.756s user 0m0.239s sys 0m0.713s /lib/modules/5.14.21-150400.24.38-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst
/lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst
Elesar:~ #
Elesar:~ # uname -a Linux Elesar 5.14.21-150400.24.41-default #1 SMP PREEMPT_DYNAMIC Fri Jan 13 08:55:22 UTC 2023 (1d4442d) x86_64 x86_64 x86_64 GNU/Linux Elesar:~ # rpm -qf /lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst kernel-default-5.14.21-150400.24.41.1.x86_64 Elesar:~ #
Elesar:~ # su - nobody nobody@Elesar:~> l /lib total 5020 drwxr-xr-x 10 root root 4096 Jan 31 14:43 ./ drwxr-xr-x 25 root root 4096 Dec 27 18:38 ../ drwxr-xr-x 2 root root 4096 Dec 27 19:03 apparmor/ -rwxr-xr-x 1 root root 82 Aug 23 2021 cpp* ...
nobody@Elesar:~> l /lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst -rw-r--r-- 1 root root 38245 Jan 16 13:48 /lib/modules/5.14.21-150400.24.41-default/kernel/sound/pci/hda/snd-hda-intel.ko.zst nobody@Elesar:~>
Well, no, user nobody can list the module. Why can't "locate"?
Maybe because my "/usr" is a different partition in this machine? But it is not in my main machine at home.
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Grtz, Erwin
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow.
I would never have guessed that.
[Unit] Description=Update locate database Documentation=man:updatedb
[Service] # added automatically, for details please see # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort ProtectSystem=full ProtectHome=read-only PrivateDevices=true ProtectHostname=true ProtectClock=true ProtectKernelTunables=true ProtectKernelModules=true ProtectKernelLogs=true ProtectControlGroups=true RestrictRealtime=true # end of automatic additions Type=oneshot ExecStart=/bin/sh -c \ "chown -R ${RUN_UPDATEDB_AS}:root /var/lib/mlocate && \ su --shell=/bin/sh ${RUN_UPDATEDB_AS} -c /usr/bin/updatedb"
# Ensure we have proper umask bnc#941296 UMask=0022
# Alter the priority of the updatedb process Nice=19 IOSchedulingClass=2 IOSchedulingPriority=7
# Load sysconfig EnvironmentFile=/etc/sysconfig/locate
On Thu, 2 Feb 2023 13:32:14 +0100 "Carlos E. R." robin.listas@telefonica.net wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow.
I would never have guessed that.
[snip of evidence showing that actually is the case]
Is it just me or does that seem like a complication too far to everybody else? An unexpected failure of a well-known longstanding sevice with a totally unexpected and difficult to find reason, and all to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
On 2023-02-02 13:58, Dave Howorth wrote:
On Thu, 2 Feb 2023 13:32:14 +0100 "Carlos E. R." <> wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow.
I would never have guessed that.
[snip of evidence showing that actually is the case]
Is it just me or does that seem like a complication too far to everybody else? An unexpected failure of a well-known longstanding sevice with a totally unexpected and difficult to find reason, and all to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
I still have not read the documentation, so maybe my question is answered there. What is the problem with my users (me) finding the location of kernel modules? Or can it be exploited remotely? Surely only root can run or load a module.
I use "/etc/permissions.easy", not "secure" nor "paranoid". So why are we getting this extra hardening?
On 2023-02-02 14:11, Carlos E. R. wrote:
On 2023-02-02 13:58, Dave Howorth wrote:
On Thu, 2 Feb 2023 13:32:14 +0100 "Carlos E. R." <> wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow.
I would never have guessed that.
[snip of evidence showing that actually is the case]
Is it just me or does that seem like a complication too far to everybody else? An unexpected failure of a well-known longstanding sevice with a totally unexpected and difficult to find reason, and all to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
I still have not read the documentation, so maybe my question is answered there. What is the problem with my users (me) finding the location of kernel modules? Or can it be exploited remotely? Surely only root can run or load a module.
I use "/etc/permissions.easy", not "secure" nor "paranoid". So why are we getting this extra hardening?
I now have read the given link (https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort) and no, those questions are not answered there.
Dave Howorth wrote:
[snip of evidence showing that actually is the case]
Is it just me or does that seem like a complication too far to everybody else? An unexpected failure of a well-known longstanding sevice with a totally unexpected and difficult to find reason,
The lack of some error messages does seem ... hmm, disappointing.
and all to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
I don't think systemd is to blame (other than for providing the features), I think it is SUSE / ourselves:
https://en.opensuse.org/openSUSE:Security_Features -> Systemd hardening effort
On Thu, 02 Feb 2023 16:19:10 +0100 Per Jessen per@jessen.ch wrote:
Dave Howorth wrote:
[snip of evidence showing that actually is the case]
Is it just me or does that seem like a complication too far to everybody else? An unexpected failure of a well-known longstanding sevice with a totally unexpected and difficult to find reason,
The lack of some error messages does seem ... hmm, disappointing.
and all to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
I don't think systemd is to blame (other than for providing the features), I think it is SUSE / ourselves:
https://en.opensuse.org/openSUSE:Security_Features -> Systemd hardening effort
Yes, my apologies to the systemd folks. Somewhat of a sledgehammer approach by the opensuse folks. Move fast and break things, I suppose :(
It seems like adding a comment to https://bugzilla.suse.com/show_bug.cgi?id=1181400 pointing out that it breaks locate would be the right thing to do.
Dave Howorth wrote:
On Thu, 02 Feb 2023 16:19:10 +0100 Per Jessen per@jessen.ch wrote:
Dave Howorth wrote:
to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
I don't think systemd is to blame (other than for providing the features), I think it is SUSE / ourselves:
https://en.opensuse.org/openSUSE:Security_Features -> Systemd hardening effort
Yes, my apologies to the systemd folks. Somewhat of a sledgehammer approach by the opensuse folks. Move fast and break things, I suppose :(
There was a comment in the the wiki page, about the brute force mass implementation and how maintainers could decline. I guess nobody did.
Given that 'locate' isn't installed by default, maybe it's not used an awful lot anymore.
It seems like adding a comment to https://bugzilla.suse.com/show_bug.cgi?id=1181400 pointing out that it breaks locate would be the right thing to do.
Yep, agree.
On 2/2/23 8:31 AM, Per Jessen wrote:
Dave Howorth wrote:
On Thu, 02 Feb 2023 16:19:10 +0100 Per Jessen per@jessen.ch wrote:
Dave Howorth wrote:
to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
I don't think systemd is to blame (other than for providing the features), I think it is SUSE / ourselves:
https://en.opensuse.org/openSUSE:Security_Features -> Systemd hardening effort
Yes, my apologies to the systemd folks. Somewhat of a sledgehammer approach by the opensuse folks. Move fast and break things, I suppose :(
There was a comment in the the wiki page, about the brute force mass implementation and how maintainers could decline. I guess nobody did.
Given that 'locate' isn't installed by default, maybe it's not used an awful lot anymore.
I install it automatically because it's it's NOT default.
I work on commercial systems (not any flavor of suse) and it's always installed
It seems like adding a comment to https://bugzilla.suse.com/show_bug.cgi?id=1181400 pointing out that it breaks locate would be the right thing to do.
Yep, agree.
On 2023-02-02 17:31, Per Jessen wrote:
Dave Howorth wrote:
On Thu, 02 Feb 2023 16:19:10 +0100 Per Jessen per@jessen.ch wrote:
Dave Howorth wrote:
to what purpose? It doesn't stop bad actors accessing the modules in some other way. What were the systemd people smoking?
I don't think systemd is to blame (other than for providing the features), I think it is SUSE / ourselves:
https://en.opensuse.org/openSUSE:Security_Features -> Systemd hardening effort
Yes, my apologies to the systemd folks. Somewhat of a sledgehammer approach by the opensuse folks. Move fast and break things, I suppose :(
There was a comment in the the wiki page, about the brute force mass implementation and how maintainers could decline. I guess nobody did.
Given that 'locate' isn't installed by default, maybe it's not used an awful lot anymore.
It seems like adding a comment to https://bugzilla.suse.com/show_bug.cgi?id=1181400 pointing out that it breaks locate would be the right thing to do.
Yep, agree.
Done.
On 02.02.2023 19:23, Dave Howorth wrote:
It seems like adding a comment to https://bugzilla.suse.com/show_bug.cgi?id=1181400 pointing out that it breaks locate would be the right thing to do.
And what stops you from doing it?
On Thu, 2 Feb 2023 20:12:09 +0300 Andrei Borzenkov arvidjaar@gmail.com wrote:
On 02.02.2023 19:23, Dave Howorth wrote:
It seems like adding a comment to https://bugzilla.suse.com/show_bug.cgi?id=1181400 pointing out that it breaks locate would be the right thing to do.
And what stops you from doing it?
I'm not the one with the problem. I don't even use locate.
On 2/2/23 06:58, Dave Howorth wrote:
What were the systemd people smoking?
I've asked that for a decade now.... (since Arch first went to systemd)
While it is very capable, it has also turned into a monstrosity running at a known PID.
On 2023-02-02 13:32, Carlos E. R. wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow.
I would never have guessed that.
Does not work.
Elesar:~ # systemctl cat mlocate.service ... # /etc/systemd/system/mlocate.service.d/override.conf ProtectKernelModules=false
Elesar:~ # systemctl start mlocate.service Elesar:~ # locate snd-hda-intel Elesar:~ #
Carlos E. R. wrote:
Does not work.
Your service unit override is incomplete - it worked for me with this:
[Service] ProtectKernelModules=false
On 2023-02-02 17:20, Per Jessen wrote:
Carlos E. R. wrote:
Does not work.
Your service unit override is incomplete - it worked for me with this:
[Service] ProtectKernelModules=false
Oops. :-D
On Thu, 2 Feb 2023 14:24:47 +0100 "Carlos E. R." robin.listas@telefonica.net wrote:
On 2023-02-02 13:32, Carlos E. R. wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow.
I would never have guessed that.
Does not work.
Elesar:~ # systemctl cat mlocate.service ... # /etc/systemd/system/mlocate.service.d/override.conf ProtectKernelModules=false
Elesar:~ # systemctl start mlocate.service Elesar:~ # locate snd-hda-intel Elesar:~ #
Presumably you need to run updatedb or whatever it's called before you'll see any different results?
On 2023-02-02 17:21, Dave Howorth wrote:
On Thu, 2 Feb 2023 14:24:47 +0100 "Carlos E. R." robin.listas@telefonica.net wrote:
On 2023-02-02 13:32, Carlos E. R. wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow.
I would never have guessed that.
Does not work.
Elesar:~ # systemctl cat mlocate.service ... # /etc/systemd/system/mlocate.service.d/override.conf ProtectKernelModules=false
Elesar:~ # systemctl start mlocate.service Elesar:~ # locate snd-hda-intel Elesar:~ #
Presumably you need to run updatedb or whatever it's called before you'll see any different results?
That's the systemctl call ;-)
It works now, I had forgotten the "[service]" line.
Carlos E. R. wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow. I would never have guessed that.
Yeah, me neither. That was quite a find, but it would (eventually) have become apparent to anyone running an strace on updatedb.
On 2023-02-02 16:12, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow. I would never have guessed that.
Yeah, me neither. That was quite a find, but it would (eventually) have become apparent to anyone running an strace on updatedb.
To anyone, I doubt it. How is a systemd "thing" seen inside the updatedb call? I'm unsure I would see it.
Wait, I don't know how to trace a program that is run this way:
systemctl start mlocate.service
Carlos E. R. wrote:
On 2023-02-02 16:12, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
On 01-02-2023 15:17, Carlos E. R. wrote:
On 2023-02-01 15:00, Bengt Gördén wrote:
Carlos E. R. wrote:
...
Hi Carlos,
The issue is caused by systemd hardening. Have a look at the file "/usr/lib/systemd/system/mlocate.service",in particular the line "ProtectKernelModules=true". This systemd setting not only prevents the service from loading any modules, but also denies the service access to directory "/lib/modules".
Wow. I would never have guessed that.
Yeah, me neither. That was quite a find, but it would (eventually) have become apparent to anyone running an strace on updatedb.
To anyone, I doubt it.
Well, to anyone who can read the output of strace, of course. It would be quite obvious when updatedb tries to open a directory and the permissions fail. Well, I hope they would - maybe I'll have to try it.
How is a systemd "thing" seen inside the updatedb call? I'm unsure I would see it.
In the strace, there would probably be an opendir() call that fails. or somewthing similar.
Wait, I don't know how to trace a program that is run this way: systemctl start mlocate.service
Well, don't do it that way, that is silly. Instead, you switch to user 'nobody' and then you run it:
su -s /bin/sh nobody strace /usr/bin/updatedb
Per Jessen wrote:
Carlos E. R. wrote:
Wait, I don't know how to trace a program that is run this way: systemctl start mlocate.service
Well, don't do it that way, that is silly. Instead, you switch to user 'nobody' and then you run it:
Sorry, that was also silly - of course, you have to run the strace from within the service unit with $SUBJ enabled.
So you override the service unit, prepend 'strace' to the ExecStart, write output to a file etc etc. Likely it will produce too much output, so rinse & repeat.
On 2023-02-02 19:04, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
Wait, I don't know how to trace a program that is run this way: systemctl start mlocate.service
Well, don't do it that way, that is silly. Instead, you switch to user 'nobody' and then you run it:
Sorry, that was also silly - of course, you have to run the strace from within the service unit with $SUBJ enabled.
So you override the service unit, prepend 'strace' to the ExecStart, write output to a file etc etc. Likely it will produce too much output, so rinse & repeat.
It's an idea.
On 2023-02-02 18:58, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-02-02 16:12, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-02-02 12:31, Erwin Lam wrote:
...
Wow. I would never have guessed that.
Yeah, me neither. That was quite a find, but it would (eventually) have become apparent to anyone running an strace on updatedb.
To anyone, I doubt it.
Well, to anyone who can read the output of strace, of course. It would be quite obvious when updatedb tries to open a directory and the permissions fail. Well, I hope they would - maybe I'll have to try it.
I can read straces, but not all of them :-)
How is a systemd "thing" seen inside the updatedb call? I'm unsure I would see it.
In the strace, there would probably be an opendir() call that fails. or somewthing similar.
Wait, I don't know how to trace a program that is run this way: systemctl start mlocate.service
Well, don't do it that way, that is silly. Instead, you switch to user 'nobody' and then you run it:
su -s /bin/sh nobody strace /usr/bin/updatedb
No, because that works! It has to be run the way it fails.
On February 1, 2023 9:00:38 AM EST, "Bengt Gördén" bengan@bag.org wrote:
Carlos E. R. wrote:
Why can't I locate them with locate?
Either you have something in your conf (/etc/updatedb.conf) or your systemd update timer (mlocate.timer, /usr/lib/systemd/system/mlocate.timer) is out of order. I have TW, so it might be different on the Leap.
Or maybe run "updatedb".
On 2023-02-02 13:59, ken wrote:
On February 1, 2023 9:00:38 AM EST, "Bengt Gördén" bengan@bag.org wrote:
Carlos E. R. wrote:
Why can't I locate them with locate?
Either you have something in your conf (/etc/updatedb.conf) or your systemd update timer (mlocate.timer, /usr/lib/systemd/system/mlocate.timer) is out of order. I have TW, so it might be different on the Leap.
Or maybe run "updatedb".
In my main computer, or my server, with several hard disks, that takes half an hour or so.
And the result is erased soon, as soon as the service runs again.
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
On 2/1/23 08:30, Per Jessen wrote:
Carlos E. R. wrote:
Why can't I locate them with locate?
Maybe a configuration issue? Can you find other kernel modules with 'locate'? I don't use locate, I'm not familiar with the configuration.
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
On 2023-02-01 19:27, Per Jessen wrote:
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
In my case, yes.
But I want to know why locate doesn't locate them. It should.
Carlos E. R. wrote:
On 2023-02-01 19:27, Per Jessen wrote:
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
In my case, yes.
But I want to know why locate doesn't locate them. It should.
Well, if it were me, I would try running updatedb with an strace, to see if it even touches on the directories. The updatedb seems to have permissions, so there has to be some other reason why it is avoiding /lib/modules - if it is indeed avoiding it.
On 2023-02-01 19:45, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-02-01 19:27, Per Jessen wrote:
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
In my case, yes.
But I want to know why locate doesn't locate them. It should.
Well, if it were me, I would try running updatedb with an strace, to see if it even touches on the directories. The updatedb seems to have permissions, so there has to be some other reason why it is avoiding /lib/modules - if it is indeed avoiding it.
When updatedb is run as root, without parameters, it finds those files.
And now, back at home, locate finds those files, in auxiliary (old) paths, something that it wasn't doing the other time I tried:
cer@Telcontar:~> locate snd-hda-intel /data/storage_b/Grande/copia/test_a__factory_10.2/lib/modules/2.6.18.2-34-default/kernel/sound/pci/hda/snd-hda-intel.ko /data/storage_b/mkzftree/home/_lib_test/modules/3.11.10-25-desktop/kernel/sound/pci/hda/snd-hda-intel.ko /data/storage_b/mkzftree/home/_lib_test/modules/3.11.10-29-desktop/kernel/sound/pci/hda/snd-hda-intel.ko /home/_lib_test/modules/3.11.10-25-desktop/kernel/sound/pci/hda/snd-hda-intel.ko /home/_lib_test/modules/3.11.10-29-desktop/kernel/sound/pci/hda/snd-hda-intel.ko /home_aux/cer/tmp/kernel/.tmp_versions/snd-hda-intel.mod /home_aux/cer/tmp/kernel/sound/pci/hda/.snd-hda-intel.ko.cmd /home_aux/cer/tmp/kernel/sound/pci/hda/.snd-hda-intel.mod.o.cmd /home_aux/cer/tmp/kernel/sound/pci/hda/.snd-hda-intel.o.cmd /home_aux/cer/tmp/kernel/sound/pci/hda/snd-hda-intel.ko /home_aux/cer/tmp/kernel/sound/pci/hda/snd-hda-intel.mod.c /home_aux/cer/tmp/kernel/sound/pci/hda/snd-hda-intel.mod.o /home_aux/cer/tmp/kernel/sound/pci/hda/snd-hda-intel.o cer@Telcontar:~>
I have to do other things, I can not study the reason just now. HA! I had a hunch, and apparmour is complaining:
--- /etc/apparmor.d/usr.bin.locate 2023-01-19 11:00:57.000000000 +0100 +++ /tmp/tmpl45psoxu 2023-02-01 22:27:23.742385925 +0100 @@ -1,9 +1,11 @@ -# Last Modified: Fri Apr 13 22:23:29 2018 -#include <tunables/global> +# Last Modified: Wed Feb 1 22:27:23 2023 +include <tunables/global>
/usr/bin/locate { - #include <abstractions/base> - #include <abstractions/nameservice> + include <abstractions/base> + include <abstractions/nameservice> + + capability setgid,
/usr/bin/locate mr, /var/lib/mlocate/mlocate.db r,
Still not enough to make it work.
Carlos E. R. wrote:
On 2023-02-01 19:45, Per Jessen wrote:
Carlos E. R. wrote:
But I want to know why locate doesn't locate them. It should.
Well, if it were me, I would try running updatedb with an strace, to see if it even touches on the directories. The updatedb seems to have permissions, so there has to be some other reason why it is avoiding /lib/modules - if it is indeed avoiding it.
When updatedb is run as root, without parameters, it finds those files.
Right.
And now, back at home, locate finds those files, in auxiliary (old) paths, something that it wasn't doing the other time I tried:
Okay, but that seems to be a tangent, as we are not interested in those paths.
I had a hunch, and apparmour is complaining:
Complaining about what? :-) You left out the most useful bit of information ...
--- /etc/apparmor.d/usr.bin.locate 2023-01-19 11:00:57.000000000
If there is an apparmor issue, I think you are looking at the wrong thing. You probably ought to look at 'updatedb'.
I don't have a 15.4 system, I only have a TW test system with 'locale', but I don't see apparmor complaining about anything related to updatedbd or locate. I updated my own TW test system last night, and it failed to mount root, I'll have to go and fix that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2023-02-02 at 08:54 +0100, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-02-01 19:45, Per Jessen wrote:
Carlos E. R. wrote:
But I want to know why locate doesn't locate them. It should.
Well, if it were me, I would try running updatedb with an strace, to see if it even touches on the directories. The updatedb seems to have permissions, so there has to be some other reason why it is avoiding /lib/modules - if it is indeed avoiding it.
When updatedb is run as root, without parameters, it finds those files.
Right.
And now, back at home, locate finds those files, in auxiliary (old) paths, something that it wasn't doing the other time I tried:
Okay, but that seems to be a tangent, as we are not interested in those paths.
Obviously, but it is another complication, another nail in "locate is acting weird".
I had a hunch, and apparmour is complaining:
Complaining about what? :-) You left out the most useful bit of information ...
I posted the output from AA. That's summarizes what it complains about :-)
It needed this:
/usr/bin/locate mr, /var/lib/mlocate/mlocate.db r,
It seems the terminal I used seems to be gone (I did several reboots for a bugzilla report), so I can not check back.
Wait, I have the audit log:
Telcontar:~ # grep "usr/bin/locate|/var/lib/mlocate/mlocate.db" /var/log/audit/* /var/log/audit/audit.log.1:type=AVC msg=audit(1675247354.543:1682): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=26774 comm="locate" capability=6 capname="setgid" /var/log/audit/audit.log.1:type=AVC msg=audit(1675247368.135:1683): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=26782 comm="locate" capability=6 capname="setgid" /var/log/audit/audit.log.1:type=AVC msg=audit(1675286657.200:1789): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=541 comm="locate" capability=6 capname="setgid" /var/log/audit/audit.log.1:type=AVC msg=audit(1675286870.985:1790): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/locate" pid=714 comm="apparmor_parser" /var/log/audit/audit.log.1:type=AVC msg=audit(1675286932.552:1858): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/bin/locate" pid=832 comm="apparmor_parser" /var/log/audit/audit.log.2:type=AVC msg=audit(1669806411.637:4112): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=9731 comm="locate" capability=6 capname="setgid" /var/log/audit/audit.log.2:type=AVC msg=audit(1669807739.641:4211): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=13352 comm="locate" capability=6 capname="setgid" /var/log/audit/audit.log.2:type=AVC msg=audit(1670190817.054:740): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/locate" pid=6620 comm="apparmor_parser" Telcontar:~ #
(I had to switch from Thunderbird to Alpine. The former wraps the lines)
--- /etc/apparmor.d/usr.bin.locate 2023-01-19 11:00:57.000000000
If there is an apparmor issue, I think you are looking at the wrong thing. You probably ought to look at 'updatedb'.
Can be both, updatedb and locate. The later checks what permissions has the person that asks, and gives different results based on that. I haven't decided yet which is failing, but I suspect it is updatedb.
In any case, what I checked was "aa-logprof", and it said that there were problems with the locate profile or files. I don't remember exactly the wording, but I know I saw the word "locate" somewhere and said AHÁ! :-D
I don't have a 15.4 system, I only have a TW test system with 'locale', but I don't see apparmor complaining about anything related to updatedbd or locate. I updated my own TW test system last night, and it failed to mount root, I'll have to go and fix that.
Ha, that's a more important issue.
Me, I'm just having my tea, and preparing to leave for a different location.
- -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
I had a hunch, and apparmour is complaining:
Complaining about what? :-) You left out the most useful bit of information ...
I posted the output from AA.
I didn't see any. All I saw was some diff output ?
It needed this:
/usr/bin/locate mr, /var/lib/mlocate/mlocate.db r,
Funny that those should be missing in Leap 15.4 - that apparmor profile is quite old. (2018).
Hmm, I just looked at the 'mlocate' package in Leap 15.4, those two lines _are_ in the profile. I think we have some disconnect?
Wait, I have the audit log:
Telcontar:~ # grep "usr/bin/locate|/var/lib/mlocate/mlocate.db" /var/log/audit/* /var/log/audit/audit.log.1:type=AVC msg=audit(1675247354.543:1682): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=26774 comm="locate" capability=6 capname="setgid"
Okay - setgid, that is not in the profile. Nor is it in tw.
I updated my own TW test system last night, and it failed to mount root, I'll have to go and fix that.
Ha, that's a more important issue.
Well, it's just a test system, hardly ever used anymore. Last booted 576 days ago and that was probably a power outage. As I seem to be unable to boot the tw installer, I'm trying to work out what I might try instead. Even I know what the problem is, I need access to the root filesystem to fix it :-(
On 2023-02-02 10:53, Per Jessen wrote:
Carlos E. R. wrote:
I had a hunch, and apparmour is complaining:
Complaining about what? :-) You left out the most useful bit of information ...
I posted the output from AA.
I didn't see any. All I saw was some diff output ?
Yes, it is printed by aa-logprof at the end.
It needed this:
/usr/bin/locate mr, /var/lib/mlocate/mlocate.db r,Funny that those should be missing in Leap 15.4 - that apparmor profile is quite old. (2018).
Hmm, I just looked at the 'mlocate' package in Leap 15.4, those two lines _are_ in the profile. I think we have some disconnect?
I think I answered this before leaving home a while ago? Maybe I did not hit "send".
Anyway, see the post by Erwin Lam, it is systemd "interfering".
On 2023-02-02 10:53, Per Jessen wrote:
Carlos E. R. wrote:
I had a hunch, and apparmour is complaining:
Complaining about what? :-) You left out the most useful bit of information ...
I posted the output from AA.
I didn't see any. All I saw was some diff output ?
Printed by AA at the end.
It needed this:
/usr/bin/locate mr, /var/lib/mlocate/mlocate.db r,Funny that those should be missing in Leap 15.4 - that apparmor profile is quite old. (2018).
Yes, funny.
Hmm, I just looked at the 'mlocate' package in Leap 15.4, those two lines _are_ in the profile. I think we have some disconnect?
Maybe my file was not replaced. :-?
My file in backup (Apr 15 2022):
# Last Modified: Fri Apr 15 20:39:33 2022 #include <tunables/global>
/usr/bin/locate { #include <abstractions/base> #include <abstractions/nameservice>
capability setgid,
/usr/bin/locate mr, /var/lib/mlocate/mlocate.db r,
}
My current file is:
# Last Modified: Wed Feb 1 22:27:50 2023 include <tunables/global>
/usr/bin/locate { include <abstractions/base> include <abstractions/nameservice>
capability setgid,
/usr/bin/locate mr, /var/lib/mlocate/mlocate.db r,
}
Just the comment symbol. I didn't interpret correctly the diff, which is normal in me :-}
Wait, I have the audit log:
Telcontar:~ # grep "usr/bin/locate|/var/lib/mlocate/mlocate.db" /var/log/audit/* /var/log/audit/audit.log.1:type=AVC msg=audit(1675247354.543:1682): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=26774 comm="locate" capability=6 capname="setgid"
Okay - setgid, that is not in the profile. Nor is it in tw.
But it is in mine, and in my backup. It is possible that the upgrade to 15.4 reset it, so now aa complains again and I had to put it back.
Carlos E. R. wrote:
Wait, I have the audit log:
Telcontar:~ # grep "usr/bin/locate|/var/lib/mlocate/mlocate.db" /var/log/audit/* /var/log/audit/audit.log.1:type=AVC msg=audit(1675247354.543:1682): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=26774 comm="locate" capability=6 capname="setgid"
Okay - setgid, that is not in the profile. Nor is it in tw.
But it is in mine, and in my backup. It is possible that the upgrade to 15.4 reset it, so now aa complains again and I had to put it back.
I'm sure you've reported it, so it'll turn up in public eventually :-)
On 2023-02-02 23:32, Per Jessen wrote:
Carlos E. R. wrote:
Wait, I have the audit log:
Telcontar:~ # grep "usr/bin/locate|/var/lib/mlocate/mlocate.db" /var/log/audit/* /var/log/audit/audit.log.1:type=AVC msg=audit(1675247354.543:1682): apparmor="DENIED" operation="capable" profile="/usr/bin/locate" pid=26774 comm="locate" capability=6 capname="setgid"
Okay - setgid, that is not in the profile. Nor is it in tw.
But it is in mine, and in my backup. It is possible that the upgrade to 15.4 reset it, so now aa complains again and I had to put it back.
I'm sure you've reported it, so it'll turn up in public eventually :-)
I don't remember if I have reported it in bugzilla. In the past, prior to aa-logprof displaying the diff, it was not that easy. Ok, now I have that, but I don't remember where to report. Sometimes, posting here was enough.
On 2/1/23 13:27, Per Jessen wrote:
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
These find commands worked just now. Sound works now given the fix I noted yesterday.
The ones I used from email yesterday before the fix did not work.
On 2023-02-02 10:13, Allen Wilkinson wrote:
On 2/1/23 13:27, Per Jessen wrote:
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
These find commands worked just now. Sound works now given the fix I noted yesterday.
The ones I used from email yesterday before the fix did not work.
So what are you doing, still booting a previous kernel to have sound, or something else?
uname (*.41-default) and /boot file links to initrd (*.28-default) and vmlinuz are still as I noted yesterday after fix. It does suggest machine is booting mixed kernels, which may break during next update🙁.
On 2/2/23 04:28, Carlos E. R. wrote:
On 2023-02-02 10:13, Allen Wilkinson wrote:
On 2/1/23 13:27, Per Jessen wrote:
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
These find commands worked just now. Sound works now given the fix I noted yesterday.
The ones I used from email yesterday before the fix did not work.
So what are you doing, still booting a previous kernel to have sound, or something else?
Allen Wilkinson wrote:
On 2/1/23 13:27, Per Jessen wrote:
Allen Wilkinson wrote:
I do not find them with locate or the find command you used. But if I manually go to the directory you find them at, I do see the modules there.
Ignoring 'locate', that does not make much sense.
Does this find your modules:
find /lib/modules -type f -name snd-sof-pci-intel-tgl* find /lib/modules -type f -name snd-hda-intel*
These find commands worked just now. Sound works now given the fix I noted yesterday.
The ones I used from email yesterday before the fix did not work.
Well, they were specific to my system and the working directory. You can't expect those to also work for you, without modification.
* Per Jessen per@jessen.ch [01-27-23 12:36]:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
I believe they are working on a new installer but it is still yast, but a different method of presentation. iirc.
Patrick Shanahan wrote:
- Per Jessen per@jessen.ch [01-27-23 12:36]:
Lew Wolfgang wrote:
On 1/27/23 04:05, Carlos E. R. wrote:
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
+1
I've known Ubuntu and RHEL admins who switched to openSUSE only because of Yast. Myself included.
and you really both expect YaST soon to disappear?
I believe they are working on a new installer but it is still yast, but a different method of presentation. iirc.
Probably d-yast: https://github.com/yast/d-installer
That page has very good description.
Carlos E. R. composed on 2023-01-27 13:05 (UTC+0100):
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
Did you see an announcement that openSUSE is getting a completely new installer? When will this happen? How soon is soon? YaST *is* openSUSE's installer.
On 2023-01-27 19:39, Felix Miata wrote:
Carlos E. R. composed on 2023-01-27 13:05 (UTC+0100):
Soon yast will cease to exist, and there will be no more reason to choose openSUSE.
Did you see an announcement that openSUSE is getting a completely new installer? When will this happen? How soon is soon? YaST *is* openSUSE's installer.
Nononono. There is nothing of the sort. The only thing I know is that this is not the first module to go. Some other module went out not long ago, I forget which.
Maybe YaST network, in favour of Network manager?
And each time a module goes, it is like a nail in me.
There is work in some other variant of yast, I don't remember which because I have not tested it.
On Fri, 27 Jan 2023 20:09:31 +0100, "Carlos E. R." robin.listas@telefonica.net wrote:
There is work in some other variant of yast, I don't remember which because I have not tested it.
"D-Installer is the provisional codename for the" ... "evolution of YaST." https://en.opensuse.org/openSUSE:ALP/Workgroups/Installation/DInstaller
I'm concerned that it has a web-based interface. Such things are generally worse than built-in ones, and YaST has a good one now. More important, text mode is needed when the window system is not available.
"A text-based alternative interface (not necessarily equivalent in functionality to the graphical/web one) would be nice to have for SSH and/or serial installation."
No. It's a requirement, and it needs to be equivalent to the web interface. If the window system is broken or just not there, YaST still needs to function. That could be with 'elinks' and other text-based web browsers, but not with reduced functionality. -- Robert Webb
On 2023-01-27 17:10, Robert Webb wrote:
On Fri, 27 Jan 2023 20:09:31 +0100, "Carlos E. R." robin.listas@telefonica.net wrote:
There is work in some other variant of yast, I don't remember which because I have not tested it.
"D-Installer is the provisional codename for the" ... "evolution of YaST." https://en.opensuse.org/openSUSE:ALP/Workgroups/Installation/DInstaller
I'm concerned that it has a web-based interface. Such things are generally worse than built-in ones, and YaST has a good one now. More important, text mode is needed when the window system is not available.
Did you actually miss this? https://en.opensuse.org/File:D-installer-overview.png
On Fri, 27 Jan 2023 18:36:03 -0600, Darryl Gregorash raven@accesscomm.ca wrote:
On 2023-01-27 17:10, Robert Webb wrote:
On Fri, 27 Jan 2023 20:09:31 +0100, "Carlos E. R." robin.listas@telefonica.net wrote:
There is work in some other variant of yast, I don't remember which because I have not tested it.
"D-Installer is the provisional codename for the" ... "evolution of YaST." https://en.opensuse.org/openSUSE:ALP/Workgroups/Installation/DInstaller
I'm concerned that it has a web-based interface. Such things are generally worse than built-in ones, and YaST has a good one now. More important, text mode is needed when the window system is not available.
Did you actually miss this? https://en.opensuse.org/File:D-installer-overview.png
Yes, I actually missed (the thumbnail of) that on the DInstaller page. Thanks. Looking at it now, the thumbnail is too small for me to read, and I was only skimming the page for the major descriptive points about what the successor to YaST was planned to be. The page says:
"In a nutshell: D-Installer is an effort to build a web-based installer on top of YaST libraries using Cockpit as a frontend. ..."
That says it *is* web-based. Only later does it say a reduced functionality text-based alternative would be "nice to have."
So if you pretend that those three interfaces (Web, CLI, and Qt App) shown in D-installer-overview.png are interchangeable, then it looks great. -- Robert Webb
On 2023-01-28 00:10, Robert Webb wrote:
On Fri, 27 Jan 2023 20:09:31 +0100, "Carlos E. R." robin.listas@telefonica.net wrote:
There is work in some other variant of yast, I don't remember which because I have not tested it.
"D-Installer is the provisional codename for the" ... "evolution of YaST." https://en.opensuse.org/openSUSE:ALP/Workgroups/Installation/DInstaller
I'm concerned that it has a web-based interface.
There was a web-yast years ago. It failed.
Such things are generally worse than built-in ones, and YaST has a good one now. More important, text mode is needed when the window system is not available.
Web-yast was supposedly accessible from another machine.
"A text-based alternative interface (not necessarily equivalent in functionality to the graphical/web one) would be nice to have for SSH and/or serial installation."
No. It's a requirement, and it needs to be equivalent to the web interface. If the window system is broken or just not there, YaST still needs to function. That could be with 'elinks' and other text-based web browsers, but not with reduced functionality.
text based yast is the most important tool to have, specially on server or remotely. It even works using a rescue CD.
-- Robert Webb
Carlos E. R. wrote:
On 2023-01-28 00:10, Robert Webb wrote:
On Fri, 27 Jan 2023 20:09:31 +0100, "Carlos E. R." robin.listas@telefonica.net wrote:
There is work in some other variant of yast, I don't remember which because I have not tested it.
"D-Installer is the provisional codename for the" ... "evolution of YaST."
https://en.opensuse.org/openSUSE:ALP/Workgroups/Installation/DInstaller
I'm concerned that it has a web-based interface.
There was a web-yast years ago. It failed.
It is still there, and it doesn't seem to be going anywhere :-)
https://en.opensuse.org/Portal:WebYaST https://en.opensuse.org/openSUSE:WebYaST_Development
On 28.01.2023 12:08, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-01-28 00:10, Robert Webb wrote:
On Fri, 27 Jan 2023 20:09:31 +0100, "Carlos E. R." robin.listas@telefonica.net wrote:
There is work in some other variant of yast, I don't remember which because I have not tested it.
"D-Installer is the provisional codename for the" ... "evolution of YaST."
https://en.opensuse.org/openSUSE:ALP/Workgroups/Installation/DInstaller
I'm concerned that it has a web-based interface.
There was a web-yast years ago. It failed.
It is still there, and it doesn't seem to be going anywhere :-)
https://en.opensuse.org/Portal:WebYaST https://en.opensuse.org/openSUSE:WebYaST_Development
Last commit in this repository was 8 years ago.
On 2023-01-28 10:08, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-01-28 00:10, Robert Webb wrote:
On Fri, 27 Jan 2023 20:09:31 +0100, "Carlos E. R." robin.listas@telefonica.net wrote:
There is work in some other variant of yast, I don't remember which because I have not tested it.
"D-Installer is the provisional codename for the" ... "evolution of YaST."
https://en.opensuse.org/openSUSE:ALP/Workgroups/Installation/DInstaller
I'm concerned that it has a web-based interface.
There was a web-yast years ago. It failed.
It is still there, and it doesn't seem to be going anywhere :-)
https://en.opensuse.org/Portal:WebYaST https://en.opensuse.org/openSUSE:WebYaST_Development
It did go. I remember because I worked on its translation to Spanish, and then it was removed.
Carlos E. R. wrote:
On 2023-01-28 10:08, Per Jessen wrote:
Carlos E. R. wrote:
There was a web-yast years ago. It failed.
It is still there, and it doesn't seem to be going anywhere :-)
https://en.opensuse.org/Portal:WebYaST https://en.opensuse.org/openSUSE:WebYaST_Development
It did go. I remember because I worked on its translation to Spanish, and then it was removed.
<nitpick> It hasn't been "removed": https://github.com/webyast/webyast </nitpick>
but as Andrei mentioned earlier, eight years since last commit, so it isn't likely to be going anywhere.
On 2023-01-28 13:38, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-01-28 10:08, Per Jessen wrote:
Carlos E. R. wrote:
There was a web-yast years ago. It failed.
It is still there, and it doesn't seem to be going anywhere :-)
https://en.opensuse.org/Portal:WebYaST https://en.opensuse.org/openSUSE:WebYaST_Development
It did go. I remember because I worked on its translation to Spanish, and then it was removed.
<nitpick> It hasn't been "removed": https://github.com/webyast/webyast </nitpick>
Ok :-)
<nitpick> it was removed from the translation server or database. </nitpick>
:-D
but as Andrei mentioned earlier, eight years since last commit, so it isn't likely to be going anywhere.
Right.
On 1/27/23 13:09, Carlos E. R. wrote:
Nononono. There is nothing of the sort. The only thing I know is that this is not the first module to go. Some other module went out not long ago, I forget which.
Maybe YaST network, in favour of Network manager?
And each time a module goes, it is like a nail in me.
Nah...
Just means you look it up on the Arch wiki... and do it by hand :)
On 1/27/23 02:18, Per Jessen wrote:
Examples:
SuSE 9.3, from 2005 ... almost twenty years old. Seriously?
Chuckling... I still have a box with 9.0 Pro on it I can crank -- if the caps haven't gone bad :)
David C. Rankin wrote:
On 1/27/23 02:18, Per Jessen wrote:
Examples:
SuSE 9.3, from 2005 ... almost twenty years old. Seriously?
Chuckling... I still have a box with 9.0 Pro on it I can crank -- if the caps haven't gone bad :)
I can do better :-) I'm writing this from knode on openSUSE 10.3 ....
On 1/28/23 03:04, Per Jessen wrote:
Chuckling... I still have a box with 9.0 Pro on it I can crank -- if the caps haven't gone bad :)
I can do better :-) I'm writing this from knode on openSUSE 10.3 ....
I'll see you a 10.3 and raise you a 10.0 :)
$ cat /mnt/pv/etc/SuSE-release SUSE LINUX 10.0 (i586) OSS VERSION = 10.0
David C. Rankin wrote:
On 1/28/23 03:04, Per Jessen wrote:
Chuckling... I still have a box with 9.0 Pro on it I can crank -- if the caps haven't gone bad :)
I can do better :-) I'm writing this from knode on openSUSE 10.3 ....
I'll see you a 10.3 and raise you a 10.0 :)
LOL!
I have a couple of good reasons for keeping this machine on 10.3, but Firefox and TB are of course both long outdated, and I'm beginning to have issues with SSL/TLS, so I do my internet and email on a laptop.
-
Allen Wilkinson -
Andrei Borzenkov -
Bengt Gördén -
Bruce Ferrell -
Carlos E. R. -
Darryl Gregorash -
Dave Howorth -
David C. Rankin -
Erwin Lam -
Felix Miata -
joe a -
ken -
kschneider bout-tyme.net -
Lew Wolfgang -
Masaru Nomiya -
Patrick Shanahan -
Per Jessen -
Robert Webb