Bug 39244 - Installer dismally fails on an attempt to "update"
Summary: Installer dismally fails on an attempt to "update"
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.3
Hardware: alpha
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-06 05:42 UTC by Michal Jaegermann
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-06-10 05:24:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
a list of packages before an upgrade was attempted (3.41 KB, application/octet-stream)
2001-05-07 20:24 UTC, Michal Jaegermann
no flags Details
a list of packages now after failed upgrade attempts (3.52 KB, application/octet-stream)
2001-05-07 20:25 UTC, Michal Jaegermann
no flags Details
package list used to test (and side-by-side diff w/michal's list) ... (18.72 KB, text/plain)
2001-05-09 16:03 UTC, Brock Organ
no flags Details

Description Michal Jaegermann 2001-05-06 05:42:40 UTC
This is a diary of my attempts to run "update" from an existing RH 7.0
"test" installation to a beta of RH 7.1.  A machine used is UP1100
Nautilus, 600 MHz ev67 processor, 256 Megabytes of memory, with G450
Matrox graphics card.  All partition from a test installation are on a
SCSI drive hooked up to sym53c875 controller.  There is altogether 449
Megabytes of a swap space spread over different drives and anaconda
complaints that it wants 31 MBytes more (bother!).

Various 7.0, and earlier, distribution variants were installed on
the box without any troubles.  A CD with rpms is tested and all
rpms on it are readable.  Also dumping various other files from this
CD to /dev/null does not generate any complaints.

Usually an update starts ok, brings an graphics screen and starts
before failing one way or another.

Try one - the installer dies without a feedback doing "Finding
packages to upgrade".  Initially a keyboard is operational but a
search through different text consoles does not provide any clues.
A keyboard goes away before I have a chance to try to examine any
possible log files.  Power switch time.

Try two - we are further this time.  An installation gets aborted
because there is missing space - 10 Megs on /, 20 Megs on /usr and
38 Megs on /usr/share.  I get dumped back to a "main" screen after
this information is displayed.  Despite of that hitting "Next" button
at this moment repeats an installation attempt but this time more
space is missing because "installation image" gets copied to a hard
drive for the second time.  It is possible to get out of this loop
but far from obvious.

Try three - after an initial boot from a CD a text mode installer
starts and shortly after complaints that it cannot find a Red Hat
CD-ROM in "any of CD drives" (it happens to be only one).

Try four - I agree to a creation of this extra 31 MB of a swap space.
The installer dies again in "Finding packages to upgrage".  Both a
keyboard and a mouse are locked immediately when a disk activity
stops.  A lack of any indicator that a machine is still alive in this,
and other long phases where nothing visible happens for long periods
of time, is very disconcerting.  I know that I have to wait but
newbies would likely decide that a machine is dead much earlier.

A post-mortem examination of a disk reveal that this happnes while
writing files in /var/lib/anaconda-rebuilddb988995439 directory.
There are no newer files that those on the whole disk and they are
obviously incomplete.  A listing of /var/lib/rpm looks like this:

-rw-r--r--    1 root     root      2686976 Apr 24 16:35 Basenames
-rw-r--r--    1 root     root        24576 Apr 14 14:02 Conflictname
-rw-r--r--    1 root     root        24576 Apr 24 16:36 Group
-rw-r--r--    1 root     root        24576 Apr 24 16:35 Name
-rw-r--r--    1 root     root     10526720 Apr 24 16:35 Packages
-rw-r--r--    1 root     root        90112 Apr 24 16:36 Providename
-rw-r--r-- 1 root     root        98304 Apr 24 16:36 Requirename
-rw-r--r--    1 root     root        24576 Apr 24 16:35 Triggername

while in other directory we collected so far only that:

-rw-r--r--    1 root     root      2580480 May  4 10:59 Basenames
-rw-r--r--    1 root     root        24576 May  4 10:59 Conflictname
-rw-r--r--    1 root     root        24576 May  4 10:59 Group
-rw-r--r--    1 root     root        24576 May  4 10:59 Name
-rw-r--r--    1 root     root      7004160 May  4 10:59 Packages
-rw-r--r--    1 root     root        49152 May  4 10:59 Providename
-rw-r--r--    1 root     root        90112 May  4 10:59 Requirename
-rw-r--r--    1 root     root        24576 May  4 10:59 Triggername

Try five - a behaviour like in try three

Try six - dies in "Finding packages to upgrage" but this time very

I run 'rpm --rebuilddb' to eliminate a possibility of a corrupted
database.  Takes a looong while but finishes successfully.

Try seven - No change; anaconda-rebuilddb locks up.

Try eight - I reduce an amount of swap space by mounting "only"
256 Megs.  An instant success.  We are starting to install packages.
After seven packages completed the installer dies while attempting
to install a new version of glibc.  A file system is messed up with
missing or invalid blocks in /lib/libpthreads... and /lib/libresolv...
After a cleanup I am installing a new glibc "by hand" to get a machine
in some consistent state.  Not a whiff of problems beyond that
that a new version of rpm generates "unaligned trap" on every

Try nine - dies in "Finding packages to upgrage".

Try ten - An attempt of a text install.  Dies before finding possible
candidates for an upgrade with "install exited abnormally - received
signal 4".  On the fourth console one can find "Error -3 while

Try eleven - installing in a text mode.  Locks up on a check
of package dependencies.  On another console one can observe
warnings "maximum mount count reached" for all mounted file systems.
This is kind of curious taking into account a number of times these
file systems were rebuild in fsck.

Try twelve - in a text mode.  An installation starts and dies, after
96 packages were installed, in an attempt to install tcl-8.3.1-53
leaving a file system in a serious disarray.  To check what went
wrong I try to use files from /var/lib/anaconda-rebuilddb...
as an rpm base.  a command 'rpm -qa | grep tcl' shows
and none of these is passing 'rpm -V' with files missing from both.
Attempts of 'rpm -e' on both or 'rpm -force -Uvh tcl-8.3.1-53.alpha.rpm'
generate "Segmentation violation (core dumped)".  This kind of explains
why the whole installation stopped.

I guess that something more usable is needed before I will be able
to continue with tests.

Why you insist on using 2.4 for installation purposes?  It does not
seem currently fit for that - especially with swapping bugs.


Comment 1 Phil Copeland 2001-05-06 07:36:59 UTC
umm where did you get RC1 for the Alpha from? I've not built one for public
consumption as yet! is this something you found in rawhide? If you're desperate
for something to test I've got an ISO set probably better for what you want to
play with which I've been doing some testing with.


Comment 2 Michal Jaegermann 2001-05-06 16:59:32 UTC
> umm where did you get RC1 for the Alpha from?

From nowhere.  As I wrote elsewhere (beta testers mailing list)
an annoucement told to file bugs against "wolverine".  The only
small catch is there is no "wolverine" listed in bugzilla and I had
to file this _somewhere_.  If you have a better place then refile
it yourself and please correct information for testers.

This "RESOLVED NOTABUG" is either a mistake or a sick joke.  If you
are going to ignore bug reports then please tell that in advance
and I will stop wasting my time.  I certainly spent way too long
fighting with this installer and trying to convey what I thought
would be a useful information.

Comment 3 Brock Organ 2001-05-07 18:21:27 UTC

I am reopening your bug ... let me try to ask some questions to try to more 
clearly understand your steps above.

Firstly, are you using the recent beta provided and have you checked the 
md5sums of the ISOs used ...?

Upgrade 1) - dies during "Finding packages to upgrade" step ...  I have not 
seen this problem here upgrading a full stock 7.0 upgrade to the 7.1 beta (of 
course, I wasn't using the same hardware as you describe above) ... what was 
your original package manifest?  Was it a stock 7.0 install (Workstation, 
Server or Custom)?  Do you have a previous package list that we can use to try 
to faithfully reproduce your problem?

Upgrades 2) through 9)  - Are these upgrades performed on the above system, or 
were they performed on a fresh installed system?  This is important.  If some 
problem during the first upgrade caused system damage, then we may have very 
little chance of reproducing (and hence fixing) problems 2 thru 9 ...

