Оновлення 9
Я вирішив спробувати експеримент. Я вийняв SSD зі свого робочого столу і тимчасово помістив його в свій ноутбук Dell Latitude. Ось, ось воно завантажується initrdна порядок швидше, гоління за 6 секунд від часу завантаження ...
Зараз я трохи розгублений ... можливо, у GRUB є проблема з чіпсетом моєї материнської плати?
Оновлення 8
Тож я помітив щось цікаве щодо світла активності жорсткого диска. Коли ви завантажуєте initrd, це майже так, як якщо світло працює з ШІМ на 10% робочому циклі чи щось. Це змушує мене замислитися, чи зчитування GRUB не оптимізоване, можливо, щось на зразок виконує виклик ОС для читання кожного байту, а не читання зображення як потоку байтів?
Оновлення 7
Здається, що завантаження початкового рамдиска є великою частиною проблеми.
Всередині GRUB я натиснув Cна командний рядок вручну. Потім я перейшов до введення кожного рядка з моєї конфігурації за замовчуванням по одному (введення цих UUID було болісним!) , І зазначив час виконання команди. Ось що я знайшов:
- Більшість команд виконано миттєво
- Команда для завантаження ядра зайняла близько однієї секунди
- Команда для завантаження початкового рамдиска зайняла 7 секунд
Після введення всіх рядків з конфігураційного файла я переходжу до запуску boot. З моменту натискання клавіші введення до моменту появи екрана входу пройшло приблизно 7,5 секунд.
Цікавим є той факт, що зображення, яке він завантажує, становить 36 Мб. Тож якщо для завантаження знадобилося 7 секунд, тоді він читає його лише зі швидкістю 5 Мб / сек!
Індикатор активності диска на моїй вежі вмикається цілі 7 секунд ...
Також ось цікавий фрагмент зі сторінки Вікіпедії про initrd :
Інші дистрибутиви Linux (такі як Fedora та Ubuntu) генерують більш загальне зображення initrd. Вони починаються лише з назви пристрою кореневої файлової системи (або її UUID) і повинні відкривати все інше під час завантаження. У цьому випадку програмне забезпечення повинно виконувати складний каскад завдань, щоб встановити кореневу файлову систему
Оновлення 6
Натан Осман запитував час завантаження в режимі однокористування в чаті.
З моменту потрапляння F10в GRUB до моменту появи підказки проходить 13 секунд.
Крім того, я розмовляв із Занною та Рінцвінд у чаті, і вони обоє мають 8-секундний запуск з моменту натискання кнопки живлення. Мої 20 секунд - від GRUB. Якби я порахував час POST, це було б ще довше!
Оновлення 5
Ubuntu може прочитати мій SSD з максимальною швидкістю 550 Мб / с ...
Оновлення 4
Тому я видалив quiet splash $vt_handoffпараметри з команди завантаження в GRUB на своєму ноутбуці (майте на увазі, що у цього ноутбука немає SSD) і помітив дуже цікаву річ під час завантаження послідовності:
Він висить на цій лінії протягом 15 секунд:
[ 4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped
Ось малюнок (низької якості):
Не впевнений, яке значення це ...
Оновлення 3
Я приурочив завантаження однієї з інших моїх машин, що працюють 14.04 (майте на увазі, що на цій машині немає SSD) , і з моменту натискання клавіші введення в GRUB до появи екрана входу потрібно 40 секунд.
Після натискання клавіші Enter він сидить на тому ж пустому фіолетовому екрані протягом 20 секунд, після чого анімація Ubuntu завантажується і потрібно ще 20 секунд до посадки на екрані входу.
Я подивився на вихід з dmesg, але не можу точно сказати, де закінчилося завантаження. Я думаю, це закінчилося за 25 секунд. Ось кілька останніх рядків:
[ 24.916824] wlan0: associated
[ 24.916852] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 25.215550] init: kdm main process (869) killed by TERM signal
[ 25.441216] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[ 25.445587] vboxdrv: Found 2 processor cores.
[ 25.446142] vboxdrv: fAsync=0 offMin=0x18c offMax=0x960
[ 25.446228] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[ 25.446230] vboxdrv: Successfully loaded version 4.3.36_Ubuntu (interface 0x001a000b).
[ 25.476940] vboxpci: IOMMU not found (not registered)
[ 33.174926] init: plymouth-upstart-bridge main process ended, respawning
[ 36.495811] init: anacron main process (933) killed by TERM signal
Якщо я правильно його витлумачив, це здається універсальним питанням GRUB.
Оновлення 2
Я зміг підтвердити, що це проблема GRUB , встановивши колір тла GRUB на зелений, використовуючи командний рядок, доступ до якого здійснюється натисканням кнопки Cв GRUB.
Коли я натискаю клавішу Enter, я отримую порожній зелений екран за ~ 15 секунд до завантаження завантажувальної анімації Ubuntu ...
Оновлення
Я думаю, що проблема полягає в тому, що GRUB займає багато часу для завантаження зображення ядра.
Питання
На моєму Samsung 850 Pro 512GB SSD я встановив Ubuntu 16.04, і я не можу зрозуміти, чому час завантаження становить 20 секунд. (З моменту потрапляння в GRUB). Майте на увазі, що 20, на які я посилаюсь, - це 17 на екран входу, а потім ще 3 на робочий стіл)
Крім того, не впевнений, що це актуально чи ні, але:
- Ubuntu встановлюється в режимі MBR, тому що я зневажаю UEFI.
- У мене встановлені власні драйвери Nvidia
Дивлячись на зображення, що генеруєтьсяsystemd-analyze plot > bootimage2 , мій запуск, мабуть, зайняв 3 секунди?
А дивлячись dmesg, мій запуск, мабуть, зайняв 4 секунди. Але я приурочив її секундоміром, і це зайняло 20 секунд! (Не включаючи час POST). Знову ж таки, майте на увазі, що 20, на які я посилаюсь, - це 17 на екран входу, а потім ще 3 на робочий стіл)
Ось як йде послідовність запуску:
- POST
- GRUB навантажує
- Я запускаю секундомір, коли натискаю ENTER
- Я отримую порожній фіолетовий екран ~ 15 секунд
- Я бачу анімацію завантаження Ubuntu протягом двох секунд
- Я сідаю на екран входу
- Я зупиняю секундомір
- Я ввожу свій пароль, натискаю клавішу enter і знову запускаю секундомір.
- Через 3 секунди я приземлююся на робочий стіл
- Я знову зупиняю свою секундомір.
Ось повний результат від dmesg: http://paste.ubuntu.com/23955108/
Ось перші рядки з виходу systemd-analyze blame:
365ms dev-sda5.device
327ms networking.service
287ms accounts-daemon.service
286ms ModemManager.service
233ms systemd-logind.service
216ms apport.service
213ms grub-common.service
209ms ondemand.service
200ms irqbalance.service
183ms speech-dispatcher.service
178ms apparmor.service
160ms gpu-manager.service
148ms thermald.service
148ms pppd-dns.service
146ms systemd-user-sessions.service
142ms alsa-restore.service
140ms console-setup.service
137ms rsyslog.service
105ms NetworkManager.service
104ms upower.service
102ms avahi-daemon.service
100ms systemd-udev-trigger.service
Ці люди мають таку ж проблему:
- https://ubuntuforums.org/showthread.php?t=2325045
- https://www.bleepingcomputer.com/forums/t/598260/booting-ubuntu-temporary-stuck-on-a-purple-screen/
- І, здається, навіть люди з ARCH мають цю проблему ...
Будь-які ідеї?
systemd-analyze blame. Дивна частина Груба застрягла на "завантаженні початкового диска" приблизно 10 секунд, коли це мала б частку секунди через розмір файлу. Тоді відставання просто пішло. Можливо, це було оновлення ядра? Можливо, зміни, які я вніс, plymouthdне впевнені.