LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Fedora (https://www.linuxquestions.org/questions/fedora-35/)
-   -   Destroyed my runlevel settings... (https://www.linuxquestions.org/questions/fedora-35/destroyed-my-runlevel-settings-4175492206/)

theCalcaholic 01-22-2014 04:50 PM

Destroyed my runlevel settings...
 
Hello,

I just destroyed my fedora installation by selecting an invalid runlevel...

I tried to select runlevel 3 but executed

Code:

ln -s /lib/systemd/system/multi-user.target.target /etc/systemd/system/default.target
instead of
Code:

ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
However it is still possible for me to access the filesystem from a live system allthough the fedora partition is encrypted; yet I do'nt know how to recover the runlevel.
If I knew in which file this setting is stored I could probably recover it...

So I appreciate your suggestions and help.

With regards, thecalcaholic

rknichols 01-22-2014 07:45 PM

It's just the symbolic link that you created in /etc/systemd/system/ . "ls -l /etc/systemd/system/default.target" will show it. Just remove the incorrect link and make the correct one.
Code:

# rm -i /etc/systemd/system/default.target
rm: remove symbolic link `/etc/systemd/system/default.target`? y
# ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target


theCalcaholic 01-25-2014 06:41 AM

Thank you! I guess this worked. But it wasn't the only thing that prevented Fedora from booting but also a misconfigured X Server...
Before this all happend I had tried to install the nvidia drivers together with bumblebee and it was necessary to reconfigure the X server until I could boot normally again.

For those who might have the same problem I will shortly outline how I was able to solve it. At first I followed rknichols suggestion and replaced the "default.target" - to point to a valid target (see post before how to do it).
Thereby it is to mention that since I ran the commands from a live system I had to adjust the paths a little bit.
At first I mounted the partition Fedora is installed to, using Nautilus (I don't know how to do the decryption from the shell). Than I looked up the path it was mounted to - per default this is "/run/media/<partition name>", in my case "/run/media/Fedora" if I remember it right.
Than I set the working directory in a shell instance to this path by doing
Code:

# cd /run/media/Fedora
Than I could execute the commands given by rknichols but had to remove the leading Slashes when manipulating the link (run/media/Fedora/etc/systemd/system/default.target), since this isn't an absolute path in the live system.

Code:

# rm -i etc/systemd/system/default.target
rm: remove symbolic link `etc/systemd/system/default.target`? y
# ln -s /lib/systemd/system/multi-user.target etc/systemd/system/default.target

After having done this I rebooted in text mode by pressing 'e' at grubs system selection screen and adding " 3" (without quotation marks) to the first line.
There the system did not fully start but after a plenty of tries I noticed that I was to able to switch to a console by pressing Ctrl + Alt + F2 (or any other F-Key except of F1) where I could login successfully and after executing 'startx' and rebooting the whole thing ran fine again. :)

rknichols 01-25-2014 09:27 AM

Quote:

Originally Posted by theCalcaholic (Post 5104932)
Than I could execute the commands given by rknichols but had to remove the leading Slashes, since this isn't an absolute path in the live system.

Code:

# rm -i etc/systemd/system/default.target
rm: remove symbolic link `etc/systemd/system/default.target`? y
# ln -s lib/systemd/system/multi-user.target etc/systemd/system/default.target


That is not a valid link. You need the leading "/" on that link target. At the time the symbolic like is being followed, the system is running with its real root directory. Furthermore, a relative link, like the one you write, is evaluated relative to the directory where the link is stored, so in this case systemd would be trying to open
Code:

/etc/systemd/system/lib/systemd/system/multi-user.target
which does not exist.

Your system boots because systemd is using its built-in default for the case where no valid default.target exists.

BTW, if you did want to write that as a relative symlink, the correct target would be
Code:

../../../lib/systemd/system/multi-user.target
I don't know of any good reason for doing that. The link is significant only in the running system, and there the absolute symlink is correct (and a lot more human-readable).

theCalcaholic 01-31-2014 05:32 PM

Quote:

Originally Posted by theCalcaholic View Post
Quote:

Than I could execute the commands given by rknichols but had to remove the leading Slashes, since this isn't an absolute path in the live system.

Code:

# rm -i etc/systemd/system/default.target
rm: remove symbolic link `etc/systemd/system/default.target`? y
# ln -s lib/systemd/system/multi-user.target etc/systemd/system/default.target


That is not a valid link. You need the leading "/" on that link target. At the time the symbolic like is being followed, the system is running with its real root directory. Furthermore, a relative link, like the one you write, is evaluated relative to the directory where the link is stored, so in this case systemd would be trying to open
Code:

Code:

/etc/systemd/system/lib/systemd/system/multi-user.target
which does not exist.
You're right, of course. I actually pointed to the absolute path when I created that link but failed to remember it when I wrote the whole thing down. I'll correct that.


All times are GMT -5. The time now is 09:20 PM.