Zenon,

Tried "init 3" and terminal login just loops.

Tried doing the glibc replace and got the following error after entering
line 1:

error:  postun(glibc-2.3.2-11.9) scriplet failed, exit status 255
error: %trigger(redhat-lsb1.3-1) scriplet failed, exit status 255
rpmdb: /var/lib/rpm/Triggername: No such file or directory
rpmdb: /var/lib/rpm/Triggername: cannot sync: no such file or directory
error: db4 error(2) from dbenv->close: No such file or directory


Needless to say, trying step 2 did yield much other than:

Preparing:
 ########################################
############### [100%]
package glibc-2.3.2-11.9 is already
installed
rpmdb: /var/lib/rpm/Basenames: No such file or directory
rpmdb: /var/lib/rpm/Basenames: cannot sync: no such file or directory
error: db4 error(2) from dbenv->close: No such file or directory


I went to bugzilla, but I think my choice of keywords was probably pretty
poor.  "loop" and "login" yielded nothing, and "glibc" yielded a boat load,
but none seemed to apply.

Any other suggestions?

Thanks!!

Don











"Zenon Panoussis" <spamtrap@provocation.net> wrote in message
news:3fb511a0$0$58715$e4fe514c@news.xs4all.nl...
quote:

>
> Don wrote:
> 
>
> Try appending "init 3" to the grub root=... line and see if
> you can log in on the command line.
>
> If that doesn't work either, you probably have a messed-up
> glibc. The easiest way to recover is booting the installation
> CD/floppy with "linux rescue" and then running
>
> # rpm --root /mnt/sysimage --nodeps -e glibc
> # rpm --root /mnt/sysimage -hiv /path/to/glibc-{ver}.{arch}.rpm
>
> Make sure to install the right glibc for your architecture.
> Lots more on this subject at http://bugzilla.redhat.com
>
> Z
>

[ Post a follow-up to this message ]

Don wrote:
quote:

> Tried doing the glibc replace and got the following error after entering
> line 1:

quote:

> error:  postun(glibc-2.3.2-11.9) scriplet failed, exit status 255
> error: %trigger(redhat-lsb1.3-1) scriplet failed, exit status 255
> rpmdb: /var/lib/rpm/Triggername: No such file or directory
> rpmdb: /var/lib/rpm/Triggername: cannot sync: no such file or directory
> error: db4 error(2) from dbenv->close: No such file or directory


Did you really give --root /mnt/sysimage to your rpm command?
Did all your partitions get mounted by the rescue floppy? You
can check that by comparing the output of "df" to the contents
of /mnt/sysimage/etc/fstab . If they don't match, you should
mount the missing partitions manually. You do that with
# mount /dev/hd[xn] /mnt/sysimage/[mountdir]
where the first argument is identical to the device name in
fstab and the second argument is the mount point in fstab
prepended with "/mnt/sysimage". If your fstab uses labels
instead of partition names, use them too.

The bug I had in mind is
https://bugzilla.redhat.com/bugzill...ug.cgi?id=88456 .
It's a long but edifying reading, in more aspects than just
the technical.
quote:

> Any other suggestions?


Hm. Was there anything at all out of the ordinary with your
rh8.0 system? Did you make any non-default choices during
the upgrade (LDAP authentication and the like)? Did the
upgrade finish correctly?

I would boot again with the rescue floppy and read the log,
/mnt/sysimage/var/log/messages . The clue to what's happening
is most probably there, on or right after the time of the system
upgrade and the failed login attempts. Do also check
/mnt/sysimage/var/log/dmsg .

Does /mnt/sysimage/var/lib/rpm exist? If so, does ls -l return
something like
Basenames     __db.003  Installtid   Provideversion  Sha1header
Conflictname  Dirnames  Name         Pubkeys         Sigmd5
__db.001      Filemd5s  Packages     Requirename     Triggername
__db.002      Group     Providename  Requireversion
with reasonable file sizes (not 0 bytes)? If not, what do you
see in /mnt/sysimage/var/ and /mnt/sysimage/var/lib/ ?