I just hope to make things clear on how we can find and reproduce (and then 
fix :) ) these problems ...

Comment 4 Michal Jaegermann 2001-05-07 20:21:04 UTC
> Firstly, are you using the recent beta provided

Yes, these are exactly those which I tried (I never went past
the first CD).  Are there any other ones available "outside"?

> and have you checked the md5sums of the ISOs used ...?

md5sums were OK; also on the first CD I run the following command
to check if I do not have any media errors:

find . -type f -print | \
while read n ; do echo $n ; cat $n > /dev/null ; done

It finished without reporting any problems.  Moreover you may
note that when I was installing failing rpms outside of an installer
This went without a hitch.

> Upgrade 1) - dies during "Finding packages to upgrade" step ...  I
> have not seen this problem here upgrading a full stock 7.0 upgrade to
> the 7.1 beta 

Good to know that it works for somebody but it definitely gave
me a hard time.

> what was your original package manifest?  Was it a stock 7.0 install
> (Workstation, Server or Custom)?

I do happen to have a full initial package list for this test
installation.  Attached. I also attach a list which shows a list of
packages now.  Note tcl status. It is not a "real" installation in a
sense. :-) It was updated in bits and pieces as circumstances

> Upgrades 2) through 9)  - Are these upgrades performed on the above
> system, or were they performed on a fresh installed system?

