16.04: медленная загрузка независимо от того, что я удаляю или делаю (предоставлены файлы для анализа)

Я очень разочарован тем, что мой ноутбук загружается с тех пор, как я установил Ubuntu.

До Ubuntu у меня был Kubuntu 15.04, который загружался с Grub на рабочий стол менее чем за 20 секунд. Я переключился на Ubuntu (64-битную версию), потому что слышал, что это быстрее. Пока все намного хуже. С аутологином это занимает 55 секунд. Без, я получаю от Grub до моего экрана входа в систему за 35 секунд. Затем после ввода моего пароля и нажатия клавиши ВВОД требуется еще 21 секунда для отображения рабочего стола.

Также следует отметить, что во время загрузки отсутствует фиолетовый экран или всплеск логотипа Ubuntu с прокручивающимися точками.

Когда я нахожусь на рабочем столе, все работает хорошо и быстро. Он спит и возобновляет нормально и т.д. Это только загрузка, которая касается меня. Поскольку у меня система с двойной загрузкой, я, как правило, перезагружаюсь в Windows 10, чтобы сделать определенные вещи. Загрузка в Win10 очень быстрая, но загрузка в Ubuntu занимает слишком много времени.

Я использую тот же раздел, что и раньше (который я отформатировал для новой установки Ubuntu).

Я использую systemd-analyze выяснить, что вызывает задержки. До сих пор я пробовал следующее:

• Обновил ядро ​​до 4.6
• Отключен сервис NetworkManager-wait-online
• Отключенный сервис Samba-ad-dc
• Отключенный сервис smbd
• Отключенный mnbd сервис
• Отключенный и неустановленный прибор
• Отключенный общий сервис

Вот экран, который я вижу между меню Grub и экраном входа в систему:

Я знаю, что это fsck и он появляется сразу после меню Grub. Я также осознаю, что, поскольку это происходит сразу, на самом деле это не занимает много времени. Но этот экран я вижу, пока не появится экран входа в систему. Нет заставки с прокручивающимися точками внизу, нет фиолетового экрана.

Вот ссылка на мой вывод dmesg

Мой dmesg почему-то идет только до 25 секунд.

Кроме того, я подготовил свой ботинок с systemd-analyze plot > file.svg и в конечном итоге времена, которые не имеют смысла. И на самом деле, график идет только до 20 секунд, но у меня появляется окно входа в систему намного дольше. Вот мой вывод (я связал изображение вместо того, чтобы публиковать его из-за размера изображения):

системный анализ выходных данных

Выход из systemd-analyze blame (ниже)

Выход из systemd-analyze critical-chain (ниже)

Вот вывод fdisk -l (ниже)

Как я уже говорил, я использую те же разделы, что и раньше (sdb6 для /, sdb3 для /home, sdb5 для подкачки). Они были отформатированы. Так что я не знаю, почему это могло произойти.

sda - это SSD-накопитель, sdb - это механический 1 ТБ-накопитель.

Остальная часть моего оборудования:

Ноутбук HP DV7. Процессор Intel i7, 8 ГБ оперативной памяти, графика AMD Radeon HD 7960M XT (двойное переключение с графикой Intel).

Я работал над этим некоторое время, надеюсь, мое копание показывает это, и я мог бы действительно использовать некоторую помощь здесь. Я предоставлю любые другие результаты, которые вам нужны.

Заранее спасибо!

ОБНОВИТЬ

Я пытался загрузиться с network-manager отключен и не было никакой разницы во времени загрузки. По какой-то причине networking.service все еще показывает в списке вины.

Вот мой системный анализ обвинений и критических цепочек выводов:

ОСУЖДЕНИЕ

  8.410s networking.service
  7.267s ModemManager.service
  7.138s accounts-daemon.service
  5.327s systemd-logind.service
  4.939s alsa-restore.service
  4.595s systemd-user-sessions.service
  4.166s dev-sdb6.device
  3.683s loadcpufreq.service
  3.455s apport.service
  3.353s ondemand.service
  3.261s cpufreqd.service
  2.063s gpu-manager.service
  1.643s polkitd.service
  1.508s rsyslog.service
  1.322s lm-sensors.service
  1.224s lightdm.service
  1.144s plymouth-start.service
  1.026s systemd-modules-load.service
  1.005s thermald.service
   918ms systemd-tmpfiles-setup-dev.service
   907ms avahi-daemon.service
   772ms systemd-journald.service
   534ms upower.service

Критическая цепь

graphical.target @16.982s
└─multi-user.target @16.982s
  └─cpufrequtils.service @16.976s +5ms
    └─loadcpufreq.service @13.268s +3.683s
      └─basic.target @8.324s
        └─sockets.target @8.324s
          └─avahi-daemon.socket @8.324s
            └─sysinit.target @8.230s
              └─systemd-update-utmp.service @8.102s +127ms
                └─systemd-tmpfiles-setup.service @7.768s +333ms
                  └─local-fs.target @7.767s
                    └─home.mount @7.704s +63ms
                      └─systemd-fsck@dev-disk-by\x2duuid-e715a619\x2de892\x2d40dc\x2dbc17\x2d235e98e3ffe6.service @7.180s +463ms
                        └─dev-disk-by\x2duuid-e715a619\x2de892\x2d40dc\x2dbc17\x2d235e98e3ffe6.device @7.167s

ОБНОВЛЕНИЕ 2

После стольких отключений и удаления множества приложений я все равно никуда не денусь. Однако сейчас я думаю, что это может быть проблемой с DM или DE... Но просмотр всех журналов пока что никуда не ведет.