Медленная начальная загрузка с SSD и LVM на новой установке 18,04

Моя первая установка не включала LVM и взяла спустя приблизительно 15 секунд после BIOS для начальной загрузки. Моя вторая установка включала LVM и взяла спустя приблизительно 45 секунд после BIOS для начальной загрузки. После того, как много поиска с помощью Google общего согласия, кажется, что это - ошибка, в которой выбор LVM при использовании "определенного" SSD во время установки вызовет долгую начальную загрузку, в то время как система ищет и не находит файл подкачки. Тайм-аут составляет 30 секунд. Кто-либо нашел работу вокруг для этого?

2
задан 17 May 2018 в 19:16

3 ответа

Попробуйте или следующих двух методов или обоих.

Первый метод

Проверьте, какой длины время начальной загрузки ядра путем открытия терминала и ввода:

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

(Источник)

2
ответ дан 2 December 2019 в 02:43

Кажется, что второй путь, описанный выше, не работает в целом. Также я рекомендую немного более "защищенному от неправильного использования" способу постараться не случайно переопределять подкачку 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

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

0
ответ дан 2 December 2019 в 02:43

Отказ от ответственности: во время записи у меня нет достаточной репутации для комментария других ответов, таким образом, я должен ввести новый (главным образом как ссылка для меня)

У меня была подобная проблема о новой установке 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.

1
ответ дан 2 December 2019 в 02:43

Другие вопросы по тегам:

Похожие вопросы: