Gutsy->Hardy upgrade hangs in localedef

It appears that /usr/lib/locale has become a black hole. Doing "ls /usr/lib/locale/en_AU.utf8" results in a stuck process that cannot be killed with "kill -9". This is after the installer has finished (which required killing locale-gen several times) but I have not rebooted at all yet. (I'm afraid to.)

I just experienced the same. I came through a reboot doing this.

1.
Did a "sudo killall locale-gen" whenever that problem arose

2.
I watched closely when grub and the new kernel was installed.

3.
Checked that /boot/grub/menu.lst looked right

4.
Checked /lib/modules/2.6.24-19 looked right

5.
Had a good look at the report about failed packages, nothing alarming showed up

6.
Rebooted without a problem

7.
"sudo aptitude upgrade" which fixed the problems

8.
Have a fully functional desktop

Exact same problem. Locales fails to generate after upgrade from Feisty->Gutsy->Hardy.

localedef takes 100%cpu, localedefs also seams to spawn a gzip process which is defunct. Not possible to kill either localdef or gzip. Rebooting to the same old kernel doesn't fix the problem. Haven't tried the hardy kernel yet since it was corrupted when I was forced to reboot machine with button.

Fixing the crached 2.6.24-19 kernel and rebooting to this kernel then doing a dpk-reconfigure locles works.

So the problem looks to be to generate the locles when running with the gutsy kernel. Strange.

I just ran into the same problem a few hours ago. Google brought me to the same sources as quoted above. "Compiling" the collected information, here is a work-around that did it for me (step-by-step - so everybody can solve it until the bug is fixed):

run the dist-upgrade as recommended. If the process hangs at generating locales, taking more than 20min for the first one and still not continuing:

chmod 644 /usr/bin/localedef
killall locale-gen

now the process should continue, but throwing a bunch of errors (simply ignore those). If it still not continues, check whether locale-gen has really been killed (ps aux|grep locale-gen) and repeat "killall locale-gen" until it's gone.

When update-manager is done, don't forget to

chmod 755 /usr/bin/localedef

For me, update-manager seemed to be able to finally solve the issue, there have been no more steps required after the above. But just to be sure:

Reboot to the normal grub option offered (i.e. the latest kernel just installed), but do not yet login graphically. Instead, press Ctrl-Alt-F1 to get a text console. Login there, and run

apt-get dist-upgrade
dpkg --configure -a

As just stated, in my case both were done within a second, simply stating there was nothing to do. Now you can logout here (type "exit" or press Ctrl-D), return to the graphical console (Alt-F7), and login. You are done.

Besides: I was really mad that the dist-upgrade forced me to install OpenOffice. I had it explicitly uninstalled, since it conflicts with StarOffice which I prefer. Luckily, I was able to simply uninstall OO again and there have been no side-effects left as far as I can tell up to now. The dist-upgrade should not just install stuff like that if it was not installed...

Will on -server kernel it's not that simple, since it's not possible kill the localedef and gzip process. And a "ps" when localedef is stuck also hangs ps and since many of the following updates uses ps, they will also get stuck.

The only way around the problem I can think of is to remove
/var/lib/locales/supported.d/local BEFORE doing the upgrade. This might solve the issue on -server at least.

Failing my second machine today... skit.

this is the FIX !!!!!

We may have the solution here (on the french forum).

Just reboot, but don't choose the upper choice proposed
by grub. Take another one, not in recovery mode.

Wait for the login screen, then ctrl+alt+F1
and log in.

Then make

sudo apt-get dist upgrade (but I'm not sure this is necessary)

then :

sudo dpkg --configure -a

and for me everything is fine. Still this is a big bug...

REF ####
 hurlements
First Cup of Ubuntu

Join Date: Jul 2008
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts

http://ubuntuforums.org/showthread.php?t=861194&page=2

Let's call it a workaround, it's surely not a fix. ;^) Also, it didn't work for me, though I'd done quite a bit of other experimentation so my system wasn't exactly fresh. In fact, after needing to use the magic SysRq key to reboot a couple of times (I had an unkillable localedef that prevented system shutdown) my filesystem is totally corrupted and all data lost. Luckily the really important stuff was on other partitions/drives.

I'm not so impressed with this release, guys.

My findings so far when upgrading a couple of servers.

*When localedef takes 100% cpu it's not possible to kill it.
*killall locale-gen makes the upgrade continue for awhile but get stuck when one package tries to do a ps, which will also hang.
*Poweroff and then start with Gutsy kernel doesn't work since localedef takes 100% again when configuring locales.

The only solution I can find on -server kernel is to:
* mv /var/lib/locales/supported.d/local ~/
* do-release-upgrade
* start with new Hardy kernel
* mv ~/local /var/lib/locales/supported.d/
* dpkg-reconfigure locales
* reboot

Thanks Rocco!! This work around works for me.

My upgrade also hangs yesterday. After reboot I removed the /var/lib/locales/supported.d/local file and start "dpkg --configure -a"

i found out that localedef works well with the old kernel 2.6.22-14 (the original one coming with gutsy) but not the current one -15 in gutsy. Maybe the kernel is messed up?

So if all fails and you still have the old kernel on your box, use this one and do the upgrade.

I was able to get around this bug by going to a tty command prompt (ctrl-alt-fn) and running
sudo dpkg -r -a
then running
dpkg --configure -a
The configure step appeared to pick up at the failing local installation and the rest of the upgrade continued.

I just want to mention a possible important aspect:
This bug is not limited to OS Upgrades!

I tried adding another language via System->Administration->Language Support, and got the exact same issue: hang when generating locales.

The "work around" that made my machine able to install stuff was:
1) reboot (the only way to kill locale-gen)
2) sudo rm /usr/bin/localedef (deletes all localization)
3) sudo dpkg --configure -a ("fixes" the package manager so u can install stuff)

However, when I tried to re-install "locales" and "belocs-locales-bin" using the synaptic package manager, i got into the same problem; hang when generating locales.

I hope this will help to track down the bug, since this is not only an upgrade issue, the simplest steps to reproduce are:
1) Open language Support (System->Administration->Language Support)
2) Select another language
3) Click OK
4) Notice the system hang when generating locales

