He provided the startcg script also which is why I was wondering where the -c parameter and name of config file is:

startcg

Without the -c param?  No I wasn't aware of that.  I assumed (I guess incorrectly) that it used the default config if you told it to read from config file w/ -c

Although mostly answered above I'll add a few bits...

1. On Ubuntu now the preferred init system is Upstart. It should eventually replace SysV (/etc/init.d style) methods for system init. Note that the miner.conf is not a script but a config that tells Upstart what and when to do things. I could improve mine by having it cue on X started rather than the "sleep 15" (which allows X time to init), but I'm lazy and the fews pokes I made at syntax to wait for X didn't work right.

2. I coded the changes a while back (and submitted to author) for writing a cgminer.conf based on current values. One of the "enhancements" was it being able to use a default config so that simpler startup commands could be used and config tweaks while running could be saved. Also a new pool config format was a side effect.

3. This tells su to run a command (as optional user too). I use this as Upstart currently has no better way to "run as" a non-root user. I don't run as root since a vulnerability in cgminer could allow a hacker to gain root access. It does talk across the net after all (though it doesn't listen, better safe than sorry).

The commas mentioned are actually what separate each GPU value and are not part of the numeric value. I have been using my code with 2 GPUs without problems and have saved/loaded many times. I'm not saying the problem doesn't exist, just that it may be something specific to this user/config that needs to be looked at and figured out.

Also, I'm pretty sure that I have different code on my system than what was released. This happened due to the timing and my continued work on it after I submitted it. I think the release version saves some values that are never changed by the user's manual tweaking. That wouldn't cause this issue but once I saw that I modified my code to save the different tweaked values.

I didn't submit my changes because it was unclear if that was what most users would want and it was untested. Anyway, it's a fuzzy area for me as I don't know if my code works fine because it uses different values. The real problem is that no one except me tested the code and I've seen almost zero feedback on whether it works for most people or is broken everywhere. I do know without doubt that saving and loading works for me.

I'm willing to fix it and submit a patch but I'll need clear details on what happens that's wrong as I do not get the same behavior here. eg. my copy writes out
...
"intensity" : "8,8",
"gpu-engine" : "1020,970",
"gpu-fan" : "50-85,50-85",
"gpu-memclock" : "300,300",
"gpu-powertune" : "0,0",
"gpu-vddc" : "1.161,1.174",
"temp-cutoff" : "95,95",
"temp-overheat" : "85,85",
"temp-target" : "70,70",
...
when I save.

Oh, and a problem for me is that I'm still using my own edit of 2.0.6 - so I'd actually need to sync to the newest version before I could fix anything. Drats.

It's a bug.

A value of 0 in the configuration implies "not set" which means cgminer does not try to set the value it has received.

However I do recall cgminer not starting up complaining about bad values.  What about 0.00 does it just ignore those or does it error out?

I looked at the load config code and it compares the read value with a range <= 0 && >= 9999 to determine if error. So it should not allow any invalid value for gpu_vddc and should throw an error. The example.conf shouldn't have 0.000 there as default. Presumably a missing line would result in a default supplied by ADL code but I'm not certain.

I can confirm this. I have the exact same thing. Only VDDC is "wrong" and set to zero. Trying to launch cgminer results in an error unless I fill out the VDCC values or remove those lines.