4

I'm using Opensuse 12.3.
systemd-195-13.45.1.x86_64

After few problems when I added a disc at btrfs mount I'm trying put my system in emergency mode (which I consider all services will be stopped and all mounts able to be unmounted),.

But they just don't work!!!

How to force systemd enter in emergency mode? (or something equivalent of init single mode) and force the emergency mode at boot time(grub menu)?

First attempt:
I use the old way : init 1 at the console...
They show me the emergency screen , ask for root password, but after this re-login, I still unable to unmount my btrfs FS (says it are in use). (with lsof I don't found anything using this mounts).
The runlevel command return level 3... not 1...

Second attempt:
I run the command systemctl emergency which show me the "emergency screen" , ask for root password... and then finally show me runlevel = 1 . But I'm still not able to umount my btrfs FS....

Third attempt:
I reboot the machine and at grub screen I type 'e' to add the "emergency" word at the options. Where they give me a message like "emergency word is invalid". I try with "single" word and get the same behave....


My final solution was remove the automatically mount from fstab and reboot my system at normal mode. Then finally I able to run my check at btrfs Fs... but is very annoying because all services which depends this mount start give errors...

  • 1
    check the system logs - init 1 is not working so there must be something serious going on. – suspectus Jan 7 '14 at 12:06
  • 2
    You haven't described the nature of the original problem. If the system can't unmount the disk for some kind of weird reason, it can't unmount the disk. Switching runlevels may be intended to try and do certain things, but emergency mode is not "automatically fix all my problems mode". So: you'd be better off asking a question describing your problems with the disk, not systemd, etc. – goldilocks Jan 7 '14 at 12:19
  • Hi @goldilocks, I don't want the emergency mode to "solve all problems", but as they own name says it's for emergency! Considering this I suppose they should be capable to force all services/process out to free any mount system... (at least, years ago the init 1 always solves this for me). Will be useful to know if the systemctl emergency should be attend situations like that (or I should use other mode?) and at any tip how to force it at next reboot and avoid at boot time anyone use the FS before I execute my stuffs... – ceinmart Jan 7 '14 at 13:32
2

There are 4 targets in systemd. what you wanted is emergency.target I think you can try these steps:

  1. reboot the system
  2. interrupt the boot loader menu countdown by pressing any key
  3. move the cursor the entry to be started
  4. press e to edit the current entry
  5. move the cursor tho the entry to the line that starts with linux16. This is the kernel command line.

6.append systemd.unit=desired.target

  1. press ctrl+x to boot with these changes.

This is rhel7's method . I think it is maybe similar with suse . Once you enter into emergency mode, root password is still needed. good luck:)

0

After read the comments of @suspectus and @goldilocks , although already "solve" my original problem with the btrfs, I tested again putting my system in emergency mode.

I considering have misunderstand the difference between emergency mode of systemd with single mode of SystemV.
But as I don't have sure about my answer and about my understand... so, I will not check my answer as correct for now.

The emergency mode, close and shutdown all services for good and not change the runlevel and not dismount any volume/FS.


About my root problem which trick my mind, where I think not entered in emergency mode berfore...

Discover I will not be capable to umount my FS because I need to umount it with systemctl command:

systemctl stop dados.mount

Where "dados" is my btrfs FS /dados. Then they dismount effectively.
The weird thing, there is no way to identify why the unmount command inform the FS is "in use" and nothing is showed at lsof command.
Probably some internal latch between the umount/systemd...

  • 1
    The "in use" error could also happen if there are sub-mounts under the btrfs mount point. Looking at man systemd.mount and man systemd, systemd might be handling that automatically. – sourcejedi Jun 28 '14 at 7:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.