I read about the benefits of running shell scripts in another shell then bash so I installed dash. Then I tried to link /bin/sh to dash instead of bash. I do not have a good understanding of linking but thought copying such a command wouldn’t lead to problems. I seem to have something wrong and made an invalid link (maybe linking to itself?). When I turn on my computer and try to start openSuse, it says it can not find a shell. I am stuck in some kind of command line but the only thing I can do is fill in my user name and passwords, if I do that, it tells me I have no mail.
I think chrooting in from a usb is the way to solve this (I have done this ones before after misconfiguring grub) but don’t know how to solve the problem with the (symbolic) links.
I would truly appreciate any help.
Twijg
I do not think that script written for one interpreter will run very well on a different interpreter. Even if both are shells and thus probably related. Some shells differ more from others then some others, but I would never take the chance.
Linking the default shell to something different is of course a recipe for disaster. Every script in the system that wants the default shell will now be treated by a different program (when the link points to another shell if you intended) or not run at all (when your link failed for some reason).
I think your best approach is a rescue boot, mount the / file system of the broken system and undo the link.
When you get to that point, try entering “root” for the user name and the root password. Then chances are that will get you in with a root command line, where you can fix the problem.
You probably need to then do:
cd /bin
rm sh
ln -s bash sh
I looked at “dash” in Yast Software Management.
What you did ought to have worked, since “dash” is supposed to be a posix compliant implementation of “sh”.
I am not at all surprised that it did not work. But that should be considered a bug. It indicates that too many bashisms have crept into the system. It indicates that there are scripts that ought to start with “#! /bin/bash” but have either omitted that line or used “#! /bin/sh” instead.
Or perhaps there are bashisms in “/etc/profile”.
Hmm, maybe I should experiment with that. But it might work for me, because I use “csh” as my shell.
Thanks for your reply, I’ll try to do that.
I too thought that all bash dependent scripts would have specified bash as shell instead of using the sh. The problem could also be a wrong linkage of mine. If I can make it work again, I’ll try again to use dash as standard shell, hopefully that will work, if not, I’ll just keep using bash for everything.
Before posting, I had checked with a Tumbleweed system. But the system that I checked was last updated a week ago.
I have since checked another system, one that has been more recently update. And the shell setup has changed.
Now “/bin/sh” is a link to “/usr/bin/sh”. And “sh” has now been put under control of update-alternatives. You can probably fix it with
update-alternatives --config sh
which should tell you that something is wrong and that it is fixing it.
Follow that with
cd /bin
rm sh
ln -s ../usr/bin/sh .
And then check with:
ls -lL /bin/sh /bin/bash
Those should both give the same date and file size since they should both be links to the same file.
I may experiment with “dash”. I installed it, but “update-alternatives” does not see it as an alternative for “sh”. Perhaps the recent changes are a work in progress.
An update.
I installed “dash” (in an up-to-date Tumbleweed)
I then did:
cd /usr/bin
rm sh
ln -s dash sh
And I rebooted to see what happened.
Things were mostly fine. I tried with GDM and then with SDDM. Either way, I could get into a GUI session without a problem.
I also tried login with a different user who has “/bin/sh” as a shell. And that also went fine.
I did see one problem. During booting, I got an error:
[FAILED] Failed to start Apply settings from /etc/sysconfig/keyboard.
So there’s probably a bashism somewhere in that startup file.
I then reverted “sh” to using “bash”, and rebooted. That failure did not show up. It only shows up when using “dash”.
I tried the solutions and they didn’t work, the command
update-alternatives --config sh
complains about not having an alternative.
After trying to continue nevertheless and rebooting, I get the same error (problem with symbolic links) as before.
Can you at least show what you have now?
ls -l /bin/sh
Lets see if we can get everything the way that it should be.
This is from Tumbleweed, as updated today:
% cd /usr/bin
% ls -l sh
lrwxrwxrwx 1 root root 20 Aug 4 12:21 sh -> /etc/alternatives/sh
% cd /etc/alternatives
% ls -l sh
lrwxrwxrwx 1 root root 13 Aug 4 12:21 sh -> /usr/bin/bash
% cd /bin
twleap:rickert 6% ls -l sh
lrwxrwxrwx 1 root root 13 Aug 2 06:21 sh -> ../usr/bin/sh
You can check what you get. The dates might be different, because the date on a symlink is probably the date when that link was made.
The first two of those (for “/usr/bin” and for “/etc/alternatives”) are probably correct on your system. When you tried that “update-alternatives” command, it should have fixed those after complaining that they were broken.
The last one (for “/bin”) is probably still broken.
You can fix (as root) with:
cd /bin
rm sh
ln -s ../usr/bin/sh sh
I have a feeling I didn’t in fact successfully chrooted last time, I get this after trying to chroot, I probably also got that last time but didn’t notice:
# chroot /mnt
chroot: failed to run command ‘/bin/bash’: Too many levels of symbolic links
You probably created a loop of symlinks, like A links to B, B links to C and C links to A (or only A links to B and B links to A).
You can fix this without “chroot”.
Mount your system at “/mnt”
cd /mnt/bin
rm sh
ln -s ../usr/bin/sh sh
If you need to also fix “/usr/bin” then
cd /mnt/usr/bin
rm sh
ln -s /etc/alternatives/sh sh
Or it might be safer to try
cd /mnt/usr/bin
rm sh
ln -s bash sh
You can then fix “/etc/alternatives” after rebooting into the system.
I did these two:
It did not work. It is getting late where I am so I am going to bed, if you’ve got any more ideas about what to do, I will be very grateful for them. If nothing works, I will be reinstalling next week, after my exam (to not spend too much time on linux instead of studying).
I’m working in the dark, because I don’t know what you actually did.
Mount the root partition at “/mnt”
Then give us the output from:
ls -l /mnt/bin/sh
ls -l /mnt/usr/bin/sh
ls -l /mnt/bin/bash
ls -l /mnt/usr/bin/bash
Just a reminder,
If you want to undo your mistakes on the root partition (or volume) and your installation is default which would mean your filesystem is BTRFS, you can simply use Snapper to roll back to a date before your mistakes were made. And, if for whatever reason you wanted to roll even that back, since rollbacks always move you forward, you can even undo that as well.
TSU
But does he need a working shell to be able to roll back?
It is solved! After running the ls’s (
ls -l /mnt/bin/sh
ls -l /mnt/usr/bin/sh
ls -l /mnt/bin/bash
ls -l /mnt/usr/bin/bash
)
It was clear that /mnt/usr/bin/bash en /mnt/bin/bash where referring to each other. To solve that, I replaced /mnt/usr/bin/bash whith /usr/bin/bash from the live USB.
Upon rebooting (because I was to eager to reboot, I forgot to press send on the message with the output), everything (except the wifi but has always been a problem with my chip) worked though I think there were some more errors while booting.
Thanks a lot to everyone who helped, I am really thankful for al the answers I got so quickly.
I’m glad you have it working.
In the past, I have accidently created symlink loops, though not with bash. It’s an easy mistake to make.
Here’s a suggestion. I suggest that you now reinstall bash (forced reinstall). You can do that with Yast Software Management – tell it to do an unconditional update. That should put everything back to how it originally was (everything that is part of “bash”).
I already reinstalled it with *zypper in -f bash.
*I’ll just make my scripts use !/bin/dash instead of !/bin/sh to not have problems with bashismes from other people’s scripts.