Перемещенные разделы медленно загружаются на SSD
Я начинаю сообщество любителей Linux. Наряду с Pi и сервером AWS у меня есть старый ноутбук с Core2Duo 2,2 ГГц и 6 ГБ DDR2 для демонстрационных материалов. Для добавления oomph я установил SSD на 240 ГБ. Это система BIOS, а не UEFI. Все 64 бит.
Windows 10 и System Reserved находятся в начале, в двух первичных разделах. После этого я использовал расширенные разделы и установил свою привилегированную ОС, Xubuntu и swap. Затем, чтобы показать, что это можно сделать, я установил Windows 10 в VirtualBox в Xubuntu. Я добавил больше Ubuntu flavors, после чего решил изменить размеры разделов Windows и Xubuntu: больше Xubuntu, меньше Windows, а Kubuntu и Budgie немного перетасовывались. Я сделал это, используя gparted на live * buntu pendrive, выполненном с помощью UNetbootin. Grub2 сломался, поэтому я установил его с живым pendrive и начал загружать больше вкусов. В общей сложности пять разновидностей Ubuntu и два Mints с запасом около 30 ГБ.
Все ОС Linux на перемещенных разделах медленно загружаются (Kubuntu, Xubuntu и Budgie), они зависают во время заставки и HD индикатор активности гаснет некоторое время, пока он не сдвинется, и вы получите экран входа в систему. ОС, установленные позже, прекрасны. Например, Ubuntu Mate загружается за 15 секунд. Xubuntu занимает 1m45s.
На любой из установленных ОС практически ничего нет, поэтому я мог бы просто создать резервную копию своей виртуальной Windows 10 и перезагрузить Xu, Ku и Budgie, но я бы скорее нашел исправление :) Где я бы начал искать?
4 ответа
Спасибо за руководство - вот мои результаты !!
Диски были правильно выровнены, переместив их с помощью gparted. Вывод оптимальной выверки [1-12] соответствует выровненному, за исключением 3 (по какой-то причине не выровнен) и 4 (не существует). Я все еще думал, что это связано с разделением из-за моего нечетного макета - вот мой раздельный вывод>
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary ntfs boot
2 525MB 86.4GB 85.9GB primary ntfs
3 86.4GB 211GB 125GB extended
7 86.4GB 140GB 53.7GB logical ext4
8 140GB 142GB 2147MB logical linux-swap(v1)
5 142GB 156GB 13.3GB logical ext4
6 156GB 167GB 11.1GB logical ext4
9 167GB 178GB 11.1GB logical ext4
10 178GB 189GB 11.1GB logical ext4
11 189GB 200GB 11.1GB logical ext4
12 200GB 211GB 11.1GB logical ext4
Мне это нравится.
dmesg говорит мне, что random: crng init done происходит в тот момент, когда система зависает, и подсказка пришла от поиска в Интернете для этой строки и нахождения Ошибка запуска # 1685794. Здесь они рассказывают о проблемах с зашифрованным свопом. Поскольку мой обмен не зашифрован, я решил все равно посмотреть на мою fstab, посмотрим, произошла ли ошибка раздела подкачки. Yup, UUID был не прав.
Как я считаю, я это вызвал, я выбрал вариант «что-то еще» для каждой установки. При создании корневого раздела, если я также нажал на раздел подкачки, я установил новый UUID в раздел. Я предполагаю, что я просто не делал этого в течение последних четырех инсталляций. Как это относится к random: crng init done, я думаю, что монтажные записи fstab происходят в то же время, что и random: crng init done, что бы это ни было.
Это был также эксперимент в том, что произойдет, если я использую один обмен для нескольких установок на один машина. Теперь я знаю:)
Будучи проблемой, только после того, как вы переместили разделы, может быть только то, что разделы не выровнены правильно. Если вы используете gparted для разделов Ext4 и swap, убедитесь, что разделы правильно выровнены. Используйте собственное приложение управления дисками Windows для управления разделами NTFS.
В terminal ...
Чтобы быстро проверить, есть ли эта проблема:
sudo fdisk -l
, и он скажет, что разделы смещены или нет.
Чтобы быстро проверить, есть ли эта проблема:
sudo parted
parted> print
1 {partition 1 detail}
2 {partition 2 detail}
parted> align-check optimal 1
parted> align-check optimal 2
для получения дополнительной помощи man parted.
Спасибо за руководство - вот мои результаты !!
Диски были правильно выровнены, переместив их с помощью gparted. Вывод оптимальной выверки [1-12] соответствует выровненному, за исключением 3 (по какой-то причине не выровнен) и 4 (не существует). Я все еще думал, что это связано с разделением из-за моего нечетного макета - вот мой раздельный вывод>
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary ntfs boot
2 525MB 86.4GB 85.9GB primary ntfs
3 86.4GB 211GB 125GB extended
7 86.4GB 140GB 53.7GB logical ext4
8 140GB 142GB 2147MB logical linux-swap(v1)
5 142GB 156GB 13.3GB logical ext4
6 156GB 167GB 11.1GB logical ext4
9 167GB 178GB 11.1GB logical ext4
10 178GB 189GB 11.1GB logical ext4
11 189GB 200GB 11.1GB logical ext4
12 200GB 211GB 11.1GB logical ext4
Мне это нравится.
dmesg говорит мне, что random: crng init done происходит в тот момент, когда система зависает, и подсказка пришла от поиска в Интернете для этой строки и нахождения Ошибка запуска # 1685794. Здесь они рассказывают о проблемах с зашифрованным свопом. Поскольку мой обмен не зашифрован, я решил все равно посмотреть на мою fstab, посмотрим, произошла ли ошибка раздела подкачки. Yup, UUID был не прав.
Как я считаю, я это вызвал, я выбрал вариант «что-то еще» для каждой установки. При создании корневого раздела, если я также нажал на раздел подкачки, я установил новый UUID в раздел. Я предполагаю, что я просто не делал этого в течение последних четырех инсталляций. Как это относится к random: crng init done, я думаю, что монтажные записи fstab происходят в то же время, что и random: crng init done, что бы это ни было.
Это был также эксперимент в том, что произойдет, если я использую один обмен для нескольких установок на один машина. Теперь я знаю:)
-
1Использование только 1 свопа означает, что вы не сможете спячки с любой ОС. – heynnema 28 September 2017 в 16:29
-
2Справедливая точка зрения, и я догадался. Я никогда не был поклонником спящего режима под любой ОС. Спасибо за совет :) – David1618 28 September 2017 в 16:52
Будучи проблемой, только после того, как вы переместили разделы, может быть только то, что разделы не выровнены правильно. Если вы используете gparted для разделов Ext4 и swap, убедитесь, что разделы правильно выровнены. Используйте собственное приложение управления дисками Windows для управления разделами NTFS.
В terminal ...
Чтобы быстро проверить, есть ли эта проблема:
sudo fdisk -l
, и он скажет, что разделы смещены или нет.
Чтобы быстро проверить, есть ли эта проблема:
sudo parted
parted> print
1 {partition 1 detail}
2 {partition 2 detail}
parted> align-check optimal 1
parted> align-check optimal 2
для получения дополнительной помощи man parted.
-
1Выравнивание имеет решающее значение только для разделов, на которые вы пишете. Поскольку вы не записываете напрямую в расширенный раздел, он обычно не выровнен. И выравнивание больше импорта и для SSD & amp; новые 4K-диски. Также убедитесь, что BIOS имеет AHCI, или обрезка не будет работать. – oldfred 27 September 2017 в 01:58
-
2@oldfred Пожалуйста, объясните, почему выравнивание имеет решающее значение для разделов, на которые вы пишете. Это не имеет смысла. – heynnema 27 September 2017 в 03:15
-
3Расширенный раздел - это контейнер, а не раздел, в который вы записываете. Поэтому его начало не критично. Почти каждый другой раздел является критическим. Род Смит - настоящий эксперт, но затем он также является автором gdisk для gpt (GUID), а расширенный раздел не используется. ibm.com/developerworks/linux/library/… См. его комментарий здесь о расширенных разделах: ubuntuforums.org/… – oldfred 27 September 2017 в 06:43
-
4@oldfred ах ... вы имели в виду расширенные разделы! Я думал, что ты говоришь о всех разделах. – heynnema 27 September 2017 в 17:41
-
5спасибо oldfred, я посмотрю AHCIin BIOS. Включен ли TRIM по умолчанию в Ubuntu 17.04 и производные, когда AHCI включен в BIOS? – David1618 28 September 2017 в 14:01