Among some of the oddities that I encountered after upgrading to Ubuntu Jaunty was the fact that its power management skills, compared to Hardy, seem...a bit confused.
In Hardy, I was able to get my laptop's dual CPUs to stay cool and the fan at a low temp by using the CPU Frequency Scaling Monitor tool, a panel app for Gnome. (Of course, I needed to reconfigure a package or two to make it work, but it worked.) What I always thought was odd, though, was the fact that it always seemed to control both CPUs as a single unit. In other words, changing the frequency (or power profile) of one CPU would change the other CPU to match. At the time I figured this was a limitation of the hardware, so I didn't think much of it, and decided just to use 1 cpu monitor app instead of two since I knew that having a monitor for each separate CPU would be pointless.
After upgrading to Jaunty, however, I noticed an odd thing happening after a while: The fan would speed up and the system would get hotter when running a high-power application even though the CPU was set to 'powersave' mode (in other words, 'always-stay-at-minimum-power' mode.). For a long time I thought this was a glitch in Jaunty; Ubuntu THOUGHT it was scaling the CPU down when really it wasn't. But as I recently found out, it was user error...
Apparently, the fact that both processor speeds would change when attempting to change the speed of just one was a problem with Hardy and not the CPU hardware. But I didn't know that, so I had a CPU monitor telling me only half of the truth; one of the CPUs really was running in powersave mode, but the other was still running in ondemand.
Fixing the problem was as simple and obvious as can be: Just add a second CPU monitor for the other processor to the panel.
Wednesday, June 17, 2009
Thursday, June 4, 2009
Sansa Clip Has Special Needs for Media Info
The Sansa Clip is a nice little MP3 player. It's very small and lightweight, and has all the standard features, like playing, stopping, pausing, fast forward, rewind, shuffle, loop, and the ability to locate groups of songs based on artist, album or genre. It also has a built-in FM radio and the ability to record from the radio or from a microphone.
Like many modern MP3 players, it can connect to a computer using a couple of different protocols: MTP and MSC. If you're on Windows and using Windows Media Player to upload and download songs to and from your Sansa Clip, the MTP protocol works just fine. However, if you're on Linux or you want to use software that does not support MTP, then you need to use MSC.
When you tell your Sansa Clip to use the MSC protocal for USB mode, it makes the device act like an ordinary USB flash drive when you plug it in to your computer. This makes uploading songs a simple matter of copying files from your hard drive (or wherever) into the MUSIC folder on your Sansa Clip.
The Clip will play MP3s uploaded via MSC just the same as files uploaded as MTP without any issues. However, unlike the MTP protocol, the MSC protocol does not allow for song meta data (such as song artist, album title, album release year, etc.) to be sent to the Clip. This means that the Clip has to determine such information by reading the ID3 tags of MP3 files uploaded to it. This is where problems come in.
Many modern compressed audio formats, most notably MP3, contain information about the audio they contain (called "meta data") in the form of "ID3 tags." These tags are small pieces of text that are tacked on to the beginning or end of an MP3 file and give the name of the artist who wrote the song, the album that the song was release in, the year the album was released, and possibly a few other things.
There are several different versions of ID3 tags now. But for some reason, the Sansa Clip only supports version 2.3 with a latin1 encoding, or at least that's the only version I've got working with the Clip. Unfortunately, this format is fairly old and many CD ripping tools won't use it, favoring the newer 2.4 or 3.x versions instead. This means that MP3s ripped from CDs using such ripping tools will not sort correctly in the Clip's internal media browser, only appearing in the "Unknown" category for either Artist or Album. This makes locating songs rather bothersome.
To fix this problem, you need to convert the tags of ripped MP3s to version 2.3 with latin1 encoding. There many ways to do this, but the way I have had the most luck with is to use a Linux tool called "eyeD3". On Ubuntu, this can be installed using the following command:
One you have it installed, you can
where "some_song.mp3" is replaced with the file name of any MP3 in the directory. This will output a bunch of information, among which you should be able to see which version of ID3 the MP3 is using.
To change the ID3 tags of all the MP3s in the directory to version 2.3 with latin1 encoding, do this:
NOTE: This will actually modify the MP3 files, though the audio itself will remain unchanged.
After changing the tags, you should be able to see the artist, album, year, etc. from the Clip just like songs uploaded via MTP.
Another piece of software you might want to try out is "easytag." It is a sophisticated GUI-based tool for changing the ID3 tags of many MP3s at once and supports ID3v2.3, 2.4, and 3.x.
Like many modern MP3 players, it can connect to a computer using a couple of different protocols: MTP and MSC. If you're on Windows and using Windows Media Player to upload and download songs to and from your Sansa Clip, the MTP protocol works just fine. However, if you're on Linux or you want to use software that does not support MTP, then you need to use MSC.
When you tell your Sansa Clip to use the MSC protocal for USB mode, it makes the device act like an ordinary USB flash drive when you plug it in to your computer. This makes uploading songs a simple matter of copying files from your hard drive (or wherever) into the MUSIC folder on your Sansa Clip.
The Clip will play MP3s uploaded via MSC just the same as files uploaded as MTP without any issues. However, unlike the MTP protocol, the MSC protocol does not allow for song meta data (such as song artist, album title, album release year, etc.) to be sent to the Clip. This means that the Clip has to determine such information by reading the ID3 tags of MP3 files uploaded to it. This is where problems come in.
Many modern compressed audio formats, most notably MP3, contain information about the audio they contain (called "meta data") in the form of "ID3 tags." These tags are small pieces of text that are tacked on to the beginning or end of an MP3 file and give the name of the artist who wrote the song, the album that the song was release in, the year the album was released, and possibly a few other things.
There are several different versions of ID3 tags now. But for some reason, the Sansa Clip only supports version 2.3 with a latin1 encoding, or at least that's the only version I've got working with the Clip. Unfortunately, this format is fairly old and many CD ripping tools won't use it, favoring the newer 2.4 or 3.x versions instead. This means that MP3s ripped from CDs using such ripping tools will not sort correctly in the Clip's internal media browser, only appearing in the "Unknown" category for either Artist or Album. This makes locating songs rather bothersome.
To fix this problem, you need to convert the tags of ripped MP3s to version 2.3 with latin1 encoding. There many ways to do this, but the way I have had the most luck with is to use a Linux tool called "eyeD3". On Ubuntu, this can be installed using the following command:
sudo apt-get install eyed3One you have it installed, you can
cd to the directory that contains the MP3s whose ID3 tags you want to convert, then issueeyeD3 -v some_song.mp3where "some_song.mp3" is replaced with the file name of any MP3 in the directory. This will output a bunch of information, among which you should be able to see which version of ID3 the MP3 is using.
To change the ID3 tags of all the MP3s in the directory to version 2.3 with latin1 encoding, do this:
eyeD3 --to-v2.3 --set-encoding=latin1 --force-update *.mp3NOTE: This will actually modify the MP3 files, though the audio itself will remain unchanged.
After changing the tags, you should be able to see the artist, album, year, etc. from the Clip just like songs uploaded via MTP.
Another piece of software you might want to try out is "easytag." It is a sophisticated GUI-based tool for changing the ID3 tags of many MP3s at once and supports ID3v2.3, 2.4, and 3.x.
Sunday, May 3, 2009
A Quick, Semi-Fix for a Broken "R" button on the Game Boy Advance SP
A while back the R button on my Game Boy Advance SP stopped responding. I called Nintendo and they said it would be cheaper to buy new one than it would be to have them fix or replace the one I had because it was waaay past warranty. So, I decided to try fixing it myself.
The first thing I did was buy a special Y-shaped (tri-wing) screwdriver. This was actually pretty easy to find using eBay, and it was really cheap: less than $5.00 USD including shipping costs and insurance. It got here within a week of purchase.
The problem with the L and R buttons on the SP is that the plastic gets worn over time and the external "shoulder pads" no longer completely press the real, internal buttons that extend out from the motherboard.
To fix this issue, my plan was to affix some electrical tape to the inside of the shoulder pads so that there would be a bit more pressure between them and the internal button. But let me warn you right now: This method may work with a lot of tweaking, but I never got it to work.
Nonetheless, here's what to do to get to the L and R buttons. NOTE: This will void your warranty, meaning you will not be able to return your SP to the store or get it fixed/replaced by Nintendo! Make sure to read these instructions ALL THE WAY THROUGH before beginning, or you could really mess something up!
1.) If there is a cartridge, take it out. This will reveal a small Y-shaped screw near the cart slot.
2.) Take the battery cover off with a miniature Phillips-head screwdriver. (I had one leftover from an extended battery pack kit that I bought a while back.) Remove the battery to reveal a another Y-shaped screw.
3.) There is no step three. :)
4.) At each corner of the bottom of the SP there should be a Y-shaped screw. Combined with the two above, there is a total of 6 screws that need to be removed (not counting the one on the battery cover). Simply remove all the screws with the Y-shaped screwdriver and set them aside. (Careful, they're really small and easy to lose!). The back of the SP will now be loose, so be careful not to let it fall off.
5.) With the bottom of the SP facing down, carefully pull the top, including the screen, controls, and motherboard, off of the bottom. It should all come off in one piece, but the L and R shoulders may stick to the top and the joint pins may fall out, so be ready to catch them. This will expose the backside of the SP's motherboard, including the CPU, so be very careful not to damage anything!
6.) The L and R outer buttons are wedged between the top and bottom halves of the SP's casing and each is spring-loaded using a mechanism involving a short, thick metal pin and a thin, wiry spring through which is "wrapped" around the pin. Once the back of the casing is removed, there's very little to hold all the pieces of this mechanism in place, so if you turn the back upside down it will likely fall apart. It's not too hard to get them back together again, but chances are, this will make BOTH the shoulder buttons stop working for good!!! You have been warned.
Under each shoulder button is a small, round internal button about the size of a point from a Sharpie marker. You can press these in to hear them click. These are the "true" L and R buttons, and you need only press these to make the SP react. However, they seem to require a certain amount and angle of pressure that the outer shoulder buttons fail to provide after a while of use. You can try fixing this by wedging things between the outer and inner buttons, but I didn't have much success that way. Instead, I merely removed the outer buttons completely so that I could press the internal buttons directly. I didn't spot any electrical contacts near the internal buttons, but I can't be positive, so I can't guarantee that this is completely safe either for you or your SP...but hey, it basically works.
7.) When reassembling the SP, make sure that the power switch did not fall out. If it did, putting it back in is a fairly simple matter; just stick it back into the bottom half of the casing and slide it back and forth to make sure it clicks between the "on" and "off" positions.
8.) Put the casing back on the bottom of the SP, making sure all the stuff fits into the right grooves. Lay the SP upside down and screw the Y screws back in, but make sure not to confuse the corner screws with the smaller screws that come from behind the battery and game cart slot.
Now you have an SP with its internal L and R buttons exposed. You have to stick your fingers inside the holes at the corners to get to them and its a bit uncomfortable after a while, but they work.
The first thing I did was buy a special Y-shaped (tri-wing) screwdriver. This was actually pretty easy to find using eBay, and it was really cheap: less than $5.00 USD including shipping costs and insurance. It got here within a week of purchase.
The problem with the L and R buttons on the SP is that the plastic gets worn over time and the external "shoulder pads" no longer completely press the real, internal buttons that extend out from the motherboard.
To fix this issue, my plan was to affix some electrical tape to the inside of the shoulder pads so that there would be a bit more pressure between them and the internal button. But let me warn you right now: This method may work with a lot of tweaking, but I never got it to work.
Nonetheless, here's what to do to get to the L and R buttons. NOTE: This will void your warranty, meaning you will not be able to return your SP to the store or get it fixed/replaced by Nintendo! Make sure to read these instructions ALL THE WAY THROUGH before beginning, or you could really mess something up!
1.) If there is a cartridge, take it out. This will reveal a small Y-shaped screw near the cart slot.
2.) Take the battery cover off with a miniature Phillips-head screwdriver. (I had one leftover from an extended battery pack kit that I bought a while back.) Remove the battery to reveal a another Y-shaped screw.
3.) There is no step three. :)
4.) At each corner of the bottom of the SP there should be a Y-shaped screw. Combined with the two above, there is a total of 6 screws that need to be removed (not counting the one on the battery cover). Simply remove all the screws with the Y-shaped screwdriver and set them aside. (Careful, they're really small and easy to lose!). The back of the SP will now be loose, so be careful not to let it fall off.
5.) With the bottom of the SP facing down, carefully pull the top, including the screen, controls, and motherboard, off of the bottom. It should all come off in one piece, but the L and R shoulders may stick to the top and the joint pins may fall out, so be ready to catch them. This will expose the backside of the SP's motherboard, including the CPU, so be very careful not to damage anything!
6.) The L and R outer buttons are wedged between the top and bottom halves of the SP's casing and each is spring-loaded using a mechanism involving a short, thick metal pin and a thin, wiry spring through which is "wrapped" around the pin. Once the back of the casing is removed, there's very little to hold all the pieces of this mechanism in place, so if you turn the back upside down it will likely fall apart. It's not too hard to get them back together again, but chances are, this will make BOTH the shoulder buttons stop working for good!!! You have been warned.
Under each shoulder button is a small, round internal button about the size of a point from a Sharpie marker. You can press these in to hear them click. These are the "true" L and R buttons, and you need only press these to make the SP react. However, they seem to require a certain amount and angle of pressure that the outer shoulder buttons fail to provide after a while of use. You can try fixing this by wedging things between the outer and inner buttons, but I didn't have much success that way. Instead, I merely removed the outer buttons completely so that I could press the internal buttons directly. I didn't spot any electrical contacts near the internal buttons, but I can't be positive, so I can't guarantee that this is completely safe either for you or your SP...but hey, it basically works.
7.) When reassembling the SP, make sure that the power switch did not fall out. If it did, putting it back in is a fairly simple matter; just stick it back into the bottom half of the casing and slide it back and forth to make sure it clicks between the "on" and "off" positions.
8.) Put the casing back on the bottom of the SP, making sure all the stuff fits into the right grooves. Lay the SP upside down and screw the Y screws back in, but make sure not to confuse the corner screws with the smaller screws that come from behind the battery and game cart slot.
Now you have an SP with its internal L and R buttons exposed. You have to stick your fingers inside the holes at the corners to get to them and its a bit uncomfortable after a while, but they work.
Curing Jaunty's Fear of Touchpads.
Actually, I had one issue with upgrading to Ubuntu Jaunty, and it's an issue that has been reported by a number of people: A number of laptop touchpads no longer work out-of-the-box.
Apparently, this is some kind of bug with the X server's input drivers that needs to be fixed. It affects people whose touchpad is reported by the output of the command "
There are a couple of ways to get around this issue.
1.) Use an external mouse (because external mice don't seem to be affected by the bug), or
2.) Change the mouse driver options. There is a script for this given below.
Before I give you the script, however, please note the following:
a.) Run the script from a TTY terminal, and NOT from a X terminal emulator like xterm or gnome-terminal. If you don't, there is a chance that the X server will freeze, forcing you to restart.
b.) Run the script with ROOT PRIVELAGES by adding `sudo` to the beginning of each line, or else putting the lines into a file and executing that file with root privelages.
c.) As a side effect, this script will disable some options from the Gnome mouse configuration menu. If after running the script you find that some options were disabled that you needed to use, you can undo the changes by running the second script below.
Here is the script to enable the alternate mouse driver settings:
Here is the script to undo the changes made by the script above:
Again, make sure to run those with root privileges from the TTY command line and not from an X terminal.
As far as I can tell, what this basically does is unload the mouse drivers from memory and then load them back again using a different set of options that make it detect the mouse hardware differently. Then, it adds an option to the system configuration that makes sure that the mouse driver is always loaded with the new options whenever the system boots, making the changes permanent. The other script does the opposite.
I adapted these scripts from a solution given by a bug report by Ricardo Faria which was linked to by Matataki on the Ubuntu forums. Thanks, guys!
Sources:
* Touchpad not working (Jaunty)
* [Jaunty] synaptics driver needs to be updated [...]
Apparently, this is some kind of bug with the X server's input drivers that needs to be fixed. It affects people whose touchpad is reported by the output of the command "
xinput list" as "ETPS/2 Elantech Touchpad" or "SynPS/2 Synaptics TouchPad".There are a couple of ways to get around this issue.
1.) Use an external mouse (because external mice don't seem to be affected by the bug), or
2.) Change the mouse driver options. There is a script for this given below.
Before I give you the script, however, please note the following:
a.) Run the script from a TTY terminal, and NOT from a X terminal emulator like xterm or gnome-terminal. If you don't, there is a chance that the X server will freeze, forcing you to restart.
b.) Run the script with ROOT PRIVELAGES by adding `sudo` to the beginning of each line, or else putting the lines into a file and executing that file with root privelages.
c.) As a side effect, this script will disable some options from the Gnome mouse configuration menu. If after running the script you find that some options were disabled that you needed to use, you can undo the changes by running the second script below.
Here is the script to enable the alternate mouse driver settings:
#!/bin/bash
modprobe -r psmouse
modprobe psmouse proto=imps
echo "modprobe psmouse proto=imps" >> /etc/modprobe.d/touchpadfix.conf
Here is the script to undo the changes made by the script above:
#!/bin/bash
modprobe -r psmouse
modprobe psmouse
rm /etc/modprobe.d/touchpadfix.conf
Again, make sure to run those with root privileges from the TTY command line and not from an X terminal.
As far as I can tell, what this basically does is unload the mouse drivers from memory and then load them back again using a different set of options that make it detect the mouse hardware differently. Then, it adds an option to the system configuration that makes sure that the mouse driver is always loaded with the new options whenever the system boots, making the changes permanent. The other script does the opposite.
I adapted these scripts from a solution given by a bug report by Ricardo Faria which was linked to by Matataki on the Ubuntu forums. Thanks, guys!
Sources:
* Touchpad not working (Jaunty)
* [Jaunty] synaptics driver needs to be updated [...]
Upgrading to Ubuntu 9.04 (Jaunty Jackalope) with a Fresh Install
Well, I haven't had much to say in a while, which is unfortunately something I'm well known for. But for this blog at least, I'm going to try to change that.
For the last few days my install of Ubuntu 8.04 Studio Edition has been acting completely wonky for no obvious reason--sound systems not working, random freezes, abnormally sluggish behavior, freezing after waking up--all signs of a corrupted OS. I don't know what I did, but I must have broken something.
At this time I realized three important things:
1.) My computer was fudged.
2.) I really need this fixed.
3.) It's the weekend.
This got me to thinking: Hey, this would be a great time to give Intrepid another go! So I did.
I don't know if I mentioned this before, but I recently upgraded my laptop's HDD to a 250GB SATA, a huge improvement over the original 80GB SATA. This made it possible for me to create a separate partition for the OS and still have lots of room left over for my personal data (i.e. put /home on its own partition). With this setup, upgrading is a lot more safe because I can easily remove the OS without fear of damaging years worth of precious personal data.
I decided to do a fresh install to Intrepid rather than an upgrading through the usual tools because experience has told me that upgrading from one version of an OS to another almost never works the way its supposed to, and tends to create a lot of unwanted work. This is true not only for Ubuntu, but for any OS, as I have heard.
Installing Intrepid this time around with a simple matter of popping the CD in and telling the installer to reformat /dev/sda2 for the OS but keep /dev/sda3 for data. There was a slight hiccup with getting connected to the wifi network, but after getting the latest system updates for 8.10 that basically went away.
Then I realized that Jaunty has been out for about a month now. Well, dang!
I figured I might as well install Jaunty, even though I just spent an hour or so installing Intrepid--better now then later when I've made all my customizations. I downloaded the CD (quickly, too; I must have gotten to the server at a good time of day), burned it, and kept it in the tray while I rebooted.
The CD wouldn't boot. I just got a message saying "syslinux loading..." (or something to that effect) and it just froze there. Not sure why this happened, because the CD booted fine on the family desktop. In any case, I didn't feel like checking the CD for defects, so I decided to try a different route: Network installation.
Net installing wasn't actually as hard as I thought, and it didn't require a single disc (or disk). However, it did require another computer on the network; in this case, the family desktop running Windows XP.
The procedure is as follows:
1.) Download TFTPD32. This is a free TFTP server for Windows that will serve out the files needed to boot the Ubuntu net installer. If you plan on using this and then forgetting about it (like I did) then just download and extract the .zip version into a folder you have access to.
2.) Use Windows Explorer or an FTP client to download the installation files from the Ubuntu FTP archive. This will be a folder called "netboot" containing files of various types. I'm not sure exactly what the installed needs from this, so its best to download the whole folder. For the i386 version of Jaunty, the folder is located here at this URL:
ftp://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/ .
(For other versions, you may need to navigate up to a higher level and locate the necessary files. The archive is organized pretty well, so it shouldn't be to hard to find what you need.)
3.) From the local copy of netboot\, locate the folder called ubuntu-installer\ and copy the entire thing into the same directory as the TFTPD32 executable (.exe) file. (Note: Do not copy the CONTENTS of the folder, copy the folder itself!
4.) In the same way as above, copy the folder pxelinux.cfg\ and the file pxelinux.0 into the TFTP folder.
5.) Start the TFTPD32 executable with admin rights. Make sure that your firewall is either disabled or else configured to let TFTPD32 connect to whatever it wants.
6.) Find the DHCP tab in the TFTP window and configure it for your network. This is going to vary from computer to computer. My network has a central 4-port switch/wifi router that functions as the main gateway to the Internet and probably also functions as the WINS server (whatever that is) and its IP address is 192.168.1.1 on my LAN, so I used the following settings:
IP Pool starting address: 192.168.1.100
Size of pool: 50
Boot file: pxelinux.0
WINS/DNS server: 192.168.1.1
Default router: 192.168.1.1
Mask: 255.255.255.0
Domain name: (this was left blank)
Additional option: 0 (second field left blank)
Then I clicked "S a v e".
(The address 192.168.1.1 above should be replaced with the IP of your network's main gateway, though 192.168.1.1 is usually the default.)
7.) Optionally, click the second "log" tab so you can see what your target computer is about to do.
8.) Boot up the computer you are going to install Jaunty onto and configure the BIOS to boot from LAN/use PXE bios. This will vary wildly from computer to computer, so you're on your own for this part.
9.) Plug the computer into the same network that the TFTPD-running computer is serving from and restart it. (I mean restart the one you're trying to install Jaunty to, not the one running TFTPD.) If the BIOS was configured correctly, and if TFTPD is running and is not being blocked by any firewall, the Jaunty-to-be computer should load the PXE files and you will see the familiar Ubuntu logo.
10.) Press "enter" to enter the interactive, text-mode installer.
11.) At this point you can probably close TFTPD. On my system I had to because, the idiot that I am, I had my DHCP settings conflicting with the settings of my router, making it difficult to connect to the Internet.
At this point my particular set of choices were different from what most people's would be. I first told the installer to use /dev/sda1 for swap, /dev/sda2 for the root filesystem (/), and /dev/sda3 for personal data (/home/). I decided to give the new ext4 filesystem a try for my root, but obviously I left the /home/ partition alone (i.e. opted to NOT format it).
Next, I selected the software packages I wanted, and began installing. However, for whatever reason, installation failed unless I only picked the default Ubuntu Desktop collection (and, of course, the core Linux files). But that wasn't a problem; I merely installed the other packages later after the net install was over.
From there, everything worked like a charm, and I have to say, Jaunty is NICE! And guess what? They finally fixed whatever it was that kept causing my system to freeze after resuming from suspend-to-ram while using Compiz! Excellent! Now I can finally go fully-Compiz!
EDIT: Actually, I did have one minor issue upon upgrading. However, a solution to the issue was found the next morning. See the following entry: Curing Jaunty's Fear of Touchpads.
For the last few days my install of Ubuntu 8.04 Studio Edition has been acting completely wonky for no obvious reason--sound systems not working, random freezes, abnormally sluggish behavior, freezing after waking up--all signs of a corrupted OS. I don't know what I did, but I must have broken something.
At this time I realized three important things:
1.) My computer was fudged.
2.) I really need this fixed.
3.) It's the weekend.
This got me to thinking: Hey, this would be a great time to give Intrepid another go! So I did.
I don't know if I mentioned this before, but I recently upgraded my laptop's HDD to a 250GB SATA, a huge improvement over the original 80GB SATA. This made it possible for me to create a separate partition for the OS and still have lots of room left over for my personal data (i.e. put /home on its own partition). With this setup, upgrading is a lot more safe because I can easily remove the OS without fear of damaging years worth of precious personal data.
I decided to do a fresh install to Intrepid rather than an upgrading through the usual tools because experience has told me that upgrading from one version of an OS to another almost never works the way its supposed to, and tends to create a lot of unwanted work. This is true not only for Ubuntu, but for any OS, as I have heard.
Installing Intrepid this time around with a simple matter of popping the CD in and telling the installer to reformat /dev/sda2 for the OS but keep /dev/sda3 for data. There was a slight hiccup with getting connected to the wifi network, but after getting the latest system updates for 8.10 that basically went away.
Then I realized that Jaunty has been out for about a month now. Well, dang!
I figured I might as well install Jaunty, even though I just spent an hour or so installing Intrepid--better now then later when I've made all my customizations. I downloaded the CD (quickly, too; I must have gotten to the server at a good time of day), burned it, and kept it in the tray while I rebooted.
The CD wouldn't boot. I just got a message saying "syslinux loading..." (or something to that effect) and it just froze there. Not sure why this happened, because the CD booted fine on the family desktop. In any case, I didn't feel like checking the CD for defects, so I decided to try a different route: Network installation.
Net installing wasn't actually as hard as I thought, and it didn't require a single disc (or disk). However, it did require another computer on the network; in this case, the family desktop running Windows XP.
The procedure is as follows:
1.) Download TFTPD32. This is a free TFTP server for Windows that will serve out the files needed to boot the Ubuntu net installer. If you plan on using this and then forgetting about it (like I did) then just download and extract the .zip version into a folder you have access to.
2.) Use Windows Explorer or an FTP client to download the installation files from the Ubuntu FTP archive. This will be a folder called "netboot" containing files of various types. I'm not sure exactly what the installed needs from this, so its best to download the whole folder. For the i386 version of Jaunty, the folder is located here at this URL:
ftp://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/ .
(For other versions, you may need to navigate up to a higher level and locate the necessary files. The archive is organized pretty well, so it shouldn't be to hard to find what you need.)
3.) From the local copy of netboot\, locate the folder called ubuntu-installer\ and copy the entire thing into the same directory as the TFTPD32 executable (.exe) file. (Note: Do not copy the CONTENTS of the folder, copy the folder itself!
4.) In the same way as above, copy the folder pxelinux.cfg\ and the file pxelinux.0 into the TFTP folder.
5.) Start the TFTPD32 executable with admin rights. Make sure that your firewall is either disabled or else configured to let TFTPD32 connect to whatever it wants.
6.) Find the DHCP tab in the TFTP window and configure it for your network. This is going to vary from computer to computer. My network has a central 4-port switch/wifi router that functions as the main gateway to the Internet and probably also functions as the WINS server (whatever that is) and its IP address is 192.168.1.1 on my LAN, so I used the following settings:
IP Pool starting address: 192.168.1.100
Size of pool: 50
Boot file: pxelinux.0
WINS/DNS server: 192.168.1.1
Default router: 192.168.1.1
Mask: 255.255.255.0
Domain name: (this was left blank)
Additional option: 0 (second field left blank)
Then I clicked "S a v e".
(The address 192.168.1.1 above should be replaced with the IP of your network's main gateway, though 192.168.1.1 is usually the default.)
7.) Optionally, click the second "log" tab so you can see what your target computer is about to do.
8.) Boot up the computer you are going to install Jaunty onto and configure the BIOS to boot from LAN/use PXE bios. This will vary wildly from computer to computer, so you're on your own for this part.
9.) Plug the computer into the same network that the TFTPD-running computer is serving from and restart it. (I mean restart the one you're trying to install Jaunty to, not the one running TFTPD.) If the BIOS was configured correctly, and if TFTPD is running and is not being blocked by any firewall, the Jaunty-to-be computer should load the PXE files and you will see the familiar Ubuntu logo.
10.) Press "enter" to enter the interactive, text-mode installer.
11.) At this point you can probably close TFTPD. On my system I had to because, the idiot that I am, I had my DHCP settings conflicting with the settings of my router, making it difficult to connect to the Internet.
At this point my particular set of choices were different from what most people's would be. I first told the installer to use /dev/sda1 for swap, /dev/sda2 for the root filesystem (/), and /dev/sda3 for personal data (/home/). I decided to give the new ext4 filesystem a try for my root, but obviously I left the /home/ partition alone (i.e. opted to NOT format it).
Next, I selected the software packages I wanted, and began installing. However, for whatever reason, installation failed unless I only picked the default Ubuntu Desktop collection (and, of course, the core Linux files). But that wasn't a problem; I merely installed the other packages later after the net install was over.
From there, everything worked like a charm, and I have to say, Jaunty is NICE! And guess what? They finally fixed whatever it was that kept causing my system to freeze after resuming from suspend-to-ram while using Compiz! Excellent! Now I can finally go fully-Compiz!
EDIT: Actually, I did have one minor issue upon upgrading. However, a solution to the issue was found the next morning. See the following entry: Curing Jaunty's Fear of Touchpads.
Saturday, January 17, 2009
Have Caution when Upgrading to Ubuntu 8.10, Intrepid Ibex
For a while now I thought I was running Ubuntu 8.10 (Intrepid). Recently, however, I found out I was actually still running 8.01 (Hardy). Thanks a lot, LTS edition... (sarcasm)
Anyway, as soon as I found out, I upgraded. Immediately. *Without even backing up.* That was a mistake.
See, I was thinking the upgrade process would be smooth sailing...and for the most part, it was. Unfortunately, my highly-customized system wasn't quite ready for it, and a number of odd problems popped up post upgrade. What's more, a number of those problems apparently had nothing to do with my customizations; they appeared all on their own:
1.) A number of GConf settings relating to global keyboard shortcuts were, how should I say, "invalidated." That is, a lot of my custom keyboard shortcuts (the kind that can only be set manually through GConf keys) were no longer valid because the names of certain keyboard modifiers were changed. For example, "" was replaced with "". Seeing as nearly every letter key on my keyboard had been mapped to a shortcut when paired with and not , typing became very difficult; every time I pressed "F" I would get a new FireFox window, every time I pressed "G" Gimp started up, and so on. Seeing as I was unable to actually type "Mod4", it was very difficult to change all the "Supers" to "Mod4". (I managed to do it, though.)
2.) For some reason, nearly all the extra keys on my keyboard (such as Media, Play/Pause, Stop, Volume Up/Down, Mute, etc.) ceased to function altogether--it was like they weren't even there anymore. Also, the Favorites button was remapped to Stop. I wasn't able to fix this.
3.) This one was truly bizarre: Every time I moved an axis on a Joystick, it would move the mouse pointer! (Whaaaat...?) Also, the first joystick button was mapped to the first mouse button, and so on. At first I thought it was kind of cool, but seeing as I had no way of turning it off or configuring the behavior in any way, it quickly became a nuisance. Playing any game with a joystick was very difficult because I had to be careful not to click the "Shutdown the Computer" icon when I meant to fire at my enemies, etc.
4.) I was no longer able to hotsync my Treo 650 with the Evolution mail client over Bluetooth. This actually wasn't much of a surprise; the same thing happened when I upgraded from Feisty to Hardy, if I recall correctly.
5.) This one is probably the oddest of all. Mupen64, an N64 emulator, forgot all its input settings. This just makes absolutely no sense to me because Mupen isn't managed by Ubuntu at all. Fixing this was fairly quick, however, as I was able to reconfigure the controls the same way I had done so originally.
Whenever I start having lots of trouble with an OS (especially after a major update), I usually reinstall it fresh rather than try to manually fix each problem individually. This usually cleans up any problems I noticed, as well as the ones I didn't. Of course, it also has the side effect of wiping your hard drive (if you're not careful) thereby erasing all your personal data and whatever tweaks you had made to your system.
Actually, I didn't lose my personal data, though the tweak loss was basically unavoidable, especially since most of them had already been trashed by the first pseudo-successful upgrade attempt. There are a lot of ways to preserve data over a re-installation, but this is the way I did it:
1.) Boot the computer (a laptop, in my case) into a Live CD environment, like Knoppix.
2.) Boot into runlevel 2 (text only).
3.) Mount the main OS' hard drive partition (mine was /dev/sda2).
4.) Create a backup folder in the root, such as "ubuntu8.10-backup".
5.) Either move all files and folders in the partition root (besides the backup folder) into the backup folder using the "mv" command (you must name each object manually in order to prevent the backup folder from being moved into itself), or else archive-copy them (cp -a). It is important, especially for things like Subversion repositories, that you maintain timestamps, as well as ownership and permissions. That is why you have to use the "-a" option when you copy. (The "mv" command preserves all metadata automatically.)
6.) Reboot the computer and boot the Ubuntu install CD/DVD. (If you moved everything into the backup folder you have no other choice; the boot loader on the hard drive will fail because the system root is no longer where it should be.)
7.) (I did this, but I realize now that you probably don't have to.) Use the Live CD environment on the Ubuntu install disc to mount the old OS's root partition again and delete everything out of it (except for the backup folder) to free up space on your hard drive before the install.
8.) Unmount the partition, and any other partitions that are mounted on the same drive.
8.) Start the install process.
9.) CRITICAL: When the installer gets to the part about paritioning your hard drive, *choose to configure the partitioning scheme manually.* If you do not do this, you could lose your backup or at the very least break up your hard drive into an unnecessary number of partitions.
10.) When asked what to do with existing partitions, use the graphical tools given to indicate that your old OS's root partition should be the root of the new Ubuntu install (in other words, set its mount point to "/").
11.) CRITICAL: Make sure that the option to format the partition is *turned off* (check-marked), otherwise you WILL lose your backup.
12.) Continue with the installation as usual. You will be told that since the root is not being formatted a number of files or folders on it may get deleted or overwritten. This is not a problem for you, assuming you didn't put your backup in any of the standard Linux folders (like /etc, /bin/ sys, and so on).
13.) After the install is complete, restart, and configure your new system however you like. Make sure you get all the required updates downloaded and installed.
14.) Now, you may begin copying or moving things from your backup folder into your new system. Since most of what you wanted to keep will probably be in your old home folder, you will probably want to create a link to it in your new home folder. On my system, the following command worked:
ln -s /ubuntu8.10-backup/home/brad ~/old
(You would replace "brad" with whatever your old username was.)
15.) You may run into trouble if your username or user ID changed during the migration. If that is the case, you may have to use root privileges to change the files' username to your new username (use the "chown" command for this).
This is as far as I've gotten so far. Since my old system had a lot of tweaks, it will take a while for me to get them all back on the new system. I will post more as progress is made.
Anyway, as soon as I found out, I upgraded. Immediately. *Without even backing up.* That was a mistake.
See, I was thinking the upgrade process would be smooth sailing...and for the most part, it was. Unfortunately, my highly-customized system wasn't quite ready for it, and a number of odd problems popped up post upgrade. What's more, a number of those problems apparently had nothing to do with my customizations; they appeared all on their own:
1.) A number of GConf settings relating to global keyboard shortcuts were, how should I say, "invalidated." That is, a lot of my custom keyboard shortcuts (the kind that can only be set manually through GConf keys) were no longer valid because the names of certain keyboard modifiers were changed. For example, "
2.) For some reason, nearly all the extra keys on my keyboard (such as Media, Play/Pause, Stop, Volume Up/Down, Mute, etc.) ceased to function altogether--it was like they weren't even there anymore. Also, the Favorites button was remapped to Stop. I wasn't able to fix this.
3.) This one was truly bizarre: Every time I moved an axis on a Joystick, it would move the mouse pointer! (Whaaaat...?) Also, the first joystick button was mapped to the first mouse button, and so on. At first I thought it was kind of cool, but seeing as I had no way of turning it off or configuring the behavior in any way, it quickly became a nuisance. Playing any game with a joystick was very difficult because I had to be careful not to click the "Shutdown the Computer" icon when I meant to fire at my enemies, etc.
4.) I was no longer able to hotsync my Treo 650 with the Evolution mail client over Bluetooth. This actually wasn't much of a surprise; the same thing happened when I upgraded from Feisty to Hardy, if I recall correctly.
5.) This one is probably the oddest of all. Mupen64, an N64 emulator, forgot all its input settings. This just makes absolutely no sense to me because Mupen isn't managed by Ubuntu at all. Fixing this was fairly quick, however, as I was able to reconfigure the controls the same way I had done so originally.
Whenever I start having lots of trouble with an OS (especially after a major update), I usually reinstall it fresh rather than try to manually fix each problem individually. This usually cleans up any problems I noticed, as well as the ones I didn't. Of course, it also has the side effect of wiping your hard drive (if you're not careful) thereby erasing all your personal data and whatever tweaks you had made to your system.
Actually, I didn't lose my personal data, though the tweak loss was basically unavoidable, especially since most of them had already been trashed by the first pseudo-successful upgrade attempt. There are a lot of ways to preserve data over a re-installation, but this is the way I did it:
1.) Boot the computer (a laptop, in my case) into a Live CD environment, like Knoppix.
2.) Boot into runlevel 2 (text only).
3.) Mount the main OS' hard drive partition (mine was /dev/sda2).
4.) Create a backup folder in the root, such as "ubuntu8.10-backup".
5.) Either move all files and folders in the partition root (besides the backup folder) into the backup folder using the "mv" command (you must name each object manually in order to prevent the backup folder from being moved into itself), or else archive-copy them (cp -a). It is important, especially for things like Subversion repositories, that you maintain timestamps, as well as ownership and permissions. That is why you have to use the "-a" option when you copy. (The "mv" command preserves all metadata automatically.)
6.) Reboot the computer and boot the Ubuntu install CD/DVD. (If you moved everything into the backup folder you have no other choice; the boot loader on the hard drive will fail because the system root is no longer where it should be.)
7.) (I did this, but I realize now that you probably don't have to.) Use the Live CD environment on the Ubuntu install disc to mount the old OS's root partition again and delete everything out of it (except for the backup folder) to free up space on your hard drive before the install.
8.) Unmount the partition, and any other partitions that are mounted on the same drive.
8.) Start the install process.
9.) CRITICAL: When the installer gets to the part about paritioning your hard drive, *choose to configure the partitioning scheme manually.* If you do not do this, you could lose your backup or at the very least break up your hard drive into an unnecessary number of partitions.
10.) When asked what to do with existing partitions, use the graphical tools given to indicate that your old OS's root partition should be the root of the new Ubuntu install (in other words, set its mount point to "/").
11.) CRITICAL: Make sure that the option to format the partition is *turned off* (check-marked), otherwise you WILL lose your backup.
12.) Continue with the installation as usual. You will be told that since the root is not being formatted a number of files or folders on it may get deleted or overwritten. This is not a problem for you, assuming you didn't put your backup in any of the standard Linux folders (like /etc, /bin/ sys, and so on).
13.) After the install is complete, restart, and configure your new system however you like. Make sure you get all the required updates downloaded and installed.
14.) Now, you may begin copying or moving things from your backup folder into your new system. Since most of what you wanted to keep will probably be in your old home folder, you will probably want to create a link to it in your new home folder. On my system, the following command worked:
ln -s /ubuntu8.10-backup/home/brad ~/old
(You would replace "brad" with whatever your old username was.)
15.) You may run into trouble if your username or user ID changed during the migration. If that is the case, you may have to use root privileges to change the files' username to your new username (use the "chown" command for this).
This is as far as I've gotten so far. Since my old system had a lot of tweaks, it will take a while for me to get them all back on the new system. I will post more as progress is made.
Sunday, November 2, 2008
Getting Videos onto the DS using Linux
I recently bought an Ez Flash V Plus. I guess you could call it a sort of DS-compatible MicroSD card adapter. (Kind of confusing...it's "SD" for the "DS.") Basically it's a DS card with a MicroSD card slot on the side. It has some sort of BIOS on it that can boot a binary file located on the root of the micro's filesystem. This binary is basically an operating system kernel, comparable to the Linux kernel. This kernel, along with a bunch of data and configuration files which come with it, comprise a powerful, sophisticated program that can be used to start other DS-compatible programs stored on the micro SD card. In a sense, it's like an operating system, thought technically that's not true since the "kernel" plays no other role for programs than to load them into memory when they start. After a program starts, it's completely incapable of interacting with the kernel. It is the only program running, and there are no system calls available, as their would be if it were running through an actual OS.
Even though this starter application is not technically an operating system it is based on a popular DS homebrew media player program called Moonshell. In fact, the whole thing is basically just a modified version of Moonshell. This means that it can play an incredible range of different forms of media.
One of the things this software is supposed to be capable of handling is compressed video. Unfortunately, because of hardware constraints, the only form of video that the software can play is a proprietary format called DPG. For Windows users this is not such a problem because there is a tool available that can easily convert all the most common video formats (like AVI, MPG and FLV) to DPG in a single step. For Linux users, on the other hand, it's not so easy--not at first, anyway.
If you're on Linux, there aren't very many options for converting video files to DPG format. They do exist, however. It took me a while to find them. The solution I eventually found involved the use of a piece of software called MEncoderM, another called mpeg_stat, and a Python script. This solution is a little strange to put together, but it works very well and provides you with a utility that can easily be used to convert to DPG. Here are my sources:
MoonShell
nDs-mPeg
The script is called "dpgconv.py" and can easily be found using a Google search.
Even though this starter application is not technically an operating system it is based on a popular DS homebrew media player program called Moonshell. In fact, the whole thing is basically just a modified version of Moonshell. This means that it can play an incredible range of different forms of media.
One of the things this software is supposed to be capable of handling is compressed video. Unfortunately, because of hardware constraints, the only form of video that the software can play is a proprietary format called DPG. For Windows users this is not such a problem because there is a tool available that can easily convert all the most common video formats (like AVI, MPG and FLV) to DPG in a single step. For Linux users, on the other hand, it's not so easy--not at first, anyway.
If you're on Linux, there aren't very many options for converting video files to DPG format. They do exist, however. It took me a while to find them. The solution I eventually found involved the use of a piece of software called MEncoderM, another called mpeg_stat, and a Python script. This solution is a little strange to put together, but it works very well and provides you with a utility that can easily be used to convert to DPG. Here are my sources:
MoonShell
nDs-mPeg
The script is called "dpgconv.py" and can easily be found using a Google search.
Subscribe to:
Posts (Atom)