Note that until "try eight", which messed up glibc, nothing was
installed at all.  I was careful enough to clean-up all new leftover
stuff which appeared and to check date-stamps to make sure that I did
not miss something.  With glibc in tatters I did not have much choice.
I am afraid that I do not have that much of an extra disk space to be
able to do everything each time "from scratch".

> I just hope to make things clear on how we can find and reproduce
> (and then fix :) ) these problems ... 

It looks to me that anaconda does not play nicely with a new format
of rpm databases.  This is only a guess as a computer locks up on
failures, so I do not have a way to examine whatever may be left
there to examine, and on a reboot all evidence disappears (with
an exception of bad content of /var/lib/anaconda-rebuilddb...)


Comment 5 Michal Jaegermann 2001-05-07 20:24:00 UTC
Created attachment 17589 [details]
a list of packages before an upgrade was attempted

Comment 6 Michal Jaegermann 2001-05-07 20:25:32 UTC
Created attachment 17590 [details]
a list of packages now after failed upgrade attempts

Comment 7 Brock Organ 2001-05-08 14:39:29 UTC
> > Firstly, are you using the recent beta provided
> Yes, these are exactly those which I tried (I never went past
> the first CD).  Are there any other ones available "outside"?

No, I just wanted to make sure we were talking about the same ISOs ... :)  
That gives me the definite end point and with your package list I have a 
definite starting point ... thank you for attaching that info ... I will try 
to reproduce this behavior ... even if I don't reproduce it on generic 
hardware (I will try to find a system with hardware like yours!) this may help 
narrow the issue down.  Also, what level of SRM does your machine have ...? 

Comment 8 Michal Jaegermann 2001-05-08 20:38:45 UTC
SRM on this box identifies itself as A5.6-13, Dec 7 2000.

Comment 9 Brock Organ 2001-05-09 16:02:14 UTC
I'm still working to find a nautilus to test this on ... tests with an very 
similar package manifest on generic hardware did not fail (see following 
attachment) ... this makes me think the issue may be specific to the nautilus 
hardware and/or SRM level ...

Comment 10 Brock Organ 2001-05-09 16:03:47 UTC
Created attachment 17907 [details]
package list used to test (and side-by-side diff w/michal's list) ...

Comment 11 Michal Jaegermann 2001-05-09 22:24:01 UTC
I tried an update in a text mode once again; but this time I switched to the
second console while "Finding packages..." was grinding.  It looks that
it went through roughly 90% of the job when it died.  A "magic sysrq" key
was still operational.  This is what it produced for memory, pc and
a task list.  This is a transcript from a screen so there may be some


Free pages:  132784kB (  0kB HighMem)
(Active: 4768, inactive_dirty: 3361, inactive_clean: 0, free 16598(304 608 912)
2*8kB 0*16kB  0*32kB  0*64kB 2*128kB 2*256kB 2*512kB 1*1024kB 0*2048kB 2*4096kB
0*8192kb = 11024kb)
0*8kB 2*16kB  0*32kB  0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 1*4096kB
14*8192kb = 121760kb)
= 0kB)
Swap cache: add 0, delete 0, find 0/0
Free swap: 262568kB
32690 pages of RAM
16902 free pages
2083 reserved pages
6424 pages shared
0 pages swap cached
10 pages in table cache
Buffer memory:  9568kB

