After the upgrade to Fedora12 for some files totem hangs at startup. This is a bug in the gstreamer framework related to subtitles. It happens when you have the 'Automatically load subtitle files when movie is loaded' selected and there is an SRT file in the directory of your movie.
Quick workaround is to disable the option and load the subtitle manually.
The fix is already included in the next gstreamer update for fedora (0.10.25.1-2), but if you can't wait you can download the packages gstream, gstream-tools and the gstreamer-plugins-base from the koji build server.
Ubuntu's Karmic Koala has the same issue, the launchpad entry is at https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/441396
Monday, November 30, 2009
Thursday, November 26, 2009
The incredible shrinking harddisk
A harddisk in my home server was giving S.M.A.R.T. warnings of imminent doom, so I ordered a new harddisk, a Seagate ST31000528AS Barracuda 1TB.
I had read about some issues with bad firmware in their prior models (7200.11), but figured that was a one off that could happen to any vendor.
Received the harddisk a few days ago, plugged it in, booted an iso with GParted and proceeded to copy the partitions of the old disk to the new disk.. everything was going smoothly.
... until ...
After the copy, disconnected the old disk and plugged the new one in the first SATA port. That's when the troubles started. The disk wouldn't boot, which after thinking about it, was to be expected as I forgot to put a bootloader on it, doh! So back to GParted, but when the kernel started spewing errors, something about sectors being out of range. That's when I noticed that the disk was now detected as a 33Mb, instead of the somewhat larger 1TB it should be.
Rebooting didn't help, changing the SATA port, booting a different kernel, nothing helped.
Now here's what happened... for some reason, the team that made the BIOS of the motherboard, figured it would be a good idea to reserve some space on the harddisk to dump their crap on.. but apparently math skills are optional when applying for that position and hence they messed up the code that reserves the area (probably thought we wouldn't be using 1Tb disks any time soon). So instead of setting aside a modest sized area, the code almost grabbed the entire disk.
The reservation is done by setting the Host Protected Area of the disk.
Luckily with a recent hdparm (like the one you can find on a live CD of Fedora12 or Ubuntu 9.10), you can view/set the HPA boundary. After correcting it, my disk was back to normal... I'm still not sure why the BIOS isn't 'fixing' the disk again after a restart.. so I'm a bit worried that I'll loose data if one of the days the BIOS decides to screw me over again. Probably best to look for a BIOS update before trusting my data on the disk.
For those that are wondering.. the motherboard is a Gigabyte 965P-S3 (and finding the correct BIOS file would be so much easier if Gigabyte didn't make more than 1 revision of the motherboard or if they would at least mention how you can discover the difference between rev 1 and rev 3.3). Anyway, if you don't remember which motherboard you have, you can use the dmidecode utility or lshw if you have it installed. (or if your kernel is recent enough, you can look in /sys/devices/virtual/dmi/id)
More details and what other issues that can cause your disk to shrink are explained in this nice blog post: http://blog.atola.com/restoring-factory-hard-drive-capacity/
I had read about some issues with bad firmware in their prior models (7200.11), but figured that was a one off that could happen to any vendor.
Received the harddisk a few days ago, plugged it in, booted an iso with GParted and proceeded to copy the partitions of the old disk to the new disk.. everything was going smoothly.
... until ...
After the copy, disconnected the old disk and plugged the new one in the first SATA port. That's when the troubles started. The disk wouldn't boot, which after thinking about it, was to be expected as I forgot to put a bootloader on it, doh! So back to GParted, but when the kernel started spewing errors, something about sectors being out of range. That's when I noticed that the disk was now detected as a 33Mb, instead of the somewhat larger 1TB it should be.
Rebooting didn't help, changing the SATA port, booting a different kernel, nothing helped.
Now here's what happened... for some reason, the team that made the BIOS of the motherboard, figured it would be a good idea to reserve some space on the harddisk to dump their crap on.. but apparently math skills are optional when applying for that position and hence they messed up the code that reserves the area (probably thought we wouldn't be using 1Tb disks any time soon). So instead of setting aside a modest sized area, the code almost grabbed the entire disk.
The reservation is done by setting the Host Protected Area of the disk.
Luckily with a recent hdparm (like the one you can find on a live CD of Fedora12 or Ubuntu 9.10), you can view/set the HPA boundary. After correcting it, my disk was back to normal... I'm still not sure why the BIOS isn't 'fixing' the disk again after a restart.. so I'm a bit worried that I'll loose data if one of the days the BIOS decides to screw me over again. Probably best to look for a BIOS update before trusting my data on the disk.
For those that are wondering.. the motherboard is a Gigabyte 965P-S3 (and finding the correct BIOS file would be so much easier if Gigabyte didn't make more than 1 revision of the motherboard or if they would at least mention how you can discover the difference between rev 1 and rev 3.3). Anyway, if you don't remember which motherboard you have, you can use the dmidecode utility or lshw if you have it installed. (or if your kernel is recent enough, you can look in /sys/devices/virtual/dmi/id)
More details and what other issues that can cause your disk to shrink are explained in this nice blog post: http://blog.atola.com/restoring-factory-hard-drive-capacity/
Tuesday, November 24, 2009
Fedora 12 PreUpgrade
The issue I had with insufficient diskspace in /boot while using preupgrade is now caught by preupgrade, for more information see preupgrade update info at https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11536 and the fedora wiki at http://fedoraproject.org/wiki/PreUpgrade
Friday, November 20, 2009
Friday, November 13, 2009
HOWTO: Flooding wireless networks...
Recipe:
1 wireless network
1 part Fedora 12
1 part Pulseaudio gravy
1 foolish setting:
What do you get?! A nice flood towards your wireless network with empty 16-bit audio packets even when no application whatsoever is playing audio.
One thing I don't remember... if I ever activated that setting while playing with my VirtualGL / remote wine gaming setup.. or if it was an effect from the Fedora upgrade... either way, best to double check your own setting after upgrading, as the effect is a pretty dead wireless network at seemingly random times.
1 wireless network
1 part Fedora 12
1 part Pulseaudio gravy
1 foolish setting:
What do you get?! A nice flood towards your wireless network with empty 16-bit audio packets even when no application whatsoever is playing audio.
One thing I don't remember... if I ever activated that setting while playing with my VirtualGL / remote wine gaming setup.. or if it was an effect from the Fedora upgrade... either way, best to double check your own setting after upgrading, as the effect is a pretty dead wireless network at seemingly random times.
Thursday, November 12, 2009
Karmic Koala
Before upgrading ubuntu 9.04 with the br0ken network to 9.10, I grabbed and compiled the mainline 2.6.32-rc6 kernel to make sure I had at least a working kernel to fix issues if the Karmic kernel was broken too.
Since the mainline kernel worked fine, I continued to upgrade to Karmic Koala, which uses a 2.6.31 kernel. I was happy to find out that the ubuntu 9.10 kernel didn't have any issues with my VLAN setup.
I still wonder if the issue was caused by an ubuntu specific patch or if the mainline kernel had issues. Maybe I'll git bisect it to feed my curiosity.
Since the mainline kernel worked fine, I continued to upgrade to Karmic Koala, which uses a 2.6.31 kernel. I was happy to find out that the ubuntu 9.10 kernel didn't have any issues with my VLAN setup.
I still wonder if the issue was caused by an ubuntu specific patch or if the mainline kernel had issues. Maybe I'll git bisect it to feed my curiosity.
Tuesday, November 10, 2009
Murphy...
Since I was already busy with upgrading my laptop, I figured I might aswell upgrade my home server which was running ubuntu 8.04. However after upgrading to 8.10 my network didn't work anymore. When booting an older kernel it worked fine. Figured it was an issue in the kernel, Ubuntu 8.10 was using and since the target was to get to 9.10, I thought I might aswell continue. So upgraded the 8.10 to 9.04, however the network issue remained. With 2.6.28 on 9.04, I was unable to ping my WRT54G which runs OpenWRT. With 2.6.24 on 9.04 it works 'fine'. My home setup uses a couple of VLANs and it seems that that was causing the problems, without the VLANs the new kernel was able to ping the router.
As it was already getting late, I booted the machine with 2.6.24 and decided to call it a day.
Today, when I tried to initiate an OpenVPN connection to my home server from a remote location, the connection failed. Even a secure shell to the server didn't work. Going via the OpenWRT's shell to the server did work for some bizarre reason.
After some tracing with tcpdump and wireshark, it showed that the port number of the connection was somehow changing... ie. make a connection to port 1000 and it arrived on the server at port 1040 according to the packet trace.
First thought it had to do with the VLAN tagging and that for some reason the ubuntu kernel was interpreting the packets wrong, as I already had issues with the VLAN... but when I did the packet trace on the OpenWRT on the incoming interface, it was correct.. on the outgoing interface however it was wrong... which showed the cause was not with the ubuntu server but with the OpenWRT device. After rebooting it, the connections worked fine again.
Goes to show that when stuff goes bad, it really goes bad.. as in 2 different things going banana's at the exact same time!
Anyway the OpenWRT issue seems to be a bug in the 7.07 Kamikaze release, which is fixed in 8.09
Kamikaze 8.09 Release notes states:
So it looks like I'll have to update yet another device.
As it was already getting late, I booted the machine with 2.6.24 and decided to call it a day.
Today, when I tried to initiate an OpenVPN connection to my home server from a remote location, the connection failed. Even a secure shell to the server didn't work. Going via the OpenWRT's shell to the server did work for some bizarre reason.
After some tracing with tcpdump and wireshark, it showed that the port number of the connection was somehow changing... ie. make a connection to port 1000 and it arrived on the server at port 1040 according to the packet trace.
First thought it had to do with the VLAN tagging and that for some reason the ubuntu kernel was interpreting the packets wrong, as I already had issues with the VLAN... but when I did the packet trace on the OpenWRT on the incoming interface, it was correct.. on the outgoing interface however it was wrong... which showed the cause was not with the ubuntu server but with the OpenWRT device. After rebooting it, the connections worked fine again.
Goes to show that when stuff goes bad, it really goes bad.. as in 2 different things going banana's at the exact same time!
Anyway the OpenWRT issue seems to be a bug in the 7.07 Kamikaze release, which is fixed in 8.09
Kamikaze 8.09 Release notes states:
* fix port forwarding NAT issues in brcm-2.4
So it looks like I'll have to update yet another device.
Monday, November 9, 2009
F12 systray / panel spacing
After the upgrade, the spacing between the icons in the systray area was way too large. Apparently it's a 'feature'. *sigh*
Fix with:
Fix with:
$ gconftool-2 --type int --set /apps/panel/applets/systray/prefs/padding 0
Preupgrade to Fedora 12
Used preupgrade to upgrade my Fedora 11 to rawhide / Fedora 12. The upgrade went smoothly except for 1 issue. Apparently my /boot partition was too small (190Mb with 142Mb still free), so after preupgrade downloaded all the packages and reboot into anaconda, I was presented with a nice out of diskspace error. ouch.
I tried to remove some left over old kernels from the boot partition but it wasn't enough. Luckily I always have an external USB drive with me, so I copied the preupgrade image to that drive, tweaked grub to load it from there and that did the trick.
I tried to remove some left over old kernels from the boot partition but it wasn't enough. Luckily I always have an external USB drive with me, so I copied the preupgrade image to that drive, tweaked grub to load it from there and that did the trick.
Subscribe to:
Posts (Atom)