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

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 ;)