Comments 36
Эх, эту статейку бы мне полгода назад — сэкономило бы пару вечеров =) В итоге всё так же делал. Правда не было необходимости переноса системы — устанавливал из под VirtualBox сразу на целевой диск.
Кстати тогда у меня ещё сеть не сразу завелась — после запуска ОС (только это была Ubuntu Server) она увидела новую сетевую карту, обозвала её eth1 (eth0 осталась за сетевой картой VirtualBox) и не захотела автоматически поднимать линк на ней.
Кстати тогда у меня ещё сеть не сразу завелась — после запуска ОС (только это была Ubuntu Server) она увидела новую сетевую карту, обозвала её eth1 (eth0 осталась за сетевой картой VirtualBox) и не захотела автоматически поднимать линк на ней.
… не захотела автоматически поднимать линк на ней
Жизнь была бы невыносимо скучной, кабы не было таких «подарков» от софта и оборудования. И как решили проблему, если не секрет?
Пол года назад уже была доступна статья habrahabr.ru/post/103743/, где описывается установка Debian с помощью network-console, даже физический доступ не нужен. Можно даже ухитриться образ CDROM по TFTP подтянуть.
Кстати можно ещё создать такой preseed, что бы сам установщик поднимал ssh и саму установку проводить по нему. Правда у меня так этого и не получилось =(
Вообще говоря, решены были не все проблемы. Одна из запланированных схем использования целевой машины — distcc-сервер и CI на Jenkins, однако в stable дебиана сейчас QtSDK 4.6.3 — наш проект (QReal, если это может быть интересным) требует старшей версии. При инсталляции пакета qt-sdk из testing (4.8.1) в виртуальной машине у меня упал гном (скоро появится монитор, так что он нужен), а на целевой машине к тому же еще и сетевые службы отвалились, включая SSH. Симптомы такие: иксы сами не стартуют, но по startx запускаются, правда без гнома.
/etc/init.d/gdm3 start
xinit '/etc/init.d/gdm3 start'
А инсталляция полностью testing-дистрибутива зависает на выборе наборов ПО как в графическом, так и в псевдографическом режимах =( Похоже, самый разумный выход — собирать Qt (вариант «дожидаться монитора» не подходит потому, что все тоже самое разворачивать на VDS и, вероятно, не раз еще с этим всем придется столкнуться)
SSH обычно по умолчанию форвардит экран с локальной машины. Не пробовали на удаленной системе запустить инсталлятор из консоли SSH? У меня в таком режиме gvim нормально из виртуалки работает.
с ключом -X форвардит (с -Y еще и в обход системы безопасности X-сервера, хотя я слабо понимаю, что это) Весьма впечатляюще выглядит, круто!
А кто-нибудь знает, как заставить приложение, запущенное благодаря ключу -X SSH (форвардинг гуи на локальную машину), при логауте оставаться рабочим? screen не помогает :(
Еще один подводный камень — система может не загрузиться с подключенного к ней второго диска. Проблему стоит искать снова таки в /boot/grub/device.map — замените в нем VBox-овский UUID вашего диска на привычный /dev/-путь к нему в целевой системе или на реальный UUID (узнать его можно с помощью blkid), затем сделайте в виртуальной машине
и снова пробуйте загрузить с диска целевую машину.
# update-grub
# grub-install /dev/sdX
# update-grub
и снова пробуйте загрузить с диска целевую машину.
Если bios позволяет, можно просто консоль на последовательный порт вывести и спокойно ставить все в текстовом режиме из терминала.
Регулярно пользуюсь.
Регулярно пользуюсь.
Это-то да, только в оригинальной задаче единственная боеспособная машина — ноутбук. COM-порта у него нет, тут уж современные ноуты проигрывают своим дедам (что уж говорить, далего не на всякой нынешней full-ATX плате десктопов найдешь последовательный порт. Хорошо, если беготня за планками поправит дело)
Если не затруднит, не могли бы Вы ткнуть на ссылку, где бы про такую установку подробней почитать?
Тут, например: geco.phys.columbia.edu/~jrollins/howtos/serial_console.html
Верно. Как и COM-кабели, докстанции 3.5" дисков, клавиатуры, новые внешние 2.5" жесткие диски и мониторы (в порядке роста стоимости). Только мама-папа или папа-папа переходники SATA разве что на заказ откуда-нибудь, вот это жалко. Кстати, есть ли у exspresscard-адаптеров rs232 какие-нибудь преимущества перед usb-вариантами?
Гм… Говорят, проблемы с usb-шными
С использованием dd для клонирования есть, на самом деле, ещё проблема, если клонируем на ssd-диск.
Он окажется весь «забит» — поскольку ни о каком trim dd не знает.
Проблема становится чуть проще, если dd-ить не весь диск, а только отдельный раздел. Ну и потом воспользоваться fstrim, чтобы отрезать свободное место.
А вообще использование LVM и разбиение диска по типу «boot|swap|LVMpv» сильно облегчает жизнь в плане клонирования. Всё сводится к копированию (клонировать блок-в-блок необязательно) раздела boot. Затем подключаем том lvm на целевом диске в текущую группу томов (vgextend) и делаем pvmove для исходного диска (всё можно делать на работающей системе — она «мигрирует» достаточно быстно и совершенно безболезненно). Затем vgreduce старого тома — и вот у нас вся система оказалась на новом жёстком диске. Затем — либо прописываем в /etc/fstab uuid нового раздела boot, либо с помощью tune2fs копируем uuid со старого тома (перед этим — чтобы не нервировать систему — uuid изначального boot чуть правим. Например, увеличиваем на единичку). Ну и всё. Финальный grub-install — и мы целиком на новом диске! При этом в случае с ssd неиспользуемые части диска оказываются в trim (pvcreate делает trim раздела при создании тома. А pvmove, разумеется, двигает только фактически заполненные экстенты).
Он окажется весь «забит» — поскольку ни о каком trim dd не знает.
Проблема становится чуть проще, если dd-ить не весь диск, а только отдельный раздел. Ну и потом воспользоваться fstrim, чтобы отрезать свободное место.
А вообще использование LVM и разбиение диска по типу «boot|swap|LVMpv» сильно облегчает жизнь в плане клонирования. Всё сводится к копированию (клонировать блок-в-блок необязательно) раздела boot. Затем подключаем том lvm на целевом диске в текущую группу томов (vgextend) и делаем pvmove для исходного диска (всё можно делать на работающей системе — она «мигрирует» достаточно быстно и совершенно безболезненно). Затем vgreduce старого тома — и вот у нас вся система оказалась на новом жёстком диске. Затем — либо прописываем в /etc/fstab uuid нового раздела boot, либо с помощью tune2fs копируем uuid со старого тома (перед этим — чтобы не нервировать систему — uuid изначального boot чуть правим. Например, увеличиваем на единичку). Ну и всё. Финальный grub-install — и мы целиком на новом диске! При этом в случае с ssd неиспользуемые части диска оказываются в trim (pvcreate делает trim раздела при создании тома. А pvmove, разумеется, двигает только фактически заполненные экстенты).
Костыль интересный.Статью копирну до востребования
Не смотрели на autossh? Собрать livecd c ним и c соответствующими настройками — и получается замечательный коннект по ssh к целевой системе.
Сам так ставил не одну gentoo без физического доступа к железу.
Сам так ставил не одну gentoo без физического доступа к железу.
Хм… По описанию autossh выходит, что это утилита предназначена для поддержки SSH-соединения клиентской машины с удаленной, место ей в данной конкретной ситуации на ноутбуке, а не livecd. Задача — автоматически поднять на целевой машине SSH-сервер, а не клиент — совершенно же другая вещь, видимо, я вас не очень понял. А вот
Собрать livecd… c соответствующими настройками— это действительно задача, и она непроста. Да я и описал это все в п. 3 «Альтернативных...»
Да, именно так. Но не стоит забывать о том, что ssh умеет туннели — им на данном этапе можно и воспользоваться, autossh нужен всего лишь для автоподнятия туннеля.
А модифицировать livecd — совершенно несложная задача: разобрать squashfs той же архитектуры, убедиться в наличии необходимых библиотек (для autossh их не нужно при наличии sshd), просто скопировать содержимое пакета autossh на распакованную fs и собрать livecd обратно. Это потребует гораздо меньше работы, чем описанный у Вас в посте способ.
А модифицировать livecd — совершенно несложная задача: разобрать squashfs той же архитектуры, убедиться в наличии необходимых библиотек (для autossh их не нужно при наличии sshd), просто скопировать содержимое пакета autossh на распакованную fs и собрать livecd обратно. Это потребует гораздо меньше работы, чем описанный у Вас в посте способ.
Вот допустим есть удобная вещь: systemrescuecd. Не могу пока найти, как его разобрать, сменить пароль root и собрать назад. Для начала.
Кажется, оффстатьи должно хватить. Учитывая, что я никогда не работал с Gentoo — это совсем не так просто :) Статейка там заметно подлинее моей.
Sign up to leave a comment.
Установка Debian на физически доступную систему без монитора и клавиатуры