我正在使用双启动笔记本电脑（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 和 Windows 之间或在通用和低延迟之间切换并没有给我带来任何麻烦。
然后，一天天地，我遇到了启动问题。更准确地说：当我启动低延迟内核时，启动会挂起约 8 分钟A start job is running for apparmor initalization。
我的一部分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 的情况下启动两个内核，然后发现：
只要我专门启动通用内核，就可以毫无问题地启用 apparmor。
当我启动启用 apparmor 的低延迟时，问题就开始了。
如果我在启动 lowlatency 之前禁用 apparmor，启动就不会挂起。
如果我启动 lowlatency 时启用了 apparmor，则启动不仅会在 lowlatency 上挂起，还会在紧接着的下一次通用启动时挂起。这是下一次通用启动后的 apparmor 状态：
只有再次重新启动通用内核后，启动和 apparmor 才会恢复正常。
我比较了
sudo apparmor_status后
低延迟启动故障
以下通用启动（也有故障）
常规重启（恢复正常）
无需在任何时候手动禁用 apparmor。
cups-browsed除和后面的数字外，这三份状态报告完全相同cupsd。以下是示例：[...] 2 processes are in enforce mode. /usr/sbin/cups-browsed (960) /usr/sbin/cupsd (951) [...]
更新：
在第一次 lowlatency-boot 出现故障后，我重新启动 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)当我在最后一步（成功重启之前有故障的低延迟启动）之后启动通用内核版本时，启动过程再次挂起，apparmor 无法初始化。以下是状态报告：
因此，底线是：每次我切换到其他内核版本时，启动都会挂起。但是从第一次重新启动同一个内核开始，一切都恢复正常。直到我切换回另一个内核（并且与离开正确启动的内核或有故障的内核无关）。
如果我禁用
apparmor，我可以以正常速度加载任何内核。这是我的 apparmor shell 脚本
/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 <[email protected]> # Kees Cook <[email protected]> # # /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 start-job？
我对 Linux 还很陌生，非常感谢任何提示。