Testing alpha7 on 64MB IBM Aptiva

This machine has a 532MHz AMD K6 CPU and 64MB RAM. It hung at first boot, after displaying "Please wait..." prior to bringing up the dialog to choose locale.

I rebooted with "loglevel=7" to see what was going on, and was surprised that the kernel printed an "out of memory" message after 'hald' had loaded. The kernel killed hald, but booting was frozen at that point.

What actually causes the kernel to run out of memory (and also what takes quite a long time on CPUs with more RAM), is these two lines in the /usr/sbin/chooselocale script:

localedef -f ISO-8859-1 -i en_US --no-archive en_US
localedef -f UTF-8 -i en_US --no-archive en_US.utf8


Alpha7 (and alpha6) generates those two sets of locale files (see /usr/lib/locale) dynamically at first boot, regardless of what locale you choose to use from the choose-locale dialog.

Why am I not all that surprised about this crash? ...you can read about my experiences with the locale mechanism in earlier blog posts.

After X has loaded, there is 20MB RAM free. I exited X to the commandline and ran 'chooselocale' and the computer hung. It is the 'localedef' application itself that runs out of memory and hangs.

The IBM Aptiva does not have a swap partition or file, so everything has to happen in that 64MB. Interesting that even X can load, plus ROX-Filer -- albiet slowly as a lot of pages must be getting dumped to make space for needed ones. But, it is enough room, just, even for those large applications. I must put in a swap partition/file, but for now I would like a workaround for this situation so that it doesn't hang.

'localedef' is very disappointing. Obviously it has been written with the assumption that more RAM is available, which is quite surprising. I'm tempted to go into rant-mode, but won't.

I narrowed it down, the orinary 'en_US' locale gets generated okay, it is this that hangs the computer:

localedef -f UTF-8 -i en_US --no-archive en_US.utf8

My workaround is to generate only en_US locale at first boot, not en_US.utf8. The default setting in /etc/profile is LANG=en_US, so that is fine. Of course, the locale-dialog will offer other locales and you will be able to choose something else, but the text-mode dialog window does not offer UTF-8, so your choice should not cause a hang.

Note, it is only when the 'chooselocale' script is run from within X that you get a more sophisiticated GUI with a checkbox to enable UTF-8 -- if you really must use it (again, see my earlier blog posts about the UTF-8 locale).


Posted on 15 May 2009, 10:05


Comments:

Posted on 15 May 2009, 13:46 by Sage
AMD KII-6 machines
Don't understand 90% of the SW stuff above, but I've also been reviving three of these machines recently (anybody want one gratis?). Bruce and I reported that this kind of kit fitted with 192Mb RAM runs compact distros virtually as well as P4, better than P2 & P3. This may , in part , be due to the fact that they have L1, L2 and L3 cache available, two of those are on-chip + the old on-board chips. Some of these cpu s can be clocked to 603, although some Linux distros aren't very forgiving with non-standard bus settings. A FULL installation is also a bonus in these circumstances, although swap space can confuse matters, particularly if one listens to the lunatic fringe and provides too much (generally more than 1x SDRAM for Puppy).
The main gripe with old kit is that CD drives ~<=36x won't read CD-RW. That means burning to CD-R. I get quite irritated when developers claim perfection for their latest release, I burn to CD-R, then within days major bugs emerge. The Debian approach is more trustworthy when experimenting with old stuff.
Notwithstanding, I applaud efforts to recycle HW; time and again, I find that the really clever guys who make small .iso s with inspired selections of tightly integrated apps. (that's efficient as in Opera, not bloated as in SM !) can enable folks to run common tasks with throwaway junk at speeds approaching the cartels' money-grabbing shiny lamps. Notwithstanding, as important as app selection is the provision of the widest range of drivers and accomodating older video cards.
A final tip is to try to avoid anything Intel; for the record, yesterday the EU fined this company even more than an earlier fine against M$. These companies are crooked and their products questionable.