More NFS bugs

I upgraded my main desktop machine to Fedora 14 the other day and noticed that it hard crashes when transferring over about 300Mb of data over NFS. rsync and ssh are fine.

So I did a bit of searching and as usual there’s a shedload of Ubuntu users reporting the issue but none of them fixing it or raising it with the kernel devs instead of Canonical.

Anyway I tinkered with my /etc/fstab entries and it seems to either be down to the buffer size or async setting as now it seems to be working fine, and faster than before – odd as async and a larger buffer should speed things up!

Fixed:

vader:/data1  /media/data1  nfs4  noauto,rw,user,hard,intr,timeo=14,rsize=32768,wsize=32768,noatime  0 0

Broken:

vader:/data1  /media/data1  nfs4  noauto,rw,user,hard,intr,timeo=600,rsize=65536,wsize=65536,noatime,async  0 0

Update: seems this is more of a bug with the r8169 driver at gigabit speeds as I’m getting hard lockups now when rsync’ing large files (doesn’t happen when using 100Mbps or r8168.ko)

Its Like Dixons In Here

Now my server is finally back online (apparently although hosted in Germany somewhere, the support staff are in flood-ridden Australia) so I thought I’d update the blog.

I’ve rebuilt my desktop machine now I’ve got the HDTV card. I finally fitted the 64Gb Kingston SSD boot drive, installed Fedora 14 and put the 1Tb SpinPoint F3 hard disk back in to supplement the rapidly-filling 1Tb F1.

I noticed how much of a difference the SSD makes when rebuilding the Nessus plugin cache – on a HDD it takes literally minutes, on the SSD its almost instant!

I’m using Kaffeine to record and play via the HDTV card. The TV guide is not great, but you can manually add programs in to record or just hit the record button to record now (and pause live TV etc.)

I can’t be bothered to go the whole MythTV route as I only use it to watch TV in a window whilst I’m doing something, or to record a show when something else is on the Sky box downstairs. Xine, VLC, TVTime and MPlayer are supposed to support DVB-S too, but I can’t get them to work.

The electricians came on Friday and decided (without even looking!) that it wouldn’t be possible to run the CAT6 down the cavity alongside the satellite cables, so as the BT Business Hub has shite wireless, I’m going to have to look into HomePlug AV or Powerline HD which runs IP over the mains electrical wiring at 200Mbps or even gigabit speeds (more like 100-300Mbps apparently on the same ring main). Shame I bought those CAT6 faceplates and 65m of UTP cable now!

I’ve got Fedora 14 on the replacement Asus EeePC 1001P netbook now, its a little slow – although strangely since enabling Compiz, the desktop renders faster (not slower as you’d expect!) but its handy for web surfing or SSH. Battery life seems to be pretty good, nowhere near the advertised 11 hours I wouldn’t think though, even the Jupiter controlling the SHE power management.

The Acer Aspire Revo 3610-M nettop is being used to play the video’s downstairs through the TV, that’s the machine I wanted to connect to the desktop upstairs using CAT6. Its wireless is OK for surfing but way too slow for video – and its 802.11N chip doesn’t even work with the Fedora 14 on there, so its Windows7 playing via a 16Gb USB stick at the moment!

I noticed that to play a Full-HD file I had to use Windows Media Player as it uses the ION DirectX acceleration (like VDPAU as used in MPlayer on Linux) as the Atom CPU didn’t have the grunt without GPU acceleration when using VLC/MPC.

The new Lenovo ThinkPad T410 from work is pretty nifty too – its a desktop replacement one, so massive and no battery life, but its running all the latest Microsoft crap that we need for work – Windows7, Office2010 etc; and the VPN uses a SmartCard, which works quite nicely actually, much better than the Novell dialer crap with XP.

Update: I recompiled JtR with the newer MSCash2 v1.1 patch, downloads here.

New F14 RPM’s

I’ve patched and built 64-Bit Fedora 14 RPM’s for John-the-Ripper (the password cracker) here and rain (the packet crafter) here.

The JtR package includes the recent patches for Generic Salted SHA-1 and Netscreen, as well as the usual Jumbo-7 patch.

Update: As the SHA1/Netscreen patches have been merged into the Jumbo-9 patch, I’ve updated the John 1.7.6-3 RPM’s to just apply Jumbo-9 to a vanilla 1.7.6