Note I am not a developer so I am not sure if this could make things worse ( I don't see how it would but I would like a second opinion from someone more knowledgeable ) but if someone either has a spare machine they can replicate this problem on or someone confirms that this is safe could you run:

"sudo sh -x /usr/sbin/locale-gen > stdout.txt 2> stderr.txt"

And attaching the two files, this should tell the exact point where the script is stalling ( or stuck in a loop, or whatever the problem is )

Looking at the script and the comments here it's pretty clear that the script is probably stalling when running localedef but the output from sh -x might still be useful to see exactly what arguments are being passed to localedef if nothing else, or it might not :)

Thank you for taking the time to report this bug and helping to make Ubuntu better. Could you please add the log files from '/var/log/dist-upgrade/' to this bug report as attachments? Thanks in advance.

My '/var/log/dist-upgrade/' is empty because it is a "fresh" install of Gutsy. The hang happened when I wanted to add another language.

Where can I find helpful log files in this case?

Connor: See bug 249346 for the log files.

see #249258

Marking bug #249346 as a duplicate of this one and upgrading status to Triaged. Thank you for following through with these reports.

Thanks Rocco! Your work around worked for me as well. I'm back up and running on the 2.6.24-19-server kernel. Excellent!

This bug happened to me.

My work around:

1. Reboot. (my machine didn't shutdown clearly and had to be powered off)
2. At grub menu choose kernel 2.6.22-14 (not 2.6.22-15)
3. Once booted run dpkg --configure -a
4. wait (it takes a while)
5. Reboot

This has mostly been posted above but I thought I break it down into a simple 5 step guide for muppets like me ;)

After running the five steps above, is there anything that should be run to ensure all of the packages have been updated and installed correctly?

THANKS!

~ron

This is what worked for me thanks to folks (behda) on the Ubuntu forums. I did not lose any data and it worked just fine.

1 start PC and let it load to X login screen (after getting X setup popup and choosing continue)
2 do a ctrl+alt+F1 and get to terminal and login.
3 sudo rm /usr/bin/localedef
4 sudo dpkg --configure -a
5 let upgrade finish and when back to the prompt "reboot"

If it's of any help the 5 steps described by Drew Fitzsimmons worked for me too, in the upgrade from 7.10 to 8.04.
After the reboot everything seems to work fine.
Thanks Drew!

This happened to me as well. The process of kill -9 {all the locales processes} then reboot to a command line window, and apt-get dist-upgrade followed by dpkg-reconfigure locales fixed the problem. Thanks everybody for the help.. BUT..

This is not a new bug. It has been going on for some time. Surely the 8.04 upgrade should be suspended until it is sorted out. There are plenty of folks who don't/can't go through this fixit process.

I tried the steps above and I could not get it to work. X-server failed and I tried the repair utility. It told me that some packages were not installed properly. When doing a sudo dpkg --configure -a it would fail several packages because it looks like it could not resolve the URL to download the packages. I was so frustrated after hours of trying to get it to work that I ended up blowing away the whole install and reloading Gutsy from my CD. :(

Hope it gets fixed. I would really like to move over to Hardy.

I was just browsing with synaptic and found some interesting maybe-hint: There have been changes with the package "locales", which is replaced now by "belocs-locales-bin" (which is marked installed). However, the package "belocs-locales-data" is NOT installed. Is it possible that this causes the problem somehow? From the metadata, belocs-locales-data requires belocs-locales-bin, but not the other way round - so it may have been forgotten.

After the reboot I had a ton of files in my recycle bin. They all appear to be duplicates. Not sure where they came from.

~ron

Thanks, Drew Fitzsimmons, this work around worked for me.

I had the same problem with as Alecz20 by adding another language via System->Administration->Language Support.

Roman,

After doing the steps Drew suggested, what happens if you go to System->Administration->Language Support ?

Do you have a default language?

In my case from the list of languages, English is selected, but it does not appear below, in the drop-down menu.

Additionally, did you manage to add the other language?

I fixed the upgrade using the method I mentioned earlier, i.e.
sudo dpkg -r -a
before the dpkg --reconfigure -a
I checked System->Administration->Language Support
A popup indicated that two packages were not completely installed
language-pack-kde-en and language-pack-kde-en
I accepted the offer to install them. The available languages are now legion, with English checked as the default.

Having seen some other postings about renamed packages, I suspect this is a much cleaner way fo fixing the problem than some of the more brutal suggestions.

I encountered the same bug as Alecz20 when adding language support for zh besides en (the default). I don't want to upgrade to 804, so this is not a "upgrade" only problem.

my kernel: 2.6.22-15-generic #1 SMP

Is bug #249953 the same bug?
Also, after switched to kernel 2.6.22-14-generic #1 SMP, although I could still observe several defunct gzip processes during language-support configuration, but the whole configuration can finish successfully and automatically, and any defunct gzip process disappeared at last.

I had to set synaptic source to us main server.
that was after using options to get the gui to come in the safe mode.
restarted computer
picked 14 instead 0f 15 used regular log in
it hung at gui
restarted computer
picked options instead of logging normally
chose terminal option
then ran
sudo apt-get dist-upgrade
sudo --configure -a

it worked, I dont know how or why, but I thank all for your help

I fixed this bug by going to Language Support and since I am dutch (from the Netherlands) deselected English (this is where generating locales went wrong) and installed the Dutch language. Now "Generating locales" went fine. After the reboot there were some updates left and these updates installed the English language again without any problems.
My guess is that the bug is within the en_AU.UTF-8 file of the locales package.

I had English as default and i tried to add French.
The generating locales hanged when adding the fr_BG.UTF-8 package IIRC.

I might try your method to see if I can get both French and English.

I ran into the same problem and I followed PerJensen's steps, and this "seems" to have fixed my problem. I kind of wish I followed Drew's steps though. His steps are quite a bit simpler.

His workaround:

1. Reboot. (my machine didn't shutdown clearly and had to be powered off)
2. At grub menu choose kernel 2.6.22-14 (not 2.6.22-15)
3. Once booted run dpkg --configure -a
4. wait (it takes a while)
5. Reboot

Drew's steps worked for me in three different systems.

There's a easy workaround.

The /usr/share/locales/install-language-pack script, used in the postinst of the language-packs packages, invokes /usr/sbin/locale-gen.

locale-gen makes some work and finally it executes localedef, that hangs up. Looking the "ps -aux" output, copying the localedef execution order, deleting the option "--no-archive" it works correcty. It's a mistery, the problem is present when the locale information is stored in locale_country.charset directory inside /usr/lib/locale/, for instance, es_ES.utf-8.

This locale-gen shell script uses the /etc/belocs/locale-gen.conf conffile of belocs-locales-bin package, which has the variable ARCHIVE with the "no" value. By changing this value to "yes", the locale information is stored in one unique file /usr/lib/locale/locale-archive. And the most important, then localedef works, does not hangs up. Now we can install, reinstall language-packs and so on.

Greetings and a lot of luck

Hey Fco Javier Lopez,

Your workaround sounds interesting but I am afraid it's a bit hard to follow. This hang is one of the major things that prevent me from Upgrading to 8.04, and also prevents me from recommending my friends to do so.

My question is, can you put this workaround in simpler words? Apparently I have top change something from "no" to "yes, which sounds simple, now where EXACTLY do I have to change that?

The info you submitted is probably useful for fixing the bug, but until then what EXACTLY do the users have to do so they can upgrade and install language-packs?

Thanks!

Hi Fco Javier Lopez,

I tried your solution (changing the value ARCHIVE to "yes" in the "/etc/belocs/locale-gen.conf" file. Unfortunately, the language changing utility still hangs...

This problem has not always been the case since hardy was released.

I came across the problem today and hence this thread after coming across the same locales problem.

The thing is I have upgraded from Gutsy with no problem at all with English UK being the defualt language a couple of days after the official release after discovering the hardys migration assistant didn't work. I ended up with the other 4 users on my windows system being on my main ubuntu login. All their pictures,files etc.

After re-installing Gutsy and updating then following the upgrade path no problem at all.

About a month later after screwing up my system badly with some unofficial proposed upgrades (never doing that again) I reinstalled again with no problems and decided to keep my Gutsy installation disk just in case.

This just in case situation occured this morning following a disk corruption. I managed to rescue some essential files. Installed Gutsy. All the updates and like you found it hung.
My theory it that the situation has arison because of a bug that has arisen because of something introduced in one of the gutsy updates since hardy was releases unless the files in hardy that are downloaded during the upgrade are different now since the first release.

It would be interesting to see if someone has an original alternate CD of Hardy that allows an upgrade from Gutsy to see if there are any problems compared to trying the new 8.04.1 release available now.

Inidentally the steps to fix worked for me
kernel 2.6.22-14
 dpkg --configure -a

BUT I couldn't select ctrla-alt-f1 to a console from X. I had to safe boot to the console and log in whereupon I was given the option to dpkg. In my case it was done quite quickly and after reboot everything seems fine.

My guess is that this is related to Kernel bug #231746 [https://bugs.launchpad.net/bugs/231746]

Someone mentioned doing the upgrade from the 2.6.22-14 kernel instead of the -15, can anyone confirm this worked?

Just done the upgrade from the 2.6.22-14 kernel and everything went fine, no hang at locales.

Only little thing was kernel 2.6.22-15 got removed, so there's only the new 2.6.24-19 and old 2.6.22-14 kernel now. But this is really minor, i don't think anyone intend to run hardy with kernel 2.6.22-15 anyway.

Thank you all for all the information. I manage to workaround this problem.
After the installation failed due to the "locale" issue, I restarted my system, selected the latest installed kernel, tried Ctrl+Alt+F1 (which showed me the boot process in console mode but in the end I was still under Gnome logged in), and then I just opened a terminal under Gnome and perform the apt-get dist-upgrade and the dpkg-reconfigure -a.
It was painfully slow, but in the end worth it, as my system seems to be working properly.

I hate to be a me-to, but I just upgraded 7 servers to 8.04 and had this problem with one of them. The other 6 went fine.

The server in question was step-upgraded from 7.04 to 7.10 to 8.04 with a reboot between each. It runs Nagios. The problem didn't occur until the upgrade to 8.04 was happening (as I'm sure you expected.)

The workarounds listed above helped me get the server back up, but any attempt to add or remove software results in the freeze yet again. I have a broken dependency problem with one of the Nagios packages, but any attempt to fix it triggers the locale generation again and it freezes. Killing the process allows dpkg to continue configuring, but it never stops all the locale related processes.

Even though this is a production server, thankfully the only thing it does is use Nagios monitoring to watch the other servers, so I can live without it for a few days and run Nagios elsewhere. If I'd known about this bug before upgrading, I would NOT have upgraded any of my servers.

@Tony Maro: To get at least your broken dependencies fixed without a hang, you could try the following:

chmod 644 /usr/bin/localedef
# fix your dependencies here:
# apt-get install -f (or whatever)
chmod 755 /usr/bin/localedef
# here you may try to "repair" your locales (optionally)
# dpgk-reconfigure locales

By stealing the execute bit from /usr/bin/localedef you prevent the hang from happening - but also the setup of the locales. If you don't get any locale errors after that (try e.g. invoking some man page, like "man bash"), you probably don't need to run the dpkg-reconfigure (I may be wrong with this one - so somebody else may correct me). I successfully upgraded 3 machines this way now - so I'm done with the current dist-upgrade ;)

I just ran into this same problem. Running drew's steps, including the .14 kernel, fixed it:

His workaround:

1. Reboot. (my machine didn't shutdown clearly and had to be powered off)
2. At grub menu choose kernel 2.6.22-14 (not 2.6.22-15)
3. Once booted run dpkg --configure -a
4. wait (it takes a while)
5. Reboot

Well... I can confirm that generating locales with the old kernel (2.6.22-14) does NOT hang.

However, I have yet to figure out how to get "locale" command to show the language I chose in Language support and not "C"

Any ideas?

NVM my last problem. After the Reboot everything is fine.

I had to re-install belocs-locales-bin using synaptic since the command localedef said it wasn't installed, and apt-get install belocs-locales-bin said I already had the last version (they contradicted each other).

Re-installing is not possible in -15 kernel due to the hang, but in -14 the locale generation went smoothly.

Hello,

(how to replicate:) I've seen this issue with two of our company's (human) clients upgrading from 7.10 -> 8.04: The upgrade fails (freezes) and when the client reboots the machine it is no longer usable. Running dpkg --configure -a freezes while trying to generate locales. Killing the locale-gen-command with kill -1 or -9 switches does not work. Dpkg is also cramped since it cannot install dbus, and pretty much everything depends on it to install (and configure first).

Solution:
1. reboot the machine using the older recovery mode (the newest kernel isn't fully installed and does not work properly)
2. run "mkdir /var/run/dbus" since it is missing and would otherwise stop package dbus from upgrading.
3. run "dpkg --reconfigure -a": It will finish installation of dbus and then locale-gen will work.
4. Reboot. Everything works.

Long-term solutions to avoid similar issues in future:
- Watch the dpkg-process: if it hangs for a long while, start automatic recovery processes. It is not good behaviour that a single bad behaving package configuration halts the entire system upgrade.
- Use info from "dpkg -C" to check what package is stopping dependency-ways installation of all other packages - then report to user the name of that package or show a pstree-kind of report of showstopper dependencies.
- Fix dbus package so that is will generate directory /var/run/dbus itselft if it is missing.

I tried very hard to reproduce this. I did test gutsy->hardy upgrades with the following five methods:

 * gutsy chroot, partial upgrade to hardy's locales, libc6, and belocs-locales-bin
 * gutsy installation, partial upgrade
 * gutsy installation, full apt-get dist-upgrade
 * gutsy installation, full update-manager dist-upgrade, with 1 GB RAM and 256 MB RAM

None of those reproduced the bug. So I'm afraid this is a race condition, or dependent on some other factors than configured locales, RAM size, etc.

Martin, when you say "partial upgrade", "full apt-get dist-upgrade", etc. are you talking about upgrading after switching to hardy's repositories, or getting up to date with the latest gutsy packages?

As far as I can tell from my own experiences and the comments above, this bug only occurs when using the latest gutsy kernel (2.6.22-15). If you didn't already, I'd suggest trying:

1) Install gutsy (not just in a chroot, since you need to boot with its kernel)
2) Bring gutsy fully up-to-date with an apt-get dist-upgrade (don't yet use hardy's repositories)
3) Reboot so you are running with the latest gutsy kernel
4) Attempt to upgrade to hardy using whatever method pleases you (I used update-manager)

Unfortunately I'm not able to test this procedure myself at the moment, but it hopefully mirrors the state my system was in when I experienced this bug.

I have a pretty obvious question:

If the upgrade does NOT hang with the older kernel (2.6.22-14) would it be possible to upgrade from that kernel altogether (and add languages for that matter) in order avoid the bug in the first place?

I still haven't upgraded so I don't know exactly what the mechanics are.

I can confirm that this still occurs even with 8.04.1:

1. Fully upgraded/updated Gutsy (Gnome desktop) machine as of today Aug 5, 2008
2. Insert 8.04.1 Alternate CD and select the upgrade option on the popup window
3. Allow it to fetch updates from the network in addition to the CD
4. Upgrade proceeds until it reaches the Generating locales...
  en_AU.UTF-8...
5. Open a terminal window and kill locale... it's continuing to upgrade albeit with misconfigured packages that will need to be corrected using the workarounds listed in this bug report.

NoOP, any idea what happens if you do this between step 1 and 2:

"Reboot with 2.3.22-14 Kernel"

I suspect the upgrade will go smoothly, since Martin Pitt said he didn't have any problems with upgrading a fresh gutsy installed (hence not an updated kernel)

> NoOP, any idea what happens if you do this between step 1 and 2:
>
> "Reboot with 2.3.22-14 Kernel"
>
> I suspect the upgrade will go smoothly, since Martin Pitt said he didn't
> have any problems with upgrading a fresh gutsy installed (hence not an
> updated kernel)
>

Unfortunately no as I've already completed the update. I have one other
machine to go (this one) and it will probably wait for Intrepid. If I
get the chance I'll do a Gutsy install on a test machine later today or
tomorrow and see if I can reproduce.

Me too, twice. I've now seen this problem on two upgrades from Gutsy to Hardy.

In both cases the Gutsy machines were updated to the latest kernel (2.3.22-15).

Following the general advice to kill the locale generating processes (several times) to reach the end of the upgrade process, accepting the error messages and shutting down after the final message about the update aborting left me with machines that did boot ok and just required me to run sudo dpkg --configure -a to sucessfully generate the missing locales and ubuntu-minimal(?). The resulting installations now appear to be fine, but getting there was more stressful than it should have been...

Happy to post finer details, install logs and so on if requested.

Neil

I have also had this problem (makes Gutsy -> Hardy a pain), with exactly the same symptoms and solution.

As it seems that the problem is well documented, and there is a work-around, why is this bug still marked "Incomplete" ? Is there any file one of us can add to this bug report to help reproduce it ?
Or is there any chance that a code analysis between 2.6.22.14 (good) and 2.6.22.15 (bad) may give pointers to the race condition ?

Well... I suspect this will not get fixed in time. I don't know how much they fix stuff for older versions (e.g. Gutsy). I wonder if they can somehow instruct users to upgrade from the older kernel rather than the new one to avoid the entire hassle of "fixing the upgrade bug"

What is incomplete with this bug report ? Logfiles were provided in the duplicates bugs, there's a way to reproduce it.

To me it should be a higher priority, it seems to affect almost everybody trying the upgrade hardy->gutsy (people who didn't do it in april, or all the people who get a laptop with ubuntu preloaded).
For example a french journalist (from one of the biggest daily newspaper: Liberation) who was trying ubuntu reported it while trying to upgrade from a laptop preloaded with hardy (http://www.ecrans.fr/Linux-Le-journal-d-un-novice-2,4679.html in french). This gives a not so nice picture of the upgrade path for a Linux beginner.

I read the article. He is basically writing an article in the newspaper about the hang during the Upgrade from Gutsy to Hardy.

The problem appears to be somewhere in the new kernel, but should be fixed, or at least a work-around implemented.
maybe a small update that would make the Upgrade reboot in old kernel and do everything from there?

I don't know why the Incomplete status is... but ANYONE can reproduce this bug, even a Journalist that knows little about Linux.
As I posted in another thread, the easiest way to reproduce is:

1) have Gutsy installed with all updates
2) Try to add a language
3) Notice the hang.

