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.
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.
> 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.
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 ...
> 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...)
Created attachment 17589 [details]
a list of packages before an upgrade was attempted
Created attachment 17590 [details]
a list of packages now after failed upgrade attempts
> > 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 ...?
SRM on this box identifies itself as A5.6-13, Dec 7 2000.
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 ...
Created attachment 17907 [details]
package list used to test (and side-by-side diff w/michal's list) ...
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)
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:
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
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.
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 ... :)
Umm,.. long record, however,..
works for me..
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. :-)