The way to repair a ruined rpm database is to delete the files
that begin with double underscores, like __db.001, __db.002
and then do
# cd /mnt/sysimage
# chroot .
# rpm --rebuilddb
# ls -l /var/lib/rpm   (check you got fresh db files)
# exit
This would fix your rpm database in case it's ruined,
but leave you with the original problem. Depending on
whether you found previously unmounted partitions or
any other reasons why rpm failed the first time, you
might or might not want to rebuild the rpm database
and you might have to repeat the glibc upgrade procedure.
In any case, I would suggest that you don't start on any
of this until you know for sure what is causing your
login problem.

Z

[ Post a follow-up to this message ]

Don wrote:
quote:

> Tried doing the glibc replace and got the following error after entering
> line 1:

quote:

> error:  postun(glibc-2.3.2-11.9) scriplet failed, exit status 255
> error: %trigger(redhat-lsb1.3-1) scriplet failed, exit status 255
> rpmdb: /var/lib/rpm/Triggername: No such file or directory
> rpmdb: /var/lib/rpm/Triggername: cannot sync: no such file or directory
> error: db4 error(2) from dbenv->close: No such file or directory


Did you really give --root /mnt/sysimage to your rpm command?
Did all your partitions get mounted by the rescue floppy? You
can check that by comparing the output of "df" to the contents
of /mnt/sysimage/etc/fstab . If they don't match, you should
mount the missing partitions manually. You do that with
# mount /dev/hd[xn] /mnt/sysimage/[mountdir]
where the first argument is identical to the device name in
fstab and the second argument is the mount point in fstab
prepended with "/mnt/sysimage". If your fstab uses labels
instead of partition names, use them too.

The bug I had in mind is
https://bugzilla.redhat.com/bugzill...ug.cgi?id=88456 .
It's a long but edifying reading, in more aspects than just
the technical.
quote:

> Any other suggestions?


Hm. Was there anything at all out of the ordinary with your
rh8.0 system? Did you make any non-default choices during
the upgrade (LDAP authentication and the like)? Did the
upgrade finish correctly?

I would boot again with the rescue floppy and read the log,
/mnt/sysimage/var/log/messages . The clue to what's happening
is most probably there, on or right after the time of the system
upgrade and the failed login attempts. Do also check
/mnt/sysimage/var/log/dmsg .

Does /mnt/sysimage/var/lib/rpm exist? If so, does ls -l return
something like
Basenames     __db.003  Installtid   Provideversion  Sha1header
Conflictname  Dirnames  Name         Pubkeys         Sigmd5
__db.001      Filemd5s  Packages     Requirename     Triggername
__db.002      Group     Providename  Requireversion
with reasonable file sizes (not 0 bytes)? If not, what do you
see in /mnt/sysimage/var/ and /mnt/sysimage/var/lib/ ?

The way to repair a ruined rpm database is to delete the files
that begin with double underscores, like __db.001, __db.002
and then do
# cd /mnt/sysimage
# chroot .
# rpm --rebuilddb
# ls -l /var/lib/rpm   (check you got fresh db files)
# exit
This would fix your rpm database in case it's ruined,
but leave you with the original problem. Depending on
whether you found previously unmounted partitions or
any other reasons why rpm failed the first time, you
might or might not want to rebuild the rpm database
and you might have to repeat the glibc upgrade procedure.
In any case, I would suggest that you don't start on any
of this until you know for sure what is causing your
login problem.

Z

[ Post a follow-up to this message ]

Don wrote:
quote:

> Tried doing the glibc replace and got the following error after entering
> line 1:

quote:

> error:  postun(glibc-2.3.2-11.9) scriplet failed, exit status 255
> error: %trigger(redhat-lsb1.3-1) scriplet failed, exit status 255
> rpmdb: /var/lib/rpm/Triggername: No such file or directory
> rpmdb: /var/lib/rpm/Triggername: cannot sync: no such file or directory
> error: db4 error(2) from dbenv->close: No such file or directory


