Unable to force Debian to do unattended install... libc6 wants interactive confirm

I'm not positive on the settings in Lenny but I know that in Squeeze, sudo is configured with env_reset meaning it will strip out all but a very few select env variables before running the command.

This means the DEBIAN_FRONTEND variable you set is never actually making it to the apt-get install --yes --force-yes r-base. If you have full access to sudo, meaning you are in the sudoers files with ALL = ALL permissions, then you can override this behavior.

Try using the following instead.

sudo DEBIAN_FRONTEND=noninteractive apt-get install --yes --force-yes r-base

Edit: Note that rewriting the script to not use sudo everywhere and instead run the script as root would also work. But doing that would just be avoiding the real problem I pointed out instead of solving it and learning from it.

A more concise variant of the debconf solution mentioned in another answer is the following:

echo 'libc6 libraries/restart-without-asking boolean true' | sudo debconf-set-selections

I just used this solution successfully when upgrading glibc on Debian 7 (wheezy).

For the curious, the way I found the right configuration variable to set was as follows:

sudo apt-get install debconf-utils

sudo apt-get install -y libc6 # answer prompt interactively

debconf-get-selections | grep libc6

Step 1

On the host that had the package installed manually (interactive option selection) run:

apt-get install debconf-utils
debconf-get-selections > answers.conf

Step 2 (Optional)

At this point you may want to filter answers.conf to include the configuration answers only for specific package(s). I tested without filtering.

Step 3

When creating a new host, include answers.conf along with your automatic installation script. Before running apt-get install, in the script, run:

debconf-set-selections --verbose < answers.conf

Result

This will fill the debconf database with predefined answers. The interactive questions will not be asked when you run apt-get install.

Besides what we discussed in email, there is also the saying

If you can't beat'em, join'em.

so you could create a virtual machine on your laptop which corresponds to the (base) packages on the cloud instance, and then rebuild your own local R 2.12.1 .deb against those packages. As no upgraded libc6 is involved, you'd sidestep the issue.

Or, in line with your comment on possible side-effects being permitted, you could uninstall exim4, mysql and cron. Your R jobs won't need them. Something like

sudo dpkg --force-depends --remove ...names of your packages here...

but I can't really believe I recommend this :) You may need a trial and error to get all related exim and mysql packages.