Re: d-i install report, hppa
* Richard Hirst <rhirst@linuxcare.com> [2004-01-19 18:30]:
| On Mon, Jan 19, 2004 at 04:44:03PM +0100, Thorsten Sauter wrote:
| > * Richard Hirst <rhirst@linuxcare.com> [2004-01-18 20:48]:
| > | Initial boot fails due to a SEGV in frontend; this appears to be because
| > | of a bug in glibc, triggered by libm being reduced to what is effectively
| > | an empty library. Bug #228375 filed. I hacked mklibs to include a symbol
| > | from libm, so I could build a working image. text frontend worked ok.
| > |
| > | Kernel hung on reboot when discover tried to load de4x5.o; the kernel
| > | has the tulip driver compiled in to handle the network i/f. I renamed
| > | the module and tried again. This time it rebooted ok, and base-config
| > | ran ok.
| >
| >
| > very good news.
| > mklibs is a little bit mystic for me. :-)
| >
| > Should I include this patch on paer as long as we have no updated mklibs
| > version?
|
| Hmm, the patch is below, but I can't say whether you should hack
| /usr/bin/mklibs on paer. Carlos (hppa glibc guy) agrees that I found
| the bug in glibc, but he is fixing it in a slightly different way. I'd
| assumed that we would get a fixed glibc, rather than work round it in
| mklibs, but I guess a new mklibs is easier to arange. "log" was just a
| symbol I picked at random; the requirement is that "objdump -p libm.so.6"
| shows a non-zero DT_JMPREL value. As "log" adds about 50K to libm, I
| suspect other archs would be upset by this mklibs change.
of course, not hacking the system mklibs binary, but I could use my own
mklibs app as long as we have no fixed glibc and/or mklibs package. This
will make the images working for this time.
Bye
Thorsten
--
Thorsten Sauter
<tsauter@gmx.net>
(Is there life after /sbin/halt -p?)
Reply to: