[hardy] generating locales stalls on 64mb ram

This is the syslog, this time from a laptop with 64mb ram. The laptop ran fine on Gutsy.

This is the list of processes. After that I killed localedef, it was launched again with en_UK and again with en_US. After that the installation continued quite a bit until "setting up language-pack-en".
By the way, i partitioned using "guided partitioning" but there's no swap in /etc/fstab yet.

Preseeding the language question shouldn't make a difference. Could you attach /var/log/partman from the installer? The problem is likely that there's no swap.

I doubt this is a localechooser bug as such - rejecting that task.

There you go.

I'm very interested in the original poster's script to install a low memory IceWM system that works in 64MB, as it would help me put Ubuntu onto an old ThinkPad that has just 96MB of RAM. There are many other people trying to fit Ubuntu into low-RAM environments, and since Ubuntu has such a great repository of lightweight apps, it's not that hard to do lightweight Ubuntu variants (others include Fluxbuntu, UbuntuLite, IceBuntu, OpenGEU [E17], etc).

i tried to install the Xubuntu-alternate iso on a Celeron 600 with 64MB RAM and 10GB disk.
it took about 2h storing language-en-base and then later on in the install at least 16h (overnight and then i was away at work) configuring language files. it was at 67% installing when i got home from work and i didnt want to wait another night so i stopped it.
i wonder if (for low memory installs) there is any way to have the language stuff either pre-configured or deferred to idle time after the system is installed.

anyway, in #ubuntu+1 they are telling me that 384MB is minimum required for Hardy alternate install

I had test run with 8.04 final alternate ISO, same symptoms as before. Logfiles:

Comfirmed.
"75% Speichere Sprache..." takes about two hours.

A swap-partition is availible an according to free it is used.

Same issue here.

I do a dry-run in VirtualBox for a 64 MB install of Xubuntu 8.04.
I am discouraged to do the real install on my low memory machine.

There's 2 steps hanging:
* 75% Generating locales
- 24 min for step "localechooser: en_US.UTF-8"
* 1% Configuring language-pack-en-base
- 27 min for "in-target: en_AU.UTF-8"
- 27 min for "in-target: en_BW.UTF-8"
- 27 min for "in-target: en_CA.UTF-8"
- 27 min for "in-target: en_DK.UTF-8"
- 27 min for "in-target: en_GB.UTF-8"
.... and it continues ...

Is there any way to defer the locale generation for later install, or to pre-generate the locales with a faster system ?

i've tested a dirty solution for 64 MiB systems:

* select the "command line install" in english: F4 at the welcome screen
 --> it has less chances to hang during install
* do the install until it hangs at 75% because of generating locales
* switch to 4th VT with "Alt+F4" to check what it is doing
* switch to 2nd VT with "Alt+F2"
* Enter the command prompt in 2nd VT
* # chmod ugo-x /target/usr/bin/localedef
 --> so it fails silently on future attempts to generate other locales (more than 10 english locales).
* go back to the progress bar "Alt+F1"
* let the process finish the generation of "en_US" locale (it takes many minutes ... or hours)
* the process should not hang any more on locale generation
* after install and reboot, you are on the login prompt
* $ sudo chmod ugo+x /usr/bin/localedef
* $ sudo nano /var/lib/locales/supported.d/en (and add a leading "#" in front of the languages you do not want to generate)
* $ sudo dpkg-reconfigure locales (this time it is faster)
* $ sudo aptitude (or any other package manager)
* install (x)ubuntu-desktop or less packages, depending on what you really need
* install the "language-selector" package (or only the language you need, and use update-locale command)

it should work... but i would prefer an easier solution

Maybe it is possible to do the hack before the step "Installing the base system" reaches 75%:
* "/usr/bin/localedef" is part of package"belocs-locales-bin"
* this package is installed before the process reaches 40%

If you do the "chmod" when the step "Installing the base system" is between 40% and 75% it will prevent the generation of "en_US".
But I did not test, and I am not sure the system is bootable if the "en_US" locale is not generated.

Please report success or failure.

Even if you choose language English for faster install, be sure to select the appropriate keymap before install (press F3), so you can type your login/password rightly.

it'll probably work without any locale, and fallback to using builtin C locale. hopefully for system work this doesn't matter, but software may fail to do things right at some point, which should anyway be farther away than booting and re-running locale-gen.

indeed it has worked.

worth to be noted is that tehere's another bottleneck: each time apt-get kicks in there is a noticeable delay like this bug when building the dependency tree.

I trust Debian does not have this problem?
Any word on this, Colin Watson? Importance still undecided?

Whether Debian has this problem is probably more to do with which locales it generates by default than anything else.

