Re: Going from Broadcom's sources to wireless card to WPA network

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  [ Background:  Installing drivers for Broadcom's wireless card on
    a Dell M6400 laptop running a Live USB of
    Fedora-14-x86_64-Live-Desktop.iso failed to result in a wireless
    connection;  since Broadcom's sources from 

        http://www.broadcom.com/support/802.11/linux_sta.php

    need to be built using a kernel of the target OS, and since I
    don't have access to any other F14, I now need to build these
    sources on the live USB, using the laptop's internal drive as a
    place to hold the required libraries etc.  And I am new to such
    activities.]
    
  Briefly, I was able to build the sources from Broadcom, but
  not without having to overcome some hurdles!  Here are the
  details:
  
  The command:
  
      yum --installroot=/media/OS/home/f14 install kernel-headers kernel-devel
      
  failed with the message:
  
      Loaded plugins: langpacks, presto, refresh-packagekit
      Adding en_US to language list
      
      Error: Cannot retrieve repository metadata (repomd.xml)
      for repository: fedora.  Please verify its path and try
      again
      
      Could not parse metalink
      https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64
      error was
      No repomd file
  
  Not being used to reading error messages in detail, I just
  googled for the first line of the error message, and found:
  
      http://digitizor.com/2009/06/17/how-to-fix-the-cannot-retrieve-repository-metadata-repomd-xml-error-in-fedora-11/
  
  As per that web-page, I modified /etc/yum.repos.d/fedora.repo
  and /etc/yum.repos.d/fedora-updates.repo -- but not /etc/hosts.
  yum failed again, but this time I read the error message in
  detail -- and noticed $releasever in the url.  I went back to
  the two .repo files and replaced $releasever by 14 ($basearch 
  would automatically become x86_64).
  
  Question 1: What's the bug that prevents $releaserver from
              taking its value?
  
  This time, although the yum command went forward, it aborted
  with some message (alas!, I didn't record the error message).
  The above web-page mentioned modifying the /etc/hosts file,
  which I hadn't done;  I pinged both mirrors.fedoraproject.org
  and mirrors.rpmfusion.org and found that the numerical
  addresses did _match_ the values in that web-page.  Still
  puzzled, I went ahead and edited /etc/hosts files as advised,
  and tried yum again -- it succeeded!
  
  Question 2: Why did I need to modify the /etc/hosts file even
              though ping showed that the human-readable
              addresses were being resolved to correct values?
              Perhaps, it was just some congestion at the
              destination url, and the command would have worked
              the second time even without the modification to
              /etc/hosts?
  
  Then I did:
  
      yum --installroot=/media/OS/home/f14 install gcc
  
  Not having wget, I used Firefox to get Broadcom's sources
  hybrid-portsrc_x86_64-v5_100_82_38.tar.gz.
  
  The attempts to build the sources had hurdles too, all but one
  of the hurdles was because of the non-standard installation
  location.
  
  I had to update PATH and LD_LIBRARY_PATH, which is
  understandable.
  
      export PATH=$PATH:/media/OS/home/f14/usr/local/bin:/media/OS/home/f14/usr/bin
      export LD_LIBRARY_PATH=/media/OS/home/f14/usr/lib64
      export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/media/OS/home/f14/usr/lib64/perl5/CORE
  
  I had to create some soft-links:
  
      cd /lib/modules/2.6.35.6-45.fc14.x86_64/
      mv build build.org
      ln -s /media/OS/home/f14/usr/src/kernels/2.6.35.6-45.fc14.x86_64  build   
  
      cd /usr/lib64
      ln -s /media/OS/home/f14/usr/lib64/perl5  perl5
      cd ../share
      ln -s /media/OS/home/f14/usr/share/perl5  perl5
  
  I think the need for the preceding is understandable too;
  "understandable" meaning this need does _not_ occur because of
  some bug in the process of installing in the non-default location.

  Then there was the issue about not finding ld;  I poked around
  and found something strange:
  
      cd  /media/OS/home/f14/usr/bin
      ls -laF  ld
      ld -> /etc/alternatives/ld
      
      cd  /media/OS/home/f14/etc/alternatives
      ls -laF ld*
      ld -> /usr/bin/ld.bfd
  
  The above is strange since the use of absolute paths in the
  links means that there will be issues when the modules are
  installed in a non-default location!  I modified the above
  as follows:
  
      cd  /media/OS/home/f14/etc/alternatives
      ln -s ../../usr/bin/ld.bfd  ld
      ln -s ../../usr/bin/ld.bfd  ld.bfd
  
      cd  /media/OS/home/f14/usr/bin
      # Should have used a relative path in the next command
      # Even better, could have just done: ln -s ld.bfd ld
      ln -s /media/OS/home/f14/etc/alternatives/ld ld
  
  Question 3: Why doesn't the module that provides ld use
              relative paths in the soft links -- thereby
              allowing that module to be easily installed in
              a non-standard location?
      
  Question 4: An annoying thing about the terminal is that
              selection does nothing and right click brings up
              a menu -- how to change this so that selection
              results in an automatic copy to the clipboard, 
              and right-click results in paste?
  
  I have not yet gotten to installing the wl.ko;  hope to do so
  something this week.
  
  --Suresh
  
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux