Re: [arch-general] [arch-dev-public] removing load-modules.sh from udev
On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen <teg@jklm.no> wrote: <snip>
rc.conf - MODULES(!mod1, !mod2): blacklisting modules in the modules array will no longer have any effect. modprobe already provides two different ways of preventing modules from being loaded, so this is just a matter of updating some configuration files. To blacklist modules, add a new .conf file to /etc/modprobe.d/ with the contents
blacklist mod1 blacklist mod2 <snip>
This seems a regression of current rc.conf behaviour (in essence, moves another configuration back to upstream default which was previously in rc.conf). Is there any good reason to keep current behaviour (perhaps an Arch-specific udev rule which parses MODULES for blacklisting?) Just something I noticed when reading the mail, I don't really see a problem with doing things the upstream way.
Thanks for your Oon-ee. Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen <teg@jklm.no> wrote: <snip>
rc.conf - MODULES(!mod1, !mod2): blacklisting modules in the modules array will no longer have any effect. modprobe already provides two different ways of preventing modules from being loaded, so this is just a matter of updating some configuration files. To blacklist modules, add a new .conf file to /etc/modprobe.d/ with the contents
blacklist mod1 blacklist mod2 <snip>
This seems a regression of current rc.conf behaviour (in essence, moves another configuration back to upstream default which was previously in rc.conf). Is there any good reason to keep current behaviour (perhaps an Arch-specific udev rule which parses MODULES for blacklisting?)
I have not found any uses of the MODULES array like you describe (if they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know. Cheers, Tom
On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen <teg@jklm.no> wrote:
Thanks for your Oon-ee.
Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen <teg@jklm.no> wrote: <snip>
rc.conf - MODULES(!mod1, !mod2): blacklisting modules in the modules array will no longer have any effect. modprobe already provides two different ways of preventing modules from being loaded, so this is just a matter of updating some configuration files. To blacklist modules, add a new .conf file to /etc/modprobe.d/ with the contents
blacklist mod1 blacklist mod2 <snip>
This seems a regression of current rc.conf behaviour (in essence, moves another configuration back to upstream default which was previously in rc.conf). Is there any good reason to keep current behaviour (perhaps an Arch-specific udev rule which parses MODULES for blacklisting?)
I have not found any uses of the MODULES array like you describe (if they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know.
Cheers,
Tom
Glad to oblige, here's my current MODULES:- MODULES=(!phc-intel acpi_cpufreq vboxdrv vboxnetflt loop fuse !net-pf-10 !snd_pcsp uinput !pcspkr coretemp) When I was testing out undervolting I used the phc-intel blacklist to prevent it loading (otherwise it would automatically load even if not listed). Don't use it anymore, but its a use-case. The blacklists of the other three I got from the old old Beginner's Guide when I first set up (couple of years back) but at least snd_pcsp and pcspkr are still recommended to be blacklisted here https://wiki.archlinux.org/index.php/Disable_PC_Speaker_Beep The purpose is simply to disable those annoying speaker beeps. Since computers normally come with sound cards nowadays, why would we want to hear polyphonic beeps which even our handphones and microwave ovens don't use anymore =). As I said, when the change happens I'd personally just write the custom udev rules and forget about them, no big deal.
On Sun, May 29, 2011 at 6:31 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen <teg@jklm.no> wrote:
Thanks for your Oon-ee.
Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen <teg@jklm.no> wrote: <snip>
rc.conf - MODULES(!mod1, !mod2): blacklisting modules in the modules array will no longer have any effect. modprobe already provides two different ways of preventing modules from being loaded, so this is just a matter of updating some configuration files. To blacklist modules, add a new .conf file to /etc/modprobe.d/ with the contents
blacklist mod1 blacklist mod2 <snip>
This seems a regression of current rc.conf behaviour (in essence, moves another configuration back to upstream default which was previously in rc.conf). Is there any good reason to keep current behaviour (perhaps an Arch-specific udev rule which parses MODULES for blacklisting?)
I have not found any uses of the MODULES array like you describe (if they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know.
Cheers,
Tom
Glad to oblige, here's my current MODULES:- MODULES=(!phc-intel acpi_cpufreq vboxdrv vboxnetflt loop fuse !net-pf-10 !snd_pcsp uinput !pcspkr coretemp)
When I was testing out undervolting I used the phc-intel blacklist to prevent it loading (otherwise it would automatically load even if not listed). Don't use it anymore, but its a use-case. The blacklists of the other three I got from the old old Beginner's Guide when I first set up (couple of years back) but at least snd_pcsp and pcspkr are still recommended to be blacklisted here https://wiki.archlinux.org/index.php/Disable_PC_Speaker_Beep
The purpose is simply to disable those annoying speaker beeps. Since computers normally come with sound cards nowadays, why would we want to hear polyphonic beeps which even our handphones and microwave ovens don't use anymore =).
As I said, when the change happens I'd personally just write the custom udev rules and forget about them, no big deal.
Ah, and I just remembered net-pf-10 was to disable IPv6 (I think). But in that case, the wiki has been updated with the new methods of doing so.
On 05/29/2011 04:32 AM, Oon-Ee Ng wrote:
On Sun, May 29, 2011 at 6:31 PM, Oon-Ee Ng<ngoonee.talk@gmail.com> wrote:
On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen<teg@jklm.no> wrote:
Thanks for your Oon-ee.
On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen<teg@jklm.no> wrote: <snip>
rc.conf - MODULES(!mod1, !mod2): blacklisting modules in the modules array will no longer have any effect. modprobe already provides two different ways of preventing modules from being loaded, so this is just a matter of updating some configuration files. To blacklist modules, add a new .conf file to /etc/modprobe.d/ with the contents
blacklist mod1 blacklist mod2 <snip>
This seems a regression of current rc.conf behaviour (in essence, moves another configuration back to upstream default which was previously in rc.conf). Is there any good reason to keep current behaviour (perhaps an Arch-specific udev rule which parses MODULES for blacklisting?) I have not found any uses of the MODULES array like you describe (if
Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng<ngoonee.talk@gmail.com> wrote: they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know.
Cheers,
Tom
Glad to oblige, here's my current MODULES:- MODULES=(!phc-intel acpi_cpufreq vboxdrv vboxnetflt loop fuse !net-pf-10 !snd_pcsp uinput !pcspkr coretemp)
When I was testing out undervolting I used the phc-intel blacklist to prevent it loading (otherwise it would automatically load even if not listed). Don't use it anymore, but its a use-case. The blacklists of the other three I got from the old old Beginner's Guide when I first set up (couple of years back) but at least snd_pcsp and pcspkr are still recommended to be blacklisted here https://wiki.archlinux.org/index.php/Disable_PC_Speaker_Beep
The purpose is simply to disable those annoying speaker beeps. Since computers normally come with sound cards nowadays, why would we want to hear polyphonic beeps which even our handphones and microwave ovens don't use anymore =).
As I said, when the change happens I'd personally just write the custom udev rules and forget about them, no big deal.
Ah, and I just remembered net-pf-10 was to disable IPv6 (I think). But in that case, the wiki has been updated with the new methods of doing so. Also !usblp for those of us with USB printer issues. (especially HP usb inkjets)
On Sun, May 29, 2011 at 12:44 PM, Casey Peter <caseyjp1@gmail.com> wrote:
Also !usblp for those of us with USB printer issues. (especially HP usb inkjets)
Yup, blacklist it in /etc/modprobe.d (we should probably fix this once and for all, I believe other distro's simply removed this module, but haven't had time to look into it). On my computer the module is not loaded for some reason (I have a HP usb laserjet)... -t
On Sun, May 29, 2011 at 12:44 PM, Casey Peter<caseyjp1@gmail.com> wrote:
Also !usblp for those of us with USB printer issues. (especially HP usb inkjets) Yup, blacklist it in /etc/modprobe.d (we should probably fix this once and for all, I believe other distro's simply removed this module, but haven't had time to look into it). On my computer the module is not loaded for some reason (I have a HP usb laserjet)...
-t Once the udev goes 'live', we probably need to update the printer wiki
On 05/29/2011 04:52 AM, Tom Gundersen wrote: section as that was where I found the solution to my printer issue, and the officjets printers are widely used. Oh, and the issue was more specific to the officejet printers, as the lasers just seemed "to work". I'd agree about removing it, as the distros (ubuntu/fedora/etc.) I have in my test partitions don't have issues with the officejets or that module.
Am 29.05.2011 12:52, schrieb Tom Gundersen:
On Sun, May 29, 2011 at 12:44 PM, Casey Peter<caseyjp1@gmail.com> wrote:
Also !usblp for those of us with USB printer issues. (especially HP usb inkjets)
Yup, blacklist it in /etc/modprobe.d (we should probably fix this once and for all, I believe other distro's simply removed this module, but haven't had time to look into it). On my computer the module is not loaded for some reason (I have a HP usb laserjet)...
-t
Removing the module isn't a good idea, as some applications still need it. For example escputil, which is shipped with gutenprint, needs usblp to read the ink levels from some EPSON printers. So only blacklisting it by default seems to be the better way. -- Regards, Richard Schütz
On Sun, May 29, 2011 at 1:19 PM, Richard Schütz <r.schtz@t-online.de> wrote:
ood idea, as some applications still need it. For example escputil, which is shipped with gutenprint, needs usblp to read the ink levels from some EPSON printers. So only blacklisting it by default seems to be the better way.
Thanks for your feedback Richard, this is good to know. Any idea how others deal with this? Cheers, Tom
On Sun, May 29, 2011 at 12:32 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Sun, May 29, 2011 at 6:31 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen <teg@jklm.no> wrote:
Thanks for your Oon-ee.
Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen <teg@jklm.no> wrote: <snip>
rc.conf - MODULES(!mod1, !mod2): blacklisting modules in the modules array will no longer have any effect. modprobe already provides two different ways of preventing modules from being loaded, so this is just a matter of updating some configuration files. To blacklist modules, add a new .conf file to /etc/modprobe.d/ with the contents
blacklist mod1 blacklist mod2 <snip>
This seems a regression of current rc.conf behaviour (in essence, moves another configuration back to upstream default which was previously in rc.conf). Is there any good reason to keep current behaviour (perhaps an Arch-specific udev rule which parses MODULES for blacklisting?)
I have not found any uses of the MODULES array like you describe (if they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know.
Cheers,
Tom
Glad to oblige, here's my current MODULES:- MODULES=(!phc-intel acpi_cpufreq vboxdrv vboxnetflt loop fuse !net-pf-10 !snd_pcsp uinput !pcspkr coretemp)
When I was testing out undervolting I used the phc-intel blacklist to prevent it loading (otherwise it would automatically load even if not listed). Don't use it anymore, but its a use-case. The blacklists of the other three I got from the old old Beginner's Guide when I first set up (couple of years back) but at least snd_pcsp and pcspkr are still recommended to be blacklisted here https://wiki.archlinux.org/index.php/Disable_PC_Speaker_Beep
The purpose is simply to disable those annoying speaker beeps. Since computers normally come with sound cards nowadays, why would we want to hear polyphonic beeps which even our handphones and microwave ovens don't use anymore =).
As I said, when the change happens I'd personally just write the custom udev rules and forget about them, no big deal.
Ah, and I just remembered net-pf-10 was to disable IPv6 (I think). But in that case, the wiki has been updated with the new methods of doing so.
This usecase of disabling features you don't need is exactly what "blacklist" is for, so it should work as expected to create a file in /etc/modprobe.d: blacklist pcspkr blacklist phc_intel Note that some of the blacklisting you are doing might be obsolete by the next udev release: I will remove some old arch-specific rules so that pcspkr will become opt-in rather than opt-out in many (all?) cases. snd_pcsp is not included in the standard arch kernel (AFAICT), I don't know its history though, so don't know what happened to it. Cheers, Tom
On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen <teg@jklm.no> wrote:
I have not found any uses of the MODULES array like you describe (if they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know.
i'll really like to know what is the "meant" way of using MODULES array in rc.conf? in rc.conf shipped with initscripts 2011.05.2-1, it is stated clearly: "MODULES: Modules to load at boot-up. Prefix with a ! to blacklist." and all of a sudden, prefixing modules with ! in MODULES array to blacklist the module at boot is considered improper use?
On Sun, May 29, 2011 at 12:45 PM, Auguste Pop <auguste@gmail.com> wrote:
On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen <teg@jklm.no> wrote:
I have not found any uses of the MODULES array like you describe (if they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know.
i'll really like to know what is the "meant" way of using MODULES array in rc.conf?
in rc.conf shipped with initscripts 2011.05.2-1, it is stated clearly: "MODULES: Modules to load at boot-up. Prefix with a ! to blacklist." and all of a sudden, prefixing modules with ! in MODULES array to blacklist the module at boot is considered improper use?
No. I was saying that only load-modules.sh/initscripts should parse the MODULES array directly (Oon-ee was suggesting that udev rules might rely on the MODULES array). Once we make this change, then blacklisting in rc.conf will become unsupported and we would of course update the comment and make an announcement. It should be replaced by a native modprobe configuration file (see my previous email or "man modprobe.conf"). Cheers, Tom
No. I was saying that only load-modules.sh/initscripts should parse the MODULES array directly (Oon-ee was suggesting that udev rules might rely on the MODULES array).
Once we make this change, then blacklisting in rc.conf will become unsupported and we would of course update the comment and make an announcement. It should be replaced by a native modprobe configuration file (see my previous email or "man modprobe.conf").
On Sun, May 29, 2011 at 6:56 PM, Tom Gundersen <teg@jklm.no> wrote: thanks for the explanation. i have used modprobe.conf to blacklist ipv6 on some boxes. and used ! in MODULES array to blacklist speaker, which is what's wrote on wiki. i know they probably do the same thing. and just love the possibility that "rc.conf rules them all". :p have a nice weekend~
I recently did a fresh install and noticed a ton of modules prefixed with ! in rc.conf by default. Not at the box currently but it was 5-7 modules listed. This will have to be changed. Also, this functionality has worked the same way for the entire time that I've used Arch. That is since 2003 and prefixing with ! was used to blacklist way back then. This change will break a lot of configurations.
On 29 May 2011 15:53, Robert Howard <howard.rob@gmail.com> wrote:
I recently did a fresh install and noticed a ton of modules prefixed with ! in rc.conf by default. Not at the box currently but it was 5-7 modules listed. This will have to be changed.
Also, this functionality has worked the same way for the entire time that I've used Arch. That is since 2003 and prefixing with ! was used to blacklist way back then. This change will break a lot of configurations.
If that happened then you used the Archboot install media with it's hwdetect consistent device ordering option. Archboot isn't official install media and I suspect that feature will have to be reworked because of the udev changes anyway. -- Jason Steadman http://www.meyithi.com/ http://twitter.com/meyithi
On Sun, May 29, 2011 at 5:03 PM, Meyithi <mail@meyithi.com> wrote:
If that happened then you used the Archboot install media with it's hwdetect consistent device ordering option. Archboot isn't official install media and I suspect that feature will have to be reworked because of the udev changes anyway.
Thanks for the pointer. I was not aware of this behavior. I looked at the wikipage of archboot and I don't think this feature can work reliably: modprobe does not promise to insert the modules in our MODULES array in the order they are listed. To get persistent ordering of devices one should use udev rules (though in most cases this is not needed). Cheers, Tom
On Sun, May 29, 2011 at 4:53 PM, Robert Howard <howard.rob@gmail.com> wrote:
I recently did a fresh install and noticed a ton of modules prefixed with ! in rc.conf by default. Not at the box currently but it was 5-7 modules listed. This will have to be changed.
This is not in the initscripts package. Don't know where this could have come from...
Also, this functionality has worked the same way for the entire time that I've used Arch. That is since 2003 and prefixing with ! was used to blacklist way back then. This change will break a lot of configurations.
Back in the day it was needed due to lacking features in module-init-tools and udev. Now it is no longer needed. All you have to do is to update the syntax, which should be easy enough. Please let me know if you discover issues with this though. Cheers, Tom
On Sunday 29 of May 2011 13:56:15 Tom Gundersen wrote:
On Sun, May 29, 2011 at 12:45 PM, Auguste Pop <auguste@gmail.com> wrote:
On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen <teg@jklm.no> wrote:
I have not found any uses of the MODULES array like you describe (if they exist they should be considered bugs though, the MODULES array was not meant to be used in this way). However, if anyone knows of any, then please let me know.
i'll really like to know what is the "meant" way of using MODULES array in rc.conf?
in rc.conf shipped with initscripts 2011.05.2-1, it is stated clearly: "MODULES: Modules to load at boot-up. Prefix with a ! to blacklist." and all of a sudden, prefixing modules with ! in MODULES array to blacklist the module at boot is considered improper use?
No. I was saying that only load-modules.sh/initscripts should parse the MODULES array directly (Oon-ee was suggesting that udev rules might rely on the MODULES array).
Once we make this change, then blacklisting in rc.conf will become unsupported and we would of course update the comment and make an announcement. It should be replaced by a native modprobe configuration file (see my previous email or "man modprobe.conf").
I seem to remember that the point of rc.conf was to configure system in one place. Looks like the politics are changing. Networking, hardwareclock, now modules. Locale next ? Regards,
2011/5/29 Vytautas Stankevičius <brotheris@gmail.com>:
I seem to remember that the point of rc.conf was to configure system in one place. Looks like the politics are changing.
rc.conf is the one place for all Arch-specific settings. As you know /etc is full of config files owned by different packages, rc.conf is for the stuff that does not belong anywhere else. As time goes by, upstream projects gain more config options making some of the ones in rc.conf obsolete. This is, in my opinion, a good thing as it means less code for us to maintain. An example of this is the UDEV_TIMEOUT variable. We keep this in rc.conf since udev does not support setting it in udev.conf. However, it is on their TODO list, so when this support is added to udev we will remove it from rc.conf.
Networking, hardwareclock, now modules.
Though I get your point, I think your examples were poorly chosen: Networking can still be configured in rc.conf. We will soon support a new syntax as we are adding support for iproute2, but the old one will still be supported (though marked as deprecated). Hardware clock is still supported in rc.conf. We only added a comment to suggest people set it to UTC, as LOCALTIME is causing more problems than it solves. That said, hwclock already has a config file for this variable, so we might revisit this in the future. We still support modules, only the blacklisting is deprecated.
Locale next ?
There are some open feature requests to improve our locale handling, but I see no reason to stop supporting the LOCALE variable in rc.conf. Cheers, Tom
On Mon, May 30, 2011 at 2:50 AM, Tom Gundersen <teg@jklm.no> wrote:
2011/5/29 Vytautas Stankevičius <brotheris@gmail.com>:
I seem to remember that the point of rc.conf was to configure system in one place. Looks like the politics are changing.
rc.conf is the one place for all Arch-specific settings. As you know /etc is full of config files owned by different packages, rc.conf is for the stuff that does not belong anywhere else.
Thank you, this is a very clear statement, and applies further than just to this topic (I'm thinking systemd and the possible resulting deprecation of our DAEMONS array in rc.conf). Wasn't aware of 'Arch-specific settings' in this context, even though it makes perfect sense once mentioned.
participants (8)
-
Auguste Pop
-
Casey Peter
-
Meyithi
-
Oon-Ee Ng
-
Richard Schütz
-
Robert Howard
-
Tom Gundersen
-
Vytautas Stankevičius