Не запускается systemd linux
Обновлено: 06.07.2024
systemd offers users the ability to manage services under the user's control with a per-user systemd instance, enabling users to start, stop, enable, and disable their own user units. This is convenient for daemons and other services that are commonly run for a single user, such as mpd, or to perform automated tasks like fetching mail.
Contents
How it works
Similarly to system units, user units are located in the following directories (ordered by ascending precedence):
-
/usr/lib/systemd/user/ where units provided by installed packages belong.
- Be aware that the systemd --user instance is a per-user process, and not per-session. The rationale is that most resources handled by user services, like sockets or state files will be per-user (live on the user's home directory) and not per session. This means that all user services run outside of a session. As a consequence, programs that need to be run inside a session will probably break in user services. The way systemd handles user sessions is pretty much in flux. See [1] and [2] for some hints on where things are going.
- systemd --user runs as a separate process from the systemd --system process. User units can not reference or depend on system units or units of other users.
Basic setup
All the user units will be placed in
/.config/systemd/user/ . If you want to start units on first login, execute systemctl --user enable unit for any unit you want to be autostarted.
Tip: If you want to enable a unit for all users rather than the user executing the systemctl command, run systemctl --global enable unit as root. Similarly for disable .Environment variables
The user instance of systemd does not inherit any of the environment variables set in places like .bashrc etc. There are several ways to set environment variables for the systemd user instance:
-
For users with a $HOME directory, create a .conf file in the
One variable you may want to set is PATH .
After configuration, the command systemctl --user show-environment can be used to verify that the values are correct.
Service example
Create the drop-in directory /etc/systemd/system/user@.service.d/ and inside create a file that has the extension .conf (e.g. local.conf ):
DISPLAY and XAUTHORITY
DISPLAY is used by any X application to know which display to use and XAUTHORITY to provide a path to the user's .Xauthority file and thus the cookie needed to access the X server. If you plan on launching X applications from systemd units, these variables need to be set. Systemd provides a script in /etc/X11/xinit/xinitrc.d/50-systemd-user.sh to import those variables into the systemd user session on X launch. [3] So unless you start X in a nonstandard way, user services should be aware of the DISPLAY and XAUTHORITY .
If you customize your PATH and plan on launching applications that make use of it from systemd units, you should make sure the modified PATH is set on the systemd environment. Assuming you set your PATH in .bash_profile , the best way to make systemd aware of your modified PATH is by adding the following to .bash_profile after the PATH variable is set:
Note that this will not affect systemd services started before PATH is imported.
pam_environment
Automatic start-up of systemd user instances
The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. Use the following command to enable lingering for specific user:
Warning: systemd services are not sessions, they run outside of logind. Do not use lingering to enable automatic login as it will break the session.Writing user units
Example
The following is an example of a user version of the mpd service:
Example with variables
The following is an example of a user version of sickbeard.service , which takes into account variable home directories where SickBeard can find certain files:
As detailed in systemd.unit(5) , the %h variable is replaced by the home directory of the user running the service. There are other variables that can be taken into account in the systemd manpages.
Reading the journal
The journal for the user can be read using the analogous command:
To specify a unit, one can use
Note that journald will not write user journals for users with UIDs below 1000, instead directing everything to the system journal.
Temporary files
/.local/share/user-tmpfiles.d/ , in that order. For this functionality to be used, it is needed to enable the necessary systemd user units for your user:
The syntax of the configuration files is the same than those used system-wide. See the systemd-tmpfiles(8) and tmpfiles.d(5) man pages for details.
Xorg and systemd
This article or section needs expansion.
There are several ways to run xorg within systemd units. Below there are two options, either by starting a new user session with an xorg process, or by launching xorg from a systemd user service.
Automatic login into Xorg without display manager
The factual accuracy of this article or section is disputed.
Reason: This setup ends up with two user D-Bus buses, one for the desktop, and an other for systemd. Why cannot we use the systemd one alone? (Discuss in Talk:Systemd/User)This option will launch a system unit that will start a user session with an xorg server and then run the usual
The session will use its own dbus daemon, but various systemd utilities will automatically connect to the dbus.service instance. Finally, enable the xlogin@username service for automatic login at boot. The user session lives entirely inside a systemd scope and everything in the user session should work just fine.
Xorg as a systemd user service
Alternatively, xorg can be run from within a systemd user service. This is nice since other X-related units can be made to depend on xorg, etc, but on the other hand, it has some drawbacks explained below.
xorg-server provides integration with systemd in two ways:
- Can be run unprivileged, delegating device management to logind (see Hans de Goede commits around this commit).
- Can be made into a socket activated service (see this commit). This removes the need for systemd-xorg-launch-helper-gitAUR .
Unfortunately, to be able to run xorg in unprivileged mode, it needs to run inside a session. So, right now the handicap of running xorg as user service is that it must be run with root privileges (like before 1.16), and cannot take advantage of the unprivileged mode introduced in 1.16.
Note: This is not a fundamental restriction imposed by logind, but the reason seems to be that xorg needs to know which session to take over, and right now it gets this information calling logind's GetSessionByPID using its own pid as argument. See this thread and xorg sources. It seems likely that xorg could be modified to get the session from the tty it is attaching to, and then it could run unprivileged from a user service outside a session. Warning: On xorg 1.18 socket activation seems to be broken. The client triggering the activation deadlocks. See the upstream bug report [5]. As a temporary workaround you can start the xorg server without socket activation, making sure the clients connect after a delay, so the server is fully started. There seems to be no nice mechanism to get a startup notification for the X server.This is how to launch xorg from a user service:
1. Make xorg run with root privileges for any user, by editing /etc/X11/Xwrapper.config
2. Add the following units to
where $ is the virtual terminal where xorg will be launched, either hard-coded in the service unit, or set in the systemd environment with
Note: xorg should be launched at the same virtual terminal where the user logged in. Otherwise logind will consider the session inactive.3. Make sure to configure the DISPLAY environment variable as explained above.
4. Then, to enable socket activation for xorg on display 0 and tty 2 one would do:
Now running any X application will launch xorg on virtual terminal 2 automatically.
The environment variable XDG_VTNR can be set in the systemd environment from .bash_profile , and then one could start any X application, including a window manager, as a systemd unit that depends on xorg@0.socket .
Warning: Currently running a window manager as a user service means it runs outside of a session with the problems this may bring: break the session. However, it seems that systemd developers intend to make something like this possible. See [6] and [7]X clients as a user service
This section is being considered for removal.
Reason: ArchWiki is not a code patching platform. (Discuss in Talk:Systemd/User)With an adapted version of sx , one can easily have all the X clients running as a user service while leaving Xorg, the server, running in a session unprivileged.
First, put a copy of /usr/bin/sx under /usr/local/bin/ . The copy can be named e.g. sdsx so that the original sx can remain accessible.
The caveat of this approach is that, if for some reason not a single X client succeeded in reaching the server, the server will need to be killed from another tty manually. Also, if e.g. xrdb needs to be run in sxrc , it will now need to be run with the option -retain . See Xserver(1) and xrdb(1) for details.
One of the use cases and/or advantages of this approach is that the X clients will now be running under the user manager ( user@$uid.service ) and snippet (i.e. systemctl edit ) applied to it (e.g. NetworkNamespacePath= ) will also be applied to the programs running in the graphical environment (including but not limited to the command-line shells running in an terminal emulator).
Some use cases
Persistent terminal multiplexer
This article or section is out of date.
Reason: References user-session@.service instead of user@.service ; the latter does not contain Conflicts=getty@tty1.service . (Discuss in Talk:Systemd/User)You may wish your user session to default to running a terminal multiplexer, such as GNU Screen or Tmux, in the background rather than logging you into a window manager session. Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in with myStuff.target).
To create this type of user session, procede as above, but instead of creating wm.target, create multiplexer.target:
cruft.target , like mystuff.target above, should start anything you think should run before tmux or screen starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.
You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to /tmp/gpg-agent-info . This sample session, when you start X, will also be able to run X programs, since DISPLAY is set.
Once this is done, systemctl --user enable tmux.service , multiplexer.target and any services you created to be run by cruft.target and you should be set to go! Activated user-session@.service as described above, but be sure to remove the Conflicts=getty@tty1.service from user-session@.service , since your user session will not be taking over a TTY. Congratulations! You have a running terminal multiplexer and some other useful programs ready to start at boot!
Window manager
Note: The [Install] section includes a WantedBy part. When using systemctl --user enable it will link this as/.config/systemd/user/wm.target.wants/window_manager.service , allowing it to be started at login. Is recommended to enable this service, not to link it manually.
Kill user processes on logout
Arch Linux builds the systemd package with --without-kill-user-processes , setting KillUserProcesses to no by default. This setting causes user processes not to be killed when the user logs out. To change this behavior in order to have all user processes killed on the user's logout, set KillUserProcesses=yes in /etc/systemd/logind.conf .
Note that changing this setting breaks terminal multiplexers such as tmux and GNU Screen. If you change this setting, you can still use a terminal multiplexer by using systemd-run as follows:
For example, to run screen you would do:
Using systemd-run will keep the process running after logout only while the user is logged in at least once somewhere else in the system and user@.service is still running.
Troubleshooting
Runtime directory '/run/user/1000' is not owned by UID 1000, as it should
If you see errors such as this and your login session is broken, it is possible that another system (non-user) service on your system is creating this folder. This can happen for example if you use a docker container that has a bind mount to /run/user/1000 . To fix this, you can either fix the container by removing the mount, or disable/delay the docker service.
error while loading shared libraries: librt.so.1: cannot open shared object file Permission denied
Mar 26 20:08:16 localhost systemd-networkd[216]: /usr/lib/systemd/systemd-networkd: error while loading shared libraries: librt.so.1: cannot open shared object file: Permission denied Mar 26 20:08:16 localhost systemd[1]: systemd-networkd.service: main process exited, code=exited, status=127/n/a Mar 26 20:08:16 localhost systemd[1]: Failed to start Network Service. Mar 26 20:08:16 localhost systemd[1]: Unit systemd-networkd.service entered failed state. Mar 26 20:08:16 localhost systemd[1]: systemd-networkd.service has no holdoff time, scheduling restart. Mar 26 20:08:16 localhost systemd[1]: Stopping Network Service. Mar 26 20:08:16 localhost systemd[1]: Starting Network Service. Mar 26 20:08:16 localhost systemd[1]: systemd-networkd.service start request repeated too quickly, refusing to start. Mar 26 20:08:16 localhost systemd[1]: Failed to start Network Service. Mar 26 20:08:16 localhost systemd[1]: Unit systemd-networkd.service entered failed state.
Права в дирректории:
-rwxr-xr-x 1 root root 173312 Mar 26 23:33 librt-2.19.so -rwxr-xr-x 1 root root 339784 Mar 26 23:33 librt.a -rwxr-xr-x 1 root root 384838 Mar 26 23:33 librt_pic.a -rwxr-xr-x 1 root root 871 Mar 26 23:33 librt_pic.map lrwxrwxrwx 1 root root 10 Mar 26 23:33 librt.so -> librt.so.1 lrwxrwxrwx 1 root root 13 Mar 26 23:33 librt.so.1 -> librt-2.19.so
Если напрямую запустить исполняемый файл /usr/lib/systemd/systemd-networkd Сеть отлично запускается
Это он при старте системы не хочет работать или даже если его отдельно запускать?
Отдельно. уже при загружённой системе
А дистрибутив какой? systemd вот только обновился, может быть что-то сломали если не в нём самом, то в пакете.
lampslave
systemd-212, arch x86_64, УМВР.
Надо плотнее смотреть в разрешения. SELinux используется?
Тогда можно зайти с другой стороны и проверить, не были ли он сломан раньше :) ТС ведь не указал ни версию, ни дистрибутив.
Или может быть параллельно какой-нибудь network-manager запущен и они между собой эту либу никак не поделят?
Дистрибутив самописный. Systemd из git скомпилен. Network manager и в помине нету.
Можно ли отключить X во время загрузки? Я настраиваю сервер, поэтому было бы неплохо, если бы он не загружал графический интерфейс при каждой загрузке.
На экране входа в систему GDM от 11.04 и более ранних, я думаю, была опция сеанса xterm, которая просто выдаст вам командную строку. В качестве альтернативы вы можете получить что-то из опции восстановления в GRUB, хотя, вероятно, вы не сможете установить это значение по умолчанию таким образом. Спасибо. Итак, как мне остановить загрузку LightDM при загрузке?Редактируйте /etc/default/grub с вашим любимым редактором, например nano :
Найдите эту строку:
Измените это на:
Для систем, которые используют systemd
Это дополнительный шаг для системных выпусков, например, Ubuntu 15.04, все еще необходимы шаги, описанные выше для grub.
Вы должны сказать, systemd чтобы не загружать графический менеджер входа в систему:
Вы по-прежнему сможете использовать X, набрав startx после входа в систему.
Это работает для lightdm, это работает для любого графического менеджера входа в систему? Это правильный способ загрузки системы Linux без загрузки X-сервера? Просто кажется более логичным? Выберите один . :) Любой графический менеджер входа в систему? Вместо этого это решение привязано к grub, который не используется (или даже недоступен) на новых мобильных платформах, где работает Ubuntu, а отключение службы не зависит от загрузчика. Надлежащим образом ? Факт не упоминается. Более логично? Ингибирование определенной службы не является логически параметром времени загрузки. Но вы все еще как-то правы из-за другого факта: ваше решение не только блокирует lightdm, но и plymouth (на шаге initrd и других), поэтому его семантика заключается не в «отключении X», а в «отключении любой графической настройки», и это требует возни Конфигурация загрузчика. Спасибо ! Поскольку вопрос задан для Ubuntu, а не для мобильной платформы (можете ли вы что-нибудь изменить в мобильной версии Ubuntu? Почему это было бы хорошо? Я предполагаю, что вы будете заблокированы в подсказке, которая ничего не знает о вводе с клавиатуры и принимает причудливые прикосновения пальцев и жесты: P) Я предполагаю, что мы говорим об Ubuntu, настольной операционной системе на базе Linux, которую я люблю и могу изменять в соответствии со своими потребностями. :) Но вы правы, есть проблема семантики с заголовком поста, не стесняйтесь редактировать его как-нибудь более правильно! Спасибо за комментарии. @Joyce сначала запустится, systemctl get-default чтобы узнать, каково текущее имя уровня запуска и запомните его имя, затем используйте его, systemctl set-default multi-user.target чтобы изменить его на «multi-user.target», или вместо этого запустите эти команды равенства и посмотрите изменения. rm '/etc/systemd/system/default.target' тогда ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target' . Если проблема все еще существует, верните уровень запуска по умолчанию, через который вы его запомните systemctl set-default RunLevelName .Установка графического интерфейса, вероятно, приведет к его автоматическому запуску, но в Ubuntu очень легко загружаться в текстовом режиме. Просто откройте /etc/default/grub как root и добавьте text в
линия. Затем запустите:
Ваша система всегда будет загружаться в текстовом режиме.
Если вы хотите загрузиться с GUI, просто нажмите e в меню загрузки и удалите text из kernel строки.
Если вы хотите запустить графический интерфейс после загрузки, просто запустите:
Надеюсь это поможет :)
Ubuntu 11.10 не использует gdm в качестве диспетчера входа в систему по @hhlp: исправлено. В последнем обновлении Lightdm задание upstart учитывает команду text cmdline ядра. @AshRj: Да, это действительно для всех версий Ubuntu, использующих upstart :)Если вы хотите загрузиться в текстовом режиме:
Редактировать /etc/default/grub . Например:
Найдите эту строку:
Затем обновите Grub:
Примечание. При удалении quiet splash (то есть GRUB_CMDLINE_LINUX_DEFAULT="" ) во время загрузки будет отображаться текст, а затем будет отображаться графический экран входа в систему, как обычно. Замена quiet splash на text оставит вас в приглашении входа в систему; чтобы начать сеанс GNOME, используйте sudo /etc/init.d/gdm start или startx .
Чтобы отключить GDM:
Установите Bum .
После установки он будет найден в Системе >> Администрирование >> Bootup-Manager
Снимите флажок Диспетчер отображения Gnome
Конфиг GRUB работал. Из любопытства, зачем мне отключать GDM? Подтверждено в 13.04, что GRUB_CMDLINE_LINUX_DEFAULT="" работает, чтобы показать детали во время загрузки, все еще при запуске графического входа в систему.Если вы используете lightdm в качестве менеджера входа в систему, его можно отключить, отключив его.
Вы можете использовать переопределение:
И запустить lightdm по команде:
Чтобы восстановить вашу систему так, чтобы lightdm всегда запускался при загрузке:
Для получения дополнительной информации, выскочка поваренная книга ваш друг:
Он уже ответил на несколько старых вопросов, но не может найти их сейчас, поэтому я суммирую различные ситуации здесь.
Чтобы остановить запущенный X-сервер startx , просто прекратите сеанс.
Чтобы остановить X-сервер, запущенный диспетчером входа в систему (GDM), запустите
затем перейдите к tty , например, нажав Ctrl - Alt - F1 , затем войдите в систему в текстовом режиме.
Чтобы вообще не запускать Менеджер входа в систему (и X), измените
затем обновите файл конфигурации grub с помощью
так что в следующий раз вы перейдете непосредственно в текстовый режим, и вам нужно startx будет начать сеанс X, или в качестве альтернативы sudo service gdm start .
Я сделал следующее
Шаг 1 Сначала обновите ваш репозиторий, запустив
sudo apt-get update
Шаг 2 В старой версии lightdm есть какая-то ошибка, поэтому мы должны обновить ее. Для этого беги,
sudo apt-get install lightdm
Шаг 3 Теперь нам нужно изменить конфигурацию grub. Шаг 3а Откройте в /etc/default/grub вашем любимом редакторе и измените
Шаг 3b Также прокомментируйте GRUB_HIDDEN_TIMEOUT = 0 Эта строка предназначена для скрытия меню GRUB.
Шаг 4 Теперь мы обновим конфигурацию GRUB.
Шаг 5 Ubuntu 11.10 Desktop Edition использует lightdm для графического интерфейса. Нам нужно отключить то же самое
sudo update-rc.d -f lightdm remove
Шаг 6 Теперь перезагрузите компьютер.
Да, сказать системе, чтобы она запускалась в консоли во время загрузки, можно путем редактирования команды grub. Когда вы достигнете меню grub, выделите запись Ubuntu и нажмите e .
Вы увидите текст, как на изображении ниже:
Изменить текст тихий всплеск на текст . Нажмите F10 для запуска. (Источник: Rolling-Ubuntu ). Я проверил это на своей системе, 14.04, загрузился в текстовую консоль, lightdm не видно. Начал Lightdm с sudo initctl start lightdm
Чтобы избежать этого каждый раз, вы можете добавить постоянную запись grub с такой опцией, как предложено в этом ответе.
Альтернативное предложение состоит в том, чтобы изменить уровень запуска по умолчанию и изменить уровни запуска, при которых lightdm запускается / останавливается, как это было предложено в другом ответе на этот же пост.
Ubuntu 18.04 Live ISO по-прежнему запускает Xorg независимо от text варианта. Вместо этого, указание уровня запуска, просто 3 вместо text , заставляет его работать. Кредит идет на этот ответ . @Ruslan Полезная информация, спасибо. Мой ответ на самом деле предназначен только для настольных компьютеров и был опубликован в 2015 году, когда был выпущен 14.04. Я тестировал это на Live ISO настольной версии Ubuntu 18.04. Ничто не требует сервера или других выпусков, чтобы эта 3 опция работала (и text чтобы не работала, что случилось со мной).Я заметил, что этот поток вращается вокруг предположения, что вы используете LightDM в качестве диспетчера дисплеев. Хотя это может быть обычный DM / welcomer, это не является частью первоначального вопроса. (И он не уточнил ..)
Я использую KDE / KDM на моем сервере. Вместо этого я просто отключаю запуск / сервис upstart под уровнем запуска 2:
/etc/init/kdm.conf : (kdm: 4: 4.8.5-0ubuntu0.3, версия Upstart: 1.5-0ubuntu7.2)
Предполагая, что при новой перезагрузке ваш уровень запуска по умолчанию равен 2, у вас будет консоль, а не KDM. Затем вы можете запустить DM / DE вручную, когда это необходимо = используйте 'startx' / etc. Чтобы вернуть машину в консоль и полностью выйти из X-сервера после этого, просто используйте «Выйти».
Другие сценарии dm .confs аналогичны. (Я настраиваю свой сервер следующим образом . чтобы иногда работать с графическим интерфейсом, но не тянуть ресурсы, когда они не используются / не нужны или просто перезагружаются.)
РЕДАКТИРОВАТЬ
(Моя текущая система: Upstart 1.12.1 / Ubuntu 14.04)
В связи с выскочкой способ решить эту проблему в последнее время заключается в простом отключении диспетчера отображения от запуска при загрузке:
эхо "ручной" | sudo tee -a / etc / init / .override
Это может быть любая служба в / etc / init, включая kdm / gdm. 'startx' для запуска по мере необходимости после перезагрузки.
Понимание процедуры загрузки в Linux RHEL7/CentOS
Следующие шаги суммируют, как процедура загрузки происходит в Linux.
1. Выполнение POST: машина включена. Из системного ПО, которым может быть UEFI или классический BIOS, выполняется самотестирование при включении питания (POST) и аппаратное обеспечение, необходимое для запуска инициализации системы.
2. Выбор загрузочного устройства: В загрузочной прошивке UEFI или в основной загрузочной записи находится загрузочное устройство.
3. Загрузка загрузчика: с загрузочного устройства находится загрузчик. На Red Hat/CentOS это обычно GRUB 2.
4. Загрузка ядра: Загрузчик может представить пользователю меню загрузки или может быть настроен на автоматический запуск Linux по умолчанию. Для загрузки Linux ядро загружается вместе с initramfs . Initramfs содержит модули ядра для всего оборудования, которое требуется для загрузки, а также начальные сценарии, необходимые для перехода к следующему этапу загрузки. На RHEL 7/CentOS initramfs содержит полную операционную систему (которая может использоваться для устранения неполадок).
5. Запуск /sbin/init: Как только ядро загружено в память, загружается первый из всех процессов, но все еще из initramfs . Это процесс /sbin/init , который связан с systemd . Демон udev также загружается для дальнейшей инициализации оборудования. Все это все еще происходит из образа initramfs .
6. Обработка initrd.target: процесс systemd выполняет все юниты из initrd.target , который подготавливает минимальную операционную среду, в которой корневая файловая система на диске монтируется в каталог /sysroot . На данный момент загружено достаточно, чтобы перейти к установке системы, которая была записана на жесткий диск.
7. Переключение на корневую файловую систему: система переключается на корневую файловую систему, которая находится на диске, и в этот момент может также загрузить процесс systemd с диска.
8. Запуск цели по умолчанию (default target): Systemd ищет цель по умолчанию для выполнения и запускает все свои юниты. В этом процессе отображается экран входа в систему, и пользователь может проходить аутентификацию. Обратите внимание, что приглашение к входу в систему может быть запрошено до успешной загрузки всех файлов модуля systemd . Таким образом, просмотр приглашения на вход в систему не обязательно означает, что сервер еще полностью функционирует.
На каждом из перечисленных этапов могут возникнуть проблемы из-за неправильной настройки или других проблем. Таблица суммирует, где настроена определенная фаза и что вы можете сделать, чтобы устранить неполадки, если что-то пойдет не так.
Передача аргементов в GRUB 2 ядру во время загрузки
Если сервер не загружается нормально, приглашение загрузки GRUB предлагает удобный способ остановить процедуру загрузки и передать конкретные параметры ядру во время загрузки. В этой части вы узнаете, как получить доступ к приглашению к загрузке и как передать конкретные аргументы загрузки ядру во время загрузки.
Когда сервер загружается, вы кратко видите меню GRUB 2. Смотри быстро, потому что это будет длиться всего несколько секунд. В этом загрузочном меню вы можете ввести e, чтобы войти в режим, в котором вы можете редактировать команды, или c, чтобы ввести полную командную строку GRUB.
После передачи e в загрузочное меню GRUB вы увидите интерфейс, показанный на скриншоте ниже. В этом интерфейсе прокрутите вниз, чтобы найти раздел, начинающийся с linux16 /vmlinuz , за которым следует множество аргументов. Это строка, которая сообщает GRUB, как запустить ядро, и по умолчанию это выглядит так:
После ввода параметров загрузки, которые вы хотите использовать, нажмите Ctrl + X, чтобы запустить ядро с этими параметрами. Обратите внимание, что эти параметры используются только один раз и не являются постоянными. Чтобы сделать их постоянными, вы должны изменить содержимое файла конфигурации /etc/default/grub и использовать grub2-mkconfig -o /boot/grub2/grub.cfg , чтобы применить изменение.
Когда у вас возникли проблемы, у вас есть несколько вариантов (целей), которые вы можете ввести в приглашении загрузки GRUB:
■ rd.break Это останавливает процедуру загрузки, пока она еще находится в стадии initramfs .
Эта опция полезна, если у вас нет пароля root.
■ init=/bin/sh или init=/bin/bash Указывает, что оболочка должна быть запущена сразу после загрузки ядра и initrd . Это полезный вариант, но не лучший, потому что в некоторых случаях вы потеряете консольный доступ или пропустите другие функции.
■ systemd.unit=rescue.target Команда запускает еще несколько системных юнитов, чтобы привести вас в более полный рабочий режим. Требуется пароль root.
Чтобы увидеть, что загружено только очень ограниченное количество юнит-файлов, вы можете ввести команду systemctl list-units .
Запуск целей(targets) устранения неполадок в Linux
1. (Пере)загружаем Linux. Когда отобразиться меню GRUB, нажимаем e ;
2. Находим строку, которая начинается на linux16 /vmlinuz. В конце строки вводим systemd.unit=rescue.target и удаляем rhgb quit ;
3. Жмем Ctrl+X, чтобы начать загрузку с этими параметрами. Вводим пароль от root;
4. Вводим systemctl list-units и смотрим. Будут показаны все юнит-файлы, которые загружены в данный момент и соответственно загружена базовая системная среда;
5. Вводим systemctl show-environment . Видим переменные окружения в режиме rescue.target;
6. Перезагружаемся reboot ;
7. Когда отобразится меню GRUB, нажимаем e . Находим строку, которая начинается на linux16 /vmlinuz. В конце строки вводим systemd.unit=emergency.target и удаляем rhgb quit ;
8. Снова вводим пароль от root;
9. Система загрузилась в режиме emergency.target;
10. Вводим systemctl list-units и видим, что загрузился самый минимум из юнит-файлов.
Устранение неполадок с помощью загрузочного диска Linux
Еще один способ восстановления работоспособности Linux использовать образ операционки.
Если вам повезет меньше, вы увидите мигающий курсор в системе, которая вообще не загружается. Если это произойдет, вам нужен аварийный диск. Образ восстановления по умолчанию для Linux находится на установочном диске. При загрузке с установочного диска вы увидите пункт меню "Troubleshooting". Выберите этот пункт, чтобы получить доступ к параметрам, необходимым для ремонта машины.
- Install CentOS 7 in Basic Graphics Mode: эта опция переустанавливает систему. Не используйте её, если не хотите устранить неполадки в ситуации, когда обычная установка не работает и вам необходим базовый графический режим. Как правило, вам никогда не нужно использовать эту опцию для устранения неисправностей при установке.
- Rescue a CentOS System: это самая гибкая система спасения. Это должен быть первый вариант выбора при использовании аварийного диска.
- Run a Memory Test: если вы столкнулись с ошибками памяти, это позволяет пометить плохие микросхемы памяти, чтобы ваша машина могла нормально загружаться.
- Boot from local drive: здесь я думаю всё понятно.
Пример использования "Rescue a CentOS System"
1. Перезагружаем сервер с установочным диском Centos 7. Загружаемся и выбираем "Troubleshooting".
2. В меню траблшутинга выбираем "Rescue a CentOS System" и загружаемся.
3. Система восстановления теперь предлагает вам найти установленную систему Linux и смонтировать ее в /mnt/sysimage . Выберите номер 1, чтобы продолжить:
4. Если была найдена правильная установка CentOS, вам будет предложено, чтобы система была смонтирована в /mnt/sysimage . В этот момент вы можете дважды нажать Enter, чтобы получить доступ к оболочке восстановления.
5. Ваша система Linux на данный момент доступна через каталог /mnt/sysimage . Введите chroot /mnt/sysimage . На этом этапе у вас есть доступ к корневой файловой системе, и вы можете получить доступ ко всем инструментам, которые необходимы для восстановления доступа к вашей системе.
Переустановка GRUB с помощью аварийного диска
Одна из распространенных причин, по которой вам нужно запустить аварийный диск, заключается в том, что загрузчик GRUB 2 не работает. Если это произойдет, вам может понадобиться установить его снова. После того, как вы восстановили доступ к своему серверу с помощью аварийного диска, переустановить GRUB 2 несложно, и он состоит из двух этапов:
- Убедитесь, что вы поместили содержимое каталога /mnt/sysimage в текущую рабочую среду.
- Используйте команду grub2-install , а затем имя устройства, на котором вы хотите переустановить GRUB 2. Если это виртуальная машина KVM используйте команду grub2-install /dev/vda и на физическом сервере или виртуальная машина VMware, HyperV или Virtual Box, это grub2-install /dev/sda .
Повторное создание Initramfs с помощью аварийного диска
Иногда initramfs также может быть поврежден. Если это произойдет, вы не сможете загрузить свой сервер в нормальном рабочем режиме. Чтобы восстановить образ initramfs после загрузки в среду восстановления, вы можете использовать команду dracut . Если используется без аргументов, эта команда создает новый initramfs для загруженного в данный момент ядра.
Кроме того, вы можете использовать команду dracut с несколькими опциями для создания initramfs для конкретных сред ядра. Существует также файл конфигурации с именем /etc/dracut.conf , который можно использовать для включения определенных параметров при повторном создании initramfs .
- /usr/lib/dracut/dracut.conf.d/*.conf содержит системные файлы конфигурации по умолчанию.
- /etc/dracut.conf.d содержит пользовательские файлы конфигурации dracut.
- /etc/dracut.conf используется в качестве основного файла конфигурации.
Исправление общих проблем
В пределах статьи, подобной этой, невозможно рассмотреть все возможные проблемы, с которыми можно столкнуться при работе с Linux. Однако есть некоторые проблемы, которые встречаются чаще, чем другие. Ниже некоторые наиболее распространенные проблемы.
Переустановка GRUB 2
Код загрузчика не исчезает просто так, но иногда может случиться, что загрузочный код GRUB 2 будет поврежден. В этом случае вам лучше знать, как переустановить GRUB 2. Точный подход зависит от того, находится ли ваш сервер в загрузочном состоянии. Если это так, то довольно просто переустановить GRUB 2. Просто введите grub2-install и имя устройства, на которое вы хотите его установить. У команды есть много различных опций для точной настройки того, что именно будет установлено, но вам, вероятно, они не понадобятся, потому что по умолчанию команда устанавливает все необходимое, чтобы ваша система снова загрузилась. Становится немного сложнее, если ваш сервер не загружается.Если это произойдет, вам сначала нужно запустить систему восстановления и восстановить доступ к вашему серверу из системы восстановления. После монтирования файловых систем вашего сервера в /mnt/sysimage и использования chroot /mnt/sysimage , чтобы сделать смонтированный образ системы вашим корневым образом: Просто запустите grub2-install , чтобы установить GRUB 2 на желаемое установочное устройство. Но если вы находитесь на виртуальной машине KVM, запустите grub2-install /dev/vda , а если вы находитесь на физическом диске, запустите grub2-install /dev/sda .
Исправление Initramfs
В редких случаях может случиться так, что initramfs будет поврежден. Если вы тщательно проанализируете процедуру загрузки, вы узнаете, что у вас есть проблема с initramfs , потому что вы никогда не увидите, как корневая файловая система монтируется в корневой каталог, и при этом вы не увидите запуска каких-либо системных модулей. Если вы подозреваете, что у вас есть проблема с initramfs , ее легко создать заново. Чтобы воссоздать его, используя все настройки по умолчанию (что в большинстве случаев нормально), вы можете просто запустить команду dracut --force . (Без --force команда откажется перезаписать ваши существующие initramfs .)
При запуске команды dracut вы можете использовать файл конфигурации /etc/dracut.conf , чтобы указать, что именно записывается в initramfs . В этом файле конфигурации вы можете увидеть такие параметры, как lvmconf = «no» , которые можно использовать для включения или выключения определенных функций. Используйте эти параметры, чтобы убедиться, что у вас есть все необходимые функции в initramfs .
Восстановление после проблем с файловой системой
Читайте также: