Я очень разочарован тем, что мой ноутбук загружается с тех пор, как я установил Ubuntu.
До Ubuntu у меня был Kubuntu 15.04, который загружался с Grub на рабочий стол менее чем за 20 секунд. Я переключился на Ubuntu (64-битную версию), потому что слышал, что это быстрее. Пока все намного хуже. С аутологином это занимает 55 секунд. Без, я получаю от Grub до моего экрана входа в систему в течение 35 секунд. Затем, после ввода моего пароля и нажатия клавиши ВВОД, для отображения рабочего стола требуется еще 21 секунда.
Также следует отметить, что во время загрузки вообще не отображается фиолетовый экран или заставка Ubuntu с прокручивающимися точками.
Когда я нахожусь за своим рабочим столом, все работает хорошо и быстро. Он спит и возобновляет нормально и т.д. Это только загрузка, которая касается меня. Поскольку у меня система с двойной загрузкой, я, как правило, перезагружаюсь в Windows 10, чтобы сделать определенные вещи. Загрузка в Win10 очень быстрая, но загрузка в Ubuntu занимает слишком много времени.
Я использую тот же раздел, что и раньше (который я отформатировал для новой установки Ubuntu).
Я использовал systemd-analyze
, чтобы выяснить, что вызывает задержки. До сих пор я пробовал следующее:
Вот экран Я вижу между меню 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
все еще отображается в списке виновных.
Вот мой системный анализ вины и выходов критической цепи:
BLAME
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 ... Но просмотр всех журналов пока что никуда не ведет.
Я отказался от версии, я пытался бежать за бесчисленными попытками ускорить ее, и пониженный до Ubuntu Gnome 14.04. Я снял большую часть Ubuntu 16.04, что она начинала вызывать проблемы.
Переключение на Gnome 14.04 заставило все загрузиться и работать настолько быстрее. Мое время начальной загрузки прошло с 55 секунд с Единицей 16.04 к 20 секундам с Gnome 14.04.
В конце, независимо от того, что я сделал, я ничего не мог ускорить немного быстрее с 16,04. Решением для меня было снижение, даже работая на новом оборудовании.
Для подтверждения этого я решил также понизить свой ПК от Kubuntu 16.04 до Gnome 14.04. Это - четырехъядерный i7 4 ГГц с 16 ГБ RAM и твердотельных дисков. Мое время начальной загрузки было первоначально ~8 секундами, и это - теперь ~5 секунд.
Обновление Драйверов устранило проблемы производительности для меня.Послушайте:
Я не знаю, решит ли это Вашу проблему, но мы видим это после обновления до 16,04. Время начальной загрузки было намного дольше, и у нас были некоторые проблемы начальной загрузки, в которых не запускался компьютер. Это было решено после удаления Плимута и всего связанного экрана-заставки.