Медленная начальная загрузка или никакая начальная загрузка вообще - как я портил свою установку человечности на этот раз?
ОБНОВЛЕНИЕ 23.03.2018
Так, я наконец определил проблему. Все о монтировании NTFS paritions на запуске на установке двойной загрузки. Таким образом, если Вы хотите обменяться данными между окнами и Linux, Вы могли бы хотеть использовать FAT32 по NTFS. Кажется, что окна иногда размонтировали файловую систему в некотором смысле, которая заставляет Linux испытывать затруднения при монтировании его снова. Для фиксации проблемы загрузки можно войти в чрезвычайную консоль и тип
ntfsfix /dev/sdXX
где sdXX идентификатор ntfs раздела. Можно искать это в Вашем /etc/fstab или путем ввода df. После runnung ntfsfix Вы могут войти в систему путем выхода из чрезвычайной консоли (просто тип exit)
ИСХОДНОЕ СООБЩЕНИЕ
Я недавно решил обновить свой ПК и переустановить человечность, а также окна. Я, должно быть, сделал некоторую ужасную ошибку, потому что начальная загрузка в человечность работает только каждая вторая попытка.
Когда начальная загрузка перестанет работать, аварийный терминал обнаружится. Я экспортировал журнал с предложенным journalctl -xb и загруженный вывод для Вас (см. ссылку ниже),
Соответствующие части моей аппаратной конфигурации:
Asus M5A97 LE R2.0 Mainboard
- PCIe 2.0 x 16: AMD Radeon R9 380
- PCIe 2.0 x 4: PCIe > M.2 Converter
- 500GB NVME attached to M.2 Converter
- PCI: Creative Sound Blaster X-Fi SB0730
- SATA-3: 480GB SSD
- SATA-3: 500GB HDD
Системная плата не имеет никакой поддержки boot-from-pcie, таким образом, я не мог установить окна или человечность непосредственно к диску NVME. Я полагал, что это могло бы быть хорошо, чтобы просто установить загрузчик на SSD (/dev/sda), поместить, начальная загрузка / монтируются на основном разделе на ssd также (/dev/sda3) и монтируют все остальное на nvme.
Чтобы постараться не настраивать личинку, я решил сначала установить окна 10 и затем установить человечность, таким образом, человечность автоматически запишет личинку в MBR/dev/sda. Это всегда работало отлично...
Дополнительно я создал ntfs-3g, монтируются, чтобы ssd обменялся данными между моими операционными системами. Я создал только один ext4 раздел на HDD и смонтировал его на некоторой пользовательской папке (в / медиа)
Что я попробовал до сих пор
Сначала я заметил, что у меня не было звука. Поскольку я купил системную плату, подержанную, я предположил, что ac97 микросхема повреждается и купила подержанную звуковую карту (см. выше). Я думал, что это могло бы, вызвал проблемы начальной загрузки, но это не имело место. У меня действительно есть звук теперь, но тем не менее проблемы загрузки.
Затем я считал что-то о проблемах UUID в/etc/fstab из-за нескольких попыток установки, и я проверил весь uuids, и они были тем же как в/etc/fstab.
Затем я считал что-то о неправильно смонтированном разделе подкачки, таким образом, я размонтировался, swapoff и swapon раздел на/dev/nvme0n1p6. Никакой успех.
Затем я нашел некоторое сообщение, что могло бы быть лучше удалить uuids из/etc/fstab и просто вставить разделы непосредственно. Таким образом, я сделал - никакой успех.
Как всегда lightdm делал много из проблем, таким образом, я установил gdm вместо этого.
lsblk -f вывод
NAME FSTYPE LABEL UUID MOUNTPOINT
loop1 squashfs /snap/vlc/190
sdb
└─sdb1 ext4 4fd6ff2a-50d0-465e-bd85-1c698bdbdc4a /media/hdd
loop0 squashfs /snap/core/4110
sda
├─sda4
├─sda2 ntfs CAC4D02AC4D01B11
├─sda5 ext4 b68dceb3-b600-4143-bbcb-836e94503c34 /var
├─sda3 ext4 09ef7d7c-6332-4c63-b4df-5875db98ebd7 /boot
├─sda1 ntfs System-reserviert 0CE4C7BBE4C7A4F4
└─sda6 ntfs Share 7FA5097E3B9D5067 /media/share
nvme0n1
├─nvme0n1p5 ntfs NVME AA52186052183393
├─nvme0n1p1
├─nvme0n1p6 swap 3277de96-09c9-4731-805a-a693c08543ab [SWAP]
└─nvme0n1p2 ext4 891a41fd-4c9b-4c0f-9f10-7abe82952b0a /
содержание /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p2 during installation
/dev/nvme0n1p2 / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda3 during installation
/dev/sda3 /boot ext4 defaults 0 2
# /var was on /dev/sda5 during installation
/dev/sda5 /var ext4 defaults 0 2
# swap was on /dev/nvme0n1p6 during installation
/dev/nvme0n1p6 none swap sw 0 0
# share ntfs partition on 480g ssd
/dev/sda6 /media/share ntfs-3g permissions 0 2
# hdd
/dev/sdb1 /media/hdd ext4 defaults 0 2
И наконец журналы моей последней неудачной попытки загрузки
http://s000.tinyupload.com/download.php?file_id=00683467828265059379&t=0068346782826505937914236
Я ценил бы любую справку! Спасибо за чтение до сих пор ;-)
ОБНОВЛЕНИЕ
Та часть нелегального выпуска могла бы быть интересной:
Mär 07 18:12:34 desktop-amdfx systemd-fsck[732]: /dev/sda3 besitzt nicht unterstützte Eigenschaft(en): metadata_csum
Mär 07 18:12:34 desktop-amdfx systemd-fsck[732]: e2fsck: Neuere Version von e2fsck benötigt!
Mär 07 18:12:34 desktop-amdfx systemd-fsck[732]: fsck failed with error code 8.
Mär 07 18:12:34 desktop-amdfx systemd-fsck[732]: Ignoring error.
Mär 07 18:12:34 desktop-amdfx systemd[1]: Found device SanDisk_Ultra_II_480GB 5.
1 ответ
Мне удалось разыскать проблемы и зафиксировать их.
Это, кажется, проблематично, чтобы иметь / var, смонтированный на другом диске. Возможно, потому что вход к/var/log является hardcoded где-нибудь во время начальной загрузки, когда диск еще не был смонтирован.
Как решить?
Начальная загрузка к режиму восстановления монтирует диски с опциями чтения-записи
затем
nano /etc/fstab
# -> in nano outcomment the /var mount by prepending a "#" character
umount /dev/sdxx /var
mkdir /media/var
mount /dev/sdxx /media/var
rm -rf /var
mkdir /var
rsync -a /media/var/ /var/
reboot
объяснения
sdxx идентификатор раздела, который Вы смонтировали на / var. В зависимости от Вашей Установки это может также запуститься с nvme.
nano /etc/fstabсначала мы должны препятствовать монтировать дополнительный раздел на / var. После того как редактор разжег outcomment монтирование и рядом с нажатиемCtrl+wсопровождаемыйCtrl+xumount /dev/sdxx /varразмонтируйте дискmkdir /media/varсоздайте каталог, в котором Вы собираетесь повторно смонтировать sdxxmount /dev/sdxx /media/varсмонтируйте раздел на новом каталогеrm -rf /varиспользуйте кувалду и удостоверьтесь, что ни до чего не оставляютmkdir /varсоздайте новую пустую папку как кореньrsync -a /media/var/ /var/скопируйте все как есть в / var. Я не знаю, почему, но CP-a получил меня, неправильно заканчивается, только rsync-a, кажется, работает надежный.rebootтестовая установка
Что, где мои проблемы с cp -r?
После копирования всех файлов к / var я проверил, кажется ли структура тем же путем выполнения нескольких команд.
проверение размера папки
du -hs /var по сравнению с. du -hs /media/var
проверение количества символьных ссылок
find /var -type l | wc -l по сравнению с. find /media/var -type l | wc -l
Я предпринял несколько попыток, CP всегда портило что-то, или полномочия были неправильными, и сервисы начали блокироваться, начальная загрузка или ссылки были созданы, где ни один не был в источнике. Не спрашивайте меня, почему - как я понимаю cp -a это должно работать отлично - но это не сделало. rsync-a сделал хотя
важный: не забывайте запаздывающую наклонную черту в команде rsync
ОБНОВЛЕНИЕ
Таким образом, ТЕПЕРЬ это становится более ясным. После конфигурирования моего/dev/sda5 для прямого монтирования /var/www вместо /var (по историческим причинам я используюсь для хостинга моих веб-проектов в том месте), начальная загрузка не была успешна снова. Таким образом, я предположил, что это должно быть апачским, это блокирует мою начальную загрузку.
Мое решение для этого
- начальная загрузка в recoverymode
- выполненный
mount -a -orw,remountиметь доступ для чтения-записи к файловой системе - выполненный
systemctl disable apache2.serviceпрепятствовать тому, чтобы апач запустился автоматически на начальной загрузке
И теперь это работает снова.
По некоторым причинам это кажется апачским, загружается, ПРЕЖДЕ ЧЕМ все диски были смонтированы. Таким образом, это могло быть некоторой ПРОТИВНОЙ ошибкой в systemd.
Я собираюсь перезагрузить 5 раз теперь, чтобы быть уверенным :-)
ОБНОВЛЕНИЕ 2
ХОРОШО - кажется, что больше чем 1 проблема влияла на меня сразу
Я наконец (по крайней мере в настоящий момент lookingfrustrated) получил свои настройки, работающие:
- перемещая все дополнительное монтирование (кроме/, / начальная загрузка и подкачка) от/etc/fstab до ручного монтирования в/etc/rc.local
- выполнение ntfsfix прежде, чем смонтировать раздел, который смонтирован и в - окна и в Linux
Так подробно:
Ubuntu, кажется, монтирует всю параллель дисков и не один за другим, это - причина случайной природы этой проблемы.
Когда окна закрываются, это не может оставить "чистую" файловую систему позади из-за некоторой внутренней вещи окон.
Мой /etc/fstab содержит только критические разделы только для Linux:
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/nvme0n1p2 / ext4 errors=remount-ro 0 1
/dev/sda3 /boot ext4 defaults 0 2
/dev/nvme0n1p6 none swap sw 0 0
И мой /etc/rc.local содержит инструкции для всего остального:
mount /dev/sda5 /var/www
mount /dev/sdb1 /media/hdd
ntfsfix /dev/sda6
mount -t ntfs-3g /dev/sda6 /media/share
exit 0
3 начальных загрузки подряд без проблем. Но я сомневаюсь, что все прекрасно действительно теперь, моя система кажется проклятой
ОБНОВЛЕНИЕ 3
Это не решение также, монтирование теперь становится "конкурентоспособным", потому что человечность пытается смонтироваться /dev/sda5 и /dev/sdb1 автоматически на/media/$USER/somelabel
Дополнительно я заметил, что ntfs-3g иногда препятствует закрыться, таким образом, я должен завершить работу путем нажатия кнопки питания.
Я думаю, что существует что-то, что я полностью пропускаю :-(