Did you really give --root /mnt/sysimage to your rpm command?
Did all your partitions get mounted by the rescue floppy? You
can check that by comparing the output of "df" to the contents
of /mnt/sysimage/etc/fstab . If they don't match, you should
mount the missing partitions manually. You do that with
# mount /dev/hd[xn] /mnt/sysimage/[mountdir]
where the first argument is identical to the device name in
fstab and the second argument is the mount point in fstab
prepended with "/mnt/sysimage". If your fstab uses labels
instead of partition names, use them too.

The bug I had in mind is
https://bugzilla.redhat.com/bugzill...ug.cgi?id=88456 .
It's a long but edifying reading, in more aspects than just
the technical.
quote:

> Any other suggestions?


Hm. Was there anything at all out of the ordinary with your
rh8.0 system? Did you make any non-default choices during
the upgrade (LDAP authentication and the like)? Did the
upgrade finish correctly?

I would boot again with the rescue floppy and read the log,
/mnt/sysimage/var/log/messages . The clue to what's happening
is most probably there, on or right after the time of the system
upgrade and the failed login attempts. Do also check
/mnt/sysimage/var/log/dmsg .

Does /mnt/sysimage/var/lib/rpm exist? If so, does ls -l return
something like
Basenames     __db.003  Installtid   Provideversion  Sha1header
Conflictname  Dirnames  Name         Pubkeys         Sigmd5
__db.001      Filemd5s  Packages     Requirename     Triggername
__db.002      Group     Providename  Requireversion
with reasonable file sizes (not 0 bytes)? If not, what do you
see in /mnt/sysimage/var/ and /mnt/sysimage/var/lib/ ?

The way to repair a ruined rpm database is to delete the files
that begin with double underscores, like __db.001, __db.002
and then do
# cd /mnt/sysimage
# chroot .
# rpm --rebuilddb
# ls -l /var/lib/rpm   (check you got fresh db files)
# exit
This would fix your rpm database in case it's ruined,
but leave you with the original problem. Depending on
whether you found previously unmounted partitions or
any other reasons why rpm failed the first time, you
might or might not want to rebuild the rpm database
and you might have to repeat the glibc upgrade procedure.
In any case, I would suggest that you don't start on any
of this until you know for sure what is causing your
login problem.

Z

[ Post a follow-up to this message ]

Zenon,

Thanks for all your suggestions and the reference to the Bugzilla page!!

Unfortunately, I am no closer to a solution.  I tried your suggestions and
some of the ones from
https://bugzilla.redhat.com/bugzill...g.cgi?id=88456.  Even hybrids!
Given that it is a hobby system with not much on it, I even attempted doing
things like deleting all the glibc related files from rescue mode and
reinstalling them.  Interestingly, while the RPM operation generally
reported errors, they seemed to be doing something.

I even went as far as trying to do a forced installation (vs. upgrade) a
couple of times.  No luck!  However, while I had the install process format
the /boot and swap spaces, I had it leave the main ext3 space for /
untouched.  My guess is there is something not being
updated/overwritten/written/deleted from the previous install that
preventing the upgrade/install of RH9.  Which actually boggles my mind as
you would think booting from CD would have it use all the CD based files.
But based on some of the comments in the Bugzilla report it probably is not
unexpected given all the issues others apparently had upgrading.

Anyway, I have some other projects I need to work on so I will have to let
this slide for a couple of weeks.

Again, thank you for all your comments, insight, and help!!!

Don







"Zenon Panoussis" <spamtrap@provocation.net> wrote in message
news:3fb60840$0$58697$e4fe514c@news.xs4all.nl...
quote:

