Перенос установленного линукса на другой диск

На своем рабочем компьютере думаю переустановить линукс с Минта на Генту. Появилось еще 2 новых диска hdd+ssd и несколько разделов нужно переразбивать.

Есть свободный раздел куда установится Гента, а позже я думаю перенести корень на SSD, кроме папок в которых гента делает тонну мелкий файликов и постоянно их меняет (это var/tmp, логи, дерево портежей и т.д.).
Собственно вопрос в том, можно ли так поступать или если SSD будет в корне, то лучше сразу его делать корнем? Гента делает ли какие-то оптимизации для SSD при его наличии или все вручную потом задачать?

Оптимизации для ssd - в

Оптимизации для ssd - в основном на уровне ФС
перенести очень просто с помощью dd или cp, далее исправить конфиг загрузчика и fstab, при необходимости

Всётаки dd удобнее, на мой

Всётаки dd удобнее, на мой взгляд, т.к. если перемонтировать /tmp в tmpfs (временно) и / в ro, то можно с загруженной системы. Но fs изменить не получится.

Червон00кий.

на десктопе будет

на десктопе будет одновременно 2 линукса, пока Гента не заработает по полной.
Так что копировать файлы можно с другого линукса/LiveCD

Для справки. Линь прекрасно

Для справки. Линь прекрасно переносится обычным cp -p -r. Грузимся с лайва и вперед. И в отличие от dd можно запросто менять как fs, так и размер раздела.
Для для переезда бутового раздела копирования недостаточно. Нужно будет (под chroot в новый корень) установить mbr ( grub2-install .... ). Все операции подробно расписаны в хендбуке.

В принципе, даже livecd

В принципе, даже livecd грузиться не обязательно, если вдумчиво, то можно и "вживую" скопировать

_SerEga_ написал(а): В

_SerEga_ написал(а):
В принципе, даже livecd грузиться не обязательно, если вдумчиво, то можно и "вживую" скопировать

Думать ещё. Зачем? Мало ли кто когда затеет писать в файлы. Да и над /dev/*
думать надо. Я предпочитаю тупо `cp -a` с незагруженной системы. Спокойнее.

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

mkdir /mnt/root mount -o bind

mkdir /mnt/root
mount -o bind / /mnt/root
И получится "незагруженная" система.

Локальный оверлей растёт

Разве это что-то изменит?

Разве это что-то изменит?

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Да, в бинде фс уже не будут

Да, в бинде фс уже не будут подмонтированы.

Локальный оверлей растёт

Спокойнее - да. Но можно

Спокойнее - да. Но можно подумать, "кто и куда может затеять писать" и не перезагружаться )

И что же, выключить всё, что

И что же, выключить всё, что может куда-то записать, вплоть до syslog?

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

у меня десктоп(как и у ТС),

у меня десктоп(как и у ТС), так что полнота логов не критична, со всеми остальными "писателями" на диск аналогично.
(/home на отдельном диске)

Зачем нужен геморрой с

Зачем нужен геморрой с потенциальной потерей консистентности? Неудаленные файлы для блокировок, не соответствующие реальным данным сессии… В общем случае это сводится к ответу на вопрос «а что будет, если подсунуть приложению Х произвольные данные». И неважно, что вероятность этого невелика – это все же плохой подход и советовать его я бы не стал.

Всё решаемо. Файлы блокировок

Всё решаемо.
Файлы блокировок очистятся при загрузке, темпы вообще можно счистить. В конце концов, можно разлогиниться, но выключаться нет смысла.

Локальный оверлей растёт

можно, конечно, и dd сделать

можно, конечно, и dd сделать по живому – пусть потом fsck.fs разбирается :D

можно, но для уверенности там

можно, но для уверенности там нужно несколько больше раздумий и телодвижений
ps я никого не призываю юзать cp на загруженной систему. Согласись, что с минимальным участием головы, вполне возможно получить рабочую копию системы этим способом

Абсолютно согласен, что с

Абсолютно согласен, что с некоторым участием головы – можно получить рабочую копию. Однако с некоторым ее неучастием или же невезением можно получить не совсем рабочие компоненты системы – после чего вся эта экономия обернется бо́льшими временными затратами. С другой стороны, ковбоем быть не запретишь.

Однако с некоторым ее

Однако с некоторым ее неучастием или же невезением можно получить не совсем рабочие компоненты системы
это справедливо для любого метода )

не понимаю в чем спор. Мне

не понимаю в чем спор. Мне как топик стартеру интересно данную процедуру сделать всего 1 раз и максимально корректно.
Т.к. проблем с отключением компьютера или перезагрузкой у меня нет, то я 100% выберу безопасный вариант с ЛайвСД, что бы копировать не "по живому". У меня же не сервер, которому нужно быть 24 часа в сутки он-лайн, так что проблемы с отключением нет как таковой.

ИМХО для этой задачи скорее

ИМХО для этой задачи скорее cpio.

:wq
--
Live free or die

cpio, говоришь? а ну,

cpio, говоришь? а ну, навскидку, как cpio обрабатывает по умолчанию soft- и hard links? И какие ключи и как управляют поведением в этом разрезе? :)

можно еще посоветовать

Цитата:
…делает ли какие-то оптимизации для SSD при его наличии или все вручную потом задачать?

можно еще посоветовать автоматически менять io scheduler на deadline (или даже noop) для «немеханических» дисков, примерно так (для udev):

/etc/udev/rules.d/60-schedulers.rules:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

разумеется, нужно проверить, есть ли в ядре нужные шедулеры:

zgrep -i IOSCHED /proc/config.gz

CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CFQ_GROUP_IOSCHED is not set
CONFIG_DEFAULT_IOSCHED="cfq"

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".