bcm4312 in Arch

Alexvader · 02-23-2010, 05:50 PM

Hi Forum

I have installed Arch in a box w/ the BCM 4312 wireless card.

built the driver as per the readme included in the latest version from Broadcom,

Quote:

# make clean (optional)
# make

When the build completes, it will produce a wl.ko file in the top level
directory.

3: Remove any other drivers for the Broadcom wireless.

There are several open source drivers that are used to drive Broadcom 802.11
chips such as b43 and ssb. If any of these are present they need to be removed before this
driver can be installed. Any previous revisions of the wl driver also need to
be removed.

# lsmod | grep "b43\|ssb\|wl"

If any of these are installed, remove them:
# rmmod b43
# rmmod ssb
# rmmod wl

To blacklist these drivers and prevent them from loading in the future:
# echo "blacklist ssb" >> /etc/modprobe.d/blacklist.conf
# echo "blacklist b43" >> /etc/modprobe.d/blacklist.conf

4: Insmod the driver.

If you were already running a previous version of wl, you'll want to provide a
clean transition from the older driver. (The path to previous driver is usually
/lib/modules/<kernel-version>/kernel/net/wireless)

# rmmod wl
# mv <path-to-prev-driver>/wl.ko <path-to-prev-driver>/wl.ko.orig
# cp wl.ko <path-to-prev-driver>/wl.ko
# depmod
# modprobe wl

Otherwise, if you have not previously installed a wl driver do this:

# modprobe lib80211
# insmod wl.ko

copied wl.ko to the right place :

Quote:

cp wl.ko /lib/modules/2.6.30-ARCH/kernel/net/wireless

as well as to /lib/modules/2.6.30-ARCH/kernel/drivers/net/wireless

depmod -a
modprobe wl

Set the modules to load at boot time in /etc/rc.conf :

Code:

#
# /etc/rc.conf - Main Configuration for Arch Linux
#

# -----------------------------------------------------------------------
# LOCALIZATION
# -----------------------------------------------------------------------
#
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
#
LOCALE="en_US.utf8"
HARDWARECLOCK="localtime"
USEDIRECTISA="no"
TIMEZONE="Europe/Lisbon"
KEYMAP="pt-latin1"
CONSOLEFONT="Agafari-16"
CONSOLEMAP=
USECOLOR="yes"

# -----------------------------------------------------------------------
# HARDWARE
# -----------------------------------------------------------------------
#
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
#
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
#
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=( !pcspkr !snd-pcsp lib80211 wl )

# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"

# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
#
HOSTNAME="iskandhar"

# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
#   - prefix an entry in INTERFACES with a ! to disable it
#   - no hyphens in your interface names - Bash doesn't like it
# 
# DHCP:     Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#

#Static IP example
eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
#eth0="dhcp"
INTERFACES=(eth0)

# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
#   - prefix an entry in ROUTES with a ! to disable it
#
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
 
# Enable these network profiles at boot-up.  These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
#   - set to 'menu' to present a menu during boot-up (dialog package required)
#   - prefix an entry with a ! to disable it
#
# Network profiles are found in /etc/network.d
#
# This now requires the netcfg package
#
#NETWORKS=(main)

# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
#   - prefix a daemon with a ! to disable it
#   - prefix a daemon with a @ to start it up in the background
#
DAEMONS=(syslog-ng gpm network netfs crond)

eth1 shows up allright in ifconfig, but if I try to scan or assign an AP to eth1, things go wrong... :

Quote:

[root@iskandhar ~]# ifconfig eth1 up
[root@iskandhar ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:21:00:9D:98:C0
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:16

eth1 Link encap:Ethernet HWaddr 00:23:8B:5C:FA:4E
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:32

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

[root@iskandhar ~]# iwconfig eth1 essid "eduroam-guest"
Error for wireless request "Set ESSID" (8B1A) :
SET failed on device eth1 ; Operation not supported.

What have i missed here...?

BRGDS

Alex

snowday · 02-23-2010, 05:55 PM

Have you considered reading the excellent documentation on the Arch Linux website?

http://wiki.archlinux.org/index.php/Broadcom_BCM4312
http://aur.archlinux.org/packages.php?ID=19514

reed9 · 02-23-2010, 06:31 PM

You also shouldn't need to explicitly load the module in rc.conf.

Quote:

cp wl.ko /lib/modules/2.6.30-ARCH/kernel/net/wireless

Also, 2.6.30 is an old kernel. The default is 2.6.32 now. If you've updated the kernel since you build the module, you would need to rebuild against the new kernel.

I recommend using the PKGBUILD in the AUR linked to above. Makes it easier to rebuild as needed, for one.

Alexvader · 02-24-2010, 09:58 AM

Hi @snowpime, @reed9

Thks for yr replies

Once again, STUPID ME

... the connection was there allright

except it was called eth0 not eth1, I will have to declare eth1 in etc/rc.conf

guess I will have to rebuild the module against 2.6.32-ARCH

But this raises some interesting questions... : ( probably n00bish also, but what the heck...

)

I have never been much into this rolling release thing, so this is my first contact with the concept.

Allright, to start,

1.) I install Arch,
2.) configure an interface,
3.) run pacman -Syu, this will give me the latest kernel, glibc, gcc, etc.
4.) Build the packages I use from source, ( believe me there's a lot of them )
5.) Convert them into Arch packages ( that is what I do in Slackware )
6.) Burn a DVD with them, just In case i need to reinstall my system from scratch