Update 2: I’ve just built Back In Time v1.0.4 for F13/14 by editing the Fedora 15 SRPM for 0.9.26 to remove an un-needed patch and update to the 1.0.4 tar.gz file.

I’m not going to use it myself yet as part of the v1.0 changes is to add the hostname to the path to the backup directories, which breaks compatibility with 0.9.x, so I’d not easily be able to use Ubuntu 9.10 or an earlier Fedora release (without making another RPM) with the backups created with this. Anyway, the download is here.

Fedora 14 Upgrade

I used a slightly modified version of my instructions in this earlier post to upgrade my laptop from Fedora 13 to 14 today, without using a DVD drive or USB key etc. Basically PXE booted over the network and did a DVD upgrade using an NFS mounted ISO image.

Last time I did this for F13 I used the yum method which caused something like 3Gb to be downloaded and took overnight. With the DVD upgrade method it did the upgrade in about and hour, then I did a yum update which pulled down about 500Mb of updates newer than the DVD.

Everything went fine, at no point was there any manual fussing required or uninstalling/reinstalling of RPM’s, so it definitely went better than F12->13.

I’m thinking of buying a Netbook for using when on the road, along with a 3G modem. As Netbooks seem to be essentially all the same spec, I can’t really decide between an Asus Eee-PC 1005PX, HP Mini 110 3105sa or Acer Aspire One D255.

I’m leaning towards the HP as it has 2Gb RAM and a 250Gb hard drive, which will come in handy as I plan to triple boot Windows 7, Fedora 14 (or Ubuntu 10.10 or even Meego/Android) and MacOSX 10.6, it also has an Atom N455 processor which means DDR3 so slightly faster memory operations than the N450’s.

I tried Nessus and OWA at 1024×600 on my aunt’s Toshiba Netbook and it seems fine on a 10.1″ screen, especially if you go into fullscreen/kiosk mode or hide some toolbars.

Update: I’m now leaning towards the Asus 1005PE-M as its supposed to have the longest battery life of all the Netbooks at around 11 hours quoted, tested to 8.5+ with a 48Whr battery (the rare 1005PE-P does 14/10 hours with a 63Whr battery!) It is 250Gb and it has gigabit/802.11n/bluetooth, which just means upgrading to 2Gb which is about 30ukp on ebay or ebuyer, but that’s taking the total into the 280ukp+ range of a laptop…..

The 1005PX has a 48Whr battery quoted at 9 hours, and one less USB port.

The HP no longer seems to be advertised with 2Gb RAM, and has gone up to 260ukp for the 1Gb/250Gb version, and looks like the battery life is 6.5 hours.

Compiling VirtualBox OSE

Building VirtualBox is getting harder and harder these days as Oracle add non-standard hacky little scripts to the codebase, just like their horrible database installation that requires you to install RPM’s to allow the installer to run, then you must remove them afterwards or your entire system will be un-upgradeable!

The build instructions here are hideously out-of-date and don’t really help much on a non-Debian system.

The first bug was a dependency on a specific version of Java, or more accurately a hardcoded location for the JRE. The fix for that was a symlink for OpenJDK, not installing the Sun JVM as they said. So as root:

cd /usr/lib/jvm/
ln -s java-1.6.0-openjdk.x86_64 java-6-openjdk

Another problem I had was that they silently started building the packages using makeself, which became a requirement, even if you used ./configure --disable-hardening, which is not supposed to build distributable packages. makeself is not packaged, so just untar it in /usr/local/bin/ as root.

Recently it seems they’ve added to the mix, compiling the UserManual.pdf using LaTeX and an obscure font. The fix for that appears to be to download and install the font, as root:

cd /usr/share/texmf/tex/latex/
mkdir bera
cd bera/
wget http://www.tug.org/texlive/devsrc/Master/texmf-dist/tex/latex/bera/beramono.sty
texhash

They’ve removed compiling the VBoxFixHDD utility as I suggested (as the code wasn’t in SVN, but the dependency was!) by commenting out line 53 of vbox/src/VBox/Devices/Storage/testcase/Makefile.kmk

#PROGRAMS += VBoxFixHdd

So OSE revision 32218 (newer than PUEL 3.2.8) now compiles on 64-Bit Fedora 13 again. There doesn’t appear to be anything hugely new, other than a redesigned GUI with a preview window.