Many, many thanks to all who posted fixes for this issue. I'm sure glad I encountered it on a test system before trying to upgrade a production box.

I have 2 systems running Dapper LTS server currently, and one that I've just put into service which is running Hardy. This morning I noticed that there was a new upgrade for locales for the Dapper systems but not for the Hardy. Has the origin of this "bug" been detected and has it been fixed so that the system upgrades will work?

Is there any way to determine when the problem has been resolved (so that the "work around" is unnecessary?)

@Gregory: The problem probably does not come up with the direct upgrade from Dapper, since as it reads it is introduced by the latest kernel from Gutsy. I just upgraded my server from Dapper last weekend (and to make sure to not hit the problem, I removed the execute bit from /usr/bin/localedef as soon as it was updated - which is at about 50% of the upgrade process - and when the upgrade was done, I ran "dpkg-reconfigure locales", which ran fine). However, I was quite surprised by the fact that the upgrade removed the apache2 and mysql server...

I'm a bit surprised that noone else seems to be considering how to *fix* this problem. All I'm hearing are work-arounds for users, which is not really adequate.

It's pretty clear that there's a kernel bug -- nothing else explains the "unkillable processes" problem (which I can personally vouch for using linux-image-2.6.22-15-generic). The only question is whether the kernel bug is new, or whether something changed in localedef so that it now triggers a bug that already existed.

I earlier mentioned that I suspected that this was related to kernel bug #231746, which indicates that the problem is triggered by trying to write a zero-length segment to a file -- either a malformed descriptor for "writev" or a zero length for an ordinary "write".

However that bug report refers to linux-image-2.6.24-16-xen so I spent a few hours last night looking through the diffs between 2.6.22-14 and 2.6.22-15 to see if there was a similar problem there. Well that part of the kernel has had a bit of an overhaul between 2.6.22 and 2.6.24, and I didn't come up with anything definitive.

I'll be looking at localedef when I get time. First up is running localedef under "strace" -- but I'm not going to get onto it for a while, so if someone else could do that and report what it's doing when it stops that would be really helpful.

I've just run the same version of localedef on 2.6.22-14, where it runs fine, and on 2.6.22-15, where it hangs.

Here's the output of "strace localedef" immediately before it hung:

