updated > rebooted > "Welcome to rescue mode!"

English Install/Boot/Login
1

Hello.
All was good on my opensuse 13.1 system.
The software updater did its thing. I rebooted and now… dead!
on boot I get “Welcome to rescue mode!” (never seen before!)

I can put in a password for root and I can see a bunch of stuff in journalctl-xb but I dont see any flags.

Where is this file located and how can I get it so that I can do a pastebin?

If I put in a password for root and then do “systemctl default” it seems to hang at the green gecko screen!..it stays there if I hit escape I only get a blinking “_” in the upper right of the screen, if I hit escape again it goes back to the green gecko.

is there a way to undo the last update?
if on a reboot I go to advanced I see the following:
openSUSE 13.1, with linux 3.11.10-11-desktop
openSUSE 13.1, with linux 3.11.10-11-desktop (recovery mode)
openSUSE 13.1, with linux 3.11.10-7-desktop
openSUSE 13.1, with linux 3.11.10-7-desktop (recovery mode)

all of them seem to do the same thing… take me to rescue mode

please help…
qu1nn

2

unless others chime in …
i had a similar thing happen today

but it was a " not found" error about selinux.so.1
and the / partition would not mount during boot

odd thing it SE is used on my Scientificlinux 6.5 install ( second drive)

now this was a experimental dist upgrade from 12.3 to 13.1 ( yes not recommended )

i had to reformat /boot and / then reinstall

repairing it worked until i UPDATED again
then the same error
so a reinstall

one of the Mods around here might know a different way
me , i do not

3

I had the same issue no matter how hard I tried
to install 13.1 the bootloader woudnt finish installing
and so i had to install 13.2, the graphical installer
looked newer and more polished to me and it did
the job, now i’m running 13.2 factory and i added the
debug repositories in case something happens i can
send in debug reports. So far so good 13.2 factory
seems really good and I do not need to fiddle with
repositories just have the 13.2 ones because I saw
on anouther forum the only command that is the safest
is Zypper dup, because the is the cutting-bleeding edge
and i might break stuff if i try to install old stuff into new
stuff, SO my recommendation is install 13.2 if you need
it because it seems really running good so far for me.

4

13.2 is a long way from being ready
Expect bigger issues

5

Well, the system goes to rescue mode if some necessary service cannot be started.
You can see the last updates with “rpm -qa --last | less” f.e., or in YaST->Software Management->Extra->History.

The latest official update was an update to systemd, but that only added necessary additional permissions for nvidia cards.

Can you post the last lines before you go into rescue mode maybe?

I don’t see how the latest official updates should cause something like this, so please post your repo list:

zypper lr -d

Try to run this in rescue mode:

systemctl --failed

This should show you what failed.

Maybe /var/log/boot.log or /var/log/messages would tell more as well.

The message is about libselinux.so.1 not found, and this library is needed even if you do not use SELinux, because basic system programs are linked against it like libmount, udev and systemd.
So no wonder that your system doesn’t boot without it.

now this was a experimental dist upgrade from 12.3 to 13.1 ( yes not recommended )

A dist upgrade from 12.3 to 13.1 should work fine, and is actually supported. But you should make sure your 12.3 system has all updates installed before you do that.

But I hope you do realize that your problem is completely different from the OP’s?
So better open a new thread about your problem.

But it seems that your initrd is somehow corrupted and missing that libselinux. Check that there’s enough space on your /boot partition for an additional kernel and initrd which get installed by the updates.

6

On 2014-06-20 04:56, qu1nn wrote:

> Where is this file located and how can I get it so that I can do a
> pastebin?

It is a binary file, so you can not paste that easily, and if you, it is
not easy for anybody else to peruse it. Further, by default in openSUSE
the journal lives in a ram disk.

So you have to use commands to display the corresponding text and post that.

Besides that, do what wolfi323 advised.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

7

The only reason system goes in rescue mode is when some filesystem could not be mounted. At least in standard configuration as shipped with openSUSE.

8

Well, a filesystem mount is a “service” (a systemd unit actually) as well, isn’t it?

And I thought there might be other services/units as well that might cause rescue mode when they cannot be started.

