Bug 125700 - no detailed error messages in the install log
no detailed error messages in the install log
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-10 06:04 EDT by Fergal Daly
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.3-65
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-06 01:19:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
factor out exec code from glibc_post_upgrade (2.91 KB, patch)
2004-07-04 16:41 EDT, Fergal Daly
no flags Details | Diff
make glibc_post_upgrade more verbose (1.67 KB, patch)
2004-07-04 16:46 EDT, Fergal Daly
no flags Details | Diff

  None (edit)
Description Fergal Daly 2004-06-10 06:04:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
install.log contains a list of packages that were installed or that
failed but the error messages are of little use for figuring out what
actually went wrong.



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
I tried installing with LVM and something went wrong (everything
worked fine when I didn't use LVM). I have no idea what the problem is
but it the same thing happened each time I tried to use LVM so it
seems to be reproducible for me.

Actual Results:  my install log looks like

Installing 1459 packages

Installing fedora-logos-1.1.20-1.noarch.
Installing hwdata-0.101-1.noarch.
Installing libgcc-3.3.2-1.i386.
Installing setup-2.5.27-1.1.noarch.
Installing filesystem-2.2.1-5.i386.
Installing basesystem-8.0-2.noarch.
Installing termcap-11.0.1-17.noarch.
Installing tzdata-2003d-1.noarch.
Installing glibc-common-2.3.2-101.i386.
Installing glibc-2.3.2-101.i686.
error: %post(glibc-2.3.2-101) scriptlet failed, exit status 115
Installing beecrypt-3.0.1-0.20030630.1.i386.
Installing bzip2-libs-1.0.2-10.i386.
Installing chkconfig-1.3.9-1.i386.
....

Expected Results:  What would have been much more useful is something like

Installing glibc-2.3.2-101.i686.
error: %post(glibc-2.3.2-101) scriptlet failed at scriptname:86
#file not found: /lib/something
exit status 115

rpm and/or anaconda should echo the output of the scripts and it
should be recorded in the log.


Additional info:

Without this I have no way of even filing a useful bug report for my
LVM install problem.
Comment 1 Jeremy Katz 2004-06-14 11:25:43 EDT
It's impossible for anaconda to record non-existent information -- why
the glibc scriptlet failed with that error is dependent on what
glibc_post_upgrade returns in various cases 
Comment 2 Jakub Jelinek 2004-06-14 11:36:05 EDT
115 means /usr/sbin/iconvconfig failed.
glibc_post_upgrade is not very verbose on purpose, it is statically
linked, but doesn't want to bloat too much, so avoids most of the
libc functions to keep the binary small.

Try running /usr/sbin/iconvconfig by hand to see why it failed.
Comment 3 Jeremy Katz 2004-06-14 11:41:25 EDT
*** Bug 125697 has been marked as a duplicate of this bug. ***
Comment 4 Fergal Daly 2004-06-14 12:13:07 EDT
I think it would not be possible to run iconvconfig by hand because
it's part of glibc and glibc failed to install so the files got
deleted (I think). The system was completely unusable, no glibc, no
grub, no kernel. chroot /mnt/sysimage gave a segfault. (#125697 has
more details)

The point of my suggestion is that the failure output from iconvconfig
should have been captured in the log, rather than me having to try and
get it manually.

Would you be interested in a patch to make glibc_post_upgrade redirect
stdout and stderr to a temp file every time it runs a command and then
to output the contents of these files if the command fails? It looks
like a fairly simple change.
Comment 5 Fergal Daly 2004-07-04 16:41:37 EDT
Created attachment 101622 [details]
factor out exec code from glibc_post_upgrade 

This patch adds a function and a macro which allows the removal of lots of
repeated code for doing execv, waitpid etc. It removes 50 lines of code and 400
bytes on the executable.
Comment 6 Fergal Daly 2004-07-04 16:46:25 EDT
Created attachment 101623 [details]
make glibc_post_upgrade more verbose

this patch follow the previous and adds some very basic printing functions so
that we can see what glibc_post_upgrade is doing and what went wrong. This adds
60 lines of code and 700 bytes to the exe but it should help tracking down
problems.
Comment 8 Ulrich Drepper 2004-10-06 01:19:11 EDT
The current rawhide builds have a patch based on yours.

Note You need to log in before you can comment on or make changes to this bug.