One problem I’ve had with my laptop ever since I bought it is the Realtek 8192 wireless chip losing connection and requiring a reboot to reconnect. This happens in both Ubuntu and Windows, though Windows is at least as likely to never connect in the first place.
I finally seem to have come up with a method of recovering the wireless connection in Linux without having to reboot. Merely restarting the network does not work, it requires unloading and reloading the driver, for which I’m using the following script:
sudo service network-manager stop
echo "Remove Wireless driver"
sudo modprobe -r rtl8192se
echo "Reload Wireless driver"
sudo modprobe rtl8192se
sudo service network-manager start
The wireless has actually been working for the last week so I’ve only just had a chance to test this script and it seems to work. The delays may be excessive, but it’s still faster than rebooting and then restarting all my software.
So I’ve upgraded through two Ubuntu versions to 12.04. One problem was that it didn’t remember the desktop background, and while it would be set temporarily when I updated it, the standard Ubuntu background would return after restarting.
Looks like the problem is in /etc/lightdm/lightdm.conf, which is setup by default for Unity. Instead, it should say:
Now it all seems to be working correctly again. I presume this is a consequence of upgrading from old versions, and wouldn’t be required for a fresh Xubuntu installation.
So, as I have to upgrade my Ubuntu installation to a version which doesn’t include Gnome 2, it’s farewell to Gnome. I’ve now switched to XFCE, and having spent some time playing with the configuration I’ve ended up with something that looks much like it and has almost all the features I’ve missed from Gnome 2.
Cool, XBMC is now available on Android as a Beta release. It’s running on my Asus Transformer TF300 and plays SD video OK but struggles with HD as there’s no hardware acceleration yet.
Ton of issues they’ll have to resolve, but it works as a music player and is the best way I’ve yet found to play SD videos over the LAN.
Get pre-release installers from here:
I use gwibber to monitor Facebook and Twitter feeds so I don’t have to log in there. It hasn’t worked in a few weeks, and attempting to open the GUI did nothing.
I finally tried running it from the command line and got the obscure error “DatabaseError: database disk image is malformed”, which is tremendously unhelpful and shows someone isn’t checking their error conditions correctly.
Turns out that gwibber stores tons of data in an sqlite database hidden in ~/.config/gwibber. Since sqlite is hardly the most reliable of databases, this can get corrupted.
To fix it, first kill all gwibber-service processes. Then dump the database and rebuild it:
$ cd ~/.config/gwibber
$ echo ".dump" | sqlite3 gwibber.sqlite | sqlite3 new.db
$ mv gwibber.sqlite old.db
$ mv new.db gwibber.sqlite
When you’re happy with the way gwibber, just delete old.db.
I must admit, I’ve never seen the attraction of sqlite. It’s handy if you want to create a small database which you won’t be reading or writing often, but software like this abuses it by creating databases of hundreds of megabytes or more. When gwibber restarted after rebuilding the database it created a journal file of over half a gigabyte on a machine with 3GB free. Not good.
Apparently the Gnome team is in deep decline, losing market share and mind share:
Staring Into The Abyss
Hmm, perhaps that’s because Gnome 3 sucks and whenever someone points that out we’re told we’re ‘scared of change’ and ‘if we don’t like Gnome, use something else’.
Dumb, dumb, dumb.
Linus still hates Gnome 3 too.
Linus also comments there on why ‘extensions’ are a piss-poor ‘solution’ to a fundamentally broken design.
At least if Gnome 3 does collapse, we might see some sanity in Linux desktop GUIs again.
Well, my raid is back after removing the old drive and installing the new one. What a pain it’s been, though; it looks like any time you get a single bad blog on an MD RAID you need to remove it immediately even though that means you could lose data if a block goes bad on the other drive.
After performing a full copy of all the data from the failing disk to the good one, I see I have 33 bad blocks on that disk; so it’s worse than I thought. Fortunately it only affects a few game installer files which are out of date anyway, so the important data is safe.
Still, now I have two RAIDs with one disk each, I’ll have to get a new disk in to replace the bad one and hopefully that will solve this problem for a couple of years.
So, MD RAID appears to be fundamentally flawed. If the active drive develops a bad sector and it has to resync, when resyncing it reads that bad sector and instead of continuing to resync the rest of the disk it… gives up. It then flags the good disk as a spare and continues to write to the bad disk.
Now, the most likely reason for this is an improper shutdown so the good disk wasn’t fully synced and a few blocks need to be fixed up. The odds are therefore very high that the block on the good disk corresponding to the bad block actually contains the correct data, and simply updating the other blocks will fix any problems you have.
But it’s too stupid to do that. My RAID was getting 75% through the resync, hitting a single 4k bad block among 3TB of data and aborting. This largely invalidates the benefit of using RAID in the first place, since the whole idea of doing so is to allow you to remove the bad disk and replace it with a new one.
As a result I’ve had to remove the good disk from the RAID since there’s no way to recover it. To fix the problem I have to manually copy all the files over from the bad disk to the good one, then replace the bad disk.
I thought I’d try ZFS this time, which has much less brain-dead failure behaviour. Unfortunately I ran into two major problems:
- ZFS in Ubuntu 10.04 doesn’t support disks with 4k block sizes. There’s an option allowing you to force it to write in 4k blocks, but that’s not in the version of ZFS included in Ubuntu 10.04.
- You can’t export ZFS disks via NFS in Ubuntu 10.04. The block size is a small performance hit, but this is a deal breaker. I share the RAID across the various Linux systems in the house with NFS, so if it can’t be shared it’s useless.
So it’s back to building a new MD RAID and hoping that this one works better than the old one. Hopefully by the time I have to worry about replacing another disk I’ll be able to switch over to ZFS after all.
I have a printer on my CentOS machine, running CUPS, which I could print to from any machine in the house, be it Linux or Windows. It all just magically worked, but that machine is only used as a workstation so it’s turned off when not in use.
I wanted to move the printer to one of my servers running Ubuntu which is available 24/7, so I don’t have to turn on the workstation to print things.
You’d think it would be easy; after all, both run CUPS and one of them just works. So I’ve configured the printer on Ubuntu and… nothing works. Every time I try to print it asks for some kind of password.
I’ve been through cupsd.conf trying to figure out how to tell it ‘just print any damn thing we send you’, but the file is arcane gibberish. Even copying the cupsd.conf file from the CentOS machine to the Ubuntu machine doesn’t solve the problem. I understand that people running this in a business with thousands of users want a lot of control, but how can they make a simple configuration where it just prints so difficult to set up?
The best thing is that every time it fails to print I have to tell it to cancel the print job, I have to tell it that yes, I really did mean to cancel the print job and then I have to re-enable the printer and then I have to ‘apply’ the changes, even though I didn’t have to apply the change that automatically disabled it even though I’m trying to get the damn thing to work. I can hardly imagine a worse user experience.
I think this demonstrates one of the big problems with modern sofware: massive overconfigurability. If you can’t decide how something should work, allow users to configure it to work in any way they want. The end result is that only an expert can get it to work at all.
IPSEC is a glowing example. There is typically one way to configure it to connect properly and roughly ten trillion ways to configure it not to work; and when it doesn’t work there’s generally no way determine why it doesn’t. The end result is that when you magically find a combination which does work you stick to it, even if that’s a less secure configuration than just giving the users a choice of half a dozen options selected by the developers.
I saw a post on a web forum recently asking about optimising Linux to run on an SSD. One problem with SSDs is that they don’t like being written to repeatedly, so I’ve worked around that by pushing most commonly updated files into /tmp, which is mounted as a RAM drive. I have an rc.local script which creates a file tree in /tmp for each user and then I created links in the user’s home directory which point to the relevant directory in /tmp.
tmpfs /tmp tmpfs defaults,noatime,nodev 0 0
Unfortunately Ubuntu seems unable to run with noexec turned on in /tmp.
# Create user directories in /tmp
for i in *
grep "/home/$i" /etc/passwd > /dev/null
if [ "$?" -eq "0" ]
if [ ! -d /tmp/$DIRNAME/$i ]
mkdir -p /tmp/$DIRNAME/$i/mozilla-cache
mkdir -p /tmp/$DIRNAME/$i/thunderbird-cache
mkdir -p /tmp/$DIRNAME/$i/cache
mkdir -p /tmp/$DIRNAME/$i/thumbnails
mkdir -p /tmp/$DIRNAME/$i/adobe
mkdir -p /tmp/$DIRNAME/$i/macromedia
chmod -R go= /tmp/$DIRNAME/$i
chown -R $i:$i /tmp/$DIRNAME/$i
chmod a+rx /tmp/$DIRNAME
Weird. I just logged into my home server and noticed that the MD RAID array was degraded; turns out that it had decided that one of the drives was a spare and not part of the RAID array. I’ve no idea how that happened.
Rebooting fixed it; now the drive is back in the RAID and the RAID is rebuilding. Hopefully that won’t happen again.
I’ll also be interested to see what happens during the rebuild. The Linux kernel has been complaining about read errors on the active disk even though SMART hasn’t reported problems. If the rebuild goes OK, that should imply that the entire disk was readable after all.
Woo-hoo; looks like someone’s finally trying to take the abomination that is Gnome 3 and turn it into a usable GUI:
Linux Mint 12 Preview
I suspect my laptop is going to switch from Ubuntu to Linux Mint in the not too distant future.
I was wondering why my laptop was thrashing the disk for several minutes after logging into Ubuntu 11.04, and I finally managed to track down the culprit. It’s more junk that Gnome is installing to be ‘user-friendly’ by tracking everything we do on the system, which for some reason is performing a lot of disk updates every time you log in.
Surely by now everyone should know that logging in is the very worst time to be performing disk-intensive operations? I’m logging in to do something useful and don’t want to be forced to wait while some crappy program checks for updates, deletes outdated files or writes lots of stuff to a database.
Anyway, this problem is easily solved:
sudo apt-get remove zeitgeist-datahub
Reboot and as if by magic your desktop will be usable almost as soon as it appears.
I really am going to have to switch to xfce soon if Gnome continues down the path they’re following.