depscan.sh/bootup freezes?

[chiatello]

ok when i bootup everything goes normal until it says



*Caching service dependencies...



then it just freezes


been trying to fix this for a while now, and i still cant figure it out

any help would be appreciated

[chiatello]

bump anyeone?

[peabody124]

i left my computer doing an emerge -e world last night and this morning it was locked up. i rebooted and got this problem.

also booting with init=/bin/bash gives a shell, but after running most commands or things like ls, the shell never returns after the function executes. interestingly this doesn't happen for cd.

i'll post any solutions i find. anyone guru's know what could cause a bash shell to not be returned too?

[peabody124]

ok, ask i hinted at in the last post, it is actually a problem with bash. There is a previous post where the author suggests downgrading a number of packages to get bash back to version 2, but I didn't want to do that and 2 doesn't seem to compile with more recent packages.

if you boot and from grub or lilo edit your boot profile to have init=/bin/bash at the end, this will bring you to a command prompt where you have once command before you have to reboot. if you have tcsh or something use that and it will function fine.

the solution i used was simply emerge -e bash. I also started an emerge -e system which didn't complete, so I can't gurantee that didn't help. The service dependencies script is just the first in the boot process that runs through the bash interepreter instead of #!/usr/bin/runscript

good luck!

[davolunteer]

I too recently experienced this problem -- boot sequence hangs at:

* Caching service dependencies

This occurred after performing an emerge for all of the kde-3.3 stuff. My problem turned out to have been that the emerge was started on one machine and I rebooted that system via ssh from another location after the emerge had completed. I suspect that I missed some "advice" from the emerge output, i.e., "You should run env-update" or something to that effect. At any rate, I rebooted from the remote location and the system was stuck as described above.

After much consternation, searching and cursing, I explored the possibility that my problem was related to the fact that I am using LDAP for auth as well as nis stuff. I temporarily corrected this by booting from the installation CD (actually, I tried booting from the installation CD several times and never could get "ls -l" and various other commands to behave correctly after chrooting to the problem system) and saving my LDAP flavor of /etc/nsswitch.conf before restoring the original file-based /etc/nsswitch.conf. I was then able to chroot to the target system and successfully executed env-update. I then restored the saved LDAP version of my nsswitch.conf and rebooted the system without any trouble.

One thing I learned is that it sure would be nice if I knew where to find any needed cleanup instructions output by emerge -- other than on the console as they whiz by!