Regarding “texture2DLod” and “texture2DLodOffset” under Ubuntu, I’ve hit the same problem myself (and have an ATI Mobility Radeon HD 3650), I believe. Specifically, I don’t seem to have access to any CG profile other than arb(f/v)p1, which precludes access to those methods, if I recall correctly.
For what it’s worth, GLSL seems a little more accommodating.
I don’t know anymore how the correct normals should look 
I just compare it with what I get from a model with a default auto-shader cg shader (there a mound called ‘test’ in the paint models tab).
Last time I checked there were some differences - a flat surface seen head on looks bluish with my shader and blackish with the model-auto-shader, but when not viewing the normals and just lighting the terrain it looks about right.
I’m not expert in these things, so take my thoughts with a grain of salt.
That said, by my understanding I would expect a flat surface seen head-on to appear blue (with RGB values of 127, 127 and 255 respectively when using a range of 0 to 255, specifically). Is your auto-shader version not perhaps being somehow given the normal map as a diffuse map as well, causing the blue areas to appear darker than they should?
As far as I had time understand Cg and GLSL uses different coordinate spaces, at least in Panda. With this code in GLSL I can get the same result as Cg autoshader:
gl_FragData[0].xzyw=gl_ProjectionMatrix * vec4(norm.xyz, 1.0)but if you make all calculations in GLSL, then I think there no reasons to convert normals or something else in Cg space.
Going back to beginning: is problem with lights still actual?
I think I’d call it solved, the light looks fine, so I won’t be bothered about the rest.
I think it’s just as ninth wrote - Cg and GLSL uses different coordinate spaces. I’ll accept that as true until proven otherwise.