But I just tried to specify an invalid partition to mount in /etc/fstab, and the system tried to switch to emergency mode, not rescue mode.
And it failed to do so because of a bug you might be aware of… :wink: (endlessly printing “Welcome to emergency mode…” on and on without ever presenting a prompt)

So when exactly does systemd enter rescue mode then? The OP clearly stated he sees “Welcome to rescue mode!”.

Anyway, I still think “systemctl --failed” should tell what failed, even if it’s a failed mount. Or not?

9

Sorry, I used them interchangeably. What do you call “rescue mode” then?

10

I don’t know what’s the difference, but systemd has a “rescue mode” and an “emergency mode”.

Again, the OP clearly states he sees the words “Welcome to rescue mode!”, whereas after a failed mount the words “Welcome to emergency mode!” appear (at least in my test).
And there is indeed /usr/lib/systemd/system/rescue.target and /usr/lib/systemd/system/emergency.target.

And even Debugging speaks of both distinctively:

Booting into Rescue or Emergency Targets
To boot directly into rescue target add systemd.unit=rescue.target or just 1 to the kernel command line. This target is useful if the problem occurs somewhere after the basic system is brought up, during the starting of “normal” services. If this is the case, you should be able to disable the bad service from here. If the rescue target will not boot either, the more minimal emergency target might.

To boot directly into emergency shell add systemd.unit=emergency.target or emergency to the kernel command line. Note that in the emergency shell you will have to remount the root filesystem read-write by yourself before editing any files:

So rescue.target is equivalent to runlevel1, and actually runlevel1.target is only a symlink to rescue.target.
Whereas emergency.target is even more minimal.

Which gives me an idea: maybe just the default target is set wrong?
@OP, can you please post the output of:

systemctl get-default

This would of course also explain why “systemctl default” did not work either (see the original post).

Try “systemctl isolate graphical.target” or “init 5” instead.

11

sorry for the late response; long day working/running around:
thanks for all the responses.

when I do systemctl get-default
I get the following response:

runlevel1.target

when I do
systemctl isolate graphical.target
or
init 5

the screen toggles to the black green gecco and then returns to “Welcome to rescue mode! …”

12

http://www.picpaste.com/20140620_zypper_snapshot-fq2G1TcR.png

13

On 2014-06-21 03:26, qu1nn wrote:
>
> wolfi323;2649811 Wrote:

> Code:
> --------------------
> > > zypper lr -d
> --------------------
>>>
>>
>>
> ’
> http://www.picpaste.com/20140620_zypper_snapshot-fq2G1TcR.png’

Although the full URL on the right hand side of the screen can not be
seen, I believe your repo list is correct.

But wolfi323 guessed right, your default target is set wrong. You just
have to change it, I think.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

14

http://www.picpaste.com/20140620_systemctl_--failed-ixILHRSC.png

this looks like it could be the culprit.

15

what should the default target be?

16

On 2014-06-21 04:06, qu1nn wrote:

>> But wolfi323 guessed right, your default target is set wrong. You just
>> have to change it, I think.
>>
>
> what should the default target be?

Typically, the graphical target. Not mine, though:


Telcontar:~ # systemctl get-default
runlevel3.target
Telcontar:~ #

which is intentional.

Hint: If there is a “get-default”, there probably is a “set-default”…

Hint 2: Have a look on the directory “/etc/systemd/system/”, you will
see the default target somewhere, and where it is defined, and where all
the possible targets are defined, so that you can choose one. So you can
find that there is a “graphical.target”, a “runlevel5.target”, a
“rescue.target”…

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

17

On 2014-06-21 03:56, qu1nn wrote:

> http://www.picpaste.com/20140620_systemctl_--failed-ixILHRSC.png
>
> this looks like it could be the culprit.

No, I think that one is irrelevant.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

18

I dont mean to be thick, but I am unclear of what to do next.

http://www.picpaste.com/20140621_etc_systemd_system-9p2WE95H.png

I am guessing that i have to set to the graphical.target.wants ?
which would be done with
systemctl set-default graphical.target.wants ???

thanks for your assistance

19

Ah, right, I mixed them up. Thank you!

20

Boot, try to switch to run level 5 as you did and after that upload to susepaste.org output of “journalctl -b” and /var/log/Xorg.0.log. This will hopefully show what fails.