Определение причин, по которым процесс загрузки зависает: «Запускается задание запуска для инициализации apparmor» - proUbuntu
0 голосов
/

Я использую ноутбук с двойной загрузкой (Ubuntu 18.04.3LTS и WIN). Он имеет чип i3-5010U с графикой Intel HD5500. Так как я использую Ubuntu как для обычного настольного компьютера, так и для аудио (Cadence, Catia, Carla, Calf), я запускаю свою систему через Grub на стандартном ядре 5.0.0-31 или на низкой скорости 4.15.0-65. В качестве аудиоинтерфейса я использую звуковую карту USB (Scarlett Focusrite).

Раньше она работала как шарм. И переключение между Ubuntu и Win или между generic и lowlatency не доставляло мне никаких проблем.

Затем, изо дня в день, я сталкивался с проблемами при загрузке. Точнее: при загрузке ядра с низкой задержкой загрузка зависает на ~ 8 минут. на «Запускается задание запуска для инициализации устройства».

часть моего boot.log

Когда наконец появляется рабочий стол, система не смогла инициализироватьсяapparmor.

systemctl status apparmor.service

возвращает это

И запуск sudo apparmor_status возвращает:

apparmor module is loaded.
39 profiles are loaded.
37 profiles are in enforce mode.
   /sbin/dhclient
   /snap/core/7917/usr/lib/snapd/snap-confine
   /snap/core/7917/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/bin/evince
   /usr/bin/evince-previewer
   /usr/bin/evince-previewer//sanitized_helper
   /usr/bin/evince-thumbnailer
   /usr/bin/evince//sanitized_helper
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/ippusbxd
   /usr/sbin/tcpdump
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   man_filter
   man_groff
   snap-update-ns.core
   snap-update-ns.gmail-desktop
   snap-update-ns.gnome-calculator
   snap-update-ns.gnome-characters
   snap-update-ns.gnome-logs
   snap-update-ns.gnome-system-monitor
   snap.core.hook.configure
   snap.gmail-desktop.gmail-desktop
   snap.gnome-calculator.gnome-calculator
   snap.gnome-characters.gnome-characters
   snap.gnome-logs.gnome-logs
   snap.gnome-system-monitor.gnome-system-monitor
2 profiles are in complain mode.
   libreoffice-oopslash
   libreoffice-soffice
2 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/cups-browsed (960) 
   /usr/sbin/cupsd (951) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Затем я поиграл с загрузкой обоих ядер с apparmorвключил и отключил и обнаружил:

1.) Пока я загружаю исключительно универсальное ядро, я могу без проблем включать apparmor.

2.) Проблемы начинаются, как только янизкая загрузка при включенном apparmor.

3.) Если я отключу apparmor перед загрузкой lowlatency, загрузка не зависнет.

4.) Если я загрузлю lowlatency с включенным apparmor, загрузка будетзависать не только на lowlatency, но и на следующей следующей общей загрузке. Это статус устройства после следующей общей загрузки . Только после перезагрузки обычного ядра еще раз загрузка и аппарат вернулись к нормальной работе.

Я сравнил выходные данные

sudo apparmor_status

после

  • неисправный загрузчик с низкой загрузкой

  • следующая общая загрузка (также неисправная)

  • общая перезагрузка (снова нормальная)

без ручного отключения apparmor в любой точке.

Все три отчета о состоянии абсолютно одинаковы, за исключением чисел, следующих за cups-browsed и cupsd. Вот пример:

[...]
2 processes are in enforce mode.
   /usr/sbin/cups-browsed (960) 
   /usr/sbin/cupsd (951) 
[...]

Обновление:

5.) Когда я перезагружаю lowlatency после неудачной первой загрузки lowlatency, все снова в порядке. Обычная загрузка с инициализацией apparmor. Единственное, что я заметил, это немного другой вывод «sudo apparmor_service», который теперь имеет 3 процесса с определенными профилями и 3 в принудительном режиме, где все остальные до сих пор имели 2 и 2:

3 processes have profiles defined.
3 processes are in enforce mode.
   /sbin/dhclient (1432) 
   /usr/sbin/cups-browsed (937) 
   /usr/sbin/cupsd (867) 

6. ) Когда я загружаю стандартную версию ядра после 5.) (успешная перезагрузка предшествующей ошибочной загрузки с низкой загрузкой), процесс загрузки снова зависает, и apparmor не может инициализироваться. Вот отчеты о состоянии:

apparmor.service

apparmor_service

Итак, в нижней строке: загрузка висит каждый разЯ переключаюсь на другую версию ядра. Но с первой перезагрузки того же ядра снова все в порядке. До тех пор, пока я не переключусь обратно на другое ядро ​​(независимо от того, оставило ли оно правильно загруженное или неисправное ядро).

Если я отключу apparmor, я могу загрузить любое ядро ​​с нормальной скоростью.

