I attempted to do everything with ffmpeg, but found there were some limitations with dissolving and so on that seemed to require scripts and sort of reinventing the wheel1. Accordingly, looked at GUI's and Kino stuck out (GTK libs), but seemed to require a lot of dependencies. Nevertheless, jumped in.
Showing posts with label zenwalk. Show all posts
Showing posts with label zenwalk. Show all posts
Tuesday, December 20, 2011
video editing - command line
Links: Kino site
I attempted to do everything with ffmpeg, but found there were some limitations with dissolving and so on that seemed to require scripts and sort of reinventing the wheel1. Accordingly, looked at GUI's and Kino stuck out (GTK libs), but seemed to require a lot of dependencies. Nevertheless, jumped in.
I attempted to do everything with ffmpeg, but found there were some limitations with dissolving and so on that seemed to require scripts and sort of reinventing the wheel1. Accordingly, looked at GUI's and Kino stuck out (GTK libs), but seemed to require a lot of dependencies. Nevertheless, jumped in.
Monday, May 30, 2011
wusb54g - ralink 2500
A family member running kernel 2.6.28.7 was having some problems with her older Linksys WUSB54G (Ralink 2500 chip). As seen in the photo, this is an external USB Wi-Fi card. 
When I installed her system (Zenwalk Slackware) back in 2009, ndiswrapper was the answer for this chip, which was posing problems for some Linux installations. It did fine, even with encryption and so on. Recently however, the relatives de-encrypted their network, probably so a visiting relative could use their network or during a Windows update, and the Linksys card was unable to associate with the LAN router once the network was keyless. This is a matter of opening or dropping the encryption configuration line and then ordering the remaining lines. However, over a telephone, implementing these kinds of changes required a lot of patience from my relative (thank you, Mom!). Ultimately, at least over the phone, it appeared there was no associating to this unencrypted network via ndiswrapper and using standard commands such as, say:
Then I got to thinking about the old rt2500 driver. This driver is anachronistic, as all of these legacy Ralink cards now are managed directly in the kernel. But it is less anachronistic than ndiswrapper. Further, it would be a lot to ask a family member to update their entire system, a full Linux installation, with only telephone guidance. It looked like the middle ground would be to withdraw ndiswrapper and install the last/latest rt2500 driver to see if it was less finicky. Would the source for this older driver still be available. Turns out it was no longer available at the Ralink site. Summary: I couldn't travel to Mom's place to make the changes and it had been going slowly over the phone.
Ralink This is supposed to take care of the patch stuff according to this site
Before compiling, be sure the card ID "1737:0078" is included in the card ID section. I located them by navigating to the top source directory and then
Still within the source directory, I also made the following change
After all of this, the rt2870sta was a no-go. A deeper look, showed that it lacks product and bus information and was not even being assigned an IRQ or other resources. For example, compare it to the (working) Atheros card below
When I installed her system (Zenwalk Slackware) back in 2009, ndiswrapper was the answer for this chip, which was posing problems for some Linux installations. It did fine, even with encryption and so on. Recently however, the relatives de-encrypted their network, probably so a visiting relative could use their network or during a Windows update, and the Linksys card was unable to associate with the LAN router once the network was keyless. This is a matter of opening or dropping the encryption configuration line and then ordering the remaining lines. However, over a telephone, implementing these kinds of changes required a lot of patience from my relative (thank you, Mom!). Ultimately, at least over the phone, it appeared there was no associating to this unencrypted network via ndiswrapper and using standard commands such as, say:iwconfig wlan0 essid FooSo it was a conundrum. We tried several different permutations, as noted above, before giving-up for the weekend.
iwconfig wlan0 key open #(or using "off")
iwconfig wlan0 ap 00:20:etc
Then I got to thinking about the old rt2500 driver. This driver is anachronistic, as all of these legacy Ralink cards now are managed directly in the kernel. But it is less anachronistic than ndiswrapper. Further, it would be a lot to ask a family member to update their entire system, a full Linux installation, with only telephone guidance. It looked like the middle ground would be to withdraw ndiswrapper and install the last/latest rt2500 driver to see if it was less finicky. Would the source for this older driver still be available. Turns out it was no longer available at the Ralink site. Summary: I couldn't travel to Mom's place to make the changes and it had been going slowly over the phone.
Solution: Linksys WUSB100
I locally purchased a WUSB100, id 1737:0078 ($15), to install onto my system, make configuration software, and then mail to her. There are two versions of WUSB100Version 1 module rt2870sta
This site indicates that the the rt2870sta works with the following Linksys USBs:USB: 1737:0070 Linksys WUSB100 v1 RangePlus Wireless Network Adapter [Ralink RT2870]Noting that my 1737:0078 is not on that list
USB: 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
USB: 1737:0077 Linksys WUSB54GC v3 802.11g Adapter [Ralink RT2070L]
Version 2 - module rt2870 or rt3070?
Written on the back of the WUSB100 in my possession: FCCID Q87-WUSB100v2. Still began with the rt2870 since some were having success with this. The kernel would recognize it and assign ra0, but would not assign memory resources or allow connection. During this process, found there are at least two chips in version 2, the Belkin 050d:825b or what I have, the Ralink chip 1737:0078. I'm on the right track but, for the Ralink chip, it appears will have to go to the rt3070sta which means a patch is necessary. That will be my next weekend project. Meanwhile, I've also left the Belkin stuff here for those who have Belkins.Ralink This is supposed to take care of the patch stuff according to this site
I believe the fix is to replace all instances of usb_buffer_alloc with usb_alloc_coherent and all instances of usb_buffer_free with usb_free_coherent. The instances I replaced were in include/os/rt_linux.h and os/linux/rt_usb_util.c.Belkin
preinstalled driver attempts
Well before I compiled the rt3070sta module, I had hoped for the good luck of a driver included with the distro working. In favor of such a dream, the WUSB100 was detected by udevmonitor and lsusb. However, no module was being loaded. Thus, I looked in the wifi driver directory for useful drviers included with the distro:$ls /lib/modules/2.6.28.7/kernel/drivers/net/wireless/I tried loading some of these with modprobe but the card continued to go unreachable. That is, in spite of modprobing these drivers in, the command
[snip] rtl8187.ko rt2x00 (directory) rtl8180.ko
$ls /lib/modules/2.6.28.7/kernel/drivers/net/wireless/rt2x00
rt2400pci.ko rt2500pci.ko rt2500usb.ko rt2x00lib.ko rt2x00pci.ko rt2x00usb.ko rt61pci.ko rt73usb.ko
#ifconfig ra0 up (or wifi0, etc)was yielding nothing. Back to the Google machine.
module rt2870sta attempts
Also before compiling the rt3070sta, I'd noticed some had success with the rt2870sta module and a few tweaks. It wasn't already onboard:root[/]# find -iname rt2870*
root[/]#
- downloaded rt3070sta, now deprecated, cached here (scroll down to "nightflier"'s post) and also here, along with some associated patches.
- downloaded the rt2870sta source, now deprecated, here.This provided me with version2010_0709_RT2870_Linux_STA_v2.4.0.1.tar.bz2.
- downloaded the firmware, same location. File is RT2870_Firmware_V22.zip.
- The settings for rt2870sta.dat are explained here
rt2870sta compiling notes
most comprehensive linkBefore compiling, be sure the card ID "1737:0078" is included in the card ID section. I located them by navigating to the top source directory and then
$ grep -r USB_DEVICE *In my source, these statements were in /common/rtusb_dev_id.c. I added the line in there:
{USB_DEVICE(0x1737,0x0078)}, /* Linksys WUSB100v2 Pepsi */(I like Pepsi, so whatever). In this fellow's source, they were in rt2870.h.
Still within the source directory, I also made the following change
$ geany /os/linux/config.mkBlacklist any modules that might attempt to load and conflict.
HAS_WPA_SUPPLICANT=y
HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y
# geany /etc/modprobe.d/blacklistBacked-up the default /etc/Wireless/RT2870STA/RT2870STA.dat
blacklist rt2x00usb
blacklist rt2x00lib
blacklist rt2500usb
# cp /etc/Wireless/RT2870STA/RT2870STA.dat /etc/Wireless/RT2870STA/RT2870STA.bak.defCompiling is a basic $make/#make install operation. Unzip and install the firmware, although I noted no significant change from before the firmware was installed to after.
# cp Download/RT2870_Firmware_V22/rt2870.bin /lib/firmware/After compiling, installation, and modprobing, it's good to run # depmod, so I did that as well. Zince I'm using Zlackware Zenwalk, added the MAC to /etc/iftab. Added the module and updated the kernel
# chmod 555 /lib/firmware/rt2870.bin
# depmod
After all of this, the rt2870sta was a no-go. A deeper look, showed that it lacks product and bus information and was not even being assigned an IRQ or other resources. For example, compare it to the (working) Atheros card below
# lshw -C network
*-network
description: Wireless interface
product: AR242x 802.11abg Wireless PCI Express Adapter
vendor: Atheros Communications Inc.
physical id: 0
bus info: pci@0000:05:00.0
logical name: wifi0
version: 01
serial: 00:2e:xx:xx:xx:xx
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list logical ethernet physical wireless
configuration: broadcast=yes driver=ath_pci ip=192.168.1.2 latency=0 multicast=yes wireless=IEEE 802.11g
resources: irq:18 memory:f3100000-f310ffff
*-network
description: Wireless interface
physical id: 1
logical name: ra0
serial: 68:3e:xx:xx:xx:xx
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=RALINK WLAN driverversion=2.4.0.0 multicast=yes wireless=Ralink STA
Thursday, February 25, 2010
zenwalk - corrupted disk
Links: helpful command explanations
A couple of Christmases ago I installed Zenwalk 6.0 on one of my parents' HP systems. It remained mostly reliable until this week, when it froze and subsequently stopped booting properly. Ultimately, we found that their system contained one or more inode conflicts. We fixed these cross-links with two commands and a great number, roughly 1,000, confirmation keystrokes. All this via an hour-long telephone call. My mother is a patient and persistent soul.
Part one
My folks told me they recalled being online arranging bookmarks in Iceweasel (Zenwalk's rebranded Mozilla-Firefox). While arranging, the system froze entirely, apparently remaining unresponsive to the last-resort X11 Ctrl+Backspace exit. Mom said she next attempted a hard reboot but this also failed. During the attempt, error messages describing cross-indexed inodes and a corrupt superblock were scrolling. This was no doubt fsck scanning /dev/sda1. Following fsck, the script eventually exited to a single-user root login. No action was taken at the root login, and the system eventually rebooted itself and again initiated fsck. And so on. Then my phone rang ;)
Part two
It appeared the most direct route was to reboot the system and let it exit to the point where it allowed the single-user root login. From that point, we could enter commands directly, such as to locate back-up copies of the superblock on /dev/sda1. With a back-up copy located, we could run a clean fsck and resolve any doubly referenced inodes. Accordingly, the first step was to retrieve a list of the backup superblocks.
# dumpe2fs /dev/sda1 | grep superblock
This provided us with a list of about 12 back-up superblock locations. The first of these was "32768".
Part three
Used the back-up superblock to reestablish order in the system files and clear-up the multiply- referenced inode conflict.
# fsck -b 32768 /dev/sda1
Fsck eventually resolved the inode conflicts and some directory problems. During the process, my mother had to enter confirming "yes"'s nearly 1,000 times.
success
The problem was solved for the time being. Since I could not access the system, it remains unclear whether the problem was related to Iceweasel, to a possible hard drive problem, or to some combination of these.
A couple of Christmases ago I installed Zenwalk 6.0 on one of my parents' HP systems. It remained mostly reliable until this week, when it froze and subsequently stopped booting properly. Ultimately, we found that their system contained one or more inode conflicts. We fixed these cross-links with two commands and a great number, roughly 1,000, confirmation keystrokes. All this via an hour-long telephone call. My mother is a patient and persistent soul.
Part one
My folks told me they recalled being online arranging bookmarks in Iceweasel (Zenwalk's rebranded Mozilla-Firefox). While arranging, the system froze entirely, apparently remaining unresponsive to the last-resort X11 Ctrl+Backspace exit. Mom said she next attempted a hard reboot but this also failed. During the attempt, error messages describing cross-indexed inodes and a corrupt superblock were scrolling. This was no doubt fsck scanning /dev/sda1. Following fsck, the script eventually exited to a single-user root login. No action was taken at the root login, and the system eventually rebooted itself and again initiated fsck. And so on. Then my phone rang ;)
Part two
It appeared the most direct route was to reboot the system and let it exit to the point where it allowed the single-user root login. From that point, we could enter commands directly, such as to locate back-up copies of the superblock on /dev/sda1. With a back-up copy located, we could run a clean fsck and resolve any doubly referenced inodes. Accordingly, the first step was to retrieve a list of the backup superblocks.
# dumpe2fs /dev/sda1 | grep superblock
This provided us with a list of about 12 back-up superblock locations. The first of these was "32768".
Part three
Used the back-up superblock to reestablish order in the system files and clear-up the multiply- referenced inode conflict.
# fsck -b 32768 /dev/sda1
Fsck eventually resolved the inode conflicts and some directory problems. During the process, my mother had to enter confirming "yes"'s nearly 1,000 times.
success
The problem was solved for the time being. Since I could not access the system, it remains unclear whether the problem was related to Iceweasel, to a possible hard drive problem, or to some combination of these.
Monday, February 8, 2010
Inspiron 7000 - Linksys WPC54G w/BCM4306
Links: Discussion on 43b module b43 module installation (doesn't work) b43 v. ndiswrapper b43legacy issues ndiswrapper solution linksys WPC54G support
This is an install I'm working on with a friend's older Inspiron 7000. We dropped Zenwalk 6.0 (Slackware light) into the system and everything configured out-of-the box, except his PCMCIA Linksys WPC54G (version 1.2) card. This entry is meant as a trail of crumbs for how we solved it.
The legacy Linkys WPC54G card employs a Broadcom 4306 chip. I've never understood the impulse behind closed-source drivers for hardware. There are millions of Linux users; if Broadcom only produces a driver for Microsoft, at least make it open-source. Linux users can then easily design a good driver. They will want to buy Broadcom-based hardware.
Since the Broadcom driver was proprietary, any drivers/modules for it needed to be reverse engineered for Linux with some predictable results. For example, the b43 module described here didn't work. The fwcutter program appeared to properly extract info from bcmwl5.sys and install it into /lib/firmware; the card was detected by the kernel and apparently was semi-configured by the b43 module; but yet the card never fully initialized. This meant it came down to either the b43legacy module or, as a last resort, to using ndiswrapper on the driver coded for MSoft by Broadcom. You know, like back in 2004. But before we capitulated to ndiswrapper or b43legacy, we wanted to try fwcutter again with a more researched approach.
environment
$ uname -r
2.6.28.7
# lspci -vnn
06:00.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
Subsystem: Linksys WPC54G [1737:4320]
Flags: bus master, fast devsel, latency 64, IRQ 11
Memory at 1c000000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb
software
Understanding from above that we're dealing with the "4320" Broadcom chip, the b43 module should have worked previously; b43 is the recommended driver for the 4320 id. I decided to recompile fwcutter, this time making sure I had version "012" of fwcutter and version 4.150.10.5 of Broadcom's proprietary driver.
$ wget http://bu3sch.de/b43/fwcutter/b43-fwcutter-012.tar.bz2
$ wget http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
success
Untarred and compiled fwcutter -- "$ make". Didn't even have to configure. Then, after untarring the driver, put the driver files in the folder with the fwcutter program and ran:
# ./b43-fwcutter -w /lib/firmware wl_apsta_mimo.o
Rebooted and the card came right up.
This is an install I'm working on with a friend's older Inspiron 7000. We dropped Zenwalk 6.0 (Slackware light) into the system and everything configured out-of-the box, except his PCMCIA Linksys WPC54G (version 1.2) card. This entry is meant as a trail of crumbs for how we solved it.
The legacy Linkys WPC54G card employs a Broadcom 4306 chip. I've never understood the impulse behind closed-source drivers for hardware. There are millions of Linux users; if Broadcom only produces a driver for Microsoft, at least make it open-source. Linux users can then easily design a good driver. They will want to buy Broadcom-based hardware.
Since the Broadcom driver was proprietary, any drivers/modules for it needed to be reverse engineered for Linux with some predictable results. For example, the b43 module described here didn't work. The fwcutter program appeared to properly extract info from bcmwl5.sys and install it into /lib/firmware; the card was detected by the kernel and apparently was semi-configured by the b43 module; but yet the card never fully initialized. This meant it came down to either the b43legacy module or, as a last resort, to using ndiswrapper on the driver coded for MSoft by Broadcom. You know, like back in 2004. But before we capitulated to ndiswrapper or b43legacy, we wanted to try fwcutter again with a more researched approach.
environment
$ uname -r
2.6.28.7
# lspci -vnn
06:00.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
Subsystem: Linksys WPC54G [1737:4320]
Flags: bus master, fast devsel, latency 64, IRQ 11
Memory at 1c000000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb
software
Understanding from above that we're dealing with the "4320" Broadcom chip, the b43 module should have worked previously; b43 is the recommended driver for the 4320 id. I decided to recompile fwcutter, this time making sure I had version "012" of fwcutter and version 4.150.10.5 of Broadcom's proprietary driver.
$ wget http://bu3sch.de/b43/fwcutter/b43-fwcutter-012.tar.bz2
$ wget http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
success
Untarred and compiled fwcutter -- "$ make". Didn't even have to configure. Then, after untarring the driver, put the driver files in the folder with the fwcutter program and ran:
# ./b43-fwcutter -w /lib/firmware wl_apsta_mimo.o
Rebooted and the card came right up.
Saturday, October 10, 2009
zenwalk - package management
Links:
Forum Thread: Prior release repositories
Forum Thread: Making a local repository for a release
The Zenwalk OS (Slackware-based) is updated once or twice a year. Following an update, the mirrors for packages (programs) are also updated and contain the latest package versions.
Let's suppose I like to use the audacious package to play music. In order to keep the installation disc as small as possible, packages such as audacious are not included in the Zenwalk installation disc. These additional packages are retrieved separately from one of the package mirrors. Open a terminal and it's easy to download and install any Zenwalk package (in this case, audacious) using the command line:
# netpkg audacious
Or, if removing:
# netpkg -remove audacious
That's about all there is to installing or removing applications Zenwalk maintains.
Maintaining Previous Versions
As noted above, Zenwalk releases entirely new distributions once or twice a year. What if I don't want to upgrade my entire operating system, but I still want to install applications? For example, suppose I've had Zenwalk 6.0 installed for a year before I remember I want to install audacious. I try to netpkg audacious but, when I do, I discover Zenwalk has upgraded to v.6.4. If I try to install the newer version of audacious, netpkg asks to upgrade portions of v.6.0. I can let netpkg do this, but maybe I don't want parts of my system to be in 6.4, while other parts are in 6.0. How do I avoid upgrading to 6.4, but still get the packages I want for 6.0?
Three Solutions
Solution a -- install without using netpkg
One can always go to the home page of any application they desire and simply download, unpack, configure, compile, and install the general release tarball (.tgz). In the case of audacious, the home page is http://audacious-media-player.org/. One might want to check for dependencies when doing so.
But a couple of solutions for installing older software can be accomplished inside of the netpkg package manager. Both of these require a small degree of manipulation of the /etc/netpkg.conf file. The second option additionally requires manipulation of the /usr/libexec/netpkg-functions file.
Solution b -- point netpkg to prior release mirrors
For a period of time after a new Zenwalk release, a few mirrors contain the previous release. One must open the /etc/netpkg.conf file with a text editor and manually add URLs for older mirrors. After doing so, I run
# netpkg mirror
and select one of the older mirrors. I found a few prior release URLs listed here, and had success with this mirror: http://viking.zenwalk.org/i486/current-old. Other archive URLs can probably be Googled, but there is a limitation to this solution: archive mirrors trail the current Zenwalk release by only one version. Users therefore only have a grace period of 6 months to a year before they will be forced to upgrade to some extent. The more permanent solution is the one below.
Solution c -- download all desired packages for dvd or other local access
This is a permanent solution, in case one wishes to never upgrade Zenwalk. The catch here is one needs to consider nearly any application they might need, because thinking of it two years later will be too late (if that happens, just use "solution a"). To download all potential applications in a Zenwalk release is roughly 10GB. I then alter netpkg to find the files on my hard drive or a dvd, instead of on a mirror. Alterations include the /etc/netpkg.conf and /usr/libexec/netpkg-functions files. Here are instructions:local repository
Supposedly it's also possible to point to a DVD with everything on it (if Apache is running) with this URL added to /etc/netpkg.conf and selected via # netpkg mirror:
!! For "solution c", it's necessary to download PACKAGES.txt and PACKAGES.txt.gz/ from the mirror. Netpkg appears unable to traverse directories to locate packages without these meta-information files. Get these files before the previous release mirrors move to a newer release or face recreating them manually, a time-consuming, nearly prohibitive task.
Forum Thread: Prior release repositories
Forum Thread: Making a local repository for a release
The Zenwalk OS (Slackware-based) is updated once or twice a year. Following an update, the mirrors for packages (programs) are also updated and contain the latest package versions.
Let's suppose I like to use the audacious package to play music. In order to keep the installation disc as small as possible, packages such as audacious are not included in the Zenwalk installation disc. These additional packages are retrieved separately from one of the package mirrors. Open a terminal and it's easy to download and install any Zenwalk package (in this case, audacious) using the command line:
# netpkg audacious
Or, if removing:
# netpkg -remove audacious
That's about all there is to installing or removing applications Zenwalk maintains.
Maintaining Previous Versions
As noted above, Zenwalk releases entirely new distributions once or twice a year. What if I don't want to upgrade my entire operating system, but I still want to install applications? For example, suppose I've had Zenwalk 6.0 installed for a year before I remember I want to install audacious. I try to netpkg audacious but, when I do, I discover Zenwalk has upgraded to v.6.4. If I try to install the newer version of audacious, netpkg asks to upgrade portions of v.6.0. I can let netpkg do this, but maybe I don't want parts of my system to be in 6.4, while other parts are in 6.0. How do I avoid upgrading to 6.4, but still get the packages I want for 6.0?
Three Solutions
Solution a -- install without using netpkg
One can always go to the home page of any application they desire and simply download, unpack, configure, compile, and install the general release tarball (.tgz). In the case of audacious, the home page is http://audacious-media-player.org/. One might want to check for dependencies when doing so.
But a couple of solutions for installing older software can be accomplished inside of the netpkg package manager. Both of these require a small degree of manipulation of the /etc/netpkg.conf file. The second option additionally requires manipulation of the /usr/libexec/netpkg-functions file.
Solution b -- point netpkg to prior release mirrors
For a period of time after a new Zenwalk release, a few mirrors contain the previous release. One must open the /etc/netpkg.conf file with a text editor and manually add URLs for older mirrors. After doing so, I run
# netpkg mirror
and select one of the older mirrors. I found a few prior release URLs listed here, and had success with this mirror: http://viking.zenwalk.org/i486/current-old. Other archive URLs can probably be Googled, but there is a limitation to this solution: archive mirrors trail the current Zenwalk release by only one version. Users therefore only have a grace period of 6 months to a year before they will be forced to upgrade to some extent. The more permanent solution is the one below.
Solution c -- download all desired packages for dvd or other local access
This is a permanent solution, in case one wishes to never upgrade Zenwalk. The catch here is one needs to consider nearly any application they might need, because thinking of it two years later will be too late (if that happens, just use "solution a"). To download all potential applications in a Zenwalk release is roughly 10GB. I then alter netpkg to find the files on my hard drive or a dvd, instead of on a mirror. Alterations include the /etc/netpkg.conf and /usr/libexec/netpkg-functions files. Here are instructions:local repository
Supposedly it's also possible to point to a DVD with everything on it (if Apache is running) with this URL added to /etc/netpkg.conf and selected via # netpkg mirror:
http://localhost:8000
!! For "solution c", it's necessary to download PACKAGES.txt and PACKAGES.txt.gz/ from the mirror. Netpkg appears unable to traverse directories to locate packages without these meta-information files. Get these files before the previous release mirrors move to a newer release or face recreating them manually, a time-consuming, nearly prohibitive task.
Tuesday, February 10, 2009
toshiba l305d-s5869 - more video
Last September, I posted about picking up one of these Toshibas. At that time, the RS780 (HD3100) ATI/Radeon video chip was problematic, and may pose some additional problems. However, currently it appears the radeonhd driver has finally matured enough to supplant the proprietary fglrx driver which seemed to only provide software rendering.
fglrx driver
fglrx installation
radeonhd download and install
ati chip audio considerations
1. Back-up the working xorg.conf in etc/X11.
2. Regardless if going forward with a newer fglrx driver, or some other driver, such as the radeonhd driver, remove the outdated fglrx driver to avoid conflicts.
3. Install git from respository or source.
4. Decide whether to install fglrx or radeonhd.
4a. fglrx driver
4b. (Radeonhd)
More coming, need some sleep
links
fglrx driver
fglrx installation
radeonhd download and install
ati chip audio considerations
steps
1. Back-up the working xorg.conf in etc/X11.
2. Regardless if going forward with a newer fglrx driver, or some other driver, such as the radeonhd driver, remove the outdated fglrx driver to avoid conflicts.
# cd /usr/share/ati
# sh fglrx-uninstall.sh
3. Install git from respository or source.
4. Decide whether to install fglrx or radeonhd.
4a. fglrx driver
4b. (Radeonhd)
# git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd
# cd xf86-video-radeonhd
# autogen.sh --prefix=/usr/
# make
# make install
# gtf 1280 800 60 -x (or whatever the native resolution and refresh)
# nano /etc/X11/xorg.conf
More coming, need some sleep
Saturday, September 27, 2008
zenwalk 5.2 in Toshiba Satellite (L305D-S5869)
2022 update
The original post from 2008 is at the bottom, but I just couldn't help wanting this dinosaur alive. NB: You must get the replacement battery for the model S5869 which is 11.1 VDC, not the 10.8 VDC of most replacements. I could not get the laptop to boot with a 10.8VDC battery.
battery and sdd
- $0 CMOS battery: run down, but I don't have an adjustable soldering iron right now, so I installed ntp and ran
# ntpdate pool.ntp.org
right after connecting to my local router - $19 battery: an inexpensive Chinese "TA3533LH" Li-Ion, 5200mAh, 6 cell. However, when I received it, it was for the
- $15 hdd -> ssd: I'd read somewhere that SATAIII was backwards compatible with SATAI and II, so I simply bought a new drive and moved stuff over.
- $0 OS: The latest version of Arch worked fine with the old hardware.
From 2008
These were on-sale recently (9/25) at Fry's and seemed like a good deal although it's understood the Linux factor might be difficult with ATI video and so on. Still for $400:
15.4 WXGA
AMD Athlon 64 X2 Dual Core
1024 MB PC6400 SDRAM
Radeon 3100HD (RS780) w/VGA out
Atheros AR5007EG (wifi)
Realtek RTL8102E (ethernet)
Realtek ALC268 (sound)
120GB 5400 RPM SATA 2.5"
DVD RW, PCMCIA, SD port
3xUSB 2.0
No bluetooth or videocamera
Booted into pre-installed Windows Vista first. The return policy is 15 days for laptops and specifies software and hardware must remain unmodified. After verification of hardware features, I blew out the unbelievably bloaty factory load, dropped in a boot disk, formatted, and mke2fs /dev/sda1. Nice.
Slackware 12.0
I had a Slack 12.0 DVD gathering dust available and Slackware is my favorite. However, errors appeared on installation and it seemed an extensive parameter set was required to tame them:
#boot nosmp noapic irqpollTo me, these problems meant that, if I continued with the Slack install on the newer hardware, I might be compiling and patching over the weekend, or that I should download and burn Slack 12.1 and begin there. I also had a copy of Slackware-based Zenwalk (formerly Minislack) 5.2 which possessed a newer kernel and a supposedly candy-coated installation process. Choices.
Zenwalk 5.2
Installed smoothly with only irqpoll needed as a parameter.
Atheros AR242x 64 (5007 chipset)
The instructions here were helpful for understanding this newer card. Zenwalk provides ath5k, but it wasn't going well. The Madwifi site has information on ath5k here, and it appears the ath5k module will eventually be effective. Currently however, the steps which worked were:
1. in /etc/modprobe.d/blacklist, blacklist the "ath5k" module
2. reboot and lsmod - make sure the ath5k is gone
3. download madwifi-hal-0.10.5.6-r3861-20080903.tar.gz , or the newest one there, make, and install.
4. reboot again and lsmod
5. iwconfig ath0
WEP and WPA
WEP is trivial, merely need the two iwconfig commands "essid" and "key restricted" to make it work. WPA, on the other hand, is a separate post. It only took 10 minutes to configure, but the description is too long for this overview. If one has a distro which requires kernel modification for WPA, the process becomes longer. This site seems to explain it t I'm also currently building a chart for easier understanding based on this site.
screen brightness and gamma
The default settings for screen brightness and backlighting install maxed at 100%, and the Fn buttons don't seem to work except in Windows - battery life, screen life, eyestrain. Without going into X, one has command-line control over the brightness. Look in /proc/acpi/video/VGA/LCD/brightness to see the possible brightness settings for the card, such as 25, 50, 75%, and so on. I like 25%, so:
#echo -n 25 > /proc/acpi/video/VGA/LCD/brightnessIt appears we cannot change the backlighting outside of X, though I haven't researched. Once in X however, open a terminal and select any number between 0.00 and 1.0 for gamma, eg:
xgamma -gamma 0.75
Realtek ALC268 Sound
Some duplicate alsamixer settings were seen. For example, alsamixer showed two microphone capture bars when only one channel was connected. I went to the Realtek downloads site, clicked a link there to the "HD Audio Codec Driver", and agreed to licensing language. After download and unpacking, it turned out this was the latest release of ALSA, so it basically installs the latest ALSA, but apparently with a newer HD driver. The alsamixer showed proper inputs following this ALSA update. and so, after setting levels, it was time for # alsactl store.
Radeon 3100HD RS780MC
Initially, Zenwalk loaded the vesa driver in /etc/xorg.conf, providing resolutions of 800x600. Common sense and #gtf seemed to indicate higher resolutions were available. In /etc/xorg.conf, I replaced "vesa" with, alternately, "ati", "radeon", and "radeonhd"; these did nothing but break X. I then relented for the proprietary driver "fglrx" described on most blogs as bloaty and slow, but operational. The driver was avialable here by selecting the Linux x86_64 -> Radeon -> ATI Radeon HD 3xxx Series and pressing "go". One note about installing this - I received checksum errors when I attemped to install it with #. ati*; I had to explicitly invoke bash #bash ati*. However, following this installation, I simply replaced "vesa" with "fglrx" in the Device section of /etc/X11/xorg.conf, rebooted, and everything worked. With the vesa-fglrx swap, the /etc/X11/xorg.conf file looks like this:
Section "Device"Adjustments to the fglrx module "Options" can come some other weekend; resolution and display appear sharp currently.
Identifier "Videocard1"
VendorName "ATI Technologies Inc"
BoardName "Video device"
Driver "fglrx"
BusID "PCI:1:5:0"
Option "RenderAccel" "true"
EndSection
additional fglrx considerations for the Radeon 3100HD R5780MC
The fglrx driver, although supplied by Radeon, does appear to have significant Googleland complaints for slowness. For me, it renders well, but very slowly: I'm experience update lines even scrolling through a simple text page on Mousepad, etc. So, it appears something either a)very inefficient, or b)very underpowered, is taking place in terms of memory usage with the fglrx driver. From Google, it appears there are a few things to investigate: 1) does flglrx load as a module? (lsmod |grep fglrx). Mine does not appear in lsmod, and this apparently means xorg.conf loads a substandard fglrx_drv.ko module. Lsmod failed to locate this module either. Odd. 2) Settings in /etc/X11/xorg.conf for the fglrx driver, under "Options" may be important. 3)Settings (don't know syntax or location) for whether the ATI card uses SIDEPORT mode (card uses its own memory),UMA mode (card shares system memory), or another unnamed mode where it uses a mix of SIDEPORT and UMA. One thing for sure, a lifesaver in these forum boards is fglrxinfo or fglrxinfo -v:
# fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0.3)
glxinfo is also important. On my system, glx is not enabled, though this may be a different problem than the overall slowness of screen panning and scrolling that I'm experiencing. A good forum thread for these issues is here, not for solutions but for the many aspects of the problem.
netpkg repos
Each time zenwalk is released, the repositories update to the most current release so that, if one needs a certain package, they generally have to update the rest of their system to be in sync with it. Suppose I like my release and just want to keep it into perpetuity. As long as 1) I have the installation disk 2) have netpkg'ed all the programs from that release I want (they download to /var/packages), and 3) have downloaded a copy of PACKAGES.TXT.gz, I can point netpkg to /var/packages and use the older release. A couple of simple modifications are required with two configuration files since netpkg doesn't inherently recognize URLs of the type "file:///". This link describes the changes to the two files, /usr/libexec/netpkg-functions and /etc/netpkg.config files, which I repeat here.
if [ $( echo "$url" | egrep -e "ftp:.*|http:.*|file:.*" ) ]; then
if [ ! "$(echo $mirror | egrep 'http://|ftp://|file://')" ] ; then
Internet_mirror = file:///var/packagesPut a copy of PACKAGES.TXT.gz into /var/packages, and you've got a self-contained distribution.
unsolved: multiple instantiation of mplayer, thunar, etc
Perhaps because of multiple processors, there's currently a problem when using DVD's. Multiple instances of related applications appear, eg 2 x MPlayer or 2 x Thunar. Working around this by disabling automatic HAL events for the time being. Manually opening one instance of the application for now.
Monday, August 18, 2008
Slackware 12.0 - install 1
Intro
Moving from Debian and Debian-based hybrids (eg. Ubuntu) means a different initialization configuration. For me, this was for the better: the straightforward /etc/rc.d layout in Slack (and its hybrids - eg. Zenwalk) is clean and almost intuitive. Another bonus was learning that Slackware doesn't use PAM. Let's look at Slack 12.0 install.
Older Machines
1. boot with non-smp kernel big.s
2. cfdisk, mke2fs, and mkswap per taste.
3."setup"
4. activate disks, including swapon. Skip formatting (done in #2)
5. install from CD's or DVD but don't configure the network
6. reboot, run the patch for non-smp.
7. add group 1000 and user 1000, do a genfstab, etc.
8. reboot, login, and further configure users, groups, fstab, inittab, profile, visudo, modules, other initialization.
9. build nvidia drivers if necessary
10. build wifi drivers if necessary (madwifi, ndiswrapper, other)
11. a second look at modules to /etc/rc.d/rc.modules and any associated commands to /etc/rc.d/rc.local
12. reboot, check dmesg -tail, verify wifi or eth0 (eg. with "route"). To make permanent see here. If box is dual-homed, alter network files appropriately.
13. download and configure xorg.conf or copy premade to /etc/X11/
14. copy /etc/X11/xinit/xinitrc to ~.xinitrc and add desired Windows Manager line at end, eg exec dbus-launch twm
15. reboot, attempt $ startx and tune.
Wireless
No need to download and compile a driver module if one came with distro: Check here:ls /lib/modules/2.6.23.12/kernel/drivers/net/wireless/
Atheros AR242x 64 (5007 chipset)
Memory location on my card for this is 53100000. The instructions here were crucial. The ath5k module doesn't apparently work well in Satellites, however it's described here, and it appears the ath5k will eventually be the way to go. For now, the steps seem to be:- in /etc/modprobe.d/blacklist, blacklist the "ath5k" module
- reboot and lsmod - verify ath5k is gone
- download madwifi-hal-0.10.5.6-r3861-20080903.tar.gz , or the newest one there, make, and install.
- reboot again and lsmod again
- # iwconfig ath0
Atheros AR5005G
download latest madwifi, eg madwifi-0.9.9.3, then the usual$ tar -xzvf madwifi*
$ cd madwifi*
$ make
# make install
# modprobe ath-pci
RaLink RT2600 802.11 MIMO
1. download latest ralink rt61 driver from ralink support.
2. $tar -xzvf 2008*
3. $cd RT61_Linux*
4. $cp Makefile.6 Makefile [kernel 2.6.x]
5. Alter module rtmp_main.c , by commenting out (around the bottom, line ~900):
return pci_module_init(&rt61_driver);
and replace it with:
return pci_register_driver(&rt61_driver)
6. Their "configure" file is not executable, so change it, then configure and make the module.
$chmod 755 Configure
$./Configure
$make
7. Make a directory where the module will locate configuration info and put these info files in it.
# mkdir /etc/Wireless/RT61STA8. The last file to go into that config directory may have CTRL+L line ends and we have to be sure these are eliminated: Use $dos2unix rt61sta.dat (or use sed). This file has the particulars for our LAN and WEP.
# cp rt2561.bin /etc/Wireless/RT61STA/
# cp rt2561s.bin /etc/Wireless/RT61STA/
# cp rt2661.bin /etc/Wireless/RT61STA/
9. Copy that file to where the others are at:
#cp rt61sta.dat /etc/Wireless/RT61STA/
10. Send the module to the kernel's module folder:
#cp rt61.ko /lib/modules/
11. Tell the kernel where to find the module by adding a line in /lib/modules/
12. Load the kernel:
#modprobe rt61
AFTER INSTALLING WIRELESS
1. provide permanence via /sbin/modprobe ath-pci to /etc/rc.d/rc.modules and any configuration for it (eg. iwconfig ath0 essid "loser") to /etc/rc.d/rc.local.
1b: in the case of Ralink /sbin/modprobe rt61 to /etc/rc.d/rc.modules.
2. further modify /etc/rc.d/rc.local to be sure card comes up. Last line for the card: iwconfig ra0 up or iwconfig ath0 up
3. reboot and "dhcpcd ra0" or ath0, check with "route" and a ping.
A NOTE ON PACKAGES
In Slackware, packages typically need to be individually compiled and installed. This leads to dependency problems because individual applications might overwrite or otherwise break dependencies from other packates. Slackware has pkgtool and users are urged to use it whenever possible.
Subscribe to:
Posts (Atom)
