Установка Debian на физически доступную систему без монитора и клавиатуры

[zebraxxl]

Эх, эту статейку бы мне полгода назад — сэкономило бы пару вечеров =) В итоге всё так же делал. Правда не было необходимости переноса системы — устанавливал из под VirtualBox сразу на целевой диск.

Кстати тогда у меня ещё сеть не сразу завелась — после запуска ОС (только это была Ubuntu Server) она увидела новую сетевую карту, обозвала её eth1 (eth0 осталась за сетевой картой VirtualBox) и не захотела автоматически поднимать линк на ней.

[ramntry]

… не захотела автоматически поднимать линк на ней

Жизнь была бы невыносимо скучной, кабы не было таких «подарков» от софта и оборудования. И как решили проблему, если не секрет?

[zebraxxl]

В /etc/network/interfaces:

iface eth0 inet dhcp
auto eth0

[zebraxxl]

Ой, толькое не eth0, а eth1

[stilet]

если удалить файлик /etc/udev/rules.d/70-persistent-net.rules перед переносом веника на новое железо, то интерфейсы заново будут нумероваться с eth0

[zebraxxl]

Я в последствии файл просто отредактировал а не удалял.

[ramntry]

спасибо (голосовать я пока не могу)

[Pilat]

Пол года назад уже была доступна статья habrahabr.ru/post/103743/, где описывается установка Debian с помощью network-console, даже физический доступ не нужен. Можно даже ухитриться образ CDROM по TFTP подтянуть.

[zebraxxl]

Кстати можно ещё создать такой preseed, что бы сам установщик поднимал ssh и саму установку проводить по нему. Правда у меня так этого и не получилось =(

[ramntry]

Вообще говоря, решены были не все проблемы. Одна из запланированных схем использования целевой машины — 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'

валится с segmentation fault от иксов. Инсталлятор с оффсайта Qt не запустить, потому что он графический — не может открыть дисплей, а собирать Qt самому и прописывать все пути и конфиги как-то не улыбается совсем. Как решать проблему — неясно. Переходить на другой дистрибутив не хочется — на VDS тоже debian 6, на буке также debian-based ось (учитывая плюшки вроде distcc это упрощает жизнь), он мне нравится хорошей документацией и стабильностью.

[ramntry]

А инсталляция полностью testing-дистрибутива зависает на выборе наборов ПО как в графическом, так и в псевдографическом режимах =( Похоже, самый разумный выход — собирать Qt (вариант «дожидаться монитора» не подходит потому, что все тоже самое разворачивать на VDS и, вероятно, не раз еще с этим всем придется столкнуться)

[salvator]

SSH обычно по умолчанию форвардит экран с локальной машины. Не пробовали на удаленной системе запустить инсталлятор из консоли SSH? У меня в таком режиме gvim нормально из виртуалки работает.

[ramntry]

с ключом -X форвардит (с -Y еще и в обход системы безопасности X-сервера, хотя я слабо понимаю, что это) Весьма впечатляюще выглядит, круто!

[ramntry]

А кто-нибудь знает, как заставить приложение, запущенное благодаря ключу -X SSH (форвардинг гуи на локальную машину), при логауте оставаться рабочим? screen не помогает :(

[salvator]

ssh клиент можно запустить демоном с включенным форвардингом портов. ключи не омню, посмотрите в мануале.

[ramntry]

Еще один подводный камень — система может не загрузиться с подключенного к ней второго диска. Проблему стоит искать снова таки в /boot/grub/device.map — замените в нем VBox-овский UUID вашего диска на привычный /dev/-путь к нему в целевой системе или на реальный UUID (узнать его можно с помощью blkid), затем сделайте в виртуальной машине

# update-grub
# grub-install /dev/sdX
# update-grub

и снова пробуйте загрузить с диска целевую машину.

[juffinhalli]

А можно так.
#nano /etc/default/grub
…
GRUB_DISABLE_LINUX_UUID=true
…
#update-grub

[ramntry]

Хотя в общем случае UUID — это удобно. По понятным причинам.

[Iv8]

Если bios позволяет, можно просто консоль на последовательный порт вывести и спокойно ставить все в текстовом режиме из терминала.
Регулярно пользуюсь.

[ramntry]

Это-то да, только в оригинальной задаче единственная боеспособная машина — ноутбук. COM-порта у него нет, тут уж современные ноуты проигрывают своим дедам (что уж говорить, далего не на всякой нынешней full-ATX плате десктопов найдешь последовательный порт. Хорошо, если беготня за планками поправит дело)

[Iv8]

Пока еще переходники usb->rs 232 вполне доступны.

[klirichek]

Тогда уж лучше сразу переходник usb->sata, и ставить на 3,5 винт прямо с ноутбука.

[sarelius]

Чем лучше?

[ur3ckr]

Если не затруднит, не могли бы Вы ткнуть на ссылку, где бы про такую установку подробней почитать?

[Iv8]

Тут, например: geco.phys.columbia.edu/~jrollins/howtos/serial_console.html

[ramntry]

Верно. Как и COM-кабели, докстанции 3.5" дисков, клавиатуры, новые внешние 2.5" жесткие диски и мониторы (в порядке роста стоимости). Только мама-папа или папа-папа переходники SATA разве что на заказ откуда-нибудь, вот это жалко. Кстати, есть ли у exspresscard-адаптеров rs232 какие-нибудь преимущества перед usb-вариантами?

[ramntry]

Гм… Говорят, проблемы с usb-шными

[lolipop]

wiki.debian.org/Debootstrap

[ramntry]

а затем осуществить ручную установку дистрибутива Debian (этот процесс тоже хорошо описан в документации)

[klirichek]

С использованием 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, разумеется, двигает только фактически заполненные экстенты).

[Zack]

Костыль интересный.Статью копирну до востребования

[StamPit]

Не смотрели на autossh? Собрать livecd c ним и c соответствующими настройками — и получается замечательный коннект по ssh к целевой системе.
Сам так ставил не одну gentoo без физического доступа к железу.

[ramntry]

Хм… По описанию autossh выходит, что это утилита предназначена для поддержки SSH-соединения клиентской машины с удаленной, место ей в данной конкретной ситуации на ноутбуке, а не livecd. Задача — автоматически поднять на целевой машине SSH-сервер, а не клиент — совершенно же другая вещь, видимо, я вас не очень понял. А вот

Собрать livecd… c соответствующими настройками

— это действительно задача, и она непроста. Да я и описал это все в п. 3 «Альтернативных...»

[StamPit]

Да, именно так. Но не стоит забывать о том, что ssh умеет туннели — им на данном этапе можно и воспользоваться, autossh нужен всего лишь для автоподнятия туннеля.

А модифицировать livecd — совершенно несложная задача: разобрать squashfs той же архитектуры, убедиться в наличии необходимых библиотек (для autossh их не нужно при наличии sshd), просто скопировать содержимое пакета autossh на распакованную fs и собрать livecd обратно. Это потребует гораздо меньше работы, чем описанный у Вас в посте способ.

[ramntry]

Вот допустим есть удобная вещь: systemrescuecd. Не могу пока найти, как его разобрать, сменить пароль root и собрать назад. Для начала.

[ramntry]

Кажется, оффстатьи должно хватить. Учитывая, что я никогда не работал с Gentoo — это совсем не так просто :) Статейка там заметно подлинее моей.