I've set an Importance since you asked, but note that not having set an Importance doesn't mean the bug is being ignored! Many bugs get fixed without the Importance ever getting set at all ...

I've encountered a possibly related problem doing a distribution upgrade from Xubuntu 7.10 to Xubuntu 8.04 on an old Sony PCG-F280 laptop with some upgrades (PII-366, 128MB RAM). The last block in the terminal window of dist-upgrade is:

Setting up belocs-locales-bin (2.4.2.2ubu
Setting up locales (2.7.9-4) ...
Installing new version of config file /et
Generating locales...
  en_AU.UTF-8...

Sorry the terminal lines are incomplete; it does not seem possible to widen the dist-upgrade window to see the rest.

It has been stuck at this point for at least an hour that I've been watching it, but it has probably been stuck here between 6 and 8 hours total (the upgrade was running overnight).

Top shows that the localedef program is active, using between 75% and 80% of CPU. Swap is being used, but only about a third of it.

This machine was set up using the Xubuntu 7.10 alternate CD, and it did not experience any undue delays during either initial install or fetching of updates.

Same trouble here. Except I've got 1.5MHz with 700MB RAM. It's been running for about 2 hours. Seems to be doing something - I mean at least it is an active process. In top I've used "renice" to set it to a lower value (i.e. -4) and that it will use more of the CPU. Hoping that will at least speed it up.

Same trouble here, although I'm upgrading to 8.04 rather than installing from afresh. I've for 700MB RAM and 1Ghz or thereabouts on an old HP Compaq nx9010.

Its my girlfriend's computer and I've effectively broken it by clicking on upgrade distribution and now I'm going away for a month or so and she is left laptopless. :(

Very disappointing that I so often have problems upgrading ubuntu :(

Is there anyway I can just downgrade again? (I guessing not?)

I can confirm FactTech's issue too, this time with an upgrade from Ubuntu 7.10 to 8.04 with the alternative install cd and the latest package updates from the internet enabled.
My machine has 1GB Ram so it has nothing to do with memory imho. (AMD 64 -3000)
The machine is at this moment pretty much useless just like jdaviescoates' and I'm looking for a workaround.

I just read this thread:
http://ubuntuforums.org/showthread.php?t=865679

" Re: Hardy 8.04 update freezes on generating locales
Just had this problem myself. It seems to be to do with the latest Gutsy kernel version.

These steps worked for me:

   1. Reboot your box, and press ESC to enter the GRUB menu
   2. Select the previous version of the kernel xxx.14 rather than xxx.15 (sorry I can't recall the exact version numbers) - don't select the fail-safe mode.
   3. Log-in as your admin user into recovery mode
   4. Manually (re)start the upgrade via a terminal session: dpkg --configure -a

It should complete the install.

Good luck"

Seems to be working now :)

Hopefully this will help some of the people here too :)

I did pretty much the same thing as jdaviescoates mentioned above. I reset the computer, ran: sudo apt-get check, then it directed me to run: dpkg --configure -a. It all ran from the command line just fine. Note that X wouldn't work with my NVIDIA card until the whole install process was complete and I rebooted.

This is certainly a dealbreaker for anyone trying to impress Granny with the ease of a Linux upgrade ;-)

Best wishes,

Thank you for your tip! It worked (in stages). I'll post my
experiences on launchpad.

Have a nice day,
JSP

On 7/21/08, spatialguru <email address hidden> wrote:
> I did pretty much the same thing as jdaviescoates mentioned above. I
> reset the computer, ran: sudo apt-get check, then it directed me to run:
> dpkg --configure -a. It all ran from the command line just fine. Note
> that X wouldn't work with my NVIDIA card until the whole install process
> was complete and I rebooted.
>
> This is certainly a dealbreaker for anyone trying to impress Granny with
> the ease of a Linux upgrade ;-)
>
> Best wishes,
>
> --
> [hardy] generating locales stalls on 64mb ram
> https://bugs.launchpad.net/bugs/202959
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "debian-installer" source package in Ubuntu: Confirmed
> Status in "localechooser" source package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: base-installer
>
> I tried installing a German cmdline system in VMWare using hardy-alternate-i386.iso Alpha 6.
> All went well until "generating locales" ("Speichere Sprachen..." in German on screen), there was constant hard disk activity but the progress bar went no further than 75%.
> I tried numerous times.
> Then I tried with 128mb ram and it worked flawlessly.
>
> Has this to do with restructuring the language chooser? In Gutsy you had to choose language during install and it switched to "Low Memory Mode" when installing on 64mb ram. In Hardy you choose your language on the CD boot prompt and there's no more "Low Memory Mode".
>
> I will try to add a syslog to this bug report later.
> (I'm currently creating a low memory install script based on IceWM so I'd be quite dissappointed if Hardy drops 64mb support.)
>