Это мой сценарий оболочки apparmor в /etc/init.d:

#!/bin/sh
# ----------------------------------------------------------------------
#    Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
#     NOVELL (All rights reserved)
#    Copyright (c) 2008, 2009 Canonical, Ltd.
#
#    This program is free software; you can redistribute it and/or
#    modify it under the terms of version 2 of the GNU General Public
#    License published by the Free Software Foundation.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program; if not, contact Novell, Inc.
# ----------------------------------------------------------------------
# Authors:
#  Steve Beattie <steve.beattie@canonical.com>
#  Kees Cook <kees@ubuntu.com>
#
# /etc/init.d/apparmor
#
### BEGIN INIT INFO
# Provides: apparmor
# Required-Start: $local_fs
# Required-Stop: umountfs
# Default-Start: S
# Default-Stop:
# Short-Description: AppArmor initialization
# Description: AppArmor init script. This script loads all AppArmor profiles.
### END INIT INFO

. /lib/apparmor/functions
. /lib/lsb/init-functions

usage() {
    echo "Usage: $0 {start|stop|restart|reload|force-reload|status|recache}"
}

test -x ${PARSER} || exit 0 # by debian policy
# LSM is built-in, so it is either there or not enabled for this boot
test -d /sys/module/apparmor || exit 0

securityfs() {
    # Need securityfs for any mode
    if [ ! -d "${AA_SFS}" ]; then
        if cut -d" " -f2,3 /proc/mounts | grep -q "^${SECURITYFS} securityfs"'$' ; then
            log_action_msg "AppArmor not available as kernel LSM."
            log_end_msg 1
            exit 1
        else
            log_action_begin_msg "Mounting securityfs on ${SECURITYFS}"
            if ! mount -t securityfs none "${SECURITYFS}"; then
                log_action_end_msg 1
                log_end_msg 1
                exit 1
            fi
        fi
    fi
    if [ ! -w "$AA_SFS"/.load ]; then
        log_action_msg "Insufficient privileges to change profiles."
        log_end_msg 1
        exit 1
    fi
}

# Allow "recache" even when running on the liveCD
if [ "$1" = "recache" ]; then
    log_daemon_msg "Recaching AppArmor profiles"
    recache_profiles
    rc=$?
    log_end_msg "$rc"
    exit $rc
fi

# do not perform start/stop/reload actions when running from liveCD
test -d /rofs/etc/apparmor.d && exit 0

rc=255
case "$1" in
    start)
        if [ -x /usr/bin/systemd-detect-virt ] && \
           systemd-detect-virt --quiet --container && \
           ! is_container_with_internal_policy; then
            log_daemon_msg "Not starting AppArmor in container"
            log_end_msg 0
            exit 0
        fi
        log_daemon_msg "Starting AppArmor profiles"
        securityfs
        load_configured_profiles
        rc=$?
        log_end_msg "$rc"
        ;;
    stop)
        log_daemon_msg "Clearing AppArmor profiles cache"
        clear_cache
        rc=$?
        log_end_msg "$rc"
        cat >&2 <<EOM
All profile caches have been cleared, but no profiles have been unloaded.
Unloading profiles will leave already running processes permanently
unconfined, which can lead to unexpected situations.

To set a process to complain mode, use the command line tool
'aa-complain'. To really tear down all profiles, run the init script
with the 'teardown' option."
EOM
        ;;
    teardown)
        if [ -x /usr/bin/systemd-detect-virt ] && \
           systemd-detect-virt --quiet --container && \
           ! is_container_with_internal_policy; then
            log_daemon_msg "Not tearing down AppArmor in container"
            log_end_msg 0
            exit 0
        fi
        log_daemon_msg "Unloading AppArmor profiles"
        securityfs
        running_profile_names | while read profile; do
            if ! unload_profile "$profile" ; then
                log_end_msg 1
                exit 1
            fi
        done
        rc=0
        log_end_msg $rc
        ;;
    restart|reload|force-reload)
        if [ -x /usr/bin/systemd-detect-virt ] && \
           systemd-detect-virt --quiet --container && \
           ! is_container_with_internal_policy; then
            log_daemon_msg "Not reloading AppArmor in container"
            log_end_msg 0
            exit 0
        fi
        log_daemon_msg "Reloading AppArmor profiles"
        securityfs
        clear_cache
        load_configured_profiles
        rc=$?

        log_end_msg "$rc"
        ;;
    status)
        securityfs
        if [ -x /usr/sbin/aa-status ]; then
            aa-status --verbose
        else
            cat "$AA_SFS"/profiles
        fi
        rc=$?
        ;;
    *)
        usage
        rc=1
        ;;
    esac
exit $rc

Кто-нибудь знает, что я могу сделать, чтобы определить, что заставляет мой процесс загрузки зависать при запуске apparmor?

Я довольно новичок в Linux, и любая подсказка очень ценится.

...