In Slackware, this allows me to redeploy a working system from nothing in 20mn... not bad huh...?!

My problem ( do I know Arch well enough to call it a problem... ?!

) with Arch is with points 3-4 6, I will explain :

This works in Slackware, but not with Arch, because if I for some reason have to reinstall Arch, when I run pacman -Syu in will install a completely different snapshot from the one I built and packaged my applications against... meaning different kernel headers, kernel, glibc, gcc...etc

So, most of my packages will have to be rebuilt against this new snapshot of Arch ... am I right here or not...?!

One possible solution for this "problem" would be installing Arch, running pacman -Syu and freezing this snapshot creating a repo containing everything that has been dumped into /var/cache/pacman/pkg/* and /var/lib/pacman/*, before building all the stuff I use.

This way, should I have to redeploy my system, I would install arch, run my pacman -Syu against my frozen repo, and install everything since nothing would be broken by a rolling update....

Is my setting possible... ?

BRGDS

Alex

reed9 · 02-24-2010, 10:51 AM

Quote:

This works in Slackware, but not with Arch, because if I for some reason have to reinstall Arch, when I run pacman -Syu in will install a completely different snapshot from the one I built and packaged my applications against... meaning different kernel headers, kernel, glibc, gcc...etc

So, most of my packages will have to be rebuilt against this new snapshot of Arch ... am I right here or not...?!

Yes. For a backup snapshot, I would use something like clonezilla. For easy rebuilds of your packages, you should create PKGBUILD scripts for them. If you have a lot of stuff compiled against the kernel, you might want to look into the long-time support kernel, also.

Other possibly useful information:
http://wiki.archlinux.org/index.php/...ging_Standards
http://wiki.archlinux.org/index.php/AUR
http://wiki.archlinux.org/index.php/ABS
http://xyne.archlinux.ca/info/bauerbill

reed9 · 02-24-2010, 10:54 AM

Quote:

One possible solution for this "problem" would be installing Arch, running pacman -Syu and freezing this snapshot creating a repo containing everything that has been dumped into /var/cache/pacman/pkg/* and /var/lib/pacman/*, before building all the stuff I use.

This way, should I have to redeploy my system, I would install arch, run my pacman -Syu against my frozen repo, and install everything since nothing would be broken by a rolling update....

Is my setting possible... ?

Hmm, I suppose you could create a local repository of packages based on when you installed your system...but then when you update, you would still have to rebuild your custom packages... I still think for a quick restoration, cloning the install would be better.

Alexvader · 02-24-2010, 11:22 AM

Hi Reed9

Late this afternoon i will make one experiment :

I have a full snapshot of Arch [core] [community] and [extra] for <x86_64> and <any>...

I will install Arch in my USB HDD, dump the whole content of [extra] [community] and [base] into /var/cache/pacman/pkg, as well as untar core....tar.gz community..tar.gz and extra.. tar.gz in /var/lib/pacman/core , /var/lib/pacman/community and /var/lib/pacman/extra, and run an "upgrade" with this frozen snapshot...

i will have to edit /etc/pacman.conf

{current}
Server = file:///var/cache/pacman/pkg

and

{extra}
Server = file:///var/cache/pacman/pkg

... Just to see how far I can get...

Crossing my fingers already...

Regardless of this possible difficulties I am poniting, I think Arch takes the K.I.S.S philosophy to an extreme... which is good...

in memory footprint, boot time speed, overall "snappiness"...

I think the Motorbike equivalent of Arch would be something like Kawasaki Ninja ZX-14...

and the Mandriva equivalent would be the vespa....

ROFL

BRGDS

Alex

Alexvader · 02-24-2010, 03:36 PM

Quote:

Originally Posted by reed9

...I still think for a quick restoration, cloning the install would be better.

Hi reed9,

Lets imagine that I have arch installed and updated in my PC.
A clean Install and Update, nothing built on top of it.

My partition setting is /boot ~ 100mb /root ~ 1 Tb and /swap ~ 2Gb...

From this /root i only have ~ 1 Gb taken... In case I build an Image of my hdd for restoration, using Akronis, or Clonezilla, it will not ammount to the ~ 1 Tb size of my hdd, will it...?

... I mean, the space IS THERE, but it is empty space... are images generated for cloning compressed and optimized...?

Can they be created to be bootable from a DVD...?

I ask this bcause i never used this stuff, nor have i cloned a system before...

BRGDS

Alex

reed9 · 02-24-2010, 04:46 PM

I'm not super familiar with cloning drives, actually, I just know that what you were thinking of doing sounded unnecessarily complex. I would guess it would just take up as much space as you have used.

I would recommend having a separate home partition, and reserve 10-20 GB for root. That way, you can much more easily reinstall or change distros, all the while maintaining the same /home.