1218150691.384821 creat("/usr/lib/locale/en_NZ.utf8/LC_CTYPE", 0666) = 3
1218150691.403450 writev(3, [{"\x15\x11\x03\x20\x58\x00\x00\x00", 8}, {"\x68\x01\x00\x00\x68\x04\x00\x00\x68\x0a\x00\x00\x68\x0a"..., 352}, {"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"..., 768}, {"\x80\x00\x00\x00\x81\x00\x00\x00\x82\x00\x00\x00\x83\x00"..., 1536}, {NULL, 0}, {"\x80\x00\x00\x00\x81\x00\x00\x00\x82\x00\x00\x00\x83\x00"..., 1536}, {NULL, 0}, {"\x00\x00\x02\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x00"..., 1024}, {NULL, 0}, {NULL, 0}, {NULL, 0}, {NULL, 0}, {"\x75\x70\x70\x65\x72\x00", 6}, {"\x6c\x6f\x77\x65\x72\x00", 6}, {"\x61\x6c\x70\x68\x61\x00", 6}, {"\x64\x69\x67\x69\x74\x00", 6}, {"\x78\x64\x69\x67\x69\x74\x00", 7}, {"\x73\x70\x61\x63\x65\x00", 6}, {"\x70\x72\x69\x6e\x74\x00", 6}, {"\x67\x72\x61\x70\x68\x00", 6}, {"\x62\x6c\x61\x6e\x6b\x00", 6}, {"\x63\x6e\x74\x72\x6c\x00", 6}, {"\x70\x75\x6e\x63\x74\x00", 6}, {"\x61\x6c\x6e\x75\x6d\x00", 6}, {"\x63\x6f\x6d\x62\x69\x6e\x69\x6e\x67\x00", 10}, {"\x63\x6f\x6d\x62\x69\x6e\x69\x6e\x67\x5f\x6c\x65\x76\x65"..., 17}, {"\x00\x00\x00\x00", 4}, {"\x74\x6f\x75\x70\x70\x65\x72\x00", 8}, {"\x74\x6f\x6c\x6f\x77\x65\x72\x00", 8}, {"\x74\x6f\x74\x69\x74\x6c\x65\x00", 8}, {"\x00\x00\x00\x00", 4}, {"\x10\x00\x00\x00\x11\x00\x00\x00\x07\x00\x00\x00\xff\x01"..., 25560}, ...], 125

Note the "{NULL, 0}" elements.

Now it's a matter of getting a suitable kernel patch.

This workaround worked for me, also.

HTH.

I suspect that Martin Kealey probably is on to the real issue.

@Martin Pitt: why are you only testing with -14 when the current Gutsy upgrades are at -15?

@Alecz20: I finally managed to test on two systems. As you probably know, on slower low memory systems loading up a new Ubuntu, updating, and then upgrading is pretty much an all day job. I loaded up 2 freshly installed Gutsy's, fully updated them both to -15, and performed the upgrade on both; 1 at -14 and 1 at -15. The -14 worked and the -15 failed at the localedef.

@Martin Kealey: which command/file did you use with localedef? I still have 2 Gutsy's left (w/-14 & -15) and I'd also like to try to confirm.

The strace output starts with:

execve("/usr/bin/localedef-real", ["/usr/bin/localedef-real", "--no-archive", "--magic=20051014", "-i", "en_NZ", "-c", "-f", "UTF-8", "en_NZ.UTF-8"], [/* 42 vars */])

Adjust to suit the locales you actually have installed.

(I moved /usr/bin/localedef to /usr/bin/localedef-real, and created a script in its place that started localedef-real under strace. So now I have lots of strace logs in /var/tmp ... they're about 250kB when it runs to completion and about 150 kB when they stall.)

My script also writes a history log, which says:

2008-08-08,11:02:05+1200 [7651] /usr/bin/localedef --no-archive --magic=20051014 -i en_AU -c -f UTF-8 en_AU.UTF-8
2008-08-08,11:02:07+1200 [7680] /usr/bin/localedef --no-archive --magic=20051014 -i en_BW -c -f UTF-8 en_BW.UTF-8
2008-08-08,11:02:09+1200 [7708] /usr/bin/localedef --no-archive --magic=20051014 -i en_CA -c -f UTF-8 en_CA.UTF-8
2008-08-08,11:02:11+1200 [7737] /usr/bin/localedef --no-archive --magic=20051014 -i en_DK -c -f UTF-8 en_DK.UTF-8
2008-08-08,11:02:13+1200 [7767] /usr/bin/localedef --no-archive --magic=20051014 -i en_GB -c -f UTF-8 en_GB.UTF-8
2008-08-08,11:02:15+1200 [7798] /usr/bin/localedef --no-archive --magic=20051014 -i en_HK -c -f UTF-8 en_HK.UTF-8
2008-08-08,11:02:17+1200 [7827] /usr/bin/localedef --no-archive --magic=20051014 -i en_IE -c -f UTF-8 en_IE.UTF-8
2008-08-08,11:02:19+1200 [7851] /usr/bin/localedef --no-archive --magic=20051014 -i en_IN -c -f UTF-8 en_IN
2008-08-08,11:02:21+1200 [7881] /usr/bin/localedef --no-archive --magic=20051014 -i en_NZ -c -f UTF-8 en_NZ.UTF-8
2008-08-08,11:11:29+1200 [6524] /usr/bin/localedef --no-archive --magic=20051014 -i en_NZ -c -f UTF-8 en_NZ.UTF-8
^^^ above stalled
vvv below ran to completion
2008-08-08,13:32:08+1200 [7547] /usr/bin/localedef --no-archive --magic=20051014 -i en_NZ -c -f UTF-8 en_NZ.UTF-8
2008-08-08,13:47:23+1200 [6740] /usr/bin/localedef --no-archive --magic=20051014 -i en_NZ -c -f UTF-8 en_NZ.UTF-8
2008-08-08,13:47:25+1200 [6769] /usr/bin/localedef --no-archive --magic=20051014 -i en_PH -c -f UTF-8 en_PH.UTF-8
2008-08-08,13:47:27+1200 [6798] /usr/bin/localedef --no-archive --magic=20051014 -i en_SG -c -f UTF-8 en_SG.UTF-8
2008-08-08,13:47:29+1200 [6827] /usr/bin/localedef --no-archive --magic=20051014 -i en_US -c -f UTF-8 en_US.UTF-8
2008-08-08,13:47:31+1200 [6856] /usr/bin/localedef --no-archive --magic=20051014 -i en_ZA -c -f UTF-8 en_ZA.UTF-8
2008-08-08,13:47:33+1200 [6885] /usr/bin/localedef --no-archive --magic=20051014 -i en_ZW -c -f UTF-8 en_ZW.UTF-8

On Fri, Aug 08, 2008 at 10:39:24AM +0200, Benoit Boissinot wrote:
> The only related diff between the kernel versions is below,
> notice how the 'if (unlikely(status))' differs from the upstream patch:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=64649a58919e66ec21792dbb6c48cb3da22cbd7f
>
> it doesn't seem to take into account partial writes (status > 0).

Ok, after the commit_write, they seems identical. But still that's
probably the only related patch (if the bug is from the kernel).

--
:wq

If you look at the history for this file:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=mm/filemap.c;h=54e9686508550b198b4779df048bbfe46b2ddb08;hb=HEAD

You'll see that http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64649a58919e66ec21792dbb6c48cb3da22cbd7f was backported.

I think the backport is wrong. Let me explain why:
The first filemap_set_next_iovec() finds a {NULL, 0} iovec
Then if "!segment_eq(get_fs(), KERNEL_DS)" (write is from userspace), the variable bytes will be equal to 0 (because cur_iov->iov_len - iov_base == 0).
Then it will goto zero_length_segment
And here the patch changed the behaviour, before the test was ">= 0" so it included the case where the iovec was empty, and then it finished by calling filemap_set_next_iovec() which would advance from at least one iovec before continuing.
Now it test for "> 0" so nothing will happen before the continue instruction. Hence the infinite loop.

If I'm right this is a kernel bug, so please change the bug description accordingly, I don't know how (or don't have the permissions) to do that.

I hope this is the right way to do it, change to confirmed + change package

Thanks Tonfa,

I'll try and get the kernel team to examine the patch you've referenced.

I'm also just curious if this issue still manifests itself if you try to upgrade from Hardy to the ucoming Intrepid. But please note that testing upgrading to Intrepid is completely at your own comfort level though and not mandatory for you to do. As noted in our Alpha release announcements "Pre-releases of Intrepid are *not* encouraged for anyone needing a stable system or anyone who is not comfortable running into occasional, even frequent breakage. They are, however, recommended for Ubuntu developers and those who want to help in testing, reporting, and fixing bugs." I'm just curious if this will also affecct the upcoming release. Let us know if you feel comfortable to test and what the results are if you do. Thanks.

On Fri, Aug 08, 2008 at 06:06:53PM -0000, Leann Ogasawara wrote:
> Thanks Tonfa,
>
> I'll try and get the kernel team to examine the patch you've referenced.
>
> I'm also just curious if this issue still manifests itself if you try to
> upgrade from Hardy to the ucoming Intrepid.

I personnaly don't have the ressources to test, but looking at the kernel
history, the backported patches is a couple of months older than 2.6.24
(the kernel shipped in hardy). So there shouldn't be any backport
screw-up related to mm/filemap.c in it.

regards,

Benoit

--
:wq

Add me to the stack.

Upgraded using the Upgrade Wizard, and it locked up at

Generating locales...
  en_AU.UTF-8...

Dropped into a shell and issued "sudo killall locale-gen" and it moved on...

Good thing I have more than one computer. I can see this being devastating for someone with only one PC!

Oh, and this was on Kubuntu where I experienced the error.........

After an upgrade of 7.10 to 8.04 I had the same error. I booted into recovery menu, dropped to root and did this:
apt-get update && apt-get - u dist-upgrade.
well, it sort of continued for a while even doing all the locales and some other packages but eventually aborted with a 'too many errors' message and stated that dpkg was interrupted and should be run manually , so then i ran this:
(as root user)
dpkg --configure -a
this got it a bit further along but eventually after upgrading many packages? it aborted again., so at this point I typed 'exit' to return to the recovery menu, and now selected the resume normal boot option and although very very slow it eventually actually showed the graphical ubuntu logon screen. How do I continue with a full recovery to fix the still broken apps/pacages? Any help appreciated. Please provide exact instructions.

Here's what I did --

killed the wizard
dropped into a shell
issued dpkg --configure -a
opened another shell
issued sudo killall locale-gen ------------every time it locked up on
some language thing
it finally finished

then reboot
pick a different kernel when grub starts.
dont' pick a recovery one, just roll back a version or two, but whatever
you do, don't pick the one that's at fault (which is 15 i think)
next --
DO NOT LOG INTO THE GUI

hit control alt F2

log in to the console

type
sudo apt-get dist-upgrade

when it finishes, sudo reboot now

let autopilot take over....

should be good to go.

Well, as a linux newb, im just confused. Ive only used windows, up until a few months ago.
I've only recently had the time/patience to try and upgrade to v8.04. Needless to say, it froze on "generating locales". As this is my only pc, and the filesystem was corrupt, i could do nothing except format and re-install 7.03 from disc, then upgrade to 7.10. In total i spent 12 hours achieving absolutely nothing, except losing all my media files.
I do want to stick with ubuntu, but im disheartened with it now.

Please help a lil newb like me, before i jump off the bridge, and back onto windows.

Does that workround permenantly solve the problem of, and install, v8.04?

Also, could i just boot kernel 14 and upgrade with the update manager?

There was no reason for you to lose any data.

You should have backups (irrespective of the OS you use) because
something can always go wrong.

Something you must consider is to have a separate partition for your
data, or at the very least for your home directory (or directories)
and put all data there, then when an upgrade comes along you always
have the option of a full reinstall without touching your data.

If you find too overwhelming all this discussion I suggest you install
from scratch using the latest version of Ubuntu. With time you may
find that following the workarounds provided is achievable, for the
time being you may be better off just putting a DVD and reinstalling
to have a clean start.

Regards and good luck.

On Tue, Aug 12, 2008 at 1:24 AM, Big Dave <email address hidden> wrote:
> Well, as a linux newb, im just confused. Ive only used windows, up until a few months ago.
> I've only recently had the time/patience to try and upgrade to v8.04. Needless to say, it froze on "generating locales". As this is my only pc, and the filesystem was corrupt, i could do nothing except format and re-install 7.03 from disc, then upgrade to 7.10. In total i spent 12 hours achieving absolutely nothing, except losing all my media files.
> I do want to stick with ubuntu, but im disheartened with it now.
>
> Please help a lil newb like me, before i jump off the bridge, and back
> onto windows.
>
> Does that workround permenantly solve the problem of, and install,
> v8.04?
>
> Also, could i just boot kernel 14 and upgrade with the update manager?
>
> --
> Gutsy->Hardy upgrade hangs in localedef
> https://bugs.launchpad.net/bugs/249340
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in "langpack-locales" source package in Ubuntu: New
> Status in "linux" source package in Ubuntu: Incomplete
> Status in "linux-source-2.6.22" source package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: locales
>
> I've been running Feisty for a while and decided to upgrade to Hardy. I used the Update Manager to upgrade from Feisty to Gutsy without problems last night. Tonight I decided to take the next step from Gutsy to Hardy. I again used the Update Manager GUI. But this time things didn't go so well.
>
> During the step "Setting up locales (2.7.9-4) ..." I get the following message:
>
> Generating locales...
> en_AU.UTF-8...
>
> And then the installer hangs forever with localedef eating 100% CPU.
>
> I'm not the only one. Here are the relevant threads on the forums:
>
> http://ubuntuforums.org/showthread.php?t=861384
>
> http://ubuntuforums.org/showthread.php?t=861194
>
> Interestingly enough, both threads were started *tonight* and there are no relevant earlier threads matching "localedef", which makes me suspect this was due to a very recent change.
>
> As a workaround, "sudo killall locale-gen" allows the installation to continue, though several packages fail to install due to dependency errors.
>
> I also submitted an automated bug report after the failed upgrade (bug 249346).
>
>

Since Big Dave has already reinstalled, this is small consolation.

First thing to know is that the entire file system was likely not corrupted.
Second thing to know is that if you boot with a live CD, you can likely
look at it, and almost certainly repair it.
Third thing to know is that it's worth trying to search the net for a
solution, even if you have to go to the local library to do it because
your one and only PC is temporarily down.

If you happen to have a dual boot Windows/Linux system and GRUB is
corrupted so that you don't think you can't get into Windows, there are
ways around that too.

If you're interested in learning more about Linux, there are lots of
resources on the net, including the IBM developerWorks tutorials for LPI
certification (http://www.ibm.com/developerworks/linux/lpi/) which cover
a lot of useful system administration material and a recent article
"Lazy Linux: 10 essential tricks for admins"
(http://www.ibm.com/developerworks/linux/library/l-10sysadtips/). These
aren't the only resources (by far), I just happen to work for dW and
wrote some of the LPI tutorials.

Ian Shields
jlms wrote:
> There was no reason for you to lose any data.
>
> You should have backups (irrespective of the OS you use) because
> something can always go wrong.
>
> Something you must consider is to have a separate partition for your
> data, or at the very least for your home directory (or directories)
> and put all data there, then when an upgrade comes along you always
> have the option of a full reinstall without touching your data.
>
> If you find too overwhelming all this discussion I suggest you install
> from scratch using the latest version of Ubuntu. With time you may
> find that following the workarounds provided is achievable, for the
> time being you may be better off just putting a DVD and reinstalling
> to have a clean start.
>
> Regards and good luck.
>
>

Well, I have the same problem. Can't use the GUI (as some suggests), the target is running headless and no X is installed.

I tried to clear the locales and reboot - now the server isn't event answering a ping.

I vote to make mark this bug critical, since it is likely that thousands
of people will experience it while upgrading from 7.10 -> 8.04.

importance critical

@ Big Dave :

Now that you are in 7.10, and want to upgrade to 8.04, just do the following:
1) Reboot and choose -14 kernel, not -15
2) Go to update manager, and choose upgrade
3) Answer all questions

Done! Not hangs, not crash, no problems!!!

I was lucky enough to upgrade after reading about this bug. The bug occurred to me while adding a language with the -15 kernel.

So, upgrading from the -14 kernel, goes flawlessly! (Hint: workaround)

@ Ishields + Alecz20:
Thank you both very much for your helpful and informative replies.
I shall run the upgrade from kernel -14, i'll let you know what happens.
Fingers crossed.

I updated 4 machines yesterday and had no issues at all by using
kernel 14.

Let us know how it goes....

Worked for me too! Only, now I have to select kernel 14 when I reset the
computer. Anyone know how to set the kernel as default?? Thanks!

On Tue, Aug 12, 2008 at 4:01 PM, Robby Minick <email address hidden>wrote:

> I updated 4 machines yesterday and had no issues at all by using
> kernel 14.
>
> Let us know how it goes....
>
> --
> Gutsy->Hardy upgrade hangs in localedef
> https://bugs.launchpad.net/bugs/249340
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in "langpack-locales" source package in Ubuntu: New
> Status in "linux" source package in Ubuntu: Incomplete
> Status in "linux-source-2.6.22" source package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: locales
>
> I've been running Feisty for a while and decided to upgrade to Hardy. I
> used the Update Manager to upgrade from Feisty to Gutsy without problems
> last night. Tonight I decided to take the next step from Gutsy to Hardy. I
> again used the Update Manager GUI. But this time things didn't go so well.
>
> During the step "Setting up locales (2.7.9-4) ..." I get the following
> message:
>
> Generating locales...
> en_AU.UTF-8...
>
> And then the installer hangs forever with localedef eating 100% CPU.
>
> I'm not the only one. Here are the relevant threads on the forums:
>
> http://ubuntuforums.org/showthread.php?t=861384
>
> http://ubuntuforums.org/showthread.php?t=861194
>
> Interestingly enough, both threads were started *tonight* and there are no
> relevant earlier threads matching "localedef", which makes me suspect this
> was due to a very recent change.
>
> As a workaround, "sudo killall locale-gen" allows the installation to
> continue, though several packages fail to install due to dependency errors.
>
> I also submitted an automated bug report after the failed upgrade (bug
> 249346).
>
>

@joe: Why? Once the upgrade is finished, you can use the latest kernel again. But if you insist on the -14 kernel to be used, check your /boot/grub/menu.lst - with the keyword "default n" (where "n" is a number) you can define which option should be automatically used (if user doesn't decide otherwise manually). Usually this is set to "0" to always boot the latest kernel by default. Count your kernel entries (check for the "title" keyword) starting by "0", and put the appropriate number to the "default" keyword. Not sure what happens if a new kernel is added ;)

After I got blocked, I was able to get around this bug by going to a tty
command prompt (ctrl-alt-fn) and running
sudo dpkg -r -a
then running
dpkg --configure -a
The configure step appeared to pick up at the failing local installation
and the rest of the upgrade continued.

You could try that too.

Ian.

Big Dave wrote:
> @ Ishields + Alecz20:
> Thank you both very much for your helpful and informative replies.
> I shall run the upgrade from kernel -14, i'll let you know what happens.
> Fingers crossed.
>
>

I'm in a rather hozed state, after deciding to start upgrading a -server installation from Feisty -> Gutsy -> Hardy due to Feisty going EOL in a couple months...

The Gutsy upgrade went fine, I got hung up with locales. I don't have a 2.6.22-14 kernel to fall back to, only 2.6.20-16. My dpkg-reconfigures throw these:

perl: warning: Setting locale failed.

perl: warning: Please check that your locale settings:

        LANGUAGE = (unset),

        LC_ALL = (unset),

        LANG = "en_US.UTF-8"

which cause errors finishing up the 2.6.24-19 install:

dpkg: error processing linux-image-2.6.24-19-server (--configure):

 subprocess post-installation script returned error exit status 1

dpkg: dependency problems prevent configuration of linux-ubuntu-modules-2.6.24-19-server:

[...]
# locale

locale: Cannot set LC_CTYPE to default locale: No such file or directory

locale: Cannot set LC_ALL to default locale: No such file or directory

LANG=en_US.UTF-8

LC_CTYPE="en_US.UTF-8"
[...]

No combination of dpkg-reconfigures after mkdir'ing /var/run/dbus, chmod'ing /usr/bin/localedef, rm'ing /var/lib/locales/supported.d/local, or other workarounds others have recommended is helping me here... Any advice? There are a bunch of servers that will need to be upgraded.

Just in case you didn't try... can you update the Gutsy servers? Maybe that way you will have access to 2.6.22-14 kernel and run the upgrade to Hardy from there.

After I got blocked, I was able to get around this bug by going to a tty
command prompt (ctrl-alt-fn) and running
sudo dpkg -r -a
then running
dpkg --configure -a
The configure step appeared to pick up at the failing local installation
and the rest of the upgrade continued.

You could try that too. It's very low risk and from what I understand of the bug, likely to help.

Ian.

oedstero wrote:
> I'm in a rather hozed state, after deciding to start upgrading a -server
> installation from Feisty -> Gutsy -> Hardy due to Feisty going EOL in a
> couple months...
>
> Th

I have created a patch to go into the next kernel update. I have uploaded a -generic kernel (i386 currently, amd64 will follow) to http://people.ubuntu.com/~smb/bug249340 which can be used as a replacement until the official upload is there.

Alecz20: that worked like a charm, great advice. I was able to install 2.6.22-14, force removal of 2.6.24-19 (had to touch and mkdir some /boot & modules directories along the way), boot into 2.6.22-14 and reinstall 2.6.24-19.

For the 2nd feisty upgrade, I just installed 2.6.22-14 after do-release-upgrade, booted into that, then went to Hardy w/o a hitch.

Well, having tried all the various options given here and elsewhere, I've finally managed to get back into 2.6.22-14. Now the only remaining question is - how do I get rid of the broken 2.6.24-19 and reinstall? (as it still won't boot into it - I just get the [initramfs] error...

Did you try:

sudo aptitude upgrade

sudo apt-get dist upgrade

then :

sudo dpkg --configure -a

"1" or "2" might not be necessary, but should not cause any harm.

Hi Guys,

Just adding a note that I've added the Gutsy and Dapper SRU nominations for linux-source-2.6.15 and linux-source-2.6.22. Thanks.

Commited fix as 3e6751ac6696b26d94a005be2f5854b9620e44b4
UBUNTU: mm: Fix zero length segment loop
to gutsy tree.

Fix commited as 88649b1a7909fe67af95a5374ddb94d06088d4b5
UBUNTU: mm: Fix zero length segment loop
to dapper tree.

Hmmm.... OK. Have managed to get 2.6.24-14 working again (except it's showing as Hardy) have uninstalled 2.6.24-19 (as far as I am able to determine (everything is showing as uninstalled in Synaptic) but now, when I try to upgrade to 2.6.24-19 again, it tells me there is no upgrade available.

I seem to be going round in circles here. On the one hand, I would appear to have removed all references to the Hardy kernel - yet it still thinks it is the hardy kernel!?! HTF do I get this back up to a proper -19 kernel that boots?

Well, i came from Bug #202959 to this one since it's the upgrade problem and not a memory problem.

I did terminate the stalled processes multiple times from other shells, reconfigured and rebooted.

I might add, that the localedef works again after the reboot and new run's of apt-get update and upgrade..

I see my system is more unstable than before the upgrade from gutsy, but i can at least work with the current 2.6.24-19 kernel. :)

I would like to add that I had this problem with a simple apt-get upgrade. That has nothing to do with hardy dist-upgrade.

A newer version of language-pack-en or language-pack-en-base (I don't remember which) invokes a postinst command /usr/share/locales/install-language-pack, which invokes /usr/sbin/locale-gen, which invokes localedef, which hangs. I had to boot the -14 kernel, do the upgrade, and then I could go back to -15.

Why does the Ubuntu installer (upgrade manager) not check the kernel version (and blacklist 2.6.22-15)? Why the kernel 2.6.22-16 is not released yet? Hardy Heron was released in April, the bug was reported in July, and we are in August!

About the bug: with Linux 2.6.22-15, localedef hangs. With Linux 2.6.22-14 it's running fine (localedef finishs its job).

Thanks Izzy. Your work-around solved this problem for me.

Glad to read this - you are very welcome!

if we "just" reboot on 2.6.22-14 it works.... I don't understand what devs had made with 2.6.22-15, but that really.... -.-

Apparently a patch is on the works, so the developers have acknowledged the bug and are working on getting it fixed.

"Boot with -14" is not a good solution for me, because the installer FORCED ME to delete -14 and leave only -15 since for some reason installing Gutsy requires 62.5MiB free on boot (which I have as a separate partition with only 80MiB).

Hopefully all my killall of all the locale related things did the trick and I will be able to reboot my system...

But gosh, how did such a HUGE bug find it's way into 7.10 and stay open for so long? There should at least be an error message blocking proceeding when trying to update a -15 kernel 7.10 to 8.04 update.

And why does the new kernel stuff suddenly need 62,5MiB of free space on boot? That is an insane increase (7.10 -15 kernel takes 15-20 MiB).

I've seen this on several Gutsies, so this bug definately affects Gutsy and is confirmed.

Sorry, I know this is a bit confusing but the invalid for Gutsy was unter the heading od 2.6.15 (which is Dapper). It is commited for 2.6.22 (which is Gutsy).

None of the possible fixes mentioned above seem to work for me. (See Open Question #42920) Like Stefan, I don't have any -14 kernel to boot from, and all the unresolved dependencies keep me from installing anything else, and I can't resolve the dependencies because a package seems to be missing....Catch-22! Ack!

@John

You can "dpkg -i" the .deb from http://people.ubuntu.com/~smb/bug249340/

No joy for me:
root@gamabunta:~# wget
http://people.ubuntu.com/~smb/bug249340/linux-image-2.6.22-15-generic_2.6.22-15.57smb1_i386.deb
--17:31:01--
http://people.ubuntu.com/~smb/bug249340/linux-image-2.6.22-15-generic_2.6.22-15.57smb1_i386.deb
           =>
`linux-image-2.6.22-15-generic_2.6.22-15.57smb1_i386.deb'
Resolving
people.ubuntu.com... 91.189.90.132
Connecting to
people.ubuntu.com|91.189.90.132|:80... connected.
HTTP request sent,
awaiting response... 200 OK
Length: 18,597,738 (18M)
[application/x-debian-package]

100%[======================================================================================>]
18,597,738   144.78K/s    ETA 00:00

17:34:21 (90.69 KB/s) -
`linux-image-2.6.22-15-generic_2.6.22-15.57smb1_i386.deb' saved
[18597738/18597738]

root@gamabunta:~# dpkg -i
linux-image-2.6.22-15-generic_2.6.22-15.57smb1_i386.deb
Selecting
previously deselected package linux-image-2.6.22-15-generic.
(Reading
database ... 42041 files and directories currently installed.)
Unpacking linux-image-2.6.22-15-generic (from
linux-image-2.6.22-15-generic_2.6.22-15.57smb1_i386.deb) ...
Done.
dpkg: dependency problems prevent configuration of
linux-image-2.6.22-15-generic:
 linux-image-2.6.22-15-generic depends
on dpkg (>= 1.10.24); however:
  Package dpkg is not configured
yet.
 linux-image-2.6.22-15-generic depends on initramfs-tools (>=
0.36ubuntu6); however:
  Package initramfs-tools is not configured
yet.
 linux-image-2.6.22-15-generic depends on coreutils | fileutils
(>= 4.0); however:
  Package coreutils is not configured yet.
  Package fileutils is not installed.
 linux-image-2.6.22-15-generic depends on module-init-tools (>=
3.2.1-0ubuntu1); however:
  Package module-init-tools is not
configured yet.
dpkg: error processing linux-image-2.6.22-15-generic
(--install):
 dependency problems - leaving unconfigured
Errors
were encountered while processing:
 linux-image-2.6.22-15-generic

> @John
>
> You can "dpkg -i"
the .deb from http://people.ubuntu.com/~smb/bug249340/
>
> --
> Gutsy->Hardy upgrade hangs in localedef
>
https://bugs.launchpad.net/bugs/249340
> You received this bug
notification because you are a direct subscriber
> of the bug.
>
> Status in “langpack-locales” source package in
Ubuntu: Invalid
> Status in “linux” source package in Ubuntu:
Invalid
> Status in “linux-source-2.6.15” source package in
Ubuntu: Fix
> Committed
> Status in
“linux-source-2.6.22” source package in Ubuntu: Fix
>
Committed
> Status in langpack-locales in Ubuntu Dapper:
Invalid
> Status in linux in Ubuntu Dapper: Invalid
>
Status in linux-source-2.6.15 in Ubuntu Dapper: Fix Committed
>
Status in linux-source-2.6.22 in Ubuntu Dapper: Invalid
> Status
in langpack-locales in Ubuntu Gutsy: Invalid
> Status in linux in
Ubuntu Gutsy: Invalid
> Status in linux-source-2.6.15 in Ubuntu
Gutsy: Invalid
> Status in linux-source-2.6.22 in Ubuntu Gutsy:
Fix Committed
>
> Bug description:
> Binary
package hint: locales
>
> I've been running Feisty for a
while and decided to upgrade to Hardy. I
> used the Update
Manager to upgrade from Feisty to Gutsy without problems
> last
night. Tonight I decided to take the next step from Gutsy to Hardy.
...

This bug was fixed in the package linux-source-2.6.15 - 2.6.15-52.71

---------------
linux-source-2.6.15 (2.6.15-52.71) dapper-security; urgency=low

  * mm: Fix zero length segment loop
    - LP: #249340
    follow-up for CVE-2008-0598

  [Upstream Kernel Changes]

  * Fix compiler warning on 64-bit
    follow-up for CVE-2008-1673

linux-source-2.6.15 (2.6.15-52.70) dapper-security; urgency=low

  * (CVE-2008-3275) vfs: fix lookup on deleted directory
  * (CVE-2008-3272) sound: ensure device number is valid in snd_seq_oss_synth_make_info
  * (CVE-2008-2931) check privileges before setting mount propagation
  * (CVE-2008-2812) TTY: fix for tty operations bugs
  * USB: remove short initial timeout for device descriptor fetch
    - LP: #185025

 -- Stefan Bader <email address hidden> Thu, 14 Aug 2008 10:27:05 -0400

This bug was fixed in the package linux-source-2.6.22 - 2.6.22-15.58

---------------
linux-source-2.6.22 (2.6.22-15.58) gutsy-security; urgency=low

  [Stefan Bader]

  * mm: Fix zero length segment loop
    - LP: #249340
    follow-up for CVE-2008-0598

  [Upstream Kernel Changes]

  * Fix compiler warning on 64-bit
    follow-up for CVE-2008-1673
  * netfilter: nf_nat_snmp_basic: fix a range check in NAT for SNMP
    follow-up for CVE-2008-1673

linux-source-2.6.22 (2.6.22-15.57) gutsy-security; urgency=low

  [Upstream Kernel Changes]

  * (CVE-2008-2812) TTY: fix for tty operations bugs
  * (CVE-2008-3272) sound: ensure device number is valid in
    snd_seq_oss_synth_make_info
  * (CVE-2008-3275) vfs: fix lookup on deleted directory

 -- Stefan Bader <email address hidden> Thu, 14 Aug 2008 10:11:31 -0400

On 08/25/2008 11:18 AM, Launchpad Bug Tracker wrote:
> This bug was fixed in the package linux-source-2.6.22 - 2.6.22-15.58

I can confirm that the fix worked for me. I just updated my last Gutsy
machine with the -15 kernel and all went smooth.

Worked for me on 2 different systems. 2.6.22-15 to 2.6.22.19 worked fine. No problems at all.
One final note, I tried this same upgrade from 2.6.22-14 last week and it failed.

The statement above should read 2.6.24.19.

Also, I was in the midst of transferring to a bigger hard drive, so I'm sure it was at 2.6.22-14 before I updated to 2.6.24-19. Tried it before and after this bug was closed.

Before: Copied entire hard drive, booted and attempted to upgrade from 7.10 (2.6.22-14) to Hardy with the Update Manager. It hangs on localedef

After: Upgrade of latest kernel (8/28/2008) and repeated the transfer. No problems at all.

Same problem, with mac mini hardware, up-to-date Hardy Heron, 2.6.24-19-generic kernel, and locales_2.7.9-4_all :

Generating locales...
  en_AU.UTF-8...

And then freezes.
This happens during almost every software upgrade (using update manager).

If you upgrade the kernel components to 2.6.24-21 from -proposed, does this help?

Please let me know what can I try to do to resolve my update process.
Thanks.
Enrico

2008/9/5 Stefan Bader <email address hidden>

> If you upgrade the kernel components to 2.6.24-21 from -proposed, does
> this help?
>
> --
> Gutsy->Hardy upgrade hangs in localedef
> https://bugs.launchpad.net/bugs/249340
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in "langpack-locales" source package in Ubuntu: Invalid
> Status in "linux" source package in Ubuntu: Invalid
> Status in "linux-source-2.6.15" source package in Ubuntu: Fix Released
> Status in "linux-source-2.6.22" source package in Ubuntu: Fix Released
> Status in langpack-locales in Ubuntu Dapper: Invalid
> Status in linux in Ubuntu Dapper: Invalid
> Status in linux-source-2.6.15 in Ubuntu Dapper: Fix Released
> Status in linux-source-2.6.22 in Ubuntu Dapper: Invalid
> Status in langpack-locales in Ubuntu Gutsy: Invalid
> Status in linux in Ubuntu Gutsy: Invalid
> Status in linux-source-2.6.15 in Ubuntu Gutsy: Invalid
> Status in linux-source-2.6.22 in Ubuntu Gutsy: Fix Released
>
> Bug description:
> Binary package hint: locales
>
> I've been running Feisty for a while and decided to upgrade to Hardy. I
> used the Update Manager to upgrade from Feisty to Gutsy without problems
> last night. Tonight I decided to take the next step from Gutsy to Hardy. I
> again used the Update Manager GUI. But this time things didn't go so well.
>
> During the step "Setting up locales (2.7.9-4) ..." I get the following
> message:
>
> Generating locales...
> en_AU.UTF-8...
>
> And then the installer hangs forever with localedef eating 100% CPU.
>
> I'm not the only one. Here are the relevant threads on the forums:
>
> http://ubuntuforums.org/showthread.php?t=861384
>
> http://ubuntuforums.org/showthread.php?t=861194
>
> Interestingly enough, both threads were started *tonight* and there are no
> relevant earlier threads matching "localedef", which makes me suspect this
> was due to a very recent change.
>
> As a workaround, "sudo killall locale-gen" allows the installation to
> continue, though several packages fail to install due to dependency errors.
>
> I also submitted an automated bug report after the failed upgrade (bug
> 249346).
>
>

--
Enrico Stronati

Still experiencing this problem during a debootstrap.

FWIW, I tried to upgrade from fully-patched 7.10 to 8.04.1 6 weeks ago and ran into this.

I tried a few of the fixes but nothing worked, so I restored the backup image to undo all changes.

I tried again this week and it worked perfectly.

Thank you. Due to (possibly unrelated) problems, I had to revert anyway. I'm now back in Gutsy for the foreseeable future.

Michael

--- On Sat, 9/27/08, Thomas <email address hidden> wrote:

> From: Thomas <email address hidden>
> Subject: [Bug 249340] Re: Gutsy->Hardy upgrade hangs in localedef
> To: <email address hidden>
> Date: Saturday, September 27, 2008, 8:25 AM
> FWIW, I tried to upgrade from fully-patched 7.10 to 8.04.1 6
> weeks ago
> and ran into this.
>
> I tried a few of the fixes but nothing worked, so I
> restored the backup
> image to undo all changes.
>
> I tried again this week and it worked perfectly.
>
> --
> Gutsy->Hardy upgrade hangs in localedef
> https://bugs.launchpad.net/bugs/249340
> You received this bug notification because you are a direct
> subscriber
> of the bug.
>
> Status in “langpack-locales” source package in Ubuntu:
> Invalid
> Status in “linux” source package in Ubuntu: Invalid
> Status in “linux-source-2.6.15” source package in
> Ubuntu: Fix Released
> Status in “linux-source-2.6.22” source package in
> Ubuntu: Fix Released
> Status in langpack-locales in Ubuntu Dapper: Invalid
> Status in linux in Ubuntu Dapper: Invalid
> Status in linux-source-2.6.15 in Ubuntu Dapper: Fix
> Released
> Status in linux-source-2.6.22 in Ubuntu Dapper: Invalid
> Status in langpack-locales in Ubuntu Gutsy: Invalid
> Status in linux in Ubuntu Gutsy: Invalid
> Status in linux-source-2.6.15 in Ubuntu Gutsy: Invalid
> Status in linux-source-2.6.22 in Ubuntu Gutsy: Fix Released
>
> Bug description:
> Binary package hint: locales
>
> I've been running Feisty for a while and decided to
> upgrade to Hardy. I used the Update Manager to upgrade from
> Feisty to Gutsy without problems last night. Tonight I
> decided to take the next step from Gutsy to Hardy. I again
> used the Update Manager GUI. But this time things
> didn't go so well.
>
> During the step "Setting up locales (2.7.9-4)
> ..." I get the following message:
>
> Generating locales...
> en_AU.UTF-8...
>
> And then the installer hangs forever with localedef eating
> 100% CPU.
>
> I'm not the only one. Here are the relevant threads on
> the forums:
>
> http://ubuntuforums.org/showthread.php?t=861384
>
> http://ubuntuforums.org/showthread.php?t=861194
>
> Interestingly enough, both threads were started *tonight*
> and there are no relevant earlier threads matching
> "localedef", which makes me suspect this was due
> to a very recent change.
>
> As a workaround, "sudo killall locale-gen" allows
> the installation to continue, though several packages fail
> to install due to dependency errors.
>
> I also submitted an automated bug report after the failed
> upgrade (bug 249346).

This is really Fixed: On last Saturday (29. Sep) i upgraded successfully a Gutsy System to Hardy. I have enabled _all_ Upgrades, including proposed & backports.

Betz Stefan

Heise linked to this Bug. At least the issue seems to be resolved. I will test it in some days.

Verified the fix using 2.6.22-15.58 (generic/AMD64).

fyi, shouldn't the recommendation on to boot into 2.6.22-14 be updated/removed?

Cheers,
Brad

I'm using Gutsy 2.6.22-16-rt. Is this going to be a problem upgrading to Hardy through the Update Manager?

barry - why did you make this private?

I can't really regard this problem as having been fixed. I upgraded Ubuntu 7.10 to 8.04, and had this problem. Of course, I did still have the old (..15) kernel installed, due to not having upgraded (nor booted, for that matter) this machine for many months), but the update system never gave any warning -- it simply hung my system.

At the very least, a warning should be given that you need to upgrade your kernel /before/ attempting the full upgrade.

I'd like to regretfully add that this bug is very much present in all these releases: 7.04, 7.10, 8.04, 8.10.

Granted, it's not easily reproducible but it does affect a lot of users (regardless of one's linux know-how).

The problem almost certainly lies in one of the localedef subroutines and is not bound to the underlying kernel (I have tried both downgrading the belocs-locale-bin package in 8.04 and updating it on a 7.04 release to no avail). Since this is in the gnu c lib it is understandably not an ubuntu maintained code. Alas, with ubuntu being the most wide spread distro among desktop users (feel free to correct me on this), it receives the most user feedback.

Instead of pretty much rejecting the idea of trying to figure out where the code fails (for which I have to agree with you, if it's not reproducible there's no point to go out on a wild goose chase), I 'd like to offer an alternative.

Localedef appears to check sth (most likely the contents of the folder /usr/lib/locale) and if it needs to install a new locale/variation combo it returns "done" if everything was executed properly or if nothing needs to be updated it returns "up-to-date" for each locale/variation already installed. In my case I almost always either get a segmentation fault or worse, the machine reboots.

The proposal is simply this and on the condition that the files being installed are 100% generic and independent of any user/setup options (a condition I believe pretty much applies). Offer the contents of the /usr/lib/locale folder for the most popular (if not all) locales as a download (for each locale separately). In this fashion, if one was to copy these files to /usr/lib/locale and install/update a locale, localedef would consider the specific locale/variation to be up-to-date and proceed without causing any errors. And no, I haven't tried it but I'm pretty certain this workaround will work.

At the very least please take this proposal into serious consideration. Being a proponent of free (but user-friendly) software I find myself questioning my decision to use open source code be that a java library or an OS. Too many times have I found myself trying to solve a non-trivial issue (and sometimes finding it impossible to come up with a decent workaround) , wasting a lot of time I could have devoted to more serious matters. This is an easy workaround for those few(?) of us unlucky to have been entangled. Plz help.

Expanding/ correcting my previous post, I 'd like to note that the mentioned affected releases are all 64 bit. After installing a 32 bit hardy locales are being installed/updated/removed without issues. Perhaps this a general hardware incompatibility when fully utilizing the 64 bit architecture?

No mfg8876, the Problem exists on 32-Bit Ubuntu to. I have migrated serveral Systems from Gutsy to Hardy, an the Bug is in all off them. It doesn't Matter if 32 oder 64-Bit.

mfg Betz Stefan

please close my inquiry no longer have problem.

----- Original Message -----
From: encbladexp
Date: Sunday, January 11, 2009 1:05 pm
Subject: [Bug 249340] Re: Gutsy->Hardy upgrade hangs in localedef
To: <email address hidden>

> No mfg8876, the Problem exists on 32-Bit Ubuntu to. I have migrated
> serveral Systems from Gutsy to Hardy, an the Bug is in all off
> them. It
> doesn't Matter if 32 oder 64-Bit.
>
> mfg Betz Stefan
>
> --
> Gutsy->Hardy upgrade hangs in localedef
> https://bugs.launchpad.net/bugs/249340
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Thu, 8 Jan 2009, mfg8876 <email address hidden> wrote:
> The problem almost certainly lies in one of the localedef subroutines and
> is not bound to the underlying kernel (I have tried both downgrading the
> belocs-locale-bin package in 8.04 and updating it on a 7.04 release to no
> avail). Since this is in the gnu c lib it is understandably not an ubuntu
> maintained code. Alas, with ubuntu being the most wide spread distro among
> desktop users (feel free to correct me on this), it receives the most user
> feedback.

Actually I *HAVE* done a trace to find the location of the problem, and I
can assure you it *IS* in the Kernel. I have 50 MB of strace to prove it.

On Sun, 11 Jan 2009 encbladexp <email address hidden> wrote:
> the Problem exists on 32-Bit Ubuntu to. I have migrated serveral Systems
> from Gutsy to Hardy, an the Bug is in all off them. It doesn't Matter if
> 32 or 64-Bit.

Indeed, the problem is with the generic part of the kernel, between certain
releases. However But localedef is run before rebooting, and so the problem
is with the OLD kernel -- the one you're migrating from, not the one you're
installing.

The resolution is to arrange to upgrade the kernel and reboot before trying
to run localedef. This could be done by either:

(1) requiring a kernel patch update as a prerequisite to doing a
    dist-upgrade; or

(2) deferring localedef until after a reboot if the currently running
    kernel is in the affected range.

I'm not a packaging expert so I don't know which of these is more feasible,
however I suspect the latter may be easier to accomplish as it wouldn't need
back-patching of the dependency lists of older releases.

-Martin

PS: this bug may also be related to https://bugs.launchpad.net/bugs/231746

I confirm also. I have upgraded 2 32bit systems, and I got the error on both! And one is a 32bit for sure, as the processor does not have any 64bit instructions, it is an old AMD Duron 900MHz!!

It finally worked1 Thank you Rocco! I already thought that i should reinstall the system, but it worked :)

I need to upgrade my Ubuntu server from 7.10 to 8.04 LTS. Since I have kernel version 2.6.22-16-server installed, do I still have to worry about this bug, or it has been already corrected on that new version?

Thanks.

----- Original Message -----
From: ToniVC
Date: Tuesday, March 24, 2009 7:30 am
Subject: [Bug 249340] Re: Gutsy->Hardy upgrade hangs in localedef
To: <email address hidden>

> I need to upgrade my Ubuntu server from 7.10 to 8.04 LTS. Since
> I have
> kernel version 2.6.22-16-server installed, do I still have to worry
> about this bug, or it has been already corrected on that new version?
>
> Thanks.
>
> --
> Gutsy->Hardy upgrade hangs in localedef
> https://bugs.launchpad.net/bugs/249340
> You received this bug notification because you are a direct subscriber
> of the bug.
> no longer using ubuntu.

hi,
cannot really tell. in my case, upgrading from 7.10 to 8.04 did not show any
major issue.
i can provide you with the detailed settings if required.

On Tue, Mar 24, 2009 at 1:10 PM, joe nowicki <email address hidden>wrote:

>
> ----- Original Message -----
> From: ToniVC
> Date: Tuesday, March 24, 2009 7:30 am
> Subject: [Bug 249340] Re: Gutsy->Hardy upgrade hangs in localedef
> To: <email address hidden>
>
> > I need to upgrade my Ubuntu server from 7.10 to 8.04 LTS. Since
> > I have
> > kernel version 2.6.22-16-server installed, do I still have to worry
> > about this bug, or it has been already corrected on that new version?
> >
> > Thanks.
> >
> > --
> > Gutsy->Hardy upgrade hangs in localedef
> > https://bugs.launchpad.net/bugs/249340
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> > no longer using ubuntu.
>
> --
> Gutsy->Hardy upgrade hangs in localedef
> https://bugs.launchpad.net/bugs/249340
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “langpack-locales” source package in Ubuntu: Invalid
> Status in “linux” source package in Ubuntu: Invalid
> Status in “linux-source-2.6.15” source package in Ubuntu: Fix Released
> Status in “linux-source-2.6.22” source package in Ubuntu: Fix Released
> Status in langpack-locales in Ubuntu Dapper: Invalid
> Status in linux in Ubuntu Dapper: Invalid
> Status in linux-source-2.6.15 in Ubuntu Dapper: Fix Released
> Status in linux-source-2.6.22 in Ubuntu Dapper: Invalid
> Status in langpack-locales in Ubuntu Gutsy: Invalid
> Status in linux in Ubuntu Gutsy: Invalid
> Status in linux-source-2.6.15 in Ubuntu Gutsy: Invalid
> Status in linux-source-2.6.22 in Ubuntu Gutsy: Fix Released
>
> Bug description:
> Binary package hint: locales
>
> I've been running Feisty for a while and decided to upgrade to Hardy. I
> used the Update Manager to upgrade from Feisty to Gutsy without problems
> last night. Tonight I decided to take the next step from Gutsy to Hardy. I
> again used the Update Manager GUI. But this time things didn't go so well.
>
> During the step "Setting up locales (2.7.9-4) ..." I get the following
> message:
>
> Generating locales...
> en_AU.UTF-8...
>
> And then the installer hangs forever with localedef eating 100% CPU.
>
> I'm not the only one. Here are the relevant threads on the forums:
>
> http://ubuntuforums.org/showthread.php?t=861384
>
> http://ubuntuforums.org/showthread.php?t=861194
>
> Interestingly enough, both threads were started *tonight* and there are no
> relevant earlier threads matching "localedef", which makes me suspect this
> was due to a very recent change.
>
> As a workaround, "sudo killall locale-gen" allows the installation to
> continue, though several packages fail to install due to dependency errors.
>
> I also submitted an automated bug report after the failed upgrade (bug
> 249346).
>
>

I am upgrading from 7.10 to 8.04 LTS with 2.6.22-16-server.

Using the upgrade manager the upgrade has been completed without a problem.

I finally did the upgrade without reverting to kernel 2.6.22-14, and had no problem at all. Thanks to everybody ;)