>
> Don wrote:
> 
> 
>
> Did you really give --root /mnt/sysimage to your rpm command?
> Did all your partitions get mounted by the rescue floppy? You
> can check that by comparing the output of "df" to the contents
> of /mnt/sysimage/etc/fstab . If they don't match, you should
> mount the missing partitions manually. You do that with
> # mount /dev/hd[xn] /mnt/sysimage/[mountdir]
> where the first argument is identical to the device name in
> fstab and the second argument is the mount point in fstab
> prepended with "/mnt/sysimage". If your fstab uses labels
> instead of partition names, use them too.
>
> The bug I had in mind is
> https://bugzilla.redhat.com/bugzill...ug.cgi?id=88456 .
> It's a long but edifying reading, in more aspects than just
> the technical.
> 
>
> Hm. Was there anything at all out of the ordinary with your
> rh8.0 system? Did you make any non-default choices during
> the upgrade (LDAP authentication and the like)? Did the
> upgrade finish correctly?
>
> I would boot again with the rescue floppy and read the log,
> /mnt/sysimage/var/log/messages . The clue to what's happening
> is most probably there, on or right after the time of the system
> upgrade and the failed login attempts. Do also check
> /mnt/sysimage/var/log/dmsg .
>
> Does /mnt/sysimage/var/lib/rpm exist? If so, does ls -l return
> something like
> Basenames     __db.003  Installtid   Provideversion  Sha1header
> Conflictname  Dirnames  Name         Pubkeys         Sigmd5
> __db.001      Filemd5s  Packages     Requirename     Triggername
> __db.002      Group     Providename  Requireversion
> with reasonable file sizes (not 0 bytes)? If not, what do you
> see in /mnt/sysimage/var/ and /mnt/sysimage/var/lib/ ?
>
> The way to repair a ruined rpm database is to delete the files
> that begin with double underscores, like __db.001, __db.002
> and then do
> # cd /mnt/sysimage
> # chroot .
> # rpm --rebuilddb
> # ls -l /var/lib/rpm   (check you got fresh db files)
> # exit
> This would fix your rpm database in case it's ruined,
> but leave you with the original problem. Depending on
> whether you found previously unmounted partitions or
> any other reasons why rpm failed the first time, you
> might or might not want to rebuild the rpm database
> and you might have to repeat the glibc upgrade procedure.
> In any case, I would suggest that you don't start on any
> of this until you know for sure what is causing your
> login problem.
>
> Z
>

[ Post a follow-up to this message ]

Zenon,

Thanks for all your suggestions and the reference to the Bugzilla page!!

Unfortunately, I am no closer to a solution.  I tried your suggestions and
some of the ones from
https://bugzilla.redhat.com/bugzill...g.cgi?id=88456.  Even hybrids!
Given that it is a hobby system with not much on it, I even attempted doing
things like deleting all the glibc related files from rescue mode and
reinstalling them.  Interestingly, while the RPM operation generally
reported errors, they seemed to be doing something.

I even went as far as trying to do a forced installation (vs. upgrade) a
couple of times.  No luck!  However, while I had the install process format
the /boot and swap spaces, I had it leave the main ext3 space for /
untouched.  My guess is there is something not being
updated/overwritten/written/deleted from the previous install that
preventing the upgrade/install of RH9.  Which actually boggles my mind as
you would think booting from CD would have it use all the CD based files.
But based on some of the comments in the Bugzilla report it probably is not
unexpected given all the issues others apparently had upgrading.

Anyway, I have some other projects I need to work on so I will have to let
this slide for a couple of weeks.

Again, thank you for all your comments, insight, and help!!!

Don







"Zenon Panoussis" <spamtrap@provocation.net> wrote in message
news:3fb60840$0$58697$e4fe514c@news.xs4all.nl...
quote:

