Моя первая установка не включала LVM и взяла спустя приблизительно 15 секунд после BIOS для начальной загрузки. Моя вторая установка включала LVM и взяла спустя приблизительно 45 секунд после BIOS для начальной загрузки. После того, как много поиска с помощью Google общего согласия, кажется, что это - ошибка, в которой выбор LVM при использовании "определенного" SSD во время установки вызовет долгую начальную загрузку, в то время как система ищет и не находит файл подкачки. Тайм-аут составляет 30 секунд. Кто-либо нашел работу вокруг для этого?
Попробуйте или следующих двух методов или обоих.
Проверьте, какой длины время начальной загрузки ядра путем открытия терминала и ввода:
systemd-analyze
wait-for-root
в /usr/share/initramfs-tools/scripts/local
испытывает таймаут после истечения 30 секунд (значение дремоты). dev_id
переменной присваивают значение RESUME
который определяется в /etc/initramfs-tools/conf.d/resume
. Этим UUID, который присвоен РЕЗЮМЕ, является UUID раздела подкачки LVM. Присвойте путь файла устройств раздела подкачки LVM, чтобы ВОЗОБНОВИТЬ и использовать wait_for_udev
вместо wait-for-root
.
Чтобы сделать это, введите (в терминале):
sudo sed -e 's/^RESUME=/#RESUME=/g' \
-i /etc/initramfs-tools/conf.d/resume
После этого закончен, введите:
echo "RESUME=/dev/mapper/ubuntu--YOUR FLAVOR OF UBUNTU HERE--vg-swap_1" | \
sudo tee -a /etc/initramfs-tools/conf.d/resume
Воссоздайте система перезагрузки и initrd.
sudo update-initramfs -u
После этого закончен, введите:
sudo reboot
Время начальной загрузки ядра должно быть быстрее. Проверьте путем ввода:
systemd-analyze
Вы также сможете использовать спящий режим после этого.
Перейдите к /etc/initramfs-tools/conf.d/
Щелкните правой кнопкой по "резюме" и выберите Edit в качестве Администратора. Измените строку
RESUME=UUID=<WHATEVER YOUT NUMBER IS>
(например. RESUME=UUID=67b3fe6f-1ec4-413f-8c5a-1136bc7f3270
) к:
RESUME=none
Теперь откройте терминал и тип:
sudo update-initramfs -u
После этого закончен, введите:
sudo reboot
Время начальной загрузки ядра должно быть быстрее. Проверьте путем ввода:
systemd-analyze
Кажется, что второй путь, описанный выше, не работает в целом. Также я рекомендую немного более "защищенному от неправильного использования" способу постараться не случайно переопределять подкачку UUID.
sudo -i #become root
cd /etc/initramfs-tools/config.d
mv resume resume.uuid
echo "RESUME=/dev/mapper/YOUR UBUNTU FLAVOUR HERE--vg-swap_1" > resume
#Example: echo "RESUME=/dev/mapper/lubuntu--vg-swap_1" > resume
update-initramfs -uk all
sync && reboot
Теперь мы можем просто переключиться назад и вперед путем переименования этих двух файлов.
Отказ от ответственности: во время записи у меня нет достаточной репутации для комментария других ответов, таким образом, я должен ввести новый (главным образом как ссылка для меня)
У меня была подобная проблема о новой установке Ubuntu с установкой без операционной системы, загружающейся в ~15s, в то время как начальная загрузка на установке LVM взяла ~50s (с паузой приблизительно 30-х на черном экране).
Первый вызов к sudo systemd-analyze blame
указанный, что у меня была другая проблема:
$ sudo systemd-analyze blame
40.699s snapd.seeded.service
...
То, что я смог решить благодаря этому другие Вопросы и ответы: Долго загружайте задержку на загрузке/экране-заставке Ubuntu после регулярного dist-обновления на чистой установке SSD (18.04) путем установки rng-tools
и определение HRNGDEVICE=/dev/urandom
как входной источник для случайных данных в /etc/default/rng-tools
.
Это решило snapd энтропийную проблему:
$ sudo journalctl -u snapd.seeded.service --since today
-- Logs begin at Tue 2018-08-21 18:22:53 CEST, end at Tue 2018-08-21 19:40:09 CE
# Before: ~40s
Aug 21 18:22:54 zen systemd[1]: Starting Wait until snapd is fully seeded...
Aug 21 18:23:36 zen systemd[1]: Started Wait until snapd is fully seeded.
Aug 21 18:50:18 zen systemd[1]: Stopped Wait until snapd is fully seeded.
-- Reboot --
# After: <1s
Aug 21 18:51:19 zen systemd[1]: Starting Wait until snapd is fully seeded...
Aug 21 18:51:19 zen systemd[1]: Started Wait until snapd is fully seeded.
....
Но ядро все еще взяло ~35s для запуска так, я прошел "Защищенный от неправильного использования" способ нолей-fenner, это не работало сначала, но после смешивания с первым решением от Arni и David, мне наконец удалось опустить время начала на ~10s.
Таким образом для (мое собственное) ссылка, вот моя версия безопасного пути для решения проблемы:
$ cd <whatever back up folder on your machine>
# backup initial config
$ cp /etc/initramfs-tools/conf.d/resume .
# Retrieve the correct path to the swap partition (for manually configured LVMs)
$ sudo fdisk -l
... some partitions
Disk /dev/mapper/vg_zen-uswap: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
... some more partitions
# Update the "resume" file with the new path
# Caution "vg_zen-uswap" is for *my* machine only :)
$ echo "RESUME=/dev/mapper/vg_zen-uswap" | sudo tee /etc/initramfs-tools/conf.d/resume
RESUME=/dev/mapper/vg_zen-uswap
# Recreate initrd
$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-32-generic
# reboot
Это добилось цели для меня. HTH.