You are not logged in.
Pages: 1
I would like to remove pcspkr.ko from kernel but I have not find it, only pcspkr.ko.gz.
As far as I know, arch uses gzip compressed modules, right? so if I remove pcspkr.ko.gz from the appropriate folder:
/lib/modules/`uname -r`/kernel/drivers/input/misc/
and then I perform the following:
depmod -a
and finally, reboot the system, is it enough, right?
Thanks!
Last edited by toni (2013-04-28 19:18:51)
Offline
Well, even if it works (I think so, but I'm not sure), the module will reappear after every update of linux. So it's better to forbid it to be loaded in the first place. For this, create the file /etc/modprobe.d/blacklist.conf and put
blacklist pcspkr
in it.
Offline
+1 for blacklist.
https://wiki.archlinux.org/index.php/Di … eaker_Beep
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
+1 for blacklist.
https://wiki.archlinux.org/index.php/Di … eaker_Beep
Blacklisting in this way is not correct as pcspkr could be loaded by another non-blacklisted module depends on it. So be careful using this way when blacklisting modules.
Better adding below line to /etc/modprobe.d/blacklist.conf
...
install module_name /bin/false
...
See below link:
https://wiki.archlinux.org/index.php/Ke … obe.d.2F_2
Offline
graysky wrote:+1 for blacklist.
https://wiki.archlinux.org/index.php/Di … eaker_BeepBlacklisting in this way is not correct as pcspkr could be loaded by another non-blacklisted module depends on it. So be careful using this way when blacklisting modules.
Better adding below line to /etc/modprobe.d/blacklist.conf
... install module_name /bin/false ...
See below link:
https://wiki.archlinux.org/index.php/Ke … obe.d.2F_2
This is a hack which leads to broken modules. Nothing depends on pcspkr. Blacklist it.
Offline
toni wrote:graysky wrote:+1 for blacklist.
https://wiki.archlinux.org/index.php/Di … eaker_BeepBlacklisting in this way is not correct as pcspkr could be loaded by another non-blacklisted module depends on it. So be careful using this way when blacklisting modules.
Better adding below line to /etc/modprobe.d/blacklist.conf
... install module_name /bin/false ...
See below link:
https://wiki.archlinux.org/index.php/Ke … obe.d.2F_2This is a hack which leads to broken modules. Nothing depends on pcspkr. Blacklist it.
ok, thanks for the info as in that link it is not said that it leads to broken modules. Anyway, I think it would be good to indicate it in the link I have provided (The person in charge of maintaining it should provide this useful info).
Anyway, I would like to know if I am correct about that arch uses compressed gzip modules (*.ko.gz) instead of (*.ko). Could you confim it? and could you confirm me if what I have said in the first post is correct? So I can close this thread as solved. It was a doubt that I had.
Only one thing, about blacklisting despite it corresponds to another thread I opened some days aro: as you say, nothing depends on pcskpr, so why blacklisting it, it is loaded anyway and pc speaker emits a beep?
I remember to blacklisting it in the way you say, even doing what I have said, and systemd for some reason was loading it. I checked some days ago by doing:
lsmod | grep pcspkr
also, could you confirme that these two methods are effective for blacklisting? I am not sure at all. It would be good that someone could confirm it as well.
Offline
toni, I can't speak for anyone else, but your last post is not clear to me at all.
Blacklisting pcspkr as suggested by Army is the right way to go. This has now been confirmed by Graysky, Falconindy, and now me. This works / should work. Are you saying you have created the blacklist.conf file with that line, rebooted, yet you still have pcspkr loaded? If so, what is the full output from `lsmod | grep pcspkr`? Does pcspkr show as a dependency for another module (it shouldn't).
The .ko.gz files are normal.
What is it you want confirmed that has not already been confirmed?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
toni, I can't speak for anyone else, but your last post is not clear to me at all.
Blacklisting pcspkr as suggested by Army is the right way to go. This has now been confirmed by Graysky, Falconindy, and now me. This works / should work. Are you saying you have created the blacklist.conf file with that line, rebooted, yet you still have pcspkr loaded? If so, what is the full output from `lsmod | grep pcspkr`? Does pcspkr show as a dependency for another module (it shouldn't).
The .ko.gz files are normal.
What is it you want confirmed that has not already been confirmed?
I remember some days ago to blacklisting pcspkr using the two ways stated in the previous posts and lsmod was returning pcspkr (loaded) but I do not remember if it was being used by another module. Anyway, if all of you are saying this is the correct way to do it, I trust on you.
Regarding to kernel modules, what is the difference between compressed gzip modules (*.ko.gz) and not compressed (*.ko)? When is used ko.gz and when *.ko? In my case I wanted to delete pcspkr.ko but only existed pcspkr.ko.gz.
Thanks!
Offline
Do not remove it from kernel. Someone may need it.
+1 to blacklisting.
Cheers.
Andrzej
The worst thing about censorship is ██████ ██ ████ ████████████ and ██████ ███████ ███ ███████████.
Offline
what is the difference between compressed gzip modules (*.ko.gz) and not compressed (*.ko)? When is used ko.gz and when *.ko?
Well... one is compressed... and the other isn't.
I honestly can't think of a better answer to your question.
Arch has chosen to compress its modules, so we never use *.ko. The module management tools in the kmod package deal with this transparently.
Offline
Do not remove it from kernel. Someone may need it.
+1 to blacklisting.
Cheers.
Andrzej
OK, I will take it into account. Thanks!
Offline
toni wrote:what is the difference between compressed gzip modules (*.ko.gz) and not compressed (*.ko)? When is used ko.gz and when *.ko?
Well... one is compressed... and the other isn't.
I honestly can't think of a better answer to your question.
Arch has chosen to compress its modules, so we never use *.ko. The module management tools in the kmod package deal with this transparently.
Maybe the compressed option to save disk usage?
Thanks a lot.
Offline
People, could you please stop powerquoting (i.e. quoting the entire discussion) and powerposting (this isn't Google+!)?
My mouse wheel has enough mileage already. Thank you.
Last edited by ackalker (2013-05-01 02:40:00)
Offline
Pages: 1