>
> Don wrote:
> 
> 
>
> Did you really give --root /mnt/sysimage to your rpm command?
> Did all your partitions get mounted by the rescue floppy? You
> can check that by comparing the output of "df" to the contents
> of /mnt/sysimage/etc/fstab . If they don't match, you should
> mount the missing partitions manually. You do that with
> # mount /dev/hd[xn] /mnt/sysimage/[mountdir]
> where the first argument is identical to the device name in
> fstab and the second argument is the mount point in fstab
> prepended with "/mnt/sysimage". If your fstab uses labels
> instead of partition names, use them too.
>
> The bug I had in mind is
> https://bugzilla.redhat.com/bugzill...ug.cgi?id=88456 .
> It's a long but edifying reading, in more aspects than just
> the technical.
> 
>
> Hm. Was there anything at all out of the ordinary with your
> rh8.0 system? Did you make any non-default choices during
> the upgrade (LDAP authentication and the like)? Did the
> upgrade finish correctly?
>
> I would boot again with the rescue floppy and read the log,
> /mnt/sysimage/var/log/messages . The clue to what's happening
> is most probably there, on or right after the time of the system
> upgrade and the failed login attempts. Do also check
> /mnt/sysimage/var/log/dmsg .
>
> Does /mnt/sysimage/var/lib/rpm exist? If so, does ls -l return
> something like
> Basenames     __db.003  Installtid   Provideversion  Sha1header
> Conflictname  Dirnames  Name         Pubkeys         Sigmd5
> __db.001      Filemd5s  Packages     Requirename     Triggername
> __db.002      Group     Providename  Requireversion
> with reasonable file sizes (not 0 bytes)? If not, what do you
> see in /mnt/sysimage/var/ and /mnt/sysimage/var/lib/ ?
>
> The way to repair a ruined rpm database is to delete the files
> that begin with double underscores, like __db.001, __db.002
> and then do
> # cd /mnt/sysimage
> # chroot .
> # rpm --rebuilddb
> # ls -l /var/lib/rpm   (check you got fresh db files)
> # exit
> This would fix your rpm database in case it's ruined,
> but leave you with the original problem. Depending on
> whether you found previously unmounted partitions or
> any other reasons why rpm failed the first time, you
> might or might not want to rebuild the rpm database
> and you might have to repeat the glibc upgrade procedure.
> In any case, I would suggest that you don't start on any
> of this until you know for sure what is causing your
> login problem.
>
> Z
>

[ Post a follow-up to this message ]

Zenon,

Thanks for all your suggestions and the reference to the Bugzilla page!!

Unfortunately, I am no closer to a solution.  I tried your suggestions and
some of the ones from
https://bugzilla.redhat.com/bugzill...g.cgi?id=88456.  Even hybrids!
Given that it is a hobby system with not much on it, I even attempted doing
things like deleting all the glibc related files from rescue mode and
reinstalling them.  Interestingly, while the RPM operation generally
reported errors, they seemed to be doing something.

I even went as far as trying to do a forced installation (vs. upgrade) a
couple of times.  No luck!  However, while I had the install process format
the /boot and swap spaces, I had it leave the main ext3 space for /
untouched.  My guess is there is something not being
updated/overwritten/written/deleted from the previous install that
preventing the upgrade/install of RH9.  Which actually boggles my mind as
you would think booting from CD would have it use all the CD based files.
But based on some of the comments in the Bugzilla report it probably is not
unexpected given all the issues others apparently had upgrading.

Anyway, I have some other projects I need to work on so I will have to let
this slide for a couple of weeks.

Again, thank you for all your comments, insight, and help!!!

Don







"Zenon Panoussis" <spamtrap@provocation.net> wrote in message
news:3fb60840$0$58697$e4fe514c@news.xs4all.nl...
quote:

