TL;DR: XFS filesystem corrupted, ran xfs_repair on unmounted system via a live USB to fix it.
A couple of weeks back one of the drives in my RAID 5 array started going bad, with SMART errors appearing. It so happened to be the drive that I had bought to replace another drive that went bad (with the same error) back at the start of 2017. Anyway, warranty replacement drive went in, re-added it to the array and all seemed fine.
Then one Friday night, I went to watch a movie that had been recorded on MythTV previously. Switched on the TV, changed to MythTV, all of the recorded programs were showing as not found. Uh-oh. Rebooted the frontend, issue still there. Time to check the backend. Logged in to it, ran dmesg, up come a heap of XFS errors. That's not good. Better restart it and see if that fixes things. Nope, now it won't boot. It gets to the recovery console and I can't do much. Checking the SMART status of the drives, they seem fine, but the RAID array is not shown. It also seems to be missing a drive, but not the one I replaced. Scratching my head, wondering what's wrong, a niggling thought that I'd have to do a fresh re-install because Mythbuntu hosed itself. I'd been thinking about it for a while, maybe setting it up in a virtual machine, changing over to ZFS, but I wanted to do that in my own time, rather than having my hand forced. I went to bed to think about it.
The next day, I thought I'd try booting off a live USB of Mythbuntu. Fortunately, that worked, and I could see the array. It was missing one of the drives - so I added it back in. Many hours of rebuilding later, it was back up. While it was rebuilding, I looked in to repairing XFS filesystems.
Once the array was up, I unmounted the volume that contained the recordings, and ran xfs_repair /dev/raid1/tv. It found quite a few problems, and rectified quite a few. With fingers crossed, I tried rebooting back into the original system...success! With a sense of relief and amazement the desktop appeared. Upon checking the list of recordings, quite a few were still missing, mostly from the last few days. I hadn't checked up on it for a little while, so whatever issue there was, was screwing up the recordings. Deleting them from within MythTV, to clean up the database, fixed that. I also noticed that a number of older recordings were also showing as missing. Probably just a byproduct of what was happening. No big deal, they are just TV shows after all.
The system has been running OK for the last few days, so hopefully the issue is resolved. I'm still at a loss as to what actually went wrong though. Might have to dig through some log files.
Thursday, May 11, 2017
Thursday, June 18, 2015
Converting RAID1 array to RAID5 using the mdadm grow command
I have finally decided to upgrade the storage in the home theatre PC, by adding a third 3TB hard drive. The storage was set up previously as RAID 1, using the software mdadm solution for the two 3TB disks. By adding a third drive and changing to a raid 5 format, the storage would increase from 3TB (about 2.7TiB) to 6TB (about 5.4TiB).
There are a few ways to do this:
1. Copy the data to a spare drive, delete the RAID 1 array, create the RAID 5 array with the three disks, copy the data back to it.
2. Back up the data to a spare drive, remove one disk from the RAID 1 array, use that disk and the new disk to make a 2 disk RAID 5 array, copy data over, remove the RAID 1 array and add that disk to the RAID 5 array so it is 3 disks.
3. Back up the data to a spare drive, Use the mdadm --grow command to change the RAID level from RAID 1 to RAID 5, add the third drive to the RAID 5 array and let it rebuild.
Initially I was going to try option 2, such as described here. But noticing one of the comments (by the wonderfully named Svenne Krap) describing that you can just change the level of the array using the mdadm grow command, I thought it would warrant further investigation. I couldn't find many other mentions of it elsewhere on the internet, so I thought I'd document what I'd done so it might help someone else.
So to try it out, I set up a virtual machine on another PC, and created three separate drives. I used mdadm to create a RAID 1 array with two of them, and then converted that array to RAID 5. It worked! I then added the third drive, and after a little while it rebuilt into a full three disk array.
So the time came to do it for real. I first wanted to back up the array - and found an old 2TB drive lying around. Fortunately, the array was only just over two thirds full, so it all managed to squeeze on to the 2TB drive after I deleted a few old TV shows. That's still nearly 600 TV shows and movies left - I have no idea when I'll get around to watching them all, but it's nice to have.
So the data was safe. I could do this switchover with a little less stress.
One thing I noticed with the options was chunk size. Different sizes give different performance. Since this box would be primarily a media box, reading and writing large video files, I went for a larger chunk size of 512KB. When creating the array in the virtual machine initially, it created only 4KB chunks as the size of the array was not a multiple of 512KB. So first up, I resized the RAID 1 array so it was. Basically I divided the size reported by the cat /proc/mdstat command, by 512. It gave a number ending in .625, meaning there weren't an exact number of 512KB chunks. By multiplying that answer (minus .625) by 512, it gave a size that could work.
So I resized the array with the following command:
sudo mdadm -G /dev/md0 --size=2930266112
I then let mdadm know about the new drive, by adding it. The new drive is /dev/sde:
sudo mdadm /dev/md0 --add /dev/sde
Now there was a third drive added as a spare to the array, but not actually in use by it yet.
Next, the big one, change the array from RAID 1 to RAID 5 (still only 2 drives):
sudo mdadm /dev/md0 --grow --level=5 --chunk=512
The array is now a RAID 5 array, with two disks. The chunk size of 512KB was also set with that command. Time to let it use the third drive to create the full, three disk RAID 5 array:
sudo mdadm --grow /dev/md0 --raid-devices 3
This kicks off the rebuilding process, which takes many hours. You can track the progress with the cat /proc/mdstat command. It ran pretty slowly on my system, at around 30,000KB/sec, until it got to the empty part of the array, when speed nearly tripled.
Later that day, the process was finished. Running sudo mdadm --detail /dev/md0 gave the new array size of about 5.4TiB - something I was a little concerned about while the rebuild was underway, because it was only showing the old size of less than 3TB. I thought I might have to resize the array afterwards, but it all came out good.
Resizing LVM
Because I was running LVM on top of the raid array, the size of the LVM volume was still unchanged - I had to increase that to let it use the extra space that was now available. Going by the size reported by the mdadm --detail command run previoulsy, there were approximately 5588GB in the array. LVM works with three 'layers' - the physical volume, basically the hard drive or RAID array; volume groups, which consist of a number of logical volumes. See here for more information. The first step is to resize the physical volume to match the size of the array:
sudo pvresize --setphysicalvolumesize 5588G /dev/md0
Next, I could extend the logical volumes to use up more of that space. I have two main logical volumes on this volume group: one called 'tv' that holds TV shows, movies, and music from MythTV, and another called 'sysbackup' that holds backups of data. I wanted to enlarge both of these - the 'tv' one, and also 'sysbackup' because I wanted to use it with Crashplan as a backup destination for some other PCs in the house.
I wanted to increase the 'sysbackup' volume to 1.2TB, so I used the following command:
sudo lvextend -L1.2T /dev/raid1/sysbackup
A couple of things to note here: the '-L1.2T' instructs it to make the total size of the volume 1.2 Terabytes. Also, the name of the volume group is still /dev/raid1 - I haven't changed the name of that, even though it is now RAID 5. It can be done with the vgrename command, but it would also mean changing mount points in the /etc/fstab file.
Next was the resizing of the 'tv' volume. I wanted to increase it by 1.6TB, so I used the following command:
sudo lvextend -L+1.6T /dev/raid1/tv
Notice the '-L+1.6T' - the plus sign commands it to expand the volume by the specified amount. Unfortunately, it reported that there wasn't 1.6TB spare, and gave a number of available extents that were free. So I tried a different approach, specifying size in extents rather than TB:
sudo lvextend -l+418800 /dev/raid1/tv
The lower-case 'l' instructs it to use extents rather than GB, TB or whatever. This worked, and I now had two newly-resized logical volumes.
Resizing the file systems
But there was one final step - the logical volumes were now bigger, but the file systems did not know about it yet. Fortunately it isn't too difficult.
The sysbackup volume was formatted with the ext4 file system. To resize that, it first had to be unmounted:
sudo umount /mnt/sysbackup
Then a check of the file system was done:
sudo e2fsck -f /dev/raid1/sysbackup
Then finally, the file system was resized to fill the available space:
sudo resize2fs /dev/raid1/sysbackup
Finally, the file system can be re-mounted. Since it is specified in the /etc/fstab file, running
sudo mount -a
did the trick. Next was the 'tv' volume. This volume was formatted with the XFS file system, and it can be resized while still mounted. The command for that was:
sudo xfs_growfs /dev/raid1/tv
Conclusion
The advantage of using the mdadm --grow command is that it is still the same array according to mdadm, just a different level. Running
sudo mdadm --detail --scan
shows that the array still has the same identifiers as when it was a RAID 1 array, so no further work is required. I ran
sudo update-initramfs -u
just in case, so it would pick up any changes in the array (and not give it a name like /dev/md127 after a reboot). I restarted the PC, and everything came back up, with the roomy new array showing up as it should. Done!
There are a few ways to do this:
1. Copy the data to a spare drive, delete the RAID 1 array, create the RAID 5 array with the three disks, copy the data back to it.
2. Back up the data to a spare drive, remove one disk from the RAID 1 array, use that disk and the new disk to make a 2 disk RAID 5 array, copy data over, remove the RAID 1 array and add that disk to the RAID 5 array so it is 3 disks.
3. Back up the data to a spare drive, Use the mdadm --grow command to change the RAID level from RAID 1 to RAID 5, add the third drive to the RAID 5 array and let it rebuild.
Initially I was going to try option 2, such as described here. But noticing one of the comments (by the wonderfully named Svenne Krap) describing that you can just change the level of the array using the mdadm grow command, I thought it would warrant further investigation. I couldn't find many other mentions of it elsewhere on the internet, so I thought I'd document what I'd done so it might help someone else.
So to try it out, I set up a virtual machine on another PC, and created three separate drives. I used mdadm to create a RAID 1 array with two of them, and then converted that array to RAID 5. It worked! I then added the third drive, and after a little while it rebuilt into a full three disk array.
So the time came to do it for real. I first wanted to back up the array - and found an old 2TB drive lying around. Fortunately, the array was only just over two thirds full, so it all managed to squeeze on to the 2TB drive after I deleted a few old TV shows. That's still nearly 600 TV shows and movies left - I have no idea when I'll get around to watching them all, but it's nice to have.
So the data was safe. I could do this switchover with a little less stress.
One thing I noticed with the options was chunk size. Different sizes give different performance. Since this box would be primarily a media box, reading and writing large video files, I went for a larger chunk size of 512KB. When creating the array in the virtual machine initially, it created only 4KB chunks as the size of the array was not a multiple of 512KB. So first up, I resized the RAID 1 array so it was. Basically I divided the size reported by the cat /proc/mdstat command, by 512. It gave a number ending in .625, meaning there weren't an exact number of 512KB chunks. By multiplying that answer (minus .625) by 512, it gave a size that could work.
So I resized the array with the following command:
sudo mdadm -G /dev/md0 --size=2930266112
I then let mdadm know about the new drive, by adding it. The new drive is /dev/sde:
sudo mdadm /dev/md0 --add /dev/sde
Now there was a third drive added as a spare to the array, but not actually in use by it yet.
Next, the big one, change the array from RAID 1 to RAID 5 (still only 2 drives):
sudo mdadm /dev/md0 --grow --level=5 --chunk=512
The array is now a RAID 5 array, with two disks. The chunk size of 512KB was also set with that command. Time to let it use the third drive to create the full, three disk RAID 5 array:
sudo mdadm --grow /dev/md0 --raid-devices 3
This kicks off the rebuilding process, which takes many hours. You can track the progress with the cat /proc/mdstat command. It ran pretty slowly on my system, at around 30,000KB/sec, until it got to the empty part of the array, when speed nearly tripled.
Later that day, the process was finished. Running sudo mdadm --detail /dev/md0 gave the new array size of about 5.4TiB - something I was a little concerned about while the rebuild was underway, because it was only showing the old size of less than 3TB. I thought I might have to resize the array afterwards, but it all came out good.
Resizing LVM
Because I was running LVM on top of the raid array, the size of the LVM volume was still unchanged - I had to increase that to let it use the extra space that was now available. Going by the size reported by the mdadm --detail command run previoulsy, there were approximately 5588GB in the array. LVM works with three 'layers' - the physical volume, basically the hard drive or RAID array; volume groups, which consist of a number of logical volumes. See here for more information. The first step is to resize the physical volume to match the size of the array:
sudo pvresize --setphysicalvolumesize 5588G /dev/md0
Next, I could extend the logical volumes to use up more of that space. I have two main logical volumes on this volume group: one called 'tv' that holds TV shows, movies, and music from MythTV, and another called 'sysbackup' that holds backups of data. I wanted to enlarge both of these - the 'tv' one, and also 'sysbackup' because I wanted to use it with Crashplan as a backup destination for some other PCs in the house.
I wanted to increase the 'sysbackup' volume to 1.2TB, so I used the following command:
sudo lvextend -L1.2T /dev/raid1/sysbackup
A couple of things to note here: the '-L1.2T' instructs it to make the total size of the volume 1.2 Terabytes. Also, the name of the volume group is still /dev/raid1 - I haven't changed the name of that, even though it is now RAID 5. It can be done with the vgrename command, but it would also mean changing mount points in the /etc/fstab file.
Next was the resizing of the 'tv' volume. I wanted to increase it by 1.6TB, so I used the following command:
sudo lvextend -L+1.6T /dev/raid1/tv
Notice the '-L+1.6T' - the plus sign commands it to expand the volume by the specified amount. Unfortunately, it reported that there wasn't 1.6TB spare, and gave a number of available extents that were free. So I tried a different approach, specifying size in extents rather than TB:
sudo lvextend -l+418800 /dev/raid1/tv
The lower-case 'l' instructs it to use extents rather than GB, TB or whatever. This worked, and I now had two newly-resized logical volumes.
Resizing the file systems
But there was one final step - the logical volumes were now bigger, but the file systems did not know about it yet. Fortunately it isn't too difficult.
The sysbackup volume was formatted with the ext4 file system. To resize that, it first had to be unmounted:
sudo umount /mnt/sysbackup
Then a check of the file system was done:
sudo e2fsck -f /dev/raid1/sysbackup
Then finally, the file system was resized to fill the available space:
sudo resize2fs /dev/raid1/sysbackup
Finally, the file system can be re-mounted. Since it is specified in the /etc/fstab file, running
sudo mount -a
did the trick. Next was the 'tv' volume. This volume was formatted with the XFS file system, and it can be resized while still mounted. The command for that was:
sudo xfs_growfs /dev/raid1/tv
Conclusion
The advantage of using the mdadm --grow command is that it is still the same array according to mdadm, just a different level. Running
sudo mdadm --detail --scan
shows that the array still has the same identifiers as when it was a RAID 1 array, so no further work is required. I ran
sudo update-initramfs -u
just in case, so it would pick up any changes in the array (and not give it a name like /dev/md127 after a reboot). I restarted the PC, and everything came back up, with the roomy new array showing up as it should. Done!
Monday, March 16, 2015
HTPC update - separating backend from frontend
After using the Atom-based HTPC for a while, I noticed it start to struggle in high load situations - like playing back HD TV while recording multiple streams, commercial flagging, trying picture-in -picture, running disk checks. I decided to upgrade the box to something a bit more powerful, so there’s a bit more headroom.
So a while back I picked up an AsRock H77-M motherboard, with a cheap Pentium G2020 CPU. 4GB of RAM was sitting around idle after a previous desktop PC upgrade, so in that went. Two, 3GB drives were installed, still in a RAID-1 configuration. The OS was installed on an SSD that was left over. Graphics were handled by an Nvidia GT630 card, made by ASUS. I chose that one because of the passive cooler, and the fact that it is quite power efficient for what it does. A TP-Link wireless card was put in so it could see the network.
For the operating system, I went with Mythbuntu 12.04 again. Installation went pretty straightforward. No real problems, TV listing data was handled by the excellent shepherd - that just does its own thing, causing very little trouble.
Playback worked beautifully on this machine - it handled everything I could throw at it. However, my curiosity was getting the better of me, so I dug out the old Atom box and reinstalled mythbuntu, this time running just as a frontend. That made quite a bit of difference - without all the overhead of doing all the database tasks, flagging commercials and the like, it ran beautifully.
Since I had recently had some network cabling installed in the house, I tried running the new box as a backend only, up in the study, with just the Atom frontend in the lounge. Without any worries about wifi dropping out, the nice fast, stable wired network connection supplied data from the backend nicely.
It ran like that for a while, but then I started thinking that there are now three points of failure instead of one. Where previously there was just the Pentium backend/frontend to troubleshoot, there was now also the frontend box, plus the router that could cause problems. Eventually I put the frontend box back away.
I’m not sure what made me do it, but soon after getting a new TV (LCD! HDMI inputs! No more fooling around with xorg.conf and custom modelines and VGA to Component transcoders!) I wanted to clear out a bit of clutter from the lounge room. Moving the big box meant I could get rid of a whole heap of things from the lounge - the UPS, the transcoder (not needed any more), the aerial connection with splitter and the external TV tuners. All of the bulky component cables are no longer needed, either, replaced by a single HDMI cable.
So up to the study the box went, along with all the tuners and UPS, but they have been tucked away behind the desk, out of sight. The lounge room now just has a power cable to the frontend box, a network cable, an optical cable to the receiver, and the HDMI cable to the TV.
For now, I’m just rebooting the router every few weeks, or whenever there is some sort of issue like PCs not being able to access the internet. A lot of data is now going across it with TV viewing.
The backend box was able to have the graphics card removed from it, as it is now running headless. I only connect to the machine via ssh. That has saved a bit of power consumption. Another change made to the backend box has been to add a second SSD, to run the OS off a RAID-1 array. This way, a drive failure will not stop the machine. It will run in a degraded state until a new one can be installed.
I did the same with the frontend box - a couple of old laptop drives were pressed into service for that. Both are pretty elderly, but since they are in RAID-1, unless they both die at the same time, it should be safe. And really, it’s only a frontend, it wouldn’t be too much of a hassle to rebuild it from scratch if needed. I’m considering replacing those drives with a couple of USB sticks, to further reduce power consumption.
For the backend box, disk usage is sitting at around 65%. I’ve been copying some of my DVD library to the server, just to avoid dealing with physical discs. I don’t actually have a DVD drive in the frontend, anyway. If space gets tight, I might need to expand storage. I’m toying with getting a third 3TB drive, and converting the system to either RAID-5, or going a bit radical and putting ZFS on Linux back on it. My only concern with that is that it can have issues with fragmentation, and my PC doesn’t use ECC RAM. A lot of memory is also used for caching purposes with ZFS.
One thing I am wondering about with my current XFS file system is to do with fragmentation. I currently have a cron script to defragment it nearly every morning. Not sure what the deal is with RAID-5, and how it deals with fragmentation. Might just have to try it and see, when I get around to it. Might just go with ext4 for the file system. Outright performance isn’t so much of an issue for this machine - video recording and playback isn’t pushing it too much.
Saturday, October 26, 2013
Laptop keyboard stopped working after upgrade to Lubuntu 13.10...fixed
I have a fairly old LG laptop (circa 2007) that I have been running Lubuntu on. It is a lighter-weight version of Ubuntu, that uses the LXDE desktop rather than Gnome. Performance is reasonable with it. Anyway, since this is sort of the guinea-pig of all my systems, I thought I'd upgrade it to the latest version of Lubuntu (my other systems are still on the 12.04 LTS releases).
The upgrade went pretty smoothly, it has to be said. It was only when I got to the login screen and tried to type my password that things went wrong - I couldn't type anything. None of the keys worked, not even Control or F1, so I could switch to a text console. The touchpad and left/right click buttons were still working, and the keyboard still worked in the Grub boot menu.
A bit of head scratching, and plugging in a separate USB keyboard allowed me to type again. But that isn't quite an optimal solution. A bit of Googling led me to the following bug report for someone else with an LG laptop. Going by the eighth comment in that, it turns out a couple of options have to be added to the grub menu, by editing the /etc/default/grub file. In my case, the file had the following line:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
I added two options to the end, so it became:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.nopnp=1 i8042.dumbkbd=1"
Saved the file, and ran sudo update-grub to let the changes apply, and rebooted. I am now typing this blog post on the working laptop keyboard!
The upgrade went pretty smoothly, it has to be said. It was only when I got to the login screen and tried to type my password that things went wrong - I couldn't type anything. None of the keys worked, not even Control or F1, so I could switch to a text console. The touchpad and left/right click buttons were still working, and the keyboard still worked in the Grub boot menu.
A bit of head scratching, and plugging in a separate USB keyboard allowed me to type again. But that isn't quite an optimal solution. A bit of Googling led me to the following bug report for someone else with an LG laptop. Going by the eighth comment in that, it turns out a couple of options have to be added to the grub menu, by editing the /etc/default/grub file. In my case, the file had the following line:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
I added two options to the end, so it became:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.nopnp=1 i8042.dumbkbd=1"
Saved the file, and ran sudo update-grub to let the changes apply, and rebooted. I am now typing this blog post on the working laptop keyboard!
Monday, November 26, 2012
Adding a larger drive to a RAID array - ZFS
If you have waded through my previous post about adding a larger drive to an lvm volume running on an mdadm RAID array, you'll have seen it's a bit of a fiddly, complex process. I have been fiddling around a bit with ZFS on Linux on my old desktop machine (Core 2 Quad Q9300, 8GB RAM). I had a couple of old 1TB drives, and added the 2TB drive that I removed from the home theatre PC, mentioned in the previous post. Actually, I had put the 3TB drive in this old box initially, intending it to replace the HTPC. But it's a bit power hungry, using around 90W at idle, and I am having some niggling playback issues with it. But that's another story. So the 3TB WD Red drive gets replaced with the old Samsung 2TB.
With the three drives, I tried creating a ZFS raidz array, basically equivalent to RAID 5. It runs pretty well. Swapping the drives over (from 3TB to 2TB) gave me an opportunity to do the ZFS version of a drive swap.
It was a bit of an anticlimax, really. There was one command, the syntax from the man page is below:
zpool replace [-f] pool device [new_device]
In my case it was something like
sudo zpool replace tank /dev/disk/by-id/scsi-SATA...(the drive removed) /dev/disk/by-id/scsi-SATA....(the 2TB drive)
That started off the resilvering process (resynchronising the data across the drives). If I then were to replace each other drive, one at a time, with the above process, it would resize the array to match the new drive sizes.
The beauty of ZFS is it simplifies things so much. It is the RAID management and file system all in one.
I would have liked to run it in the HTPC, but ZFS is quite resource-hungry, in terms of processing power and memory. Since my HTPC just has a little Atom 330 chip and is maxed out with 4GB of memory (of which only 3GB is visible), I would be staying with mdadm and lvm. There is virtually no noticeable performance penalty with it. Oh well, going through all those steps is not exactly a frequent task.
With the three drives, I tried creating a ZFS raidz array, basically equivalent to RAID 5. It runs pretty well. Swapping the drives over (from 3TB to 2TB) gave me an opportunity to do the ZFS version of a drive swap.
It was a bit of an anticlimax, really. There was one command, the syntax from the man page is below:
zpool replace [-f] pool device [new_device]
In my case it was something like
sudo zpool replace tank /dev/disk/by-id/scsi-SATA...(the drive removed) /dev/disk/by-id/scsi-SATA....(the 2TB drive)
That started off the resilvering process (resynchronising the data across the drives). If I then were to replace each other drive, one at a time, with the above process, it would resize the array to match the new drive sizes.
The beauty of ZFS is it simplifies things so much. It is the RAID management and file system all in one.
I would have liked to run it in the HTPC, but ZFS is quite resource-hungry, in terms of processing power and memory. Since my HTPC just has a little Atom 330 chip and is maxed out with 4GB of memory (of which only 3GB is visible), I would be staying with mdadm and lvm. There is virtually no noticeable performance penalty with it. Oh well, going through all those steps is not exactly a frequent task.
Adding a larger drive to a software RAID array - mdadm and lvm
The MythTV box I have in the lounge previously had two storage hard drives, in a RAID 1 configuration to prevent data loss in case of a drive failure. The drives were a 3TB Hitachi and a 2TB Samsung. I figured the Samsung drive was getting on a bit now, and it was time a new drive was installed. Might as well make it a 3TB model as well, to take advantage of all the space available on the other one that was sitting unused.
A 3TB Western Digital Red drive was picked up. I chose this as it is designed for use in a NAS environment: always on. It also has low power consumption and a good warranty. I considered a Seagate Barracuda 3TB - they were cheap, performance would be better than the Red, but they are only designed for desktop use, around 8 hours a day powered on. Warranty was pretty short as well.
Removing and replacing the old drive
The drives were configured in a software RAID 1 array, using mdadm, with lvm on top of that. This makes the array portable, and not dependent on a particular hardware controller.
The commands here were adapted from the excellent instructions found here at howtoforge.com.
Fortunately I had enough space on another PC that I was able to back up the contents of the array before starting any of this.
To remove the old drive, which on this machine was /dev/sdc, the following command was issued to mark the drive as failed, in the array /dev/md0:
sudo mdadm --manage /dev/md0 --fail /dev/sdc
Next step is to remove the drive from the array:
sudo mdadm --manage /dev/md0 --remove /dev/sdc
Then, the system could be shut down and the drive removed and replaced with the new one. After powering the system back up, the following command adds the new drive to the array:
sudo mdadm --manage /dev/md0 --add /dev/sdc
The array will then start synchronising the data, copying it to the new drive, which could take a few hours. Note that no partitioning was done on the disk, as I am just using the whole drive in the array.
While the sync is in progress, you can check how it is progressing via:
cat /proc/mdstat
It will show a percentage of completion as well as an estimated time remaining. Once it is done, the array is ready for use! I left the array like this for a day or so, just to make sure everything was working alright.
Expanding the array to fill the space available - the mdadm part
Once the synchronisation has completed, the size of the array was still only 2TB, since that is the largest a RAID 1 array could go when it consists of a 3TB and a 2TB drive. We need to tell mdadm to expand the array to fill the available space. More information on this can be found here.
This is where things got complicated for me. It is to do with the superblock format version used in the array. More detail can be found at this page of the Linux RAID wiki.
To sum up, the array I had was created with the version 0.90 superblock. The version was found by entering
sudo mdadm --detail /dev/md0
The problem, potentially, was that if I grew the array to larger than 2TB it may not work. As quoted by the wiki link above:
Now, Mythbuntu 12.04 runs the 3.2 kernel, so according to that it should be OK supporting up to 4TB. But I wasn't 100% sure on that, and couldn't find any references elsewhere about it. I decided the safest way to go about this was to convert the array to a later version of the superblock, that didn't have that size limitation. Besides, it would save time in the future in case of trying to repeat this with a drive larger than 4TB.
Following the suggestion of the wiki, I decided to update to a version 1.0 superblock, as it would store the superblock information in the same place as the 0.90.
Note: if you are trying this yourself, and the array is already version 1.0 or later, then the command to grow it is just as below (may not want to do it with 0.90 superblock and larger than 2TB):
mdadm --grow /dev/md0 --size=max
Since I was going to change the superblock version, it involved stopping the array and recreating it with the later version.
Once again, to check the details of the array at the moment:
sudo mdadm --detail /dev/md0
Now, since the array is in use by MythTV, I thought it safest to stop the program:
sudo service mythtv-backend stop
Also, I unmounted where the array was mounted:
sudo umount /var/lib/mythtv
Since the data is in an LVM volume on top of the array, I deactivated that as well (the volume is named raid1 in this instance):
sudo lvchange -a n raid1
The array is now ready to be stopped:
sudo mdadm --stop /dev/md0
Now it can be re-created, specifying the metadata (superblock) version, the RAID level, and the number and names of the drives used:
sudo mdadm --create /dev/md0 --metadata=1.0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
The array will now start resynchronising. This took a number of hours for me, as there were around 770GB of recordings there. The RAID wiki link included --assume-clean in the above command, which would have skipped the resync. I elected to leave it out, for safety's sake.
Progress can be monitored with:
cat /proc/mdstat
The lvm volume can be restarted:
sudo lvchange -a y raid1
and the unmounted volumes can be re-mounted:
sudo mount -a
Check if they are all there with the
mount
command. The mythtv service can also be restarted:
sudo service mythtv-backend start
When the array is recreated, the UUID value of the array will be different. You can get the new value with:
sudo mdadm --detail /dev/md0
Edit the /etc/mdadm/mdadm.conf file, and change the UUID value in it to the new value. This will enable the array to be found on next boot.
Another thing to do before rebooting is to run
sudo update-initramfs -u
I didn't do this at first, and after rebooting, the array showed up named /dev/md127 rather than /dev/md0. Running the above command and rebooting again fixed it for me.
Expanding the array to fill the space available - the lvm part
Quite a long-winded process, isn't it? Using the lvm command to show the lvm physical volumes:
sudo pvdisplay
showed the array was still 1.82TiB (2TB). It needed to be extended. The following command will fill the volume to the available space:
sudo pvresize -v /dev/md0
To check the results, again run:
sudo pvdisplay
Now, running:
sudo vgdisplay
gave the following results for me:
--- Volume group ---
VG Name raid1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TiB
PE Size 4.00 MiB
Total PE 715397
Alloc PE / Size 466125 / 1.78 TiB
Free PE / Size 249272 / 973.72 GiB
VG UUID gvfheX-ifvl-yW9h-v4L2-eyzs-95fe-sng2oN
A 3TB Western Digital Red drive was picked up. I chose this as it is designed for use in a NAS environment: always on. It also has low power consumption and a good warranty. I considered a Seagate Barracuda 3TB - they were cheap, performance would be better than the Red, but they are only designed for desktop use, around 8 hours a day powered on. Warranty was pretty short as well.
Removing and replacing the old drive
The drives were configured in a software RAID 1 array, using mdadm, with lvm on top of that. This makes the array portable, and not dependent on a particular hardware controller.
The commands here were adapted from the excellent instructions found here at howtoforge.com.
Fortunately I had enough space on another PC that I was able to back up the contents of the array before starting any of this.
To remove the old drive, which on this machine was /dev/sdc, the following command was issued to mark the drive as failed, in the array /dev/md0:
sudo mdadm --manage /dev/md0 --fail /dev/sdc
Next step is to remove the drive from the array:
sudo mdadm --manage /dev/md0 --remove /dev/sdc
Then, the system could be shut down and the drive removed and replaced with the new one. After powering the system back up, the following command adds the new drive to the array:
sudo mdadm --manage /dev/md0 --add /dev/sdc
The array will then start synchronising the data, copying it to the new drive, which could take a few hours. Note that no partitioning was done on the disk, as I am just using the whole drive in the array.
While the sync is in progress, you can check how it is progressing via:
cat /proc/mdstat
It will show a percentage of completion as well as an estimated time remaining. Once it is done, the array is ready for use! I left the array like this for a day or so, just to make sure everything was working alright.
Expanding the array to fill the space available - the mdadm part
Once the synchronisation has completed, the size of the array was still only 2TB, since that is the largest a RAID 1 array could go when it consists of a 3TB and a 2TB drive. We need to tell mdadm to expand the array to fill the available space. More information on this can be found here.
This is where things got complicated for me. It is to do with the superblock format version used in the array. More detail can be found at this page of the Linux RAID wiki.
To sum up, the array I had was created with the version 0.90 superblock. The version was found by entering
sudo mdadm --detail /dev/md0
The problem, potentially, was that if I grew the array to larger than 2TB it may not work. As quoted by the wiki link above:
The version-0.90 superblock limits the number of component devices within an array to 28, and limits each component device to a maximum size of 2TB on kernel version [earlier than] 3.1 and 4TB on kernel version 3.1 [or later].
Now, Mythbuntu 12.04 runs the 3.2 kernel, so according to that it should be OK supporting up to 4TB. But I wasn't 100% sure on that, and couldn't find any references elsewhere about it. I decided the safest way to go about this was to convert the array to a later version of the superblock, that didn't have that size limitation. Besides, it would save time in the future in case of trying to repeat this with a drive larger than 4TB.
Following the suggestion of the wiki, I decided to update to a version 1.0 superblock, as it would store the superblock information in the same place as the 0.90.
Note: if you are trying this yourself, and the array is already version 1.0 or later, then the command to grow it is just as below (may not want to do it with 0.90 superblock and larger than 2TB):
mdadm --grow /dev/md0 --size=max
Since I was going to change the superblock version, it involved stopping the array and recreating it with the later version.
Once again, to check the details of the array at the moment:
sudo mdadm --detail /dev/md0
Now, since the array is in use by MythTV, I thought it safest to stop the program:
sudo service mythtv-backend stop
Also, I unmounted where the array was mounted:
sudo umount /var/lib/mythtv
Since the data is in an LVM volume on top of the array, I deactivated that as well (the volume is named raid1 in this instance):
sudo lvchange -a n raid1
The array is now ready to be stopped:
sudo mdadm --stop /dev/md0
Now it can be re-created, specifying the metadata (superblock) version, the RAID level, and the number and names of the drives used:
sudo mdadm --create /dev/md0 --metadata=1.0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
The array will now start resynchronising. This took a number of hours for me, as there were around 770GB of recordings there. The RAID wiki link included --assume-clean in the above command, which would have skipped the resync. I elected to leave it out, for safety's sake.
Progress can be monitored with:
cat /proc/mdstat
The lvm volume can be restarted:
sudo lvchange -a y raid1
and the unmounted volumes can be re-mounted:
sudo mount -a
Check if they are all there with the
mount
command. The mythtv service can also be restarted:
sudo service mythtv-backend start
When the array is recreated, the UUID value of the array will be different. You can get the new value with:
sudo mdadm --detail /dev/md0
Edit the /etc/mdadm/mdadm.conf file, and change the UUID value in it to the new value. This will enable the array to be found on next boot.
Another thing to do before rebooting is to run
sudo update-initramfs -u
I didn't do this at first, and after rebooting, the array showed up named /dev/md127 rather than /dev/md0. Running the above command and rebooting again fixed it for me.
Expanding the array to fill the space available - the lvm part
Quite a long-winded process, isn't it? Using the lvm command to show the lvm physical volumes:
sudo pvdisplay
showed the array was still 1.82TiB (2TB). It needed to be extended. The following command will fill the volume to the available space:
sudo pvresize -v /dev/md0
To check the results, again run:
sudo pvdisplay
Now, running:
sudo vgdisplay
gave the following results for me:
--- Volume group ---
VG Name raid1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TiB
PE Size 4.00 MiB
Total PE 715397
Alloc PE / Size 466125 / 1.78 TiB
Free PE / Size 249272 / 973.72 GiB
VG UUID gvfheX-ifvl-yW9h-v4L2-eyzs-95fe-sng2oN
Running:
sudo lvdisplay
gives the following result:
--- Logical volume ---
LV Name /dev/raid1/tv
VG Name raid1
LV UUID Dokbch-ZJkg-QmRW-d9vR-wfM8-BFxb-3Z0krs
LV Write Access read/write
LV Status available
# open 1
LV Size 1.70 TiB
Current LE 445645
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0
I have a couple of smaller logical volumes also in this volume group, that I have not shown. That's why there's a bit of a difference between the Alloc PE value in the volume group, and the Current LE value in the logical volume. As you can see from the lines shown in bold text, the volume group raid1 has 249272 physical extents (PE) free, and the logical volume /dev/raid1/tv is currently sized 445645. To use all space, I made the size 249272+445645, which is 694917.
The command to resize a logical volume is lvresize. Logical.
sudo lvresize -l 694917 /dev/raid1/tv
Alternatively, if you want to avoid all the maths, an alternative command is
sudo lvresize -l +100%FREE /dev/raid1/tv
That command just tells lvm to use 100% of the free space. I didn't try it myself (I only found it after running the command before it).
Now, after that has been run, to check the results, enter:
sudo lvdisplay
The results:
--- Logical volume ---
LV Name /dev/raid1/tv
VG Name raid1
LV UUID Dokbch-ZJkg-QmRW-d9vR-wfM8-BFxb-3Z0krs
LV Write Access read/write
LV Status available
# open 1
LV Size 2.65 TiB
Current LE 694917
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0
and
sudo vgdisplay
gives:
--- Volume group ---
VG Name raid1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 6
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 2.73 TiB
PE Size 4.00 MiB
Total PE 715397
Alloc PE / Size 715397 / 2.73 TiB
Free PE / Size 0 / 0
VG UUID gvfheX-ifvl-yW9h-v4L2-eyzs-95fe-sng2oN
No free space shown; the lvm volume group is using the whole mdadm array, which in turn is using the whole of the two disks.
The final step for me was to grow the partition that is on the logical volume. I had formatted it with XFS, as it is good with large video files. XFS allows increasing size on a mounted partition, so the command used was:
sudo xfs_growfs -d /var/lib/mythtv
Finally, it is complete!
Tuesday, August 21, 2012
Upgrading MythTV to Mythbuntu 12.04 64-bit
As described in the previous post, the time had come to upgrade my MythTV installation. It had been installed using Mythbuntu 10.10, 32-bit. I wanted to move to the most recent version, currently Mythbuntu 12.04. There were two options available to me: upgrading the current installation, or a new install of the latest version, and copying the previous MythTV database over to it. The first option was not too appealing. Doing a distribution upgrade is a fingers-crossed, hope-this-works process a good part of the time - although I have had pretty good fortune with it on my desktop PC. If I were to go this route, I couldn't just upgrade from 10.10 -> 12.04. It would have to be 10.10 -> 11.04 -> 11.10 -> 12.04. Three complete system upgrades in succession, which would likely leave a lot of cruft left over in the installation. Lots of points of failure. The final nail in the coffin was that I wanted to move to a 64-bit installation, to take advantage of the full 4GB of memory that was installed in the system.
So a clean install it was. To prepare, I copied a number of setup files to a safe place that wouldn't be overwritten during the install. Files like:
Not all the files would end up being needed, but I felt safer having them handy, just in case.
The installation process started from a USB stick loaded with the Mythbuntu 12.04 installer, since I don't have an optical drive in it. No room, with three drives already there. I also hooked up a monitor instead of a TV, because that needs extra setup to output to a component connection.
Since there was some left over free space on the SSD, I installed to that, leaving the 10.10 install intact for now. It went remarkably smoothly. One thing I noted was that at the beginning, there is an option to update the installer. I clicked that, and the system seemed to do nothing for quite a while. Opening up a terminal window and running "top" showed that it was in fact doing something, so I waited until it finished. Once done, the installation process could begin. It would have been nice for it to have some sort of indication that it was doing something, though.
Partway through the process, it prompted for what sort of remote control is being used. I selected "Windows Media Center remote", and the thing was set up automatically. Brilliant! Didn't need that LIRC setup file listed above.
To get the system outputting to my TV properly, I just copied the old xorg.conf file to the /etc/X11 directory (I renamed the existing file, in case I needed it again) and rebooted with a sense of hope and anxiety. A minute or so later, the screen came to life! It worked!
The big one, that I was dreading, was getting the RAID array to be seen by the new install. I still consider myself quite the mdadm novice, so I was pleasantly surprised to find that the RAID array was picked up by the new install quite easily - after installing mdadm and lvm2. This command:
sudo mdadm --assemble --scan
was all that was needed for it to scan for any drives, re-assemble the array, and write a new mdadm.conf file. Easy!
Next was seeing if LVM could find the volumes created. Running
sudo lvm pvscan
sudo lvm vgscan
sudo lvm lvscan
detected all the physical volumes, volume groups, and logical volumes, respectively. Mounting the logical volume that held the recordings was successful - I could see them all. Adding the device entry to /etc/fstab seemed to work, eventually. On the first reboot it came up with an error message, mentioning there were serious problems with the mount. Not sure what it was, but a reboot afterwards seemed to make it happy. I had installed xfsprogs, to manage and defragment XFS filesystems; maybe that helped.
Going through some of the MythTV screens brought up some error messages that it couldn't write to the drive - it turned out to be a permissions issue for the files and directories on the array. Entering
sudo chown -R mythtv:mythtv /var/lib/mythtv
changed the ownership back to the mythtv user, and it seemed happy again.
Bringing the previous database over was a painless process as well. I followed the instructions here and here and the new database came over without drama.
So far it all looks good. I may have a tweak of the VDPAU settings to see if playback can be improved any - it looks fine, but the settings have just been carried over from the previous 0.23 version. Things may have changed in the current 0.25 release.
Now that the system is updated to 12.04, which is a Long Term Support (LTS) release of Ubuntu, I won't be caught out with an obsolete version after 18 months like I was with 10.10.
As a side note, one of the main reasons for moving to 64-bit was because the Zotac IONITX-A-U motherboard, with an Atom 330, was only showing 3GB of RAM installed, even though I had two, 2GB sticks in there. I thought this was a 32 bit software issue. After installing the 64-bit OS, the free memory remained the same. Even in the BIOS, it only reported 3072MB. Strange. A bit of searching around revealed this thread on Zotac's supprt forums. As it turns out, if 4GB is installed, 512MB is reserved for system use, and then there is the amount used by the onboard Nvidia ION graphics - which I had set to the maximum allowed 512MB. So only 3GB visible. It's OK, it still runs fine, but it would have been nice to be able to use a little extra.
So a clean install it was. To prepare, I copied a number of setup files to a safe place that wouldn't be overwritten during the install. Files like:
- mdadm.conf, from /etc/mdadm, which had the RAID configuration information.
- xorg.conf, from /etc/X11, which had the custom modeline used to output to my (now ancient) CRT TV.
- ssmtp.conf, from /etc/ssmtp, for email notification in the case of errors.
- apcupsd.conf, from /etc/apcupsd, the setup of the APC UPS monitoring software.
- hardware.conf, from /etc/lirc, used by LIRC to set up the Media Centre remote control.
- the MythTV database password, from /etc/mythtv/config.xml
Not all the files would end up being needed, but I felt safer having them handy, just in case.
The installation process started from a USB stick loaded with the Mythbuntu 12.04 installer, since I don't have an optical drive in it. No room, with three drives already there. I also hooked up a monitor instead of a TV, because that needs extra setup to output to a component connection.
Since there was some left over free space on the SSD, I installed to that, leaving the 10.10 install intact for now. It went remarkably smoothly. One thing I noted was that at the beginning, there is an option to update the installer. I clicked that, and the system seemed to do nothing for quite a while. Opening up a terminal window and running "top" showed that it was in fact doing something, so I waited until it finished. Once done, the installation process could begin. It would have been nice for it to have some sort of indication that it was doing something, though.
Partway through the process, it prompted for what sort of remote control is being used. I selected "Windows Media Center remote", and the thing was set up automatically. Brilliant! Didn't need that LIRC setup file listed above.
To get the system outputting to my TV properly, I just copied the old xorg.conf file to the /etc/X11 directory (I renamed the existing file, in case I needed it again) and rebooted with a sense of hope and anxiety. A minute or so later, the screen came to life! It worked!
The big one, that I was dreading, was getting the RAID array to be seen by the new install. I still consider myself quite the mdadm novice, so I was pleasantly surprised to find that the RAID array was picked up by the new install quite easily - after installing mdadm and lvm2. This command:
sudo mdadm --assemble --scan
was all that was needed for it to scan for any drives, re-assemble the array, and write a new mdadm.conf file. Easy!
Next was seeing if LVM could find the volumes created. Running
sudo lvm pvscan
sudo lvm vgscan
sudo lvm lvscan
detected all the physical volumes, volume groups, and logical volumes, respectively. Mounting the logical volume that held the recordings was successful - I could see them all. Adding the device entry to /etc/fstab seemed to work, eventually. On the first reboot it came up with an error message, mentioning there were serious problems with the mount. Not sure what it was, but a reboot afterwards seemed to make it happy. I had installed xfsprogs, to manage and defragment XFS filesystems; maybe that helped.
Going through some of the MythTV screens brought up some error messages that it couldn't write to the drive - it turned out to be a permissions issue for the files and directories on the array. Entering
sudo chown -R mythtv:mythtv /var/lib/mythtv
changed the ownership back to the mythtv user, and it seemed happy again.
Bringing the previous database over was a painless process as well. I followed the instructions here and here and the new database came over without drama.
So far it all looks good. I may have a tweak of the VDPAU settings to see if playback can be improved any - it looks fine, but the settings have just been carried over from the previous 0.23 version. Things may have changed in the current 0.25 release.
Now that the system is updated to 12.04, which is a Long Term Support (LTS) release of Ubuntu, I won't be caught out with an obsolete version after 18 months like I was with 10.10.
As a side note, one of the main reasons for moving to 64-bit was because the Zotac IONITX-A-U motherboard, with an Atom 330, was only showing 3GB of RAM installed, even though I had two, 2GB sticks in there. I thought this was a 32 bit software issue. After installing the 64-bit OS, the free memory remained the same. Even in the BIOS, it only reported 3072MB. Strange. A bit of searching around revealed this thread on Zotac's supprt forums. As it turns out, if 4GB is installed, 512MB is reserved for system use, and then there is the amount used by the onboard Nvidia ION graphics - which I had set to the maximum allowed 512MB. So only 3GB visible. It's OK, it still runs fine, but it would have been nice to be able to use a little extra.
My MythTV system - the story so far
For the past 18 moths or so I've been running a MythTV system in the lounge, which has been an excellent performer. It has liberated us from TV advertisements and from having to be home in time to watch a particular show. It has been slowly enhanced and upgraded over that time to be quite a capable machine, exceeding what could be purchased from a store.
Following on from one of the earlier build posts, one thing done was purchasing a larger wireless antenna. For under $20, it allowed the antenna to be moved to a position with better reception to the wireless router, and with a stronger signal. There have been very few connection dropouts since putting that in. The eventual goal is to have a hard-wired ethernet connection, but that will be some time down the track if I ever get the house wired up for it.
Another issue was with a hard drive upgrade. Originally with the 2TB Samsung disk, I upgraded it to a Hitachi 5K3000 3TB drive. It ran well for about three months, but then I came down to the lounge one morning and the system wasn't happy. There were drive errors of one kind or another. I grabbed the 2TB Samsung drive again (which had been serving a happy retirement in my desktop PC), and luckily was able to copy all the recordings over to it. It was fortunate that I hadn't filled the extra space either.
So the system was back to its original storage drive, until the warranty fix came back from Hitachi. About three weeks later, a replacecment drive showed up - this time it was a 3TB 7K3000, the next model up. Also, since this happened after the Thailand floods, one of those drives was now worth nearly $400, quite a bit different from the ~$160 I paid.
Now I had a refurbished 3TB drive and a 2TB drive with a year's heavy usage already on it. This made me a little nervous. It was time to move to a RAID1 system. I used the linux mdadm software RAID, with some LVM volumes on top of it. It is a while back now, but the install went OK I can't quite remember the tutorial I used, but these two have quite a lot of information on doing so. The performance hit from running RAID and LVM was not noticeable on the system, either. If desired, you can also set up email notifications if a drive fails or some other problem arises with the array - see here, here and here. One thing to note if you use gmail to send the notifications: if your password has a "#"in it, ssmtp will read the rest of the line as a comment and you'll get all sorts of strange errors. Oh yes, it's best to set up a secondary gmail account to do this, with nothing important in it, since you have to keep the password in a text file.
Since the system worked well, I didn't bother with updating it. It wasn't open to the wider internet (to access via MythWeb). But it was time for a change, and Mythbuntu 10.10 was no longer supported. It was time for an upgrade to a newer version - which will be detailed in another post.
Following on from one of the earlier build posts, one thing done was purchasing a larger wireless antenna. For under $20, it allowed the antenna to be moved to a position with better reception to the wireless router, and with a stronger signal. There have been very few connection dropouts since putting that in. The eventual goal is to have a hard-wired ethernet connection, but that will be some time down the track if I ever get the house wired up for it.
Another issue was with a hard drive upgrade. Originally with the 2TB Samsung disk, I upgraded it to a Hitachi 5K3000 3TB drive. It ran well for about three months, but then I came down to the lounge one morning and the system wasn't happy. There were drive errors of one kind or another. I grabbed the 2TB Samsung drive again (which had been serving a happy retirement in my desktop PC), and luckily was able to copy all the recordings over to it. It was fortunate that I hadn't filled the extra space either.
So the system was back to its original storage drive, until the warranty fix came back from Hitachi. About three weeks later, a replacecment drive showed up - this time it was a 3TB 7K3000, the next model up. Also, since this happened after the Thailand floods, one of those drives was now worth nearly $400, quite a bit different from the ~$160 I paid.
Now I had a refurbished 3TB drive and a 2TB drive with a year's heavy usage already on it. This made me a little nervous. It was time to move to a RAID1 system. I used the linux mdadm software RAID, with some LVM volumes on top of it. It is a while back now, but the install went OK I can't quite remember the tutorial I used, but these two have quite a lot of information on doing so. The performance hit from running RAID and LVM was not noticeable on the system, either. If desired, you can also set up email notifications if a drive fails or some other problem arises with the array - see here, here and here. One thing to note if you use gmail to send the notifications: if your password has a "#"in it, ssmtp will read the rest of the line as a comment and you'll get all sorts of strange errors. Oh yes, it's best to set up a secondary gmail account to do this, with nothing important in it, since you have to keep the password in a text file.
Since the system worked well, I didn't bother with updating it. It wasn't open to the wider internet (to access via MythWeb). But it was time for a change, and Mythbuntu 10.10 was no longer supported. It was time for an upgrade to a newer version - which will be detailed in another post.
Tuesday, October 18, 2011
Ubuntu 11.10 - Getting KeePass2 working with Chrome again
Rather rashly this time around, I updated my system to the latest version of Ubuntu, 11.10, the day it came out. The upgrade itself went fairly smoothly, although I was disappointed to find that the plugin that links my password manager of choice, Keepass2 with my browser of choice, Google Chrome, stopped working. It just popped up an error box saying it didn't recognise the plugin any more. KeePass still worked, it just was no longer able to communicate with Chrome.
After a bit of searching I couldn't find anyone else with the same issue, and I stumbled upon this answer almost by accident. The secret is that the KeePassHttp.plgx plugin, which is what used to work with Ubuntu 11.04, is not what you want any more. What you do want are two .dll files instead. I went through the following steps to get it working again:
1. From the KeePassHttp website, I downloaded the whole package (it gives a choice of a .zip or tar.gz), click either button. Ignore that the page says "Sorry, there aren't any downloads for this repository." There are!
2. Open the package file you just downloaded - double-clicking it will open it in Archive Manager.
3. Open some of the subdirectories in that folder until you find the two files called "KeePassHttp.dll" and "Newtonsoft.Json.dll". Select those two files and drag them to the Desktop. This will extract those two files, making them ready for the next step.
4. Open up a terminal window. Assuming the files are on your desktop, you can use the following command to copy them to the /usr/lib/keepass2 directory:
sudo cp ~/Desktop/*.dll /usr/lib/keepass2
While you are in a terminal window, rename the KeePassHttp.plgx file so KeePass doesn't throw that error up when you open it:
sudo mv /usr/lib/keepass2/KeePassHttp.plgx \ /usr/lib/keepass2/KeePassHttp.plgx.temp
5. If you now open KeePass2, it shouldn't throw up the error box, and if you go to Tools -> Plugins... the plugin should now appear!
One other thing I did was re-install KeePass2. With the latest release, there is no need to use the separate PPA repository as you did in previous versions of Ubuntu. It is now in the main Universe repository. What I did was uninstall KeePass2, remove the jtaylor PPA repository under software sources (either in update manager or synaptic, if you have that installed), and re-install it from the default Ubuntu repository.
I'm not sure if this is needed for the above solution to work, but I did it just to tidy things up a bit. With less repositories to check, updates go a bit quicker too. With any luck it will also install the correct packages required, that may have changed since 11.04.
After a bit of searching I couldn't find anyone else with the same issue, and I stumbled upon this answer almost by accident. The secret is that the KeePassHttp.plgx plugin, which is what used to work with Ubuntu 11.04, is not what you want any more. What you do want are two .dll files instead. I went through the following steps to get it working again:
1. From the KeePassHttp website, I downloaded the whole package (it gives a choice of a .zip or tar.gz), click either button. Ignore that the page says "Sorry, there aren't any downloads for this repository." There are!
2. Open the package file you just downloaded - double-clicking it will open it in Archive Manager.
3. Open some of the subdirectories in that folder until you find the two files called "KeePassHttp.dll" and "Newtonsoft.Json.dll". Select those two files and drag them to the Desktop. This will extract those two files, making them ready for the next step.
4. Open up a terminal window. Assuming the files are on your desktop, you can use the following command to copy them to the /usr/lib/keepass2 directory:
sudo cp ~/Desktop/*.dll /usr/lib/keepass2
While you are in a terminal window, rename the KeePassHttp.plgx file so KeePass doesn't throw that error up when you open it:
sudo mv /usr/lib/keepass2/KeePassHttp.plgx \ /usr/lib/keepass2/KeePassHttp.plgx.temp
5. If you now open KeePass2, it shouldn't throw up the error box, and if you go to Tools -> Plugins... the plugin should now appear!
One other thing I did was re-install KeePass2. With the latest release, there is no need to use the separate PPA repository as you did in previous versions of Ubuntu. It is now in the main Universe repository. What I did was uninstall KeePass2, remove the jtaylor PPA repository under software sources (either in update manager or synaptic, if you have that installed), and re-install it from the default Ubuntu repository.
I'm not sure if this is needed for the above solution to work, but I did it just to tidy things up a bit. With less repositories to check, updates go a bit quicker too. With any luck it will also install the correct packages required, that may have changed since 11.04.
Monday, July 11, 2011
Follow-up on 11.04
Well, it's been quite some time now using Ubuntu 11.04. What are my thoughts of using the Unity interface?
Let's put it this way - I've switched back to Ubuntu Classic and have almost forgotten about Unity. Just didn't enjoy it. It was especially clunky when running two screens, with the icon bar down the left side of the screen. That icon bar had a name, didn't it? I've forgotten, it's been pushed out of my memory.
In recent weeks, I've tried out CrunchBang Linux on the laptop. It's a minimal, stripped-down distro based on Debian. It's nice and quick on that, and I'm quite warming to the way the Openbox window manager does things. Being a lightweight distro, there are things that aren't in an Ubuntu install, like a suspend function. I have to do some research into enabling that - whether something has to be installed or not.
Not sure on whether I would put it on the desktop yet. For one, it is based on a fairly old 2.6.32 kernel, that doesn't fully support the solid-state drives' TRIM command. There is an experimental kernel that is an option that comes up when you first install - the "cb-welcome" script is excellent, asking whether to install various commonly-used programs.
One other thing is whether DigiKam would install properly. I have it installed, grudgingly, on this Ubuntu system because it's the next best thing to forking out big bucks on Bibble or Adobe Lightroom. Grudgingly, because it's a KDE program, a buttload of extra KDE-related cruft is installed along with it. I don't want to clog up a nice, fast Crunchbang install with that.
We'll see.
Let's put it this way - I've switched back to Ubuntu Classic and have almost forgotten about Unity. Just didn't enjoy it. It was especially clunky when running two screens, with the icon bar down the left side of the screen. That icon bar had a name, didn't it? I've forgotten, it's been pushed out of my memory.
In recent weeks, I've tried out CrunchBang Linux on the laptop. It's a minimal, stripped-down distro based on Debian. It's nice and quick on that, and I'm quite warming to the way the Openbox window manager does things. Being a lightweight distro, there are things that aren't in an Ubuntu install, like a suspend function. I have to do some research into enabling that - whether something has to be installed or not.
Not sure on whether I would put it on the desktop yet. For one, it is based on a fairly old 2.6.32 kernel, that doesn't fully support the solid-state drives' TRIM command. There is an experimental kernel that is an option that comes up when you first install - the "cb-welcome" script is excellent, asking whether to install various commonly-used programs.
One other thing is whether DigiKam would install properly. I have it installed, grudgingly, on this Ubuntu system because it's the next best thing to forking out big bucks on Bibble or Adobe Lightroom. Grudgingly, because it's a KDE program, a buttload of extra KDE-related cruft is installed along with it. I don't want to clog up a nice, fast Crunchbang install with that.
We'll see.
Thursday, May 12, 2011
Thoughts on Ubuntu 11.04 and Unity
After waiting for a few weeks until the commotion died down somewhat, I thought I would have a look at the latest version of Ubuntu, version 11.04, codenamed Natty Narwhal. A major feature of this release is the new desktop environment/interface, known as Unity. This has created a lot of controversy on the internet, which initially made me hesitant to upgrade. Lots of people have complained that it removes a lot of functionality, that things are not where they once were, and so on. I thought that rather than just stick with the old version stubbornly, or switch to the KDE environment, I would actually install it and use it for a week or two, before passing judgement.
First of all, I used my laptop as a guinea pig. There is nothing of importance on it that isn’t backed up elsewhere, so if everything got hosed it would not be too much of a drama to do a clean install. Bringing up the update manager, I clicked the “Upgrade Now” button that has been teasing me for the last few weeks. The upgrade process started, and I left it to its own devices to scan the system, download, install and configure the latest versions of everything.
Much to my pleasure, when it was finished and after rebooting, the system actually started and loaded up the shiny new Unity desktop. All the effects were running, and this is machine had a fairly old ATI card and runs the open-source radeon drivers. It’s a bit of a departure from previous versions of Ubuntu, so I can see the concern other users have. A bit of experimental clicking around brought up my first problem - how do I launch more than one instance of a program, such as the terminal window? Clicking the terminal button on the side pane (which was there because it was configured as a button on the task bar on the previous install, along with Chrome) again just brought the existing terminal window to focus.
What?
That’s not going to be much use, I thought - so a consultation of the Google was called for. Turns out, giving the icon a click with the middle mouse button is the secret to opening additional instances.
I recommend searching around for some Unity guides or tutorials - a good selection is at this site to get an idea on how to use it. Some sort of guide or walkthrough should have been included with the default install - a link on the desktop or something, as this is a pretty big step. There’s a bit of a learning curve, but I think it has a lot of promise. Another little gem I found out was the use of the Windows key (or Super key) - a quick press brings up the dash where you can type in a program’s name, similar to the functionality in Windows 7; a longer press bring up the launcher, holding it down longer puts numbers on the icons that you can then use as shortcut keys to launch the programs.
Also check out this page of things to do/tweak after installing.
After one afternoon’s usage, I get the feeling that it’s not a massive backward step as people are saying, but a different way of doing things. It’s like the step from Windows XP to Vista or Windows 7 - things are in different places now, there’s some adjustment required, but after using the new features it’s difficult going back to the old way.
After mucking about with the laptop for a bit, I thought I would do a trial install on my main system. Still not willing to risk the main install, I grabbed an old hard drive, put that in my system and unplugged my existing drives. I then started the install process from CD, from scratch.
One of the concerns I had was that Unity is a part of Compiz - the desktop effects package that does not run on the open-source nouveau drivers for Nvidia cards. I have been running those on my desktop since they allowed the suspend functionality to work - the binary nvidia drivers did not do that. So this was going to be the big test - if suspend didn’t work on the new version, I would probably give the upgrade a miss or try KDE perhaps.
After quite a while of downloading updates and various components during the install (the default mirror must have had a really slow connection), the install completed and I rebooted. First impression - the loading screen actually worked properly. The nvidia drivers might finally be playing nice! Login screen came up, followed by the desktop. Going to the nvidia-settings program confirmed that the binary drivers are in use, so it was time to see if suspend worked or not. Clicking the suspend option in the main menu, the system actually powered down. No blank screen with blinking cursor in the corner, like in previous versions. I was impressed. I’d be even more impressed if the system came back up again. Hitting the power switch, the drive span back up, up came the password prompt to unlock the system. Entering the password brought the desktop back up, with a minor bit of graphical glitchiness on the side pane, but once I moved the mouse over it, it all came good. Success!
One thing I noticed was the behaviour of the launcher with a multi-monitor configuration. the way I have my screens set up, the second screen is off to the left of the main screen. So if I move the mouse to the left edge of the main screen, to bring up the launcher, if I move any further left onto the second screen, the launcher disappears again. Might have to look into that, whether I can move it to the right edge or something.
So far, that is my experience with 11.04. Further discoveries, from a longer period of use, will be posted in the future.
First of all, I used my laptop as a guinea pig. There is nothing of importance on it that isn’t backed up elsewhere, so if everything got hosed it would not be too much of a drama to do a clean install. Bringing up the update manager, I clicked the “Upgrade Now” button that has been teasing me for the last few weeks. The upgrade process started, and I left it to its own devices to scan the system, download, install and configure the latest versions of everything.
Much to my pleasure, when it was finished and after rebooting, the system actually started and loaded up the shiny new Unity desktop. All the effects were running, and this is machine had a fairly old ATI card and runs the open-source radeon drivers. It’s a bit of a departure from previous versions of Ubuntu, so I can see the concern other users have. A bit of experimental clicking around brought up my first problem - how do I launch more than one instance of a program, such as the terminal window? Clicking the terminal button on the side pane (which was there because it was configured as a button on the task bar on the previous install, along with Chrome) again just brought the existing terminal window to focus.
What?
That’s not going to be much use, I thought - so a consultation of the Google was called for. Turns out, giving the icon a click with the middle mouse button is the secret to opening additional instances.
I recommend searching around for some Unity guides or tutorials - a good selection is at this site to get an idea on how to use it. Some sort of guide or walkthrough should have been included with the default install - a link on the desktop or something, as this is a pretty big step. There’s a bit of a learning curve, but I think it has a lot of promise. Another little gem I found out was the use of the Windows key (or Super key) - a quick press brings up the dash where you can type in a program’s name, similar to the functionality in Windows 7; a longer press bring up the launcher, holding it down longer puts numbers on the icons that you can then use as shortcut keys to launch the programs.
Also check out this page of things to do/tweak after installing.
After one afternoon’s usage, I get the feeling that it’s not a massive backward step as people are saying, but a different way of doing things. It’s like the step from Windows XP to Vista or Windows 7 - things are in different places now, there’s some adjustment required, but after using the new features it’s difficult going back to the old way.
After mucking about with the laptop for a bit, I thought I would do a trial install on my main system. Still not willing to risk the main install, I grabbed an old hard drive, put that in my system and unplugged my existing drives. I then started the install process from CD, from scratch.
One of the concerns I had was that Unity is a part of Compiz - the desktop effects package that does not run on the open-source nouveau drivers for Nvidia cards. I have been running those on my desktop since they allowed the suspend functionality to work - the binary nvidia drivers did not do that. So this was going to be the big test - if suspend didn’t work on the new version, I would probably give the upgrade a miss or try KDE perhaps.
After quite a while of downloading updates and various components during the install (the default mirror must have had a really slow connection), the install completed and I rebooted. First impression - the loading screen actually worked properly. The nvidia drivers might finally be playing nice! Login screen came up, followed by the desktop. Going to the nvidia-settings program confirmed that the binary drivers are in use, so it was time to see if suspend worked or not. Clicking the suspend option in the main menu, the system actually powered down. No blank screen with blinking cursor in the corner, like in previous versions. I was impressed. I’d be even more impressed if the system came back up again. Hitting the power switch, the drive span back up, up came the password prompt to unlock the system. Entering the password brought the desktop back up, with a minor bit of graphical glitchiness on the side pane, but once I moved the mouse over it, it all came good. Success!
One thing I noticed was the behaviour of the launcher with a multi-monitor configuration. the way I have my screens set up, the second screen is off to the left of the main screen. So if I move the mouse to the left edge of the main screen, to bring up the launcher, if I move any further left onto the second screen, the launcher disappears again. Might have to look into that, whether I can move it to the right edge or something.
So far, that is my experience with 11.04. Further discoveries, from a longer period of use, will be posted in the future.
Thursday, March 17, 2011
Using a solid state drive in a MythTV box - does it make a difference?
The other day I finally got around to installing a solid-state hard drive (a 40GB Intel X25-V) into my MythTV box, to see what sort of difference it would make in day-to-day running. Of course, I only have the root partition on it, no recordings. I still have the 2TB drive for them. What prompted the move was the occasional sluggishness to respond when going through menus, and the odd pause or stutter when hitting the "i" or Info button on the remote. It would also sometimes get a brief pause when it popped up the notice that a commercial break was about to start.
I figured that it was down to too much being asked of the main storage drive - asking it to respond snappily when it is recording four or five episodes and playing back another is just too much. What if there was a second drive that could take care of the actual running of the machine, just leaving the big drive as a bit bucket to store media on?
Taking the Intel SSD from my main desktop (I had bought a 60GB OCZ Vertex to replace it), there was a spot ready for it in the Lian Li PC-Q07 case - right under the main drive. It wouldn't get a whole lot of air, so I'm glad it's a cool-running SSD. I copied the root partition from the 2TB drive onto it, as well as creating a swap partition. Partition sizes were kept down - 16GB for the root partition, 3GB for swap, leaving more than half free for the drive to use for wear-levelling. Overkill, but Mythbuntu doesn't need much room for its base installation. Eventually I got it working and booting from the ssd (after much swearing - how I did it may be covered in a future post) and I could check out the results.
And has it made a difference? A small one, but it's noticeable. Going through menu screens is a little quicker, more responsive. During playback, hitting the info button brings up the playback time without any stutters. Ending playback brings you back to the menu quicker. It's made the interface seem that little more polished. I'd say that it's not the fact there's a solid-state drive that has made the difference, more the fact that there is a second disk that's able to take some of the load off the storage one. I am not able to test it with another type of drive (frankly I can't be stuffed), but there are advantages in power consumption in going for an SSD.
I figured that it was down to too much being asked of the main storage drive - asking it to respond snappily when it is recording four or five episodes and playing back another is just too much. What if there was a second drive that could take care of the actual running of the machine, just leaving the big drive as a bit bucket to store media on?
Taking the Intel SSD from my main desktop (I had bought a 60GB OCZ Vertex to replace it), there was a spot ready for it in the Lian Li PC-Q07 case - right under the main drive. It wouldn't get a whole lot of air, so I'm glad it's a cool-running SSD. I copied the root partition from the 2TB drive onto it, as well as creating a swap partition. Partition sizes were kept down - 16GB for the root partition, 3GB for swap, leaving more than half free for the drive to use for wear-levelling. Overkill, but Mythbuntu doesn't need much room for its base installation. Eventually I got it working and booting from the ssd (after much swearing - how I did it may be covered in a future post) and I could check out the results.
And has it made a difference? A small one, but it's noticeable. Going through menu screens is a little quicker, more responsive. During playback, hitting the info button brings up the playback time without any stutters. Ending playback brings you back to the menu quicker. It's made the interface seem that little more polished. I'd say that it's not the fact there's a solid-state drive that has made the difference, more the fact that there is a second disk that's able to take some of the load off the storage one. I am not able to test it with another type of drive (frankly I can't be stuffed), but there are advantages in power consumption in going for an SSD.
Saturday, February 19, 2011
Potential problem syncing Tomboy Notes
A problem I had the other day was getting the Tomboy Notes application to sync correctly with my other PCs and the Ubuntu One service. The thing that triggered it was editing a note using the Ubuntu One web interface - basically editing the note stored on Ubuntu's servers. When I later tried to sync my notes on the PC, the application said the sync failed, please check below for error messages. When I checked the messages below, there weren't any. Rather frustrating.
Looking on the troubleshooting section of the Ubuntu wiki, towards the bottom of the page, it mentions the commands required to start Tomboy with debug messages. As follows below:
One thing to note: to quit Tomboy, I had to right-click on the Tomboy icon on the panel and select "remove from panel". Check in the System Monitor (System -> Administration -> System Monitor) that the tomboy process is no longer running.
When I ran the above command, tried to sync (unsuccessfully) and checked the log file, it came up with an error of:
[ERROR 19:51:49.776] Synchronization failed with the following exception: String was not recognized as a valid DateTime.
at System.DateTime.Parse (System.String s, IFormatProvider provider, DateTimeStyles styles) [0x00000] in:0
Doing a search on this message revealed a couple of other people who had the same issue. One such user was here, and one of the answers pointed to this bug report here.
The solution required for me wasn't quite as drastic as what they tried - backing up all notes, deleting them from the Ubuntu One web interface and locally on the machine, syncing, then re-creating all notes. I just deleted the one note I edited from the web interface and on my local machine, and sync worked again. I recreated the note, tried re-syncing, and it all worked fine.
The moral to the story is, don't use the web interface to edit your notes. It could cause problems.
Looking on the troubleshooting section of the Ubuntu wiki, towards the bottom of the page, it mentions the commands required to start Tomboy with debug messages. As follows below:
Getting debug info
- Quit Tomboy
- Applications->Accessories->Terminal, and run:
- tomboy --debug > ~/tomboy_debug.log
One thing to note: to quit Tomboy, I had to right-click on the Tomboy icon on the panel and select "remove from panel". Check in the System Monitor (System -> Administration -> System Monitor) that the tomboy process is no longer running.
When I ran the above command, tried to sync (unsuccessfully) and checked the log file, it came up with an error of:
[ERROR 19:51:49.776] Synchronization failed with the following exception: String was not recognized as a valid DateTime.
at System.DateTime.Parse (System.String s, IFormatProvider provider, DateTimeStyles styles) [0x00000] in
Doing a search on this message revealed a couple of other people who had the same issue. One such user was here, and one of the answers pointed to this bug report here.
The solution required for me wasn't quite as drastic as what they tried - backing up all notes, deleting them from the Ubuntu One web interface and locally on the machine, syncing, then re-creating all notes. I just deleted the one note I edited from the web interface and on my local machine, and sync worked again. I recreated the note, tried re-syncing, and it all worked fine.
The moral to the story is, don't use the web interface to edit your notes. It could cause problems.
Saturday, January 29, 2011
Observations on using the Nouveau driver
A few weeks back I made a post about switching back to the open-source nouveau drivers for my Nvidia graphics card. The main upside was that the suspend and hibernate functionality now worked - something that did not happen with the binary drivers from Nvidia. This is a concern for me, since I now have a Home Theatre PC running continuously and I would like to make some power savings with my main computer.
After running for a few weeks, here are some things I have noticed:
Artifacts on screen after coming out of suspend. They usually take the form of a vertical line of red pixels, spaced apart. They disappear after a reboot, so it is not permanent, but it is mildly annoying.
OpenGL performance much reduced. I was able to bring some of it back by installing libgl1-mesa-dri-experimental, found in the Ubuntu repositories. They bring a few extra modules for using OpenGL, and allows programs like Google Earth to run again (more about this next). The modules in the repository are a fairly early build - people have had more success using current-build versions of the Gallium3D driver. I haven't tried them yet, not sure if I will.
Google Earth problems. In linux, Google Earth makes use of OpenGL to draw its graphics on screen. The implementation in the binary Nvidia drivers is quite good, in the open-source drivers it is lagging behind somewhat. Before installing libgl1-mesa-dri-experimental, Google Earth would not run at all, simply putting up a message box asking you to update your drivers. After installing, it now runs, albeit slowly.
I'm still in two minds about whether to keep these drivers or go back to the binary versions. I'll probably see how things go for a while - how much I make use of suspend (which is sooo much quicker to resume from than booting from scratch - the AHCI manager takes forever to read the drives in the BIOS) will probably determine things. It might even be worth trying an ATI card to see how the drivers are with that. I'm quite impressed by the open source radeon drivers in my laptop. I don't really use my desktop now for MythTV since building the HTPC, so VDPAU performance isn't so much a priority.
I'll update in time, whenever a decision is made.
After running for a few weeks, here are some things I have noticed:
Artifacts on screen after coming out of suspend. They usually take the form of a vertical line of red pixels, spaced apart. They disappear after a reboot, so it is not permanent, but it is mildly annoying.
OpenGL performance much reduced. I was able to bring some of it back by installing libgl1-mesa-dri-experimental, found in the Ubuntu repositories. They bring a few extra modules for using OpenGL, and allows programs like Google Earth to run again (more about this next). The modules in the repository are a fairly early build - people have had more success using current-build versions of the Gallium3D driver. I haven't tried them yet, not sure if I will.
Google Earth problems. In linux, Google Earth makes use of OpenGL to draw its graphics on screen. The implementation in the binary Nvidia drivers is quite good, in the open-source drivers it is lagging behind somewhat. Before installing libgl1-mesa-dri-experimental, Google Earth would not run at all, simply putting up a message box asking you to update your drivers. After installing, it now runs, albeit slowly.
I'm still in two minds about whether to keep these drivers or go back to the binary versions. I'll probably see how things go for a while - how much I make use of suspend (which is sooo much quicker to resume from than booting from scratch - the AHCI manager takes forever to read the drives in the BIOS) will probably determine things. It might even be worth trying an ATI card to see how the drivers are with that. I'm quite impressed by the open source radeon drivers in my laptop. I don't really use my desktop now for MythTV since building the HTPC, so VDPAU performance isn't so much a priority.
I'll update in time, whenever a decision is made.
Tuesday, January 11, 2011
A MythTV box for the lounge room: Part 3: The build
In part 2 of this series, I went over the decision process for choosing the hardware used in the MythTV box. To sum up, I went with a Zotac IONITX-A, due to the low-power Intel Atom/Nvidia ION CPU/graphics combination, inbuilt wireless, and an included laptop-style power supply. I could also use some of the DDR2 RAM sticks that I already had.
Other items bought for the box included two more ASUS U3100 mini USB TV tuners. These supplemented the one I already had (sadly I couldn't use the PCI tuner card I had in my main PC, due to the board not having any PCI slots). I picked up a 2 terabyte Samsung ecogreen hard drive as the system and storage disk. These have had good reports of being low noise, low power consumption items.
The remote control chosen was a Hauppauge unit, as described in an earlier post.
The choice of case was driven by stock availability more than anything - initially I had chosen a Mini-ITX case from Aywun (known as Apex in some countries) but none would be arriving in stock until mid January - so I still would have been waiting. Since I wanted this to be completed as a Christmas holiday project, I looked elsewhere and found the Lian Li PC-Q07 - a rather minimal-looking aluminium case. It was a tad larger than the spot I had originally planned to put the box, but I was able to do some re-arranging inside the cabinet (like removing the video recorder - won't be needing that relic any more!) and it fits nicely.
Observations from assembly
One thing noticed when putting the various parts together is that the TV tuners would not fit together when pugged into adjacent USB slots at the back of the motherboard. Their chunky plastic bodies meant you could not plug much into a neighbouring slot. This was solved by picking up some USB extension cables and hanging the tuners off those. Using the cables also meant that I could run the tuners out the back of the cabinet into free air, rather than let them warm up the inside of the cabinet. They do get surprisingly warm during use.
To connect them to the aerial, I purchased a three-way digital TV splitter. I was concerned about losing too much signal with three plugged in, but in use the strength has been around 66-70%, enough to give trouble-free viewing.
The PC-Q07 case has nowhere inside it to allow for additional fan mounting, but it was designed to take full-sized PC components, like normal ATX power supplies, full-sized DVD drives and the like. Since there was no need for a PSU to be put in it (the motherboard I chose had its own laptop-style power brick that could sit out behind the cabinet), I rigged up a 92 mm fan in the gap where a power supply would normally go. It is set up so it is drawing in air from behind the case, supplying a stream of fresh air to the other, smaller fan on the CPU/GPU, as well as the hard drive. I just used one of the power supply mounting holes - it seems to be holding in place just fine. To stop air short-circuiting too much straight out the back, I cut up a small piece of cardboard and used that to blank off the remainder of the gap in the power supply hole.
To get a better supply of air to the box, I borrowed a holesaw, attached it to my drill, and cut a couple of extra air holes in the back of the TV cabinet. This also provided some extra paths to lead cables from.
The infrared sensor from the remote was on a fairly long cable, so I was able to lead that out the back of the cabinet to a spot that is higher up, easier for the remote to reach.
Finally, I've left the wireless receiver for the keyboard and mouse plugged into the back for convenience - I can just bring them down from the other room if some typing or clicking is needed.
Findings from the first weeks of use
First of all, and the biggest relief, is that the Wife Acceptance Factor (WAF) is very high - she loves it. We both love having the power to watch what we want, when we want, being able to skip the ads if we've recorded a show earlier. Playback is flawless - any glitches we have aren't any worse than what we previously encountered with our HD set top box. It can handle 1080i playback perfectly smoothly. The only stutters are related to the hard drive when it is working particularly hard, like the other night when we found ourselves in the situation of recording four shows simultaneously (two were on different sub-channels on the same network, so one tuner could record them both) while watching a recording of a previous program. You could see the hard drive light blinking away pretty furiously. Oh yes, it would have also been flagging commercials at the same time. All these things can be tweaked and tuned, I've set it to only run one job at a time to give the little atom CPU some breathing room. Commercial flagging has been set to begin as soon as recording starts - I changed that from the default of waiting until a show has finished recording. So far, it hasn't slowed things down noticeably.
For the playback settings in MythTV, I have chosen the VDPAU Normal profile. I haven't tried the High Quality setting yet, the GPU may struggle with that, and Normal looks just fine to me.
Mythbuntu:
I decided to used the MythTV-oriented version of Ubuntu for this project, Mythbuntu. This runs the XFCE desktop, using less resources than Gnome would. Setup was quite simple, and I was pleased to find that Mythweb was installed by default - something I had never bothered with before on my previous desktop PC Myth install.
I would recommend this to anyone else considering a dedicated HTPC build. It is quite stripped back, however, so it is not much use for other purposes (although there is a facility to enable it to be reconfigured as a regular desktop through the Mythbuntu control panel).
CPU Use:
One CPU-hungry process I have noted is upconverting the audio stream to 5.1 Dolby Digital. Remotely logging in and checking CPU use during playback shows that with regular stereo passthrough to the optical output, usage is around 12-14%. With upconversion enabled at best quality, CPU use shoots up to around 63%.
Memory:
Memory-wise, I have followed recommendations posted elsewhere on the web and run two sticks of RAM, enabling dual-channel operation. This provides better bandwidth for the GPU in particular, improving playback performance.
I have two, one-gigabyte sticks of DDR2-800 ram installed, with the graphics set in BIOS to use the maximum 512MB. This has been quite sufficient, and I dare say that 1 GB would be enough if it weren't for the onboard graphics using some of the memory.
Power consumption:
I have a power meter (discussed in an earlier post on my other blog) connected to the wall outlet, measuring the power use of the PC, as well as the VGA-component transcoder. When idle, the unit consumes 44 Watts. Watching live TV, it uses 47 Watts. When 5.1 upconversion was enabled, it used 49 Watts, reflecting the extra CPU usage.
These figures are quite a bit higher than what I've seen elsewhere on the web - I saw a picture of a system playing a blu-ray disc using 30W. And this machine doesn't have an optical drive installed. All I can think of is the extra power draw of the TV tuners, the fan, and the fact that linux may not make the best use of power saving features of the CPU compared with windows 7. The other factor could be the power meter being out, something I'm finding quite likely. It does give pretty high voltage readings, which would as a result give an inflated Watt reading.
Final thoughts:
I'm glad the system build went off without a hitch. Performance is fine, although had I gone with a core i3 system it could have handled many more concurrent jobs like commercial flagging without breaking a sweat. Power use would have been higher, too, as too the cost.
The wireless signal is not the best, with the antenna located at the back of the motherboard hidden away at the back of the TV unit. I may try an external antenna, to let it get a better signal than the 40-ish percent it now gets. It makes copying movie files pretty slow, the way it is at the moment.
I'm wondering whether to put in a solid-state hard drive to have the operating system partition located on, to free up the workload of the storage drive. There is sometimes a delay of a few seconds when starting playback of a show. This isn't a major priority - it will probably inherit the Intel X25-V from my main system whenever I upgrade that.
Other items bought for the box included two more ASUS U3100 mini USB TV tuners. These supplemented the one I already had (sadly I couldn't use the PCI tuner card I had in my main PC, due to the board not having any PCI slots). I picked up a 2 terabyte Samsung ecogreen hard drive as the system and storage disk. These have had good reports of being low noise, low power consumption items.
The remote control chosen was a Hauppauge unit, as described in an earlier post.
The choice of case was driven by stock availability more than anything - initially I had chosen a Mini-ITX case from Aywun (known as Apex in some countries) but none would be arriving in stock until mid January - so I still would have been waiting. Since I wanted this to be completed as a Christmas holiday project, I looked elsewhere and found the Lian Li PC-Q07 - a rather minimal-looking aluminium case. It was a tad larger than the spot I had originally planned to put the box, but I was able to do some re-arranging inside the cabinet (like removing the video recorder - won't be needing that relic any more!) and it fits nicely.
Observations from assembly
One thing noticed when putting the various parts together is that the TV tuners would not fit together when pugged into adjacent USB slots at the back of the motherboard. Their chunky plastic bodies meant you could not plug much into a neighbouring slot. This was solved by picking up some USB extension cables and hanging the tuners off those. Using the cables also meant that I could run the tuners out the back of the cabinet into free air, rather than let them warm up the inside of the cabinet. They do get surprisingly warm during use.
To connect them to the aerial, I purchased a three-way digital TV splitter. I was concerned about losing too much signal with three plugged in, but in use the strength has been around 66-70%, enough to give trouble-free viewing.
The PC-Q07 case has nowhere inside it to allow for additional fan mounting, but it was designed to take full-sized PC components, like normal ATX power supplies, full-sized DVD drives and the like. Since there was no need for a PSU to be put in it (the motherboard I chose had its own laptop-style power brick that could sit out behind the cabinet), I rigged up a 92 mm fan in the gap where a power supply would normally go. It is set up so it is drawing in air from behind the case, supplying a stream of fresh air to the other, smaller fan on the CPU/GPU, as well as the hard drive. I just used one of the power supply mounting holes - it seems to be holding in place just fine. To stop air short-circuiting too much straight out the back, I cut up a small piece of cardboard and used that to blank off the remainder of the gap in the power supply hole.
To get a better supply of air to the box, I borrowed a holesaw, attached it to my drill, and cut a couple of extra air holes in the back of the TV cabinet. This also provided some extra paths to lead cables from.
The infrared sensor from the remote was on a fairly long cable, so I was able to lead that out the back of the cabinet to a spot that is higher up, easier for the remote to reach.
Finally, I've left the wireless receiver for the keyboard and mouse plugged into the back for convenience - I can just bring them down from the other room if some typing or clicking is needed.
Findings from the first weeks of use
First of all, and the biggest relief, is that the Wife Acceptance Factor (WAF) is very high - she loves it. We both love having the power to watch what we want, when we want, being able to skip the ads if we've recorded a show earlier. Playback is flawless - any glitches we have aren't any worse than what we previously encountered with our HD set top box. It can handle 1080i playback perfectly smoothly. The only stutters are related to the hard drive when it is working particularly hard, like the other night when we found ourselves in the situation of recording four shows simultaneously (two were on different sub-channels on the same network, so one tuner could record them both) while watching a recording of a previous program. You could see the hard drive light blinking away pretty furiously. Oh yes, it would have also been flagging commercials at the same time. All these things can be tweaked and tuned, I've set it to only run one job at a time to give the little atom CPU some breathing room. Commercial flagging has been set to begin as soon as recording starts - I changed that from the default of waiting until a show has finished recording. So far, it hasn't slowed things down noticeably.
For the playback settings in MythTV, I have chosen the VDPAU Normal profile. I haven't tried the High Quality setting yet, the GPU may struggle with that, and Normal looks just fine to me.
Mythbuntu:
I decided to used the MythTV-oriented version of Ubuntu for this project, Mythbuntu. This runs the XFCE desktop, using less resources than Gnome would. Setup was quite simple, and I was pleased to find that Mythweb was installed by default - something I had never bothered with before on my previous desktop PC Myth install.
I would recommend this to anyone else considering a dedicated HTPC build. It is quite stripped back, however, so it is not much use for other purposes (although there is a facility to enable it to be reconfigured as a regular desktop through the Mythbuntu control panel).
CPU Use:
One CPU-hungry process I have noted is upconverting the audio stream to 5.1 Dolby Digital. Remotely logging in and checking CPU use during playback shows that with regular stereo passthrough to the optical output, usage is around 12-14%. With upconversion enabled at best quality, CPU use shoots up to around 63%.
Memory:
Memory-wise, I have followed recommendations posted elsewhere on the web and run two sticks of RAM, enabling dual-channel operation. This provides better bandwidth for the GPU in particular, improving playback performance.
I have two, one-gigabyte sticks of DDR2-800 ram installed, with the graphics set in BIOS to use the maximum 512MB. This has been quite sufficient, and I dare say that 1 GB would be enough if it weren't for the onboard graphics using some of the memory.
Power consumption:
I have a power meter (discussed in an earlier post on my other blog) connected to the wall outlet, measuring the power use of the PC, as well as the VGA-component transcoder. When idle, the unit consumes 44 Watts. Watching live TV, it uses 47 Watts. When 5.1 upconversion was enabled, it used 49 Watts, reflecting the extra CPU usage.
These figures are quite a bit higher than what I've seen elsewhere on the web - I saw a picture of a system playing a blu-ray disc using 30W. And this machine doesn't have an optical drive installed. All I can think of is the extra power draw of the TV tuners, the fan, and the fact that linux may not make the best use of power saving features of the CPU compared with windows 7. The other factor could be the power meter being out, something I'm finding quite likely. It does give pretty high voltage readings, which would as a result give an inflated Watt reading.
Final thoughts:
I'm glad the system build went off without a hitch. Performance is fine, although had I gone with a core i3 system it could have handled many more concurrent jobs like commercial flagging without breaking a sweat. Power use would have been higher, too, as too the cost.
The wireless signal is not the best, with the antenna located at the back of the motherboard hidden away at the back of the TV unit. I may try an external antenna, to let it get a better signal than the 40-ish percent it now gets. It makes copying movie files pretty slow, the way it is at the moment.
I'm wondering whether to put in a solid-state hard drive to have the operating system partition located on, to free up the workload of the storage drive. There is sometimes a delay of a few seconds when starting playback of a show. This isn't a major priority - it will probably inherit the Intel X25-V from my main system whenever I upgrade that.
Subscribe to:
Posts (Atom)