Re: more language support
Enrique Zanardi <ezanardi@ull.es> writes:
> On Sat, Feb 06, 1999 at 04:41:13PM -0500, James A. Treacy wrote:
> > I was rather surprised when I found out that separate disks were needed for
> > each language. Are we really that full? The two things needed that take up
> > room are having the different translations of the text and the locale info.
> > I doubt that i18n would add even 1MB to the boot floppies.
> Currently it's just one _rescue_ floppy for each language. The base system
> contains all the translations (and I'm adding >1MB for 2.1.7 as I'm going
> to include locales*.deb).
> I would like to include gettext support and several translations on the
> rescue floppy, but I have been moving too many things out of the rescue
> disk just to be able to build it. I bet gettext and translations won't
> fit.
Take a look at what Red Hat does, the source is in "misc/src/install"
on any CD or ftp site. They use gettext to extract the data, and
build a .po file, but then they use the "simplemot" perl script to
build their own ".tr" files and use the code in "lang.c" to load the
translation files and do the translation.
(You'll also notice that Red Hat has been force to bzip some of the
programs and unzip them after booting the floppy.)
2.2.x issues follow:
====================
BTW, there are going to be some issues with the 2.2.x kernels and the
boot floppies. The "mount.c" file cheats when mounting NFS
partitions. (It uses the kernel to do name resolution and set up the
mount.)
Apparently, the kernel no longer likes this - at the very least the
server address has to be passed to the kernel via a special structure,
and it looks like a root file handle is also needed.
So, I've had to add some code to mount.c to get it to work with 2.2.x
kernels. (I took Red Hat's code - which is the same as the stuff from
the mount program, and stripped out a bunch of fluff. After this
change the size of mount.o is:
text data bss dec hex filename
7500 152 612 8264 2048 mount.o
I also need to pull in a couple of symbols from resolv (I add
-Wl,-static -lresolv to the link command), because glibc doesn't like
to do name resolution without the nss shared objects. All told it
adds about 10k or so to the size of busybox.
(I won't include the diff here, as it is 17k long).
Also, I changed the loop handling in my copy. The detection for a
"broken" loop device no longer works. (You can read from the device,
but you still can't mount it.) I just took out the detection, and
assumed a "broken" device.
Something like:
--- extract_kernel.c.orig Sun Feb 7 14:49:12 1999
+++ extract_kernel.c Sun Feb 7 14:50:16 1999
@@ -69,16 +69,10 @@
else {
int ro=1;
sprintf(prtbuf,"%s/%s",Archive_Dir,diskimage);
- device="/dev/loop0";
- set_loop(device,prtbuf,0,&ro);
- if (check_loop(device)) {
- /* image is on an NFS server -> loop device is broken, copy to local */
- del_loop(device);
sprintf(prtbuf,MSG_BROKEN_LOOP_DEV,diskimage);
pleaseWaitBox(prtbuf);
device=copy_to_local(diskimage,0);
boxPopWindow();
- }
}
return device;
}
Finally, the code in fdisk_find_partition_by_name is now segfaulting.
(If and only if I mount the nfs source for the floppies after I mount
/target. It sees that some of the entries in "fdisk_partitions" have
NULL mount_points, and they show up in the list before /target if I
mount target first. (Dunno why.) I've done:
--- fdisk.c.orig Sun Feb 7 12:09:34 1999
+++ fdisk.c Sun Feb 7 13:01:10 1999
@@ -516,7 +516,7 @@
p = fdisk_partitions;
while (p) {
- if (0 == strcmp(mount_point, p->mount_point))
+ if (p->mount_point && 0 == strcmp(mount_point, p->mount_point))
return p;
p = p->next;
}
to fix it.
The good news: I now have a tftpboot image (with 2.2.1 kernel) that
works on both 32-bit and 64-bit sparc systems. (BTW, the 2.2.x kernel
is necessary for the 64-bit systems as there is no 2.0.x kernel.)
Steve
dunham@cse.msu.edu
Reply to: