This is a known bug with the flashplugin-installer package and is currently being worked on by Canonical. In the meantime, if you wish to fix the problem yourself now rather than wait for the official fix, just follow these instructions…

1. After you have installed Flash in the usual manner, open a terminal and type in the following:

   $ sudo gedit /usr/lib/nspluginwrapper/i386/linux/npviewer

2. Once the GEdit text editor (or substitute your favourite) opens, insert the following line just before the last line (should appear in most installations as the fourth line out of a total of five lines):

   export GDK_NATIVE_WINDOWS=1

3. Save your changes and exit your text editor.
   .
4. Now restart any applications that use Flash, such as Firefox.
   .
5. In the case of Firefox, go and visit a page that uses Flash. You should now find that you can now click in Flash without a problem.
   .
6. Pat yourself on the back. You’re done.

Sometimes actions speak much louder than words, and it would be great for the client to be able to see what you are doing without cumbersome and bandwidth-hogging remote screen tools like VNC. Is there an easy way to collaborate in a terminal?

There certainly is…

1. First up, login to the client’s remote machine in question using their login, eg: login to the PC at 192.168.0.27 with the username “fred”:

   $ ssh fred@192.168.0.27

2. Once logged in, we need to create a screen session. It needs a name, so I’ll call mine “blah”, but you can make it any name you want. Type in the following (note that the “-S” parameter is uppercase):

   $ screen -S blah

3. Now instruct the client to open a terminal locally and attach themselves to your screen session by typing in the following command (note that the “-x” parameter is lowercase):

   $ screen -x blah

4. You are now both looking at a common screen session. Anything that either of you type along with any command output will be automatically and immediately seen by the other person in real-time!
   .
5. Once you’ve finished sorting out the client’s problem, terminate the screen session with:

   $ exit

6. You and the client will be both returned to your regular local terminal sessions which you can now close with the “exit” command again.

If you don’t have another machine to try this with, you can try it using two terminal windows on your own local machine. You don’t need to SSH in since you’re already logged in, just run both screen commands in their own respective windows and watch as any new information entered, including command output, appears in both terminals simultaneously.

You are not limited to only having two terminals sharing a screen session – you can have an unlimited number of terminals, remote or local, share one screen session.

Note that the shared screen session only works with the same user login. You cannot have two separate users share a screen, hence the need to login using the client’s username before setting up the screen session. If the client’s username does not have sudo rights, once inside the screen session, simply su to your admin login and then do the administrative work you require, all while your client watches on in amazement. Of course, be aware that the client can also start typing in commands whilst you are su’ed into your admin login as well, so don’t leave your terminal unattended.

Enjoy.

The machine starts up fine, but when you try and hit the network, you can’t. Closer inspection using the ifconfig command reveals that there is no “eth0″ adapter configured. Why?

Here’s how to fix it.

Ubuntu Server keeps tabs on the MAC address of the configured ethernet adapter. Unlike Ubuntu Desktop, you can’t simply change network cards willy nilly – while Ubuntu Server does detect and automatically setup new cards, it won’t automatically replace any adapter already configured as eth0 with another one, so you need to tell Ubuntu Server that you no longer need the old adapter.

This problem can also appear if you have a virtual machine such as one from Virtualbox, and you move or copy it from one host to another without ensuring that the MAC address configured for that VM’s ethernet adapter is 100% identical to the previous one.

These instructions were done with Ubuntu Server 9.04 Jaunty Jackalope in mind, but should apply to just about any release.

1. Since you can’t SSH in, you will need to login directly on the Ubuntu Server console as an appropriate user with sudo rights.
   .
2. Once logged in, type in the following and hit Enter:

   $ sudo nano /etc/udev/rules.d/70-persistent-net.rules

3. You are now presented with the Nano text editor and some info that looks similar to the following:

   # This file was automatically generated by the /lib/udev/write_net_rules
   # program, run by the persistent-net-generator.rules rules file.
   #
   # You can modify it, as long as you keep each rule on a single
   # line, and change only the value of the NAME= key.
   
   # PCI device 0x8086:0x1004 (e1000)
   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0a:03:27:c2:b4:eb", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

4. Delete the last two lines or simply comment out the SUBSYSTEM line on the end. This is a rule defining what MAC address should be explicitly assigned to “eth0″. Since you no longer have an ethernet card with the specified MAC address in this machine (it’s on the old PC, remember), Ubuntu Server effectively ignores your new ethernet adapter because its MAC address does not match the defined rule for “eth0″.
   .
5. Once you’ve made your changes, press CTRL + X and then Y and then Enter to save your changes.
   .
6. Now reboot your box with:

   $ sudo reboot

