Solved Changed wrong Shell, I cannot login anymore

Hello, Daemons.

I have a VPS machine on Amazon EC2.

I changed my default shell for root user (chsh) to "csh", but I accidentally indicated wrong directory: /usr/local/bin/csh

Now, when I try login into "root" with "su", I receive the error: su: /usr/local/bin/csh: No such file or directory

I dont have sudo installed yet.
My user is in wheel group. How can I login with root now?

Thanks in advance,
Grether
 
Another possibility: Use su -m root to retain the same shell as your lower level account, while gaining root privileges. Then use those root privileges to fix your default root shell. I believe that would work, although I can't say for sure since I've never tried it with a buggered root account.
 
After the kernel is loaded but before the /etc/rc scripts are started you need to drop into a recovery shell.
I think that one is hardcoded to /bin/csh.
I assume there is a loader delay during which you can do it ?
 
Go back in time with a backup, remotely mount the filesystem and modify the password file/db, send a request to their tech-support that you automaticly drop in multi-user and that you need single-user boot for recovery purposes ?
 
dd_ff_bb, I have a VPS machine on AWS EC2.
I haven't access to BOOT to select the Single Mode.
Don't know about AWS, but other cloud services have a console you can access, for example via a web application. Look for some documentation for that. I know that on my cloud-hosted machine, there is a (virtual) keyboard, mouse and VGA, all accessible over the web.
 
Don't know about AWS, but other cloud services have a console you can access, for example via a web application. Look for some documentation for that. I know that on my cloud-hosted machine, there is a (virtual) keyboard, mouse and VGA, all accessible over the web.
Thanks for your reply. I have console access via web application.
But I can't control boot options. I needed to change rc.conf to control BOOT and some startup options, but only root can perform this.

I will try to restore from a last backup, attach old Volume and make the changes, so after, attach as root Volume again.
 

SirDice

Administrator
Staff member
Administrator
Moderator
There's usually no "console" access with these cloud providers. The idea here is that you just throw away the image and spawn a new one if there are problems, you don't fix them the 'traditional way' by logging into them.
 
Don't know about AWS, Azure provides the "cli" root access from web. Commands are executed via python scripts, i.e. its tools. Maybe there's something similar there too?
But no console access, or rather limited access via serial console, is on Azure too. Official way of troubleshooting the VM then is to deploy 2nd VM, attach boot disk there and troubleshoot.
 
Hello guys,

Thank you for the suggestions, the problem is solved.

I created another FreeBSD VPC instance, and attached the Old Volume as a non-root volume.
After mounted the Old Volume (/mnt), I changed /mnt/boot/loader.conf:
autoboot_delay="-1" (default on FreeBSD image) --> autoboot_delay="3"

I umounted the Old Volume, Dettached and Attached it again as a Root Volume.
After theses changes, the Serial Console shows me the boot menu.

I entered in single mode, and changed the root shell. It worked.

Thanks all for the suggestions and help.
 
While you had the old disk mounted there already you could have changed the shell. FYI it seems AWS does have the cli interface. Assuming you're using tools inside the VM you can use that too in the future.
 
_martin, how can I change shell (securely) of a non-root volume?
The AWS Cli don't allow me perform this action. Differ from others instances (like Linux), FreeBSD is a Image outside from AWS, a third party Image provided by FreeBSD Project, via AWS Marketplace. The support from this AMI image is a little limited.
 
You can either manually edit the files ( /mnt/etc/passwd, /mnt/etc/master.passwd ) or chroot and modify as usual, i.e.
Code:
chroot /mnt
chsh -s /bin/csh root
exit
With the former approach you should be ok with fixing just passwd and running pwd_mkdb(8) after you boot it up. It doesn't hurt to run the cmd after just in case anyway.
Normally you should not edit it this way but it's not a normal situation when you're fixing stuff like this.

Right, without guest aws-tools you can't do it.
 
_martin, thanks.

Chrooted is a good idea. I didn't tried it.
My first atempt was to change /etc/passwd manually, but after this, FreeBSD not booting with error "secondary gpt table is corrupt or invalid".

I hope that I dont have similar problem again, but if I have, I will try chroot.

Thanks for suggestion and knowledge.
 
Invalid GPT header, especially secondary one, sounds like disk was recently expanded and gpart recover was not yet executed on it. Modifying files within partition would not cause this error.
Np,yw.
 
Top