Package keyboard-configuration post-installation script. Hang on /bin/setupcon --force --save for 10 min then killed

I concur. I can reproduce this error when I do a "sudo do-release-upgrade" on Ubuntu 11.10.

Status changed to 'Confirmed' because the bug affects multiple users.

Has anyone found a workaround for this? "sudo /bin/sh /bin/setupcon --force --save -v" does not print anything. strace does not print anything usefull either.

Same here.
Upgraded Lucid server via 'do-release-upgrade -d' and dpkg 'keyboard-configuration' (/bin/sh /bin/setupcon --force --save) freeze.
A workaround would be great!

Had the same issue; for me the problem was that the machine is headless and keyboardless. The keyboard detection mechanism in the new postinst script hangs while trying to determine the keyboard configuration; either uncommenting the old keyboard_present function (which is still in the file, commented out) or (as in my case) simply creating a keyboard_present function that returns 1 works for me.

+1 This has occurred for me while upgrading a server from Natty to Oneiric via do-release-upgrade. A fix would be great as I'm sure it affects others who are upgrading via this path (I'm going from Natty to Precise).

I was also upgrading Lucid.
But in my case the whole machine got stuck.
First at "Installing new version of config file /etc/init/console-setup.conf ..."
Reboot, dpkg -f instal..
Then at "Setting up keyboard-configuration (1.70ubuntu5) ..."
Reboot, stuck at the rootwait splash.

Correction:
The splash meaning changed, the system actually booted, I could switch to VT1 and turn on the networking.

Well, I've been battling this for the past 8 hours.

I'm trying to configure some virtual machines. My intention is to provision some real machines for use in an Ceph/OpenStack cluster. Since it'll probably take a few attempts, I want to automate as much as possible.

As a test, I am doing the deployment with a stack of VMs running under libvirtd/kvm on Gentoo. The actual machines will be headless 99% of the time (the remaining 1% will be for maintenance), so I couldn't give two hoots what keyboard layout it picks — we may even be setting up a serial device server and using serial console in the real deployment. Sadly, I don't see a way to skip this.

The set-up is a TFTP dishing out the netboot images and pxelinux configuration scripts. HTTP dishing out preseed files; one per host.

I have tried with Ubuntu 13.10, 13.04 and 12.04, all AMD64 architecture.
I have tried specifying the keyboard settings in the pre-seed file, and on the kernel command line, I've also tried leaving it out and answering on the console. No dice.

Maybe one attempt in 20 works and I get a working installation, but most of the time, install hangs at the "Configuring keyboard-configuration" step. There seems to be no rhyme or reason why it suddenly works, then doesn't.

The libvirt-manager CPU monitor seems to indicate activity consistent with a system that's waiting for input. But what? Where? How? It doesn't ask. It doesn't make it clear what it's wanting, or how I'm to provide it. It's not a matter of time either; I left VMs installing earlier this morning about 1AM … 6-7 hours later, I wake up, check on them, they're stuck at this very point.

What do I do?

Ohw, nice. Stuck here to upgrading a server in a server-center while at work, confronted with the same seemingly not solved problem. Grr..

I checked busy processes with a second terminal with "ps aux" and found:
root 22822 0.0 0.0 61072 15612 pts/2 S+ 10:44 0:00 /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/keyboard-configuration.postinst configure

Then I did:
kill -9 22822

And install process continued. Hopefully with success :p

Uhm, DON'T do the above! :/

Why? Did anyone found out what to do?
At the point of having to reinstall a big server with many users and mysql-databases because of this problem. I am really not looking forward to that.. :'(And hoping no power failure happens before i have to do the manual upgrade.
I was upgrading from 10.04 LTS to 12.04 LTS.

The hang in setupcon may be a red herring. I saw this on a machine (HP DL160 Gen9) with a FakeRAID controller (HP Dynamic Smart Array B140i) which isn't supported (yet).

I tried to install 14.04.2 LTS from USB media, and it got stuck at 76% (Running live-installer-console-setup).
After switching the controller to legacy SATA / AHCI mode, the install didn't hang anymore.

This may be caused by the controller interfering with writing to the target disk during the install, but I have no evidence for that.

As a workaround, I killed setupcon which was hanging, then it retried at the end, and I killed it again. Then I went into /usr/bin/setupcon as root and wrote in "exit 0" at the top, so it would exit without doing its evil work.

Then:

$ sudo dpkg --configure -a

at the end. And things seems fixed.

So in other words, you can do this change to /usr/bin/setupcon (and just miss whatever changes it does) after you've killed it the first time. Then the last time it tries, things will succeed. Or you can just fix things after the fact.

I have similar issue while installing Ubuntu via Cisco UCSM. Installation stuck on live-installer-console-setup until any key is pressed.
The proble was in in-target setupcon (executed by 25live-installer-console-setup) on printf redirected to $console:
 > for console in $ACTIVE_CONSOLES; do
 > [ -w $console ] || continue
 > if \
 > [ "$CHARMAP" = UTF-8 ] || [ -z "$CONSOLE_MAP$CHARMAP" ]
 > then
 > printf '\033%%G' >$console # here the installation stucks
 > else
 > printf '\033%%@' >$console
 > fi
 > done

so i ajdusted preseed not to use live-installer was workaround and everything worked fine:
d-i live-installer/enable boolean fase

Odin Hørthe Omdal (velmont), this is exacly what live-installer/enable=false do.

Bug is still there on "Ubuntu 16.04.1 Server" install on a kvm virtual machine.
Stucks at 76%
No way to kill it.

Still affects Ubuntu 16.04.2 LTS.

I found that going to each server and hitting scroll lock seemed to magically un-block the hung "/bin/sh /bin/setupcon --force --save" process and allow the apt upgrade to continue successfully. My setup may have triggered this bug because I use a KVM for my servers which uses a double-tap of scroll lock to switch screens, so I tend to be pressing scroll lock a lot at my servers' hard consoles.

I can confirm that hitting scroll lock allows setup to continue. This server has a physical keyboard directly connected to it that is never used. Scroll lock was on for some reason so hitting the button turned it off. My SSH session was stuck at "Configuring keyboard-configuration..." until I did that.

The fact that this is still broken after all these years is bullshit.

This error, and any attempts to unfreeze it ruined the ubuntu install on my VPS, and I have no means of getting the data off the fucking thing.

Tome on it just happened to me on Ubuntu 18.04.1 and I see that it was reported 2012 ffs !
This is not good at all.

The problem resides in virtual machines with some kind of broken consoles (or not correctly handled ones).

I narrowed down the problem to the the following command that is run on setupcon:

setfont -C /dev/tty1 /etc/console-setup/Lat15-VGA16.psf.gz -m /etc/console-setup/cached_ISO-8859-1.acm.gz

This is the command that locks up. It seems that "setupcon" detects tty devices wrong and tries to use invalid tty devices passing them to setfont which in turn is not able to correctly handle the situation.

To be more specific, this "setfont" process locks up in a "write" systemcall.