ps: 0000 pc: [<fffffc000085922c>]
rp: [<fffffc0000859268>] sp: [<fffffc000fbcbb98>]
 r0: 0000000000000000  r1: fffffc0009e41f18  r2: fffffc0009e41fa0  r2:
 r4: fffffc0000a85ad0  r5: fffffc0000a7f5cc  r6: 0000000000000001  r7:
 r8: fffffc000fbc8000 r16: 0000000000000001 r17: 0000000000000001 r18:
r19: 0000000000000002 r20: 0000000000000001 r21: 00000000000000ff r22:
r23: fffffc000089da94 r24: 0000000000000400 r25: 0000000000000400 r26:
r27: fffffc000089f240 r28: 0000000000000001 r29: fffffc0000ada7a0 hae:

                              free                         sibling
task		PC           stack pid father child      younger older
swapper    S fffffc0000830a84  0    1   0      8 (L-TLB)
keventd    R fffffc000083bfac  0    2   1        (L-TLB)   3
kswapd     R fffffc0000828184  0    3   1        (L-TLB)   4      2
kreclaimd  S fffffc00008289c8  0    4   1        (L-TLB)   5      3
bdflush    R fffffc000085cd30  0    5   1        (L-TLB)   6      4
kupdated   R fffffc0000828184  0    6   1        (L-TLB)   7      5
mdrecoverdy S fffffc000096c854 0    7   1        (L-TLB)   8      6
linuxrc    S fffffc0000830a84  0    8   1     10 (NOTLB)          7
linuxrc    R fffffc00008280f8  0    9   8        (NOTLB)  10
anaconda   R    current task   0   10   8     26 (NOTLB)          9
loop0      S fffffc000081a038  0   25  10        (L-TLB)  26
sh         S fffffc00008280f8  0   26  10        (NOTLB)         25

Comment 12 Michal Jaegermann 2001-05-12 00:17:53 UTC
I should add that I had an opportunity to try a "plain" installation, i.e.
not an update, on UP2000 (Tsunami).  It was mostly uneventfull.  The only
notable event was that although anaconda did recognize a TNT2 graphics card,
and it was told explicitely which monitor was that, it still insisted that
the only feasible graphics mode is 8-bit 640x480.  That is minor, as it later
obviously it did not pay any attention to itself, with an exception of this 
8-bits depth and various modern graphics cards actually dislike to be in that
mode and sometimes behave strangely.  Not in this case but a novice may
have a hard time to fix such small annoyances.

Comment 13 Brock Organ 2001-05-18 16:26:17 UTC

I've been unable to reproduce your upgrade experiences with our local nautilus 
box, but that is because it (the box) it behaving flaky, and the hardware is 
not cooperating ... :(

As for your most recent comment (ie X video resolution of only 640x480 despite 
having adaquate video card & monitor), this is a function of the amount of 
memory the installer detects your video card to have ... not all video cards 
accurately report the correct amount of video ram when queried ... ie manually 
changing the amount of memory from what was reported (probably 1 Mb in your 
case) to the actual value will then ennable you to select a higher resolution 
at the screen where you choose resolution & color bit depth ... :)

Comment 14 Phil Copeland 2001-06-04 20:06:18 UTC
Umm,.. long record, however,..
works for me..


Comment 15 Michal Jaegermann 2001-06-10 05:24:43 UTC
Well, now works for me as well but this is not the same installation set.
I got myself at last a set of RC1 CDs and with these an update,
on exactly the same installation which gave me all this trouble, run without
any incidents. 293 packages installed.

Waiting for "Finding packages to upgrade" without any feedback is a nerve
whacking experience. :-)

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