>
> Don wrote:
> 
> 
>
> Did you really give --root /mnt/sysimage to your rpm command?
> Did all your partitions get mounted by the rescue floppy? You
> can check that by comparing the output of "df" to the contents
> of /mnt/sysimage/etc/fstab . If they don't match, you should
> mount the missing partitions manually. You do that with
> # mount /dev/hd[xn] /mnt/sysimage/[mountdir]
> where the first argument is identical to the device name in
> fstab and the second argument is the mount point in fstab
> prepended with "/mnt/sysimage". If your fstab uses labels
> instead of partition names, use them too.
>
> The bug I had in mind is
> https://bugzilla.redhat.com/bugzill...ug.cgi?id=88456 .
> It's a long but edifying reading, in more aspects than just
> the technical.
> 
>
> Hm. Was there anything at all out of the ordinary with your
> rh8.0 system? Did you make any non-default choices during
> the upgrade (LDAP authentication and the like)? Did the
> upgrade finish correctly?
>
> I would boot again with the rescue floppy and read the log,
> /mnt/sysimage/var/log/messages . The clue to what's happening
> is most probably there, on or right after the time of the system
> upgrade and the failed login attempts. Do also check
> /mnt/sysimage/var/log/dmsg .
>
> Does /mnt/sysimage/var/lib/rpm exist? If so, does ls -l return
> something like
> Basenames     __db.003  Installtid   Provideversion  Sha1header
> Conflictname  Dirnames  Name         Pubkeys         Sigmd5
> __db.001      Filemd5s  Packages     Requirename     Triggername
> __db.002      Group     Providename  Requireversion
> with reasonable file sizes (not 0 bytes)? If not, what do you
> see in /mnt/sysimage/var/ and /mnt/sysimage/var/lib/ ?
>
> The way to repair a ruined rpm database is to delete the files
> that begin with double underscores, like __db.001, __db.002
> and then do
> # cd /mnt/sysimage
> # chroot .
> # rpm --rebuilddb
> # ls -l /var/lib/rpm   (check you got fresh db files)
> # exit
> This would fix your rpm database in case it's ruined,
> but leave you with the original problem. Depending on
> whether you found previously unmounted partitions or
> any other reasons why rpm failed the first time, you
> might or might not want to rebuild the rpm database
> and you might have to repeat the glibc upgrade procedure.
> In any case, I would suggest that you don't start on any
> of this until you know for sure what is causing your
> login problem.
>
> Z
>

[ Post a follow-up to this message ]

Zenon,

Tried "init 3" and terminal login just loops.

Tried doing the glibc replace and got the following error after entering
line 1:

error:  postun(glibc-2.3.2-11.9) scriplet failed, exit status 255
error: %trigger(redhat-lsb1.3-1) scriplet failed, exit status 255
rpmdb: /var/lib/rpm/Triggername: No such file or directory
rpmdb: /var/lib/rpm/Triggername: cannot sync: no such file or directory
error: db4 error(2) from dbenv->close: No such file or directory


Needless to say, trying step 2 did yield much other than:

Preparing:
 ########################################
############### [100%]
package glibc-2.3.2-11.9 is already
installed
rpmdb: /var/lib/rpm/Basenames: No such file or directory
rpmdb: /var/lib/rpm/Basenames: cannot sync: no such file or directory
error: db4 error(2) from dbenv->close: No such file or directory


I went to bugzilla, but I think my choice of keywords was probably pretty
poor.  "loop" and "login" yielded nothing, and "glibc" yielded a boat load,
but none seemed to apply.

Any other suggestions?

Thanks!!

Don











"Zenon Panoussis" <spamtrap@provocation.net> wrote in message
news:3fb511a0$0$58715$e4fe514c@news.xs4all.nl...
quote:

>
> Don wrote:
> 
>
> Try appending "init 3" to the grub root=... line and see if
> you can log in on the command line.
>
> If that doesn't work either, you probably have a messed-up
> glibc. The easiest way to recover is booting the installation
> CD/floppy with "linux rescue" and then running
>
> # rpm --root /mnt/sysimage --nodeps -e glibc
> # rpm --root /mnt/sysimage -hiv /path/to/glibc-{ver}.{arch}.rpm
>
> Make sure to install the right glibc for your architecture.
> Lots more on this subject at http://bugzilla.redhat.com
>
> Z
>

[ Post a follow-up to this message ]

Zenon,

Tried "init 3" and terminal login just loops.

Tried doing the glibc replace and got the following error after entering
line 1:

error:  postun(glibc-2.3.2-11.9) scriplet failed, exit status 255
error: %trigger(redhat-lsb1.3-1) scriplet failed, exit status 255
rpmdb: /var/lib/rpm/Triggername: No such file or directory
rpmdb: /var/lib/rpm/Triggername: cannot sync: no such file or directory
error: db4 error(2) from dbenv->close: No such file or directory


Needless to say, trying step 2 did yield much other than:

Preparing:
 ########################################
