|
Home > Archive > Red Hat Configuration > January 2004 > Re: Login Infinite Loop After RH 8.0 -> 9 Upgrade
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Login Infinite Loop After RH 8.0 -> 9 Upgrade
|
|
|
| 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
>
| |
| Zenon Panoussis 2004-01-23, 7:20 pm |
|
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
| |
| Zenon Panoussis 2004-01-23, 7:21 pm |
|
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
| |
| Zenon Panoussis 2004-01-23, 7:21 pm |
|
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
| |
|
|
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
>
| |
|
|
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
>
| |
|
|
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
>
| |
|
| 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
>
| |
|
| 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
>
| |
| Zenon Panoussis 2004-01-23, 7:23 pm |
|
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
| |
| Zenon Panoussis 2004-01-23, 7:23 pm |
|
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
| |
|
|
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
>
| |
|
|
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
>
| |
|
| 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
>
| |
| Zenon Panoussis 2004-01-23, 7:26 pm |
|
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
| |
|
|
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
>
|
|
|
|
|