Hi,
Just in case you get any other rash urges to exercise commands like that in Just remind yourself in future specifically to NEVER EVER exit a root shell after some desastrous action. Believe me, sooner or later you WILL have opportunity to use that advice. Use another terminal or ssh to verify that you have indeed rectified your mistake and can login as root. Sure. Ya, I have learnt my lesson. Thanks for the advice. I WILL not exit the root shell unitl I am sure that everything is Ok.
In that case you should be able to use the rescue cd to boot up, chroot to your original system and then use passwd to give root a password.
I did use the rescue CD. I don't understand this chroot thing. Can you elaborate on that a bit.
When you boot the rescue CD the root volume "/" used is from the cd. So any action you try to execute on /etc or /sbin will be executed on the cd files. The command chroot mounts another volume as the root volume. In this case you need to know which device on your hdd is the root volume, something like /dev/hda2 or /dev/sda3. So, you boot the rescue CD and thus you are root. Then you execute "chroot /dev/sd2" (or whatever YOUR root device is). Afterwards you have a running root shell and your normal filesystem is mounted. Then you should be able to run any root command you need. Ya, I did chroot to my filesystem on the hard disk. I booted in the Rescue mode. Then mounted my root partition /dev/sda1 to /new and chroot'd into /new and then gave passwd and gave a new passwd. It said passwd changed, but still no improvement. When I as user give su, it still gives the same error, i.e., $ su su: cannot set groups: Operation not permitted
Ya I did make a backup. But then I think the harm has already been done to the files before I made a backup.
If you have only changed the file permissions then the damage is not really significant. Many years ago I remember that I accidentally gzipped all the files in the /etc directory and I also panicked. Fortunately it was a test system with nothing installed yet. As I told in the first mail, I meddled with the passwd and shadow files before I made a backup. I deleted the x in root entry in /etc/passwd and made the root line look as root:::: in /etc/shadow. This I did from the rescue disk.
Anything else that can be done? Regards, Chaitanya. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Chaitanya Krishna A wrote:
Ya, I did chroot to my filesystem on the hard disk. I booted in the Rescue mode. Then mounted my root partition /dev/sda1 to /new and chroot'd into /new and then gave passwd and gave a new passwd. It said passwd changed, but still no improvement. When I as user give su, it still gives the same error, i.e., $ su su: cannot set groups: Operation not permitted
Ya I did make a backup. But then I think the harm has already been done to
the
files before I made a backup.
Another lesson learned. Make Backups BEFORE something bad happens. (^-^)
If you have only changed the file permissions then the damage is not really significant. Many years ago I remember that I accidentally gzipped all the files in the /etc directory and I also panicked. Fortunately it was a test system with nothing installed yet.
As I told in the first mail, I meddled with the passwd and shadow files before I made a backup. I deleted the x in root entry in /etc/passwd and made the root line look as root:::: in /etc/shadow. This I did from the rescue disk.
Anything else that can be done?
Sure, restore the root entry in etc/passwd. It should look like this: root:x:0:0:root:/root:/bin/bash When you deleted all entries you also deleted the UID/GID values, so naturally the system is a bit baffled when it tries to set UID and GID. (^-^) Sandy -- List replies only please! Please address PMs to: news-reply (@) japantest (.) homelinux (.) com
Hi, Finally I could create a new passwd for root and use login as root again. This is how I did it. 1. Use the rescue disk. Login as root 2. # mkdir mnt # mount /dev/sda1 mnt/ # chroot mnt # cp passwd.old passwd # cp shadow.old shadow # passwd New password:<new passwd for root> # /sbin/SuSEconfig 3. Exit and reboot the system Luckily someone here told me about the passwd.old and shadow.old files that the system maintains. They got me out of the mess. Unless you run SuSEconfig, the system doesn't give you the new root passwd. First I didn't know that I have to run SuSEconfig. Somewhere on the list recently I read that you have to run SuSEconfig after you install something, so I just ran SuSEconfig to if it would help. Thanks to everyone who helped me out. Francois, Dylan, Jerry and especially Sunny. Thanks for pointing out chroot guys. It also helped a lot. Regards, Chaitanya. __________________________________ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
participants (2)
-
Chaitanya Krishna A -
Sandy Drobic