############### [100%]
package glibc-2.3.2-11.9 is already
installed
rpmdb: /var/lib/rpm/Basenames: No such file or directory
rpmdb: /var/lib/rpm/Basenames: cannot sync: no such file or directory
error: db4 error(2) from dbenv->close: No such file or directory


I went to bugzilla, but I think my choice of keywords was probably pretty
poor.  "loop" and "login" yielded nothing, and "glibc" yielded a boat load,
but none seemed to apply.

Any other suggestions?

Thanks!!

Don











"Zenon Panoussis" <spamtrap@provocation.net> wrote in message
news:3fb511a0$0$58715$e4fe514c@news.xs4all.nl...
quote:

>
> Don wrote:
> 
>
> Try appending "init 3" to the grub root=... line and see if
> you can log in on the command line.
>
> If that doesn't work either, you probably have a messed-up
> glibc. The easiest way to recover is booting the installation
> CD/floppy with "linux rescue" and then running
>
> # rpm --root /mnt/sysimage --nodeps -e glibc
> # rpm --root /mnt/sysimage -hiv /path/to/glibc-{ver}.{arch}.rpm
>
> Make sure to install the right glibc for your architecture.
> Lots more on this subject at http://bugzilla.redhat.com
>
> Z
>

[ Post a follow-up to this message ]

Don wrote:
quote:

> Tried doing the glibc replace and got the following error after entering
> line 1:

quote:

> error:  postun(glibc-2.3.2-11.9) scriplet failed, exit status 255
> error: %trigger(redhat-lsb1.3-1) scriplet failed, exit status 255
> rpmdb: /var/lib/rpm/Triggername: No such file or directory
> rpmdb: /var/lib/rpm/Triggername: cannot sync: no such file or directory
> error: db4 error(2) from dbenv->close: No such file or directory


Did you really give --root /mnt/sysimage to your rpm command?
Did all your partitions get mounted by the rescue floppy? You
can check that by comparing the output of "df" to the contents
of /mnt/sysimage/etc/fstab . If they don't match, you should
mount the missing partitions manually. You do that with
# mount /dev/hd[xn] /mnt/sysimage/[mountdir]
where the first argument is identical to the device name in
fstab and the second argument is the mount point in fstab
prepended with "/mnt/sysimage". If your fstab uses labels
instead of partition names, use them too.

The bug I had in mind is
https://bugzilla.redhat.com/bugzill...ug.cgi?id=88456 .
It's a long but edifying reading, in more aspects than just
the technical.
quote:

> Any other suggestions?


Hm. Was there anything at all out of the ordinary with your
rh8.0 system? Did you make any non-default choices during
the upgrade (LDAP authentication and the like)? Did the
upgrade finish correctly?

I would boot again with the rescue floppy and read the log,
/mnt/sysimage/var/log/messages . The clue to what's happening
is most probably there, on or right after the time of the system
upgrade and the failed login attempts. Do also check
/mnt/sysimage/var/log/dmsg .

Does /mnt/sysimage/var/lib/rpm exist? If so, does ls -l return
something like
Basenames     __db.003  Installtid   Provideversion  Sha1header
Conflictname  Dirnames  Name         Pubkeys         Sigmd5
__db.001      Filemd5s  Packages     Requirename     Triggername
__db.002      Group     Providename  Requireversion
with reasonable file sizes (not 0 bytes)? If not, what do you
see in /mnt/sysimage/var/ and /mnt/sysimage/var/lib/ ?

The way to repair a ruined rpm database is to delete the files
that begin with double underscores, like __db.001, __db.002
and then do
# cd /mnt/sysimage
# chroot .
# rpm --rebuilddb
# ls -l /var/lib/rpm   (check you got fresh db files)
# exit
This would fix your rpm database in case it's ruined,
but leave you with the original problem. Depending on
whether you found previously unmounted partitions or
any other reasons why rpm failed the first time, you
might or might not want to rebuild the rpm database
and you might have to repeat the glibc upgrade procedure.
In any case, I would suggest that you don't start on any
of this until you know for sure what is causing your
login problem.

Z

[ Post a follow-up to this message ]