The steps taken by jdaviescoates worked partially for me too.
I didn't think of choosing a different kernel. As I was upgrading from
7.10 I just used the default 2.6.22.15 kernel.

The only way to stop the machine from hanging while generating those
resource files was a CTRL-ALT-DEL and then a hard press on the
hardreset button (sounds like Windows 98 doesn't it ;-) )

Next I rebooted into 2.6.22.15 recovery mode from grub. I chose to be
dropped into a root shell. There I could launch:

dpkg --configure -a

and afterwards

reboot

That got me to the Gnome logon screen. A normal logon from there would
hang though because of X not being configured completely apparently.
So after another hard reset I succesfully logged into a Gnome Failsafe
session (change the session at the logon screen).

From there I had to

sudo dpkg --configure -a

in a terminal once again which generated those resource files in less
than a second. The rest of the pending packages (including X and the
latest 2.6.24 kernel) installed smoothly as well.

HTH,
JSP

PS: While in the root recovery shell I experimented with setting the
locales package on hold as such:

echo locales hold | dpkg --set-selections

and auditing the unfinished packages with

dpkg -C

but that turned out to be unnecessary.

This bug broke my installation totally, while upgrading it was stalled doing localdef, strace on the process did not give me any output but CPU usage was nearly 100%.

Stopped the upgrade and booted into single user mode where i ran
# dpkg --reconigure -a

as suggested and it did seem to work for most packages, but ended up missing a dependency, however i did not write down which dependency was missing b/c i decided to just reinstall Hardy.

I did a do-release-upgrade and it stalled at

Setting up locales (2.7.9-4) ...
Installing new version of config file /etc/belocs/iso-639.def
Generating locales...
  en_AU.UTF-8...

Just FYI. I got 2 GB of RAM - 52MB of which are used by localedef process. 1 of 2 CPU's is at 100%. It is stalled. I checked the command line:

localedef --no-archive --magic=20051014 -i en_au -c -f UTF-8 en_AU.UTF-8

What is the --magic Parameter doing?? I cant find it in the man page.. !

Another "me too" for this bug - I have 512Mb RAM and an English GB locale being created...

localedef --no-archive --magic=20051014 -i en_GB -c -f ISO-8859-1 en_GB

...this has been running overnight on a machine to which I don't currently have ready access! Oh the joys of a dist-upgrade :)

Is this a duplicate of bug #249340?

AFAIK it is not a duplicate:
- all comments until comment 19 (2008-06-30) are related to a "fresh" install on a low memory system.
- but comments posted after 2008-07-16 (FactTech) are related to a Gutsy-Hardy upgrade.
All the "me-too" reports related to an upgrade (after 2008-07-16) should be attached to bug #249340.

I just tried with the Xubuntu 10.04 alternate CD on a system with 64 MB RAM and encountered the same problem. I'm surprised this hasn't been fixed yet.

"me too"

New install of 10.04 mini.iso, screen blanks while loading packages prior to HD partitioning. Point at which this occurs varies directly with the amount of RAM available. The more RAM, the farther the progress bar reaches.

I would very much like to install on 64MB or less systems. I have no problems *running* ubuntu 10.04 minimal + openbox in less than 64MB (anywhere from 12MB to 40MB without any desktop apps running). It seems to me that the issue occurring is simply that the CLI installer loads a pile of optional packages into RAM before formatting the HD and doing the proper install, and that this pile has required more than 64MB since 8.04 at least. An advanced CLI installer which would allow the user to choose which packages to load would be one way to solve the issue, if my assumption is correct. Alternatively, only load the bare minimum required to partition the HD and then use that space to proceed, as an option.

My motives here are quite practical: there seems to be, for a certain type of user, some kind of correlation between lack of PC literacy, lack of purchasing power, and the age of the hardware they currently own. Rather than banging my head against the wall trying to help them run modern, secure systems that "just work" within the existing legacy OS (usually a very old version of Windows), it is much more cost effective to have them use a very light weight installation of Ubuntu with all the fluff removed but with the tools they do need just a simple mouse click away. Choosing Ubuntu over other light weight distros provides the immense number of packages to choose from and, more importantly, the widest range of localization options out of the box. Specifically, the Japanese Ubuntu team have done a great job including the attractive IPA fonts that are otherwise unavailable due to Japan having a proprietary approach to open/free licensing in many cases.

Still affects the alternate installer for Precise beta 1 on a machine with 128MB of RAM.

May be a dup of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=185010
which suggests doing
  echo 100 > /proc/sys/vm/swappiness
I tried that after half an hour, and after another five minutes, install got past that
step, so perhaps it helped.

Bug 377242 may be a dup of this one.