Опасность коллизии?/var/log заполняется инструментом восстановления, но фактическим / var, расположенным на отдельном разделе
Что-то пошло не так, как надо в моей системе, и я использовал один из удобных CD начальной загрузки для восстановления grub и также сгладьте некоторые ошибки в назначениях устройств. Никакое грандиозное предприятие, и это работало обработка. Хороший.
Однако программное обеспечение восстановления на этой начальной загрузке CD любило писать в /var/log/* и "забава" началась.
Мой /var находится на отдельном разделе, пока этот инструмент радостно создал совершенно новое /var дерево и заполненный это на моем / (после того как это определило местоположение его с действительной подписью). Это не хорошо.
Предположим, я только что закрыл ПК после восстановления и (холод-) начальная загрузка в мой собственный дистрибутив снова. Это не может действительно работать, не так ли? Поскольку я знаю, что системе нужно МНОГО информационных файлов от /var при запуске. (Это используется только в качестве "дампа файла журнала", как большинство новичков думает.) На VM я попробовал это просто ради удовольствия 2 года назад: результат состоял в том, что невозможно загрузиться с девственницей /var каталог. Даже восстановление целого дерева (подкаталоги только, но никакие файлы внутри) будет работать. Там кажется чем-то действительно важным, в котором стандартные программы запуска действительно нуждаются для того, чтобы успешно достигнуть графического экрана входа в систему.
Таким образом, как можно избежать, создал ли некоторый инструмент a /var/* дерево на Вашем / раздел и не намного позже, UUID /var раздел читается системой и...? Я когда-то думал что /var раздел наложит "pseudo-/var" на / раздел, но это кажется не случаем. Плюс, это не Windows: это не превращено к a /var.backup или /var (2) или что-либо того вида.
/etc/fstab: (UUID, "нормализованные" по причинам удобочитаемости)
# /boot on /dev/sda1 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /boot ext4 ro 0 1
# / on /dev/sda2 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee / ext4 defaults 0 2
# /var (NEW) on /dev/sda6 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /var ext4 defaults 0 2
# /home on /dev/sda3 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /home ext4 defaults 0 2
# /usr on /dev/sda5 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /usr ext4 defaults 0 2
# /opt on /dev/sda7 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /opt ext4 defaults 0 2
1 ответ
Так, Вы раньше имели пустое /var в Вашей корневой файловой системе, которая использовалась в качестве точки монтирования для "реального / var", который был расположен в различной файловой системе? И когда Вы загрузились от ISO, ему так или иначе удалось создать набор подкаталогов в Вашем "корне" /var поэтому теперь, Вы волнуетесь, что после перезагрузки система не будет в состоянии смонтировать Ваш "реальный / var", потому что точка монтирования имеет некоторые файлы и каталоги в ней?
я не думаю, что Вы должны быть заинтересованы, процесс монтирования работает просто великолепно в этом случае. Файлы, расположенные в Вашей точке монтирования, становятся недоступными (пока Вы не размонтировали раздел), и целое содержание точки монтирования "заменяется" содержанием смонтированного раздела.
единственный отрицательный побочный эффект, о котором я могу думать, состоит в том, что некоторое дисковое пространство будет потрачено впустую журналами, в которых Вы не нуждаетесь, но, с другой стороны, я думаю, что было бы довольно безопасно удалить их.