On Saturday, Melanie’s laptop (a MSI Megabook 510C) decided to power off, and not come back on, so yesterday, I had an attempt at fixing it. The laptop appears to be completely dead: no POST, not noise, no lights, nothing. My few attempts at getting it going by pulling out the battery and the power and re-inserting them and poking the power button were unsuccessful. I decided to get all the data off the drive first, and then attempt to pull the laptop apart and see if I could find anything wrong.
Getting the drive out was easy enough. A few screws and a panel later revealed the drive in its caddy. With a bit of coaxing, the caddy released the drive to me, and I put it into an external USB drive case. The only thing I had handy to get the data off the drive was my ASUS Eee PC (which runs Linux) and it refused to recogise the USB drive, and even hard rebooted a few of the times I tried to plug it in. The case was a $12 job that I bought from a perhaps slightly shady dealer at the computer fair earlier that day, so this was hardly suprising. Fortunately, Melanie’s parents have a computer running XP, so I went there and copied the data off her drive and onto a USB stick that I knew the Eee would accept. After the drive caused my Eee to reboot, I was worried that perhaps it was the problem with the laptop, so I was quite relieved when the data copied across fine.
Now that the data was safe, I turned my attention to fixing the laptop. I took off all the user-servicable panels, revealing the CPU and heatsink, RAM, wireless card and of course the hard drive. I removed and re-seated the RAM and Wireless card, but didn’t touch the CPU as I didn’t have any thermal paste. Then, there were many little screws that had to be removed. Once this was done, the two layers began to separate. I uncliped a few hidden clips, but the laptop still refused to come apart. I poked around inside for a while, but couldn’t find what was holdling the two halves together, and since this was an old and fairly out of the mainstream laptop, no service manuals were available online. I gave up, as althought the laptop was already broken, it may be fixable and if I kept prying, I’d eventually break it permanently. I managed to get it all back together with no left over screws, plugged it back in and the battery charge light came on, which showed some promise. Unfortunately, that was the most life it showed. It will probably have to go to someone who knows where the hidden clips are and can take it apart safely. It is more than 3 years old, so it is about due for a failure considering how much use it has had and the fact that it was an early generation of the Megabook.
Now that I had decided to give up on the Megabook, Melanie still needed a computer to do her usual work on, so I gave her my Eee. Now the Eee runs a build of Xandros and comes with the basics she should need. It has Firefox which she used on XP, but instead of the Microsoft Office that she is accostomed to, it has Open Office. This should be fine, as she doesn’t really use the advanced features of MSOffice, but the unfamiliar user interface (particularly when combined with the tiny Eee keyboard) might slow her down a bit. However, the bigger problem is that the printer she has, a Brother MFC-5840CN doesn’t have drivers in the default install. Further, the “N” on the end of the model number designates it as a network printer, which makes it more difficult to configure again as most of the tools and documentation assume that most people will have a USB printer. Fortunately, Brother provide excellent support for Linux, and I’ve installed this printer before on Ubuntu, so I wasn’t totally lost.
After some playing the the printer tools on the Eee, it looks like it was using CUPS, and I attempted to use the built in printer manager. I chose a network printer using ipp and it detected the printer on the correct IP address. Unfortunately the MFC-5840CN driver wasn’t in the default list and using the generic driver caused the printer to lock up and print nothing, so more work was required.
I downloaded the deb packages for the LPR driver and the CUPS wrapper from the Brother Linux solutions site. The Brother site also has very good instructions for installation. Now the first thing the instructions say are that csh is required. The Eee doesn’t have csh or any of its variants, and they also don’t exist in the Eee repository. They are in the Xandros repository though, so I added this repository and installed tcsh from there. I’ve used vi in all my examples, but any text editor (e.g. kate) should do:
CTRL-ALT-T to get a terminal
sudo vi /etc/apt/sources.list
Add the following lines to the end of the file:
deb http://xnv4.xandros.com/xs2.0/upkg-srv2 etch main contrib non-free
deb http://dccamirror.xandros.com/dccri/ dccri-3.0 main
deb http://www.geekconnection.org/ xandros4 main
deb http://download.tuxfamily.org/eeepcrepos/ p701 main etch
Save and run
sudo apt-get update to download the list of packages from the new repositories. Then run
sudo apt-get install tcsh to download and install tcsh.
Once this was done I gave it a little test by typing in
csh in the terminal, expecting it to launch the C Shell. Unfortunately all I got was a
Unknown colorls variable `su' error. A bit of Googling revealed that this is caused by the
LS_COLORS environment variable having a setting that csh doesn’t recognise, so setting
LS_COLORS="" temporarily fixed this and I was greeted by the C Shell prompt. I exited the terminal and tried to install the packages by right clicking and choosing install. I got a success message for both packages, however the printer driver didn’t appear in the list, and checking the file system, I didn’t even have a
/usr/share/cups/models directory, let alone a driver wrapper file in it. Thinking the problem could be that the directory doesn’t exist, I created it, but had no further success.
I then turned to the terminal to hopefully get a more helpful message than a straight out success. Running
sudo dpkg -i --force-all --force-architecture mfc210clpr-1.0.0-1.i386.deb caused a segfault on the command line, from
/usr/local/Brother/inf/setupPrintcapij trying to do a
mv $PRINTCAP_NAME $PRINTCAP_NAME.tmp. Unfortunately, this segfault also locked up the Eee and it had to be hard rebooted. Examining the script I found that it was trying to move
/etc/printcap.tmp before editing. Performing this move manually on the command line also produced the segfault and lockup. I’m not really sure, but I’m guessing that this is due to the way the Eee handles its flash filesystem. Performing a cp of that file worked, and mv the copied file also worked, all in
/etc. The script tries to use
/etc/printcap, so I simply ran
sudo cp /etc/printcap etc/printcap.local and re-ran the package installation. While I didn’t get a segfault this time, I did get a lot of
`/var/spool/lpd/MFC5840CN': No such file or directory complaints. A
sudo mkdir -p /var/spool/lpd fixed this and now I had successfully installed the lpr driver.
Now the cups installed without any problems using
sudo dpkg -i --force-all --force-architecture cupswrappermfc210c_1.0.0-1_i386.deb. Now I could open the printer manager and select the printer I installed previously and choose to change the driver. I then selected
/usr/share/cups/model/brmfc5840cn_cups.ppd and printed a successful test page, including colour.
This whole process was rather more involved than I was expecting. Even though I knew I had to download and install the drivers, I wasn’t anticipating the problems with getting csh to run or the install of the drivers causing a segfault. However, I’m happy that due to the drivers being open source, I could get into the install files and see what was causing the issue and resolve it, which is something I’ve wished I could do in the past when installing this same printer in Windows.