Ubuntu 16.04.1 начальная загрузка Ядра LTS более чем 90 секунд
Простите мне, я просто установил Ubuntu вчера и пытаюсь учиться так быстро, как я могу.
Я не могу выяснить, почему начальная загрузка, перезапуск и завершение работы занимают много времени, от информации ниже я вижу, где проблема происходит, но я не знаю, как зафиксировать его. Я также понимаю, что начальная загрузка, перезапуск и завершение работы могли быть отдельными вопросами и раз так предпочесть запускаться с запуска / перезагрузка (я думаю, что они связаны).
Каждый раз, когда я запускаю свой компьютер или перезагружаю мой компьютер, ядро принимает 90 секунд для загрузки (находящийся в черном экране при ожидании).
Спасибо за любого и всю справку можно обеспечить.
К вашему сведению я загрузил Zorin ОС 9 без любых проблем, но это использует более старую версию Ubuntu (14.04 LTS), и я хочу использовать последнее.
Информация о системе:
- Intel I7-3770K
- AMD Radeon R9 290x
- Поршень на 32 ГБ
- Samsung SSD как основной (личинка, установленная здесь)
- WD жесткий диск 7200 об/мин как моя подкачка и поддерживает человечность.
- Ubuntu 16.04.1 LTS 64 бита, Обновленные.
Личинка установлена на моем основном диске, в то время как человечность находится на/dev/sdb3 (3-й диск в моей системе)
Я попытался загрузиться с nomodeset и это не помогает вообще.
Править: Дополнительная информация - я использую версию на 64 бита UEFI Ubuntu. Мне также установили разгон в моей BIOS. Я попытался добавить параметры к своему ядру, или я не делаю его правильно, или оно не имеет никакого эффекта. Я также попытался отключить каждое USB-устройство от своего компьютера включая мою клавиатуру, и мышь (использовал ps2 клавиатуру), и проблема осталась.
РЕДАКТИРОВАНИЕ 2: Я сделал некоторое дополнительное тестирование:
Я отключил каждый заголовок usb, отключили весь жесткий диск, и проблема все еще происходит (даже с живым usb).
У меня есть эта материнская плата:
Я думаю, что это должно быть что-то с материнской платой, возможно, вторичным контроллером SATA?
У кого-либо есть какие-либо предложения?
Изображение проанализировать графика: Ubuntu 16.04.1 LTS systemd-анализирует график
dmesg (Пример начальной загрузки 1)
[ 2.135850] sd 10:0:0:0: [sdd] 976754645 4096-byte logical blocks: (4.00 TB/3.64 TiB)
[ 2.136168] sd 10:0:0:0: [sdd] Write Protect is off
[ 2.136170] sd 10:0:0:0: [sdd] Mode Sense: 4f 00 00 00
[ 2.136327] sd 10:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.137493] sdd: sdd1
[ 2.138193] sd 10:0:0:0: [sdd] Attached SCSI disk
[ 2.627661] clocksource: Switched to clocksource tsc
[ 91.393716] random: nonblocking pool is initialized
[ 91.478893] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)
[ 92.052207] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
[ 92.052306] systemd[1]: Detected architecture x86-64.
[ 92.064886] systemd[1]: Set hostname to <AntUbuntu>.
[ 92.298399] systemd[1]: Listening on udev Kernel Socket.
[ 92.298491] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ 92.298499] systemd[1]: Reached target Remote File Systems (Pre).
dmesg (Пример начальной загрузки 2)
[ 4.297400] sd 10:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.298509] sdd: sdd1
[ 4.299195] sd 10:0:0:0: [sdd] Attached SCSI disk
[ 4.393421] random: nonblocking pool is initialized
[ 91.502212] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)
[ 92.075578] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
[ 92.075677] systemd[1]: Detected architecture x86-64.
[ 92.088193] systemd[1]: Set hostname to <AntUbuntu>.
[ 92.337609] systemd[1]: Listening on udev Control Socket.
[ 92.337646] systemd[1]: Listening on udev Kernel Socket.
[ 92.337659] systemd[1]: Listening on fsck to fsckd communication Socket.
[ 92.337709] systemd[1]: Created slice System Slice.
systemd-проанализируйте вину:
6.233s lightdm.service
5.922s snapd.refresh.service
4.198s plymouth-quit-wait.service
3.095s dev-sdb3.device
2.376s NetworkManager.service
1.961s ModemManager.service
1.959s thermald.service
1.945s accounts-daemon.service
1.773s apparmor.service
1.441s polkitd.service
1.114s plymouth-start.service
1.094s systemd-tmpfiles-setup.service
1.033s apport.service
1.004s grub-common.service
868ms networking.service
856ms systemd-journal-flush.service
721ms gpu-manager.service
695ms rsyslog.service
642ms systemd-fsck@dev-disk-by\x2duuid-1EEB\x2dDE91.service
571ms systemd-tmpfiles-setup-dev.service
558ms console-setup.service
509ms keyboard-setup.service
495ms upower.service
2 ответа
Таким образом позвольте мне получить это прямо. Это - 2 установки диска, и у Вас есть начальная загрузка и корень на отдельных дисках?
Вы думали о, возможно, помещении корневой начальной загрузки и подкачиваете разделы на ssd и использовании жесткого диска для обслуживания данных? Что-то как монтирование жесткого диска к/srv.
я выполняю эту установку с помощью карты флэш-памяти в качестве корневой начальной загрузки домой и подкачки и 2 HDD, смонтированных к/srv и/mnt, содержащему мои изображения виртуальной машины и данные, которым они служат. Время начальной загрузки является < 60 секунд
90-секундная задержка вызывается конфликтом имен сетевого интерфейса, который происходит из-за дефекта в BIOS Вашей материнской платы. Некоторые материнские платы Intel с несколькими интегрировались, NICs имеют эту проблему. Двумя материнскими платами, о которых я знаю, является Intel DZ77GA-70K (Ваш случай) и DZ77RE-75K (мой).
Примечание, что существует много видов отказа, которые вызовут длительную задержку во время продвижения начальной загрузки к потраченному впустую усилию при искании решений. Этот конкретный случай связан с конфликтами сетевого интерфейса и может быть обнаружен путем выполнения следующей команды, описанной сюда: https://bugzilla.redhat.com/show_bug.cgi? id=1102135
$ sudo grep . /sys/class/net/*/device/{index,acpi_index}
/sys/class/net/eth0/device/index:1
/sys/class/net/eth1/device/index:1
grep: /sys/class/net/*/device/acpi_index: No such file or directory
Эти два сетевых устройства имеют то же "индексное" значение 1 и индексные значения ACPI, отсутствует. Должны быть отличные индексные значения APCI, присвоенные BIOS. Из-за этих конфликтующих значений "Предсказуемая политика" Названия Сетевого интерфейса ( https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames), это появилось в udev v197, вызывает сетевые интерфейсы к так или иначе не, инициализируют правильно на начальной загрузке, и наблюдаются 90 вторых тайм-аутов.
Другой способ обнаружить это состоит в том, чтобы применить "отладку ignore_loglevel" аргументы командной строке ядра. С этими аргументами на месте во время начальной загрузки (и также в выводе dmesg) Вы будете видеть сообщение после 60 секунд от systemd-udevd, что некоторый сетевой интерфейс "занимает много времени".
systemd-udevd[447]: seq 2024 '/devices/pci0000:00/...' is taking a long time
существует несколько способов работать вокруг этой проблемы. Они документируются на ссылке freedesktop.org выше. Соответствующая часть заключается в кавычки здесь:
Вы отключаете присвоение фиксированных имен, так, чтобы непредсказуемые имена ядра использовались снова. Для этого, просто .link файл udev маски для политики по умолчанию: ln-s/dev/null/etc/systemd/network/99-default.link
Вы создаете свою собственную ручную схему именования, например, путем именования интерфейсов "internet0", "dmz0" или "lan0". Поскольку это создает Ваши собственные .link файлы в/etc/systemd/network/, которые выбирают явное имя или лучшую схему именования для одной, некоторых или всех Ваших интерфейсов. См. systemd.link (5) для получения дополнительной информации.
Вы передаете сеть ifnames=0 Предположению командной строки
ядра: эти платы Z77 от Intel появились непосредственно перед тем, как Intel вышел из настольного бизнеса материнской платы в 2013. Платы никогда не обладали преимуществом продолжающихся обновлений BIOS, которые, возможно, исправили эти проблемы. Платы работают, но существуют некоторые незначительные сбои, при этом другой - ошибки "сверхтока" USB, которые происходят на начальной загрузке и в Linux и в Windows несмотря на то, чтобы там быть никакими USB-устройствами, тянущими текущий.