7. Upon reboot, Ubuntu Server will detect the “new” ethernet adapter in your PC and will automatically write a new rule into the /etc/udev/rules.d/70-persistent-net.rules file, thus enabling networking over eth0 for your server.
   .
8. To verify that the new adapter is working, type in:

   $ ifconfig

   …and you should see eth0 now listed with your defined IP address.
   .

9. Test remote connectivity to the server and if all is well, then pat yourself on the back. You’re done.

You’re probably thinking “why the hell would anyone want to do that?!”… well, the fact of the matter is you sometimes come across a client who is just too mind-set and refuses to use anything but Windows, so yes – sometimes you need to restore the Windows MBR, but how do you do that when you don’t have a Windows CD handy?

Well, here’s how to do it using nothing but an Ubuntu 9.10 Karmic LiveCD.

It’s a little known fact that the Windows bootloader is nothing special. In fact it contains nothing proprietary to Windows at all. All the Windows bootloader does is simply look for the partition marked as “bootable” or “active” and transfer control of the boot process to it.

And would you know it? The Ubuntu LiveCD has a binary image of a generic open source bootloader that does just that!

1. Boot your soon-to-be-Windows-only machine using the Ubuntu 9.10 Karmic LiveCD. Doesn’t matter if it’s the 32-bit or 64-bit version.
   .
2. Once booted on the LiveCD, open a terminal by going to the Applications menu and then choose Accessories and then Terminal.
   .
3. Find out what the designation of the Windows drive is (generally it will be the first drive, eg: /dev/sda or /dev/hda). If you are not sure, issue the command:

   $ sudo fdisk -l
   

   …and review the output, looking for your NTFS Windows partition. Make note of the drive that partition resides on (not the partition itself), eg: “/dev/sda”, not “/dev/sda1″.

4. Now type in the following (remembering to substitute the correct drive device name for your setup in place of “/dev/sda”):

   $ sudo dd if=/usr/lib/syslinux/mbr.bin of=/dev/sda

   …which will write the image of a standard MBR contained in the /usr/lib/syslinux directory of the LiveCD environment to the first hard-drive, overwriting GRUB. WARNING: Do NOT use a partition designation, eg: “sda1″ or “sda2″, etc. This will overwrite the start of that partition which will effectively destroy data. The MBR exists at the start of the drive only, so only specify “sda” with no number on the end.

5. Shutdown and reboot. Windows should now start “natively” without GRUB appearing at all.
   .
6. Normally I’d say “pat yourself on the back” here, but it’s Windows…

While the Ubuntu-provided Bluetooth stack has not been updated to correct this problem yet, the Blueman Project that Ubuntu uses keeps marching on in development and the latest version of of the Bluez stack and Blueman applet finally corrects this problem.

Here’s how to employ it on your own setup.

EDIT October 2009: I have tested and found that the Microsoft Bluetooth Notebook 5000 mouse pairs and resumes successfully with the Ubuntu 9.10 Karmic Koala Beta release without any changes or upgrades required to the Bluetooth software. This HowTo therefore only applies to Ubuntu 9.04 Jaunty Jackalope.

1. First we need to add the Blueman Project’s PPA to your Ubuntu Jaunty installation. Open a terminal and type in:

   $ sudo gedit /etc/apt/sources.list.d/blueman.list

2. You will be presented with a blank text editor. Type or copy & paste the following lines in:

   deb http://ppa.launchpad.net/blueman/ppa/ubuntu jaunty main
   deb-src http://ppa.launchpad.net/blueman/ppa/ubuntu jaunty main

3. Save your changes and exit the editor.
   .
4. Now update your package lists with:

   $ sudo apt-get update

5. At the end you will see a NO_PUBKEY error because your setup does not yet have the GPG key for the Blueman repository to authenticate the packages with. To fix this, import the key with:

   $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 6B15AB91951DC1E2

6. Update your package lists again as per Step 4 and you should find the NO_PUBKEY error is gone now.
   .
7. By now your system is probably prompting you that there are updates to the Bluetooth stack available to install. We may as well stay at the terminal and do the updates there:

   $ sudo apt-get upgrade

8. Once that completes, the Bluetooth stack is now up to date, but we now need to install the Blueman applet to replace the Gnome version of it:

   $ sudo apt-get install blueman

   (this will automatically uninstall the bluez-gnome package as we don’t want it anymore)

9. Once that completes, logout and log back in again so that the new applet loads up to replace the old one.
   .
10. Now, switch the mouse into paring mode by holding down the pairing button on the base of the mouse until the LED on top of the mouse starts to alternate between red and green illumination.
    .
11. Now do a left-click on the Bluetooth icon in the system tray. The Bluetooth Devices window should appear. Within a few seconds of that window opening, you should see your mouse and any other nearby Bluetooth devices listed in the window.
    .

    
    .

12. Do a right-mouse click on the Microsoft Mouse entry and choose “Bond” (or ensure the Microsoft Mouse entry is selected and click on the “Bond” button in the toolbar).
    .
    .
13. You will be prompted for the PIN number of the mouse. Like most accessory items, this is just “0000″, so type that in and hit Enter, or press OK.
    .

    
    .

14. Once the mouse is bonded, you will see some signal coloured bars appear next to the Microsoft Mouse entry in the Bluetooth Devices window (which represent the Received Signal Strength, Link Quality and the Transmit Power Level). But you can’t use the mouse just yet.
    .

    
    .

15. Click on the “Trust” button in the toolbar. This will allow your mouse to reconnect without prompting you for permission when you turn it off and back on again (or when you reboot).
    .
16. Now do a right-mouse click on the Microsoft Mouse entry again and choose “Connect to Input Service” (or click on the “Setup” button in the toolbar and follow the Wizard). After a brief delay, you should now find that your mouse now moves the mouse pointer!
    .
    
    .
17. You can now close the Bluetooth Devices window. Pat yourself on the back. You’re done.

Your mouse should automatically reconnect upon reboot, PC or Mouse power saving events (such as suspend), and if you turn on the mouse after booting up your system.

I haven’t played with the Ubuntu Karmic Alpha yet to know if a more recent version of the Bluez Bluetooth stack is included. One presumes it will be, but if not, these instructions will probably work for Karmic as well.

EDIT October 2009: I have tested this mouse with the Ubuntu 9.10 Karmic Koala Beta release and it pairs first time perfectly and also resumes perfectly. There will be no need to use this HowTo with Karmic.

If, like most people, you have Compiz enabled and you start the MythTV Frontend, you will notice that rather than go full-screen, Myth will start as a window, essentially, even if your settings within Myth say to go full-screen.

In a single-screen scenario, the MythTV window will start just underneath the upper Gnome panel and the lower Gnome panel will sit over the top of the Myth window, obscuring part of the display. Proof that it’s a window can be found by holding down the ALT key and then dragging the MythTV display around with your mouse.

If you’re like me and use two displays with Myth being run on the second screen, you will see a gap at the top of the screen that is the same height as the upper Gnome panel and you will see your wallpaper showing through there, as shown in the illustration below.

Click for full size (520K)

Here’s how to fix this problem.

EDIT June 2010: This problem still plagues Ubuntu 9.10 and 10.04, and this fix will work for those releases as well.

The simplest fix is to disable Compiz altogether and MythTV will suddenly go full-screen, but that’s not really a solution – you want to keep your eye-candy! So follow the next few steps instead:

1. Go to System->Preferences->CompizConfig Settings Manager. If you do not have this option in your Preferences, then you need to add it. Quickly jump into a terminal and type in at the $ prompt:

   $ sudo apt-get install compizconfig-settings-manager

   …and hit Enter. Once installed, go back into the Preferences menu and bring it up.

2. Scroll down until you get to the “Utility” section and then click on “Workarounds”. It should alredy be selected as enabled, but if not, also make sure the checkbox next to it is enabled too.

   
   Click for full size (81K)
   .

3. The window changes to show you the Workaround options. The very first option is “Legacy Fullscreen Support”. This is unchecked by default. Click on the checkbox so that it IS checked, and then click on the Back button, then close the window.

   
   Click for full size (71K)
   .

4. Quit the MythTV Frontend if you had it open already and then restart it. You will now find that the gap has disappeared, and that the MythTV display is now appearing full-screen properly instead of just being a window.
   .
5. Pat yourself on the back.

Happy viewing!

Please note: This workaround is just that – a workaround. One minor problem that arises with it is that you may get occasional screen “flashing” or a flash of the background wallpaper appearing when a DBus message is displayed, or if you scroll a window or terminal on the same or other screen in a multi-screen setup. This does not occur often, however, and so may not bother you at all! The bug has been reported, and no doubt will be fixed in due course. When it is fixed, this workaround should be reversed.

The solution was simple – get rid of ndiswrapper and that will prevent the offending Windows driver loading which I can then delete afterwards, but how do you do this when you can’t even boot to a terminal?

With the assistance of an Ubuntu LiveCD (on USB stick in this case), I was able to remove ndiswrapper without needing to do a complete re-install of the system. Here’s how to do it.

1. Shutdown your system, insert your Ubuntu LiveCD and turn on your system.
   .
2. Allow the system to boot to the LiveCD desktop and then open a terminal.
   .
3. Determine what your system’s root partition is called by getting a list of available drives and partitions with:

   $ sudo fdisk -l

4. In my case, this Medion lappy had Windows installed and a couple of other partitions too. The root Linux partition ultimately resided on sda8, so I need to mount this somewhere. First I need a mountpoint:

   $ mkdir /dev/shm/medion

   …this creates a directory in the RAM disk called “medion” (but you can call it whatever you want).
   .

5. Now mount the partition to the mountpoint with:

   $ sudo mount /dev/sda8 /dev/shm/medion

6. Check that we can access the mounted drive with:

   $ ls -l /dev/shm/medion

7. If it contains the root filesystem of your lappy’s Ubuntu install, then you’ve done well so far. Now we need to change the system’s root filesystem from the LiveCD over to the hard-drive’s root filesystem so we can work on it. Type in:

   $ sudo chroot /dev/shm/medion

8. This will temporarily make the current session’s root filesystem the one that is on your hard-drive, as though we’d actually booted from it. From here, it’s now a simple case of removing the ndiswrapper application that was causing all my problems (notice that we are at a root prompt designated by the hash symbol):

   # apt-get remove ndiswrapper-common

9. A few warning messages popped up advising that it couldn’t find the log to write to, but that’s OK – the software still gets removed, and thus will prevent the Windows driver from killing the boot process. Once Apt had finished doing its thing, just type in:

   # exit

   …and the root filesystem will revert back to the LiveCD’s root filesystem.
   .

10. Shutdown and reboot as normal without the LiveCD, and viola – the system boots without hanging this time!

As you can see, the ability to change root filesystem can be very useful in trouble-shooting a non-booting installation but also has other uses too, one of the most common being creating custom LiveCD’s by modifying the squashfs filesystem on the LiveCD and burning to a new disc – thus allowing you to add or remove components from the default Ubuntu LiveCD environment.

Like

Unlike

Anyway, the default installation of Ubuntu Intrepid picks up everything except the Fn keys, wireless LAN adapter and the audio. The wireless LAN adapter has proven to be a bit of a challenge, so if I suss it out, I’ll write up about it later. Fn keys I’m not really fussed about (and neither is the laptop’s owner), but we needed the audio.

The SigmaTel STAC 9200 has a dotted history of frustration among Linux users in general, but thankfully it was fixed in Kernel 2.6.27-7 and Alsa 1.0.15. Unfortunately a vanilla installation of Ubuntu it still is unable to autodetect the hardware 100% properly (it will find it and name it, but all you get is silence), so you have to make one tiny manual adjustment before sound will work properly.

1. Open up a terminal and type the following at the $ prompt:

   $ sudo gedit /etc/modprobe.d/alsa-base

2. This opens up the file in the GEdit text editor. Scroll to the end of the file, hit Enter to make a new line and add the following:

   options snd-hda-intel model=gateway

3. Save your changes and close the editor.
   .
4. Now reboot. When Ubuntu comes back, you will have working audio!

Note: Reader Mouhcine has suggested that if “model=gateway” does not work for you in step 2, try using “model=gateway-m4″ which may give you more success in Ubuntu Jaunty.

The Green Bar(TM) and general video corruption looks similar to this:

The issue is that the XVideo extension of X Windows (aka Xv) is having trouble dealing with the decoded video data when using your video card to scale the video to fit the window. There is a fix, however, at a minor cost of some CPU time – instead of getting your video card to do the scaling, get the CPU to do it instead.

1. Press ALT+F2 to bring up the Run Application dialog (or just open a terminal) and type in gstreamer-properties and hit Enter.

   .

2. You will be presented with the GStreamer properties app. Click on the Video tab and you will see the following:

   .

3. Change the Default Output Plugin from Autodetect to X Window System (No Xv) and then close the application.

   .

4. Now re-run your video file through Totem and the Green Bar(TM) should now be gone. Scaling of the video to fit the window is now being done by the CPU. The impact should be negligible. Should you experience playback slowdown with other videos that never had the Green Bar(TM) issue previously, you should go back into GStreamer’s properties and re-enable Xv as required.

   .

5. Retrieve popcorn and enjoy movie.

Like

Unlike

This is caused by the client losing its language settings. You’re looking at the Armenian language. To fix this, simply:

1. Go to the fifth menu (which is the Tools menu).
2. Select Configuration Wizard from the menu and a window appears.
3. Change the language to the language you prefer, eg: English, and all of a sudden all windows will suddenly appear correctly again.
4. Click Cancel to close the window (there’s no need to go through the entire configuration wizard).

Problem solved!

Like

Unlike