Talk:Broadcom Wireless - Revision history

Dijetlo: /* Issue with ssb as a dependency of the b44 module */ new section

2015-01-27T00:06:24Z

Issue with ssb as a dependency of the b44 module: new section

← Older revision		Revision as of 00:06, 27 January 2015
Line 2:		Line 2:
	First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point:		First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point:
	Second, since there's no need in this particular case to override all of what's in /lib/modprobe.d/blacklist.conf (you only want to add content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it. --rworkman		Second, since there's no need in this particular case to override all of what's in /lib/modprobe.d/blacklist.conf (you only want to add content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it. --rworkman

			== Issue with ssb as a dependency of the b44 module ==

			Copying /lib/modprobe.d/bcm43xx.conf to /etc/modprobe.d/bcm43xx.conf and then adding the blacklist entries there worked except for the ssb module. It seems ssb is a dependency of module b44 and is being successfully loaded which blocked the function of the wl module.
			The fix was to run sbo packages b43-fwcutter and b43-firmware.

			This page is a valuable resource for checking compliance.
			http://linuxwireless.org/en/users/Drivers/b43/

			Does anybody mind if I add a section referencing that? At the check where the reader runs the blacklisted modules in lsmod expecting a null return, put a fork in there and suggest if he gets a value after blacklisting and reboot, try the b43-fwcutter/b43-firmware approach.
			Or he might check for b44 at the outset and opt for the sbo packages if it's loaded with ssb as a dependency.

Rworkman at 03:44, 3 April 2014

2014-04-03T03:44:38Z

← Older revision		Revision as of 03:44, 3 April 2014
Line 1:		Line 1:
	I just made a couple of relatively minor edits to the page (20140402):		I just made a couple of relatively minor edits to the page (20140402):
	First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point:		First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point:
	Second, since there's no need in this particular case to override all of what's in /lib/modprobe.d/blacklist.conf (you only want to add content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it.		Second, since there's no need in this particular case to override all of what's in /lib/modprobe.d/blacklist.conf (you only want to add content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it. --rworkman

Rworkman: Explanation of changes wrt /etc/modprobe.d/

2014-04-03T03:44:05Z

Explanation of changes wrt /etc/modprobe.d/

New page

I just made a couple of relatively minor edits to the page (20140402):
First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point:
Second, since there's no need in this particular case to override *all* of what's in /lib/modprobe.d/blacklist.conf (you only want to *add* content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it.