Понадобилось мне переустановить сервер, который как бы хостился у знакомых знакомых. Там был сильно устаревший Debian, а, самое главное, система стояла на обычных разделах без lvm и пространство было распределено очень не оптимально. Физический доступ получить к нему было практически нереально, местного админа попросить что-то сделать было можно, но занять это могло неделю. Виртуальный KVM у сервера был, но извне на него попасть было нельзя; у как бы хостера не было лишних IP-адресов, а внутрь его сети попасть было невозможно. Надо было переустановить сервер из-под работающей системы по ssh. Ага, давайте поменяем ротор у турбины не выключая, потом её перезапустим и будет она с новым ротором работать!

Первой идеей было создать chroot окружение на ram-диске и с него создать lvm и залить систему. Но не тут-то было, не дает система изменить таблицу разделов.

Второй идеей было взять исходники дистрибутива Debian, зашить в них IP-адрес сервера, пересобрать initrd с установщиком Debian, ssh сервером и моими IP, подставить этот initrd в конфиг grub блоком по умолчанию и перегрузиться. После этого я должен был получить ssh консоль с сетевым установщиком. На стенде у меня получилось! Но на бою все окончилось неудачей, сервер не поднялся. Хозяевам сервер оказался не очень нужен, и дело так и заглохло, но у меня осталось ощущение нерешенной задачи.

Как-то с коллегами обсуждали всякие деструктивные действия с системой (типа rm -rf /) и один из коллег сказал, что можно отключить scsi диск, на котором находится корневой раздел и система не пикнет. Это дало мне идею номер три, взять идею один, оторвать диск, вернуть диск и возвращенный диск будет уже другим, не тем который система не отдавала. Именно так и оказалось. А теперь по пунктам, как же все-таки переустановить систему без доступа к физической консоли.

Предупреждение! Надо понимать, что все, что мы будем делать — дорога в один конец, при ошибке мы теряем доступ к системе! Вполне возможно, что придется ехать 1500 километров и лезть в шахту, чтобы реанимировать сервер.

Будем считать, что IP нашей системы 192.168.56.102. Именно так было у меня на стенде. Плюс доступ к интернету через прокси:

http://proxy:8080

Начинаем работу на исходной системе.

# System #0


Заходим по ssh на сервер:

ssh 192.168.56.102

Создаем каталог и файловую систему для «Системы убийцы», монтируем её:

mkdir /target
mount none -t tmpfs -o size=1G /target/

Ставим отличную утилиту debootstrap, которая разворачивает минимальную установку Debian, при помощи неё мы создадим chroot окружение:

export http_proxy='http://proxy:8080'
apt-get -y install debootstrap

Существуют аналогичные утилиты для Федоры и Centos, соответственно febootstrap и yumbootstrap, но я с ними не работал.

Разворачиваем chroot:

debootstrap jessie /target/ http://mirror.mephi.ru/debian/

Первый аргумент — версия, второй — каталог установки, третий — репозиторий.

Бекапим самое необходимое:

mkdir /target/backup
cp /etc/network/interfaces /target/backup

Самое важное — настройки сетевых интерфейсов, без них не получится попасть в переустановленную систему.

Даем имя chroot-окружению:

echo "Killer_system" > /target/etc/debian_chroot

Слово «Killer_system» будет показываться в приглашении bash. Это важная штука, без неё будет не понятно, где мы в данный момент находимся.

Переходим в новое окружение.

# System #1


chroot /target

Монтируем полезные fs:

mount none -t proc /proc/
mount none -t sysfs /sys/
mount none -t devtmpfs /dev/
mount none -t devpts /dev/pts/

Еще раз ставим debootstrap:

apt-get -y install lvm2 debootstrap

Дальше мои заморочки: у дебиановского пакета openssh-server в рекомендованных пакетах есть пакет xauth, а у него в зависимостях всякие иксовые библиотеки. Я, как сторонник минимализма, не хочу, чтобы на сервере, где не было и не будет графики, ставились огрызки иксов. Поэтому ставим с ключиком --no-install-recommends:

apt-get -y install openssh-server openssh-client openssh-blacklist openssh-blacklist-extra --no-install-recommends

Правим конфиги. Ставим альтернативный порт для ssh демона, чтобы мы могли зайти на chroot систему по ssh:

sed -i 's/^Port .*$/Port 11122/' /etc/ssh/sshd_config

И разрешаем доступ для root:

sed -i 's/^PermitRootLogin .*$/PermitRootLogin yes/' /etc/ssh/sshd_config
/etc/init.d/ssh restart

Можно не давать доступ root, а создать пользователя и дать ему sudo права, но тут я сознательно упрощаю.

Дальше надо задать пароль root, так как по умолчанию debootstrap не устанавливает никакие пароли:

passwd root

Заходим в chroot окружение по ssh:

ssh 192.168.56.102 -l root -p 11122

Это мы делаем для того, чтобы полностью отвязаться от старой системы, у которой мы оторвем диски. А так у нас будет полностью автономная система в оперативной памяти, никак не связанная со старой.

Такой трюк очень хорошо подходит, если мы уходим от хостера, а оставлять ему наши файлы очень не хочется (я знаю, паранойя). На этом этапе просто забиваем диски нулями, если хотим быстро:

dd if=/dev/zero of=/dev/sda bs=1M

Или случайными данными в несколько проходов, если хотим хорошо. Достоинство метода в том, что мы можем дождаться окончания работы dd и, при необходимости, повторить. Если же затирать диски непосредственно из боевой системы, то посмотреть на результаты работы dd мы уже не сможем.

Попробуем простой путь, удалим тома и разделы:

# lvremove /dev/mapper/vg_old-root
  Logical volume vg_root/lv_root contains a filesystem in use.

# fdisk /dev/sda
Command (m for help): d
Selected partition 1
Partition 1 has been deleted.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

Но неудача. При этом раздел удалится, и система сломается, но воспользоваться простым путем без перезагрузки не получится. А перегружаться будет некуда.

Мы пойдем другим путем. Проверяем, где у нас что находится:

pvs
lsblk

Будем считать, что корневой раздел у нас на диске sda.

Затираем диск, чтобы ни в коем случае его не подцепил lvm.

Предупреждение! После этого момента возврата нет, даже следующий шаг не такой вредоносный. Задумаемся на минуту, проверим консоль, за которой сидим и оправдаем имя нашего chroot'а:

dd if=/dev/zero of=/dev/sda bs=1M count=100

Отрываем диски:

echo 1 > /sys/block/sda/device/delete

Проверяем, диск оторвался:

lsblk

Подключаем диск обратно:

for i in /sys/class/scsi_host/host?/scan ; do echo "- - -" > $i ; done

Проверяем, что вернулось:

lsblk

Был sda, стал sdb, отлично.

Важный момент: на згрузочном диске необходимо создать один первичный раздел размером на весь диск и этот раздел отдать lvm'у для того чтобы на него смог встать grub. Все остальные диски можно отдавать lvm'у целиком не создавая систему разделов (pvcreate /dev/sdc). Создаем таблицу разделов и один первичный раздел типа 8e, Linux LVM:

fdisk /dev/sdb
n<CR> <CR> <CR> <CR>
t<RC> 8e<CR>
w<CR>
# create new primary partition from start to end; 8e type

В первоначальной версии скрипта было создание одного логического тома под всю систему, но когда мой коллега переустанавливал Linux по этому скрипту, оказалось, что создание нескольких разделов представляет некоторую трудность, особенно отдельный раздел под логи. Внимание надо обратить на порядок создания точек монтирования и собственно монтирования разделов.

pvcreate /dev/sdb1
vgcreate vg_root /dev/sdb1
lvcreate -Zn -L500M -n lv_swap0 vg_root
lvcreate -Zn -L1G -n lv_root vg_root
lvcreate -Zn -L2G -n lv_usr vg_root
lvcreate -Zn -L2G -n lv_var vg_root
lvcreate -Zn -L1G -n lv_var_log vg_root
lvcreate -Zn -L1G -n lv_home vg_root

mkswap /dev/vg_root/lv_swap0
mkfs.ext4 /dev/mapper/vg_root-lv_root
mkfs.ext4 /dev/mapper/vg_root-lv_usr
mkfs.ext4 /dev/mapper/vg_root-lv_var
mkfs.ext4 /dev/mapper/vg_root-lv_var_log
mkfs.ext4 /dev/mapper/vg_root-lv_home

mkdir /target
mount /dev/mapper/vg_root-lv_root /target/
mkdir /target/usr /target/var /target/home
mount /dev/mapper/vg_root-lv_usr /target/usr
mount /dev/mapper/vg_root-lv_var /target/var
mkdir /target/var/log
mount /dev/mapper/vg_root-lv_var_log /target/var/log
mount /dev/mapper/vg_root-lv_home /target/home

Разворачиваем уже боевую систему на новое место на жестком диске:

export http_proxy='http://proxy:8080'
debootstrap jessie /target/ http://mirror.mephi.ru/debian/
echo "NEW_system" > /target/etc/debian_chroot

Возвращаем на место резервные копии конфигов:

cp /backup/interfaces /target/etc/network

Теперь нас ждет новая система:

# System #2


chroot /target

Обратите внимание, в приглашении командной строки теперь имя нового chroot окружения.

Монтируем файловые системы:

mount none -t proc /proc/
mount none -t sysfs /sys/
mount none -t devtmpfs /dev/
mount none -t devpts /dev/pts/

Ещё можно примонтровать эти файловые системы из родительского chroot'а:

mount -o bind /proc/ /target/proc
mount -o bind /sys/ /target/sys
mount -o bind /dev/ /target/dev
mount -o bind /dev/pts /target/dev/pts

Устанавливаем и конфигурируем openssh:

apt-get -y install openssh-server openssh-client openssh-blacklist openssh-blacklist-extra --no-install-recommends

sed -i 's/^PermitRootLogin .*$/PermitRootLogin yes/' /etc/ssh/sshd_config
passwd root

Устанавливаем пакеты, без которых не обойтись:

apt-get -y install vim sudo linux-image-3.16.0-4-amd64 grub2 lvm2 psmisc vlan 

Да, я не могу жить без vim и ненавижу nano:

update-alternatives --set editor /usr/bin/vim.basic

В принципе grub прописывается куда надо ещё при установке, но, всё же, для поддержки штанов и морального духа повторим:

update-grub
grub-install /dev/sdb

Теперь правим конфиги, вначале самый важный, без которого система не поднимется:

cat > /etc/fstab <<EOF
# /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>

/dev/mapper/vg_root-lv_root      /               ext4    errors=remount-ro 0       1
/dev/mapper/vg_root-lv_usr       /usr            ext4    defaults          0       2
/dev/mapper/vg_root-lv_var       /var            ext4    defaults          0       2
/dev/mapper/vg_root-lv_var_log   /var/log        ext4    defaults          0       2
/dev/mapper/vg_root-lv_home      /home           ext4    defaults          0       2

EOF

В файле interfaces все должно быть в порядке, ведь как-то сеть у нас работала?

vim /etc/network/interfaces

В конфиг apt'а добавляем информацию о прокси:

echo 'Acquire::http::Proxy "http://proxy:8080";' > /etc/apt/apt.conf

Меняем hostname:

echo new-system > /etc/hostname

Добавляем строчку в /etc/hosts:

echo "192.168.56.102 new-system.corp new-system" >> /etc/hosts

Добавляем админа:

adduser admin
usermod -a -G sudo admin
visudo

Размонтируем файловые системы:

umount /dev/pts
umount /dev/
umount /proc/
umount /sys/

И выходим из chroot'а:

exit

Размонтируем файловые системы:

umount /target/usr/ /target/var/log/ /target/var/ /target/home/

Если размонтировать /dev не удалось, то не удастся размонтировать и /target, но это не страшно.

Если удалось, то делаем так:

umount /target/

Если нет, то так:

sync ; sync ; sync ; mount -o remount,ro /target/

Эти команды сбросят дисковые кеши и перемонтируют корневую файловую систему в read only. После этого можно перегружаться.

Тут-то нас ждет сюрприз от всеми любимого systemd! Он знает, что мы в chroot и не дает перегрузиться! Google дает советы выйти из chroot, но нам-то выходить некуда. Но на помощь приходит Magic SysRq!

Активируем SysRq (он, скорее всего, активирован, но нам же надо убедиться?).

echo 1 > /proc/sys/kernel/sysrq

И перегружаемся:

echo b > /proc/sysrq-trigger

Барабанная дробь, тревожное ожидание, неужели мы что-то забыли, и сервер не поднялся?

ssh 192.168.56.102

Ура! Мы в новой системе!

Пересоздадим initrd. Это не обязательно, но в дальнейшем избавит от некоторых ошибок при перезагрузке:

update-initramfs -u

Удаляем файлик с именем chroot окружения:

rm /etc/debian_chroot

Вот и все.

## The end

Ссылки:


Интересная статья способах перегрузки сервера
Поделиться с друзьями
-->

Комментарии (68)


  1. daggert
    13.02.2017 13:22
    +26

    Так гланды еще никто не удалял…

    Отличная статья!


    1. ghostinushanka
      13.02.2017 19:52
      +3

      Я всё читал и ждал «и вдруг связь оборвалась...»


      1. mayorovp
        13.02.2017 20:20

        Но на бою все окончилось неудачей, сервер не поднялся. Хозяевам сервер оказался не очень нужен, и дело так и заглохло, но у меня осталось ощущение нерешенной задачи.

        Я так понял, все что после этого — лишь игры на стенде.


        1. ioannes
          13.02.2017 21:12

          Да, все что после — игры на стенде. Больше не было нужды что-то такое сделать.


          1. mahovik77
            15.02.2017 10:23
            +1

            а apt-get update & apt-get upgrade — не?


            1. ioannes
              15.02.2017 11:44

              Это обновит систему, а основной цель был перераспределить место на диске.


              1. ioannes
                15.02.2017 11:48

                Хотя, по-моему, при переходе с Lenny на Squeeze были сложности с конфигурацией сети. За давностью подробностей не помню, но вроде сеть оно внезапно теряло…


            1. Meklon
              16.02.2017 22:50
              +1

              apt-get dist-upgrade, же.


              1. ioannes
                17.02.2017 11:45

                Не, не, не. С dist-upgrade проблем не было.
                Проблема была в том, что при обновлении ломалась сеть после перезагрузки.


    1. catharsis
      14.02.2017 11:43

      что-то подобное было популярно во времена FreeBSD, например при смене архитектуры i386 -> x86_64


  1. mikkisse
    13.02.2017 13:25
    +2

    Просто блеск, люблю статьи подобного рода.


  1. Ajex
    13.02.2017 13:40

    Прочитал как детектив, особенно после слов о том, что в случае ошибки надо ехать 1500 км…


    1. respectoss
      14.02.2017 10:18

      не то слово, прочитал как на духу!


  1. ls1
    13.02.2017 13:46

    Виртуальный KVM у сервера был, но извне на него попасть было нельзя; у как бы хостера не было лишних IP-адресов, а внутрь его сети попасть было невозможно
    Если например удаленная система стоит за NAT, можно во внутренней сети там поместить хост, который будет устанавливать VPN подключение к вашему внешнему VPN серверу, в таком случае этот хост можно считать «AccessServer'ом», через него можно например подключиться к ilo/ipmi/kvm-админке
    Предупреждение! Надо понимать, что все, что мы будем делать — дорога в один конец, при ошибке мы теряем доступ к системе! Вполне возможно, что придется ехать 1500 километров и лезть в шахту, чтобы реанимировать сервер.
    Если это тестовый сервер для удаленной компиляции «hello world» — не беда, а если продуктовый — то всё же AccessServer надо иметь.


  1. Meklon
    13.02.2017 14:15
    +16

    Ух. Самая эпическая трансректальная тонзиллэктомия автогеном, которую я видел. Восхитительно)


    1. Evengard
      13.02.2017 18:41
      +1

      Я не врач, но даже я восхитился этакому загибу)))


    1. ToSHiC
      13.02.2017 21:26
      +3

      Да не, я прикольнее делал. Надо было обновить OpenBSD с ветки 2.х до 3.0, попутно они поменяли дефолтный формат исполняемых файлов с a.out на elf, то есть новые бинарники не работали со старым ядром и наоборот. Вдогонку, бутлоадер тоже надо было обновить. Всё это было установлено на роутере, который стоял на крыше пятиэтажки, метрах в 300-400 от моего дома.

      В итоге я написал и отладил на виртуалке чудо-скрипт, который сначала самые важные бинарники типа cp сохранял в закромах, потом всё сносил, кроме конфигов, с нуля разворачивал новый мир и ядро, и после этого дёргал прописывание нового бутлоадера. И оно даже отработало само!


      1. ioannes
        14.02.2017 09:57
        +1

        Да, это еще круче!


  1. Himura
    13.02.2017 14:19

    шедевр админского искусства! Реально читается как детектив)) Спасибо за приоткрытие восхитительный таинств линукса)


    1. RussianNeuroMancer
      13.02.2017 19:51
      +1

      Ещё один детектив: https://medium.com/@george.shuklin/my-upgrade-from-i386-to-amd64-and-fix-dpkg-without-dpkg-72c730369912


  1. kay
    13.02.2017 14:30

    Я проделывал такое через dropbear в initramfs. А еще лучше написать какую-нибудь автоматизацию с помощью того же ansible и проверять скрипты в kvm.


  1. pupsegadm
    13.02.2017 14:35
    +2

    Великолепно!
    Можно сравнить с:
    «удаленное конфигурирование файерволла — к дальней дороге» (с) IT-мудрость.


  1. SchmeL
    13.02.2017 15:13

    Как вариант можно было бы попробовать развернуть debootstrap на сетевом блочном устройстве.


  1. Boneyards
    13.02.2017 15:21

    Мощно!


  1. DarkByte
    13.02.2017 16:10
    +2

    Как раз недавно увидел скрипт takeover.sh. Для желающих повторить описанное в статье.


  1. maydjin
    13.02.2017 16:21

    Круто!


  1. inkvizitor68sl
    13.02.2017 16:29

    https://www.opennet.ru/tips/3007_linux_remote_install_ssh_init_busybox_mount.shtml
    Вы сегодня сговорились все =)


    1. ioannes
      14.02.2017 10:04
      +1

      Это идеи в ноосферу прорываются.


  1. click0
    13.02.2017 20:14

    Как все сложно.
    Качается нужный Live-CD образ, ставится GRUB, подправляется конфиг, чтоб при старте грузил LiveCD образ.
    Дальше перегружаем сервер и коннектимся по ssh в Live-CD.
    Дальше уже ставим нужную вам OS.
    Если сетевые настройки не по DHCP, то чуть больше шаманства.


    1. mayorovp
      13.02.2017 20:21

      Так и было сделано изначально же.


      Но на бою все окончилось неудачей, сервер не поднялся. Хозяевам сервер оказался не очень нужен, и дело так и заглохло, но у меня осталось ощущение нерешенной задачи.


      1. click0
        13.02.2017 20:25

        Надо полноценно тестировать перед применением.
        Я так понял, у автора куча свободного времени, он нарисовал портянку сразу на хабре и опеннете.


        1. mayorovp
          13.02.2017 20:26

          Извиняюсь, но вы вообще вступление к посту читали?


          На стенде у меня получилось!


          1. click0
            13.02.2017 21:24

            Поэтому и я написал — полноценно тестировать.


        1. ioannes
          13.02.2017 21:13
          +1

          На опеннете не я…


  1. konstantine_tomsk
    13.02.2017 21:13
    +2

    В статье один общий раздел под lvm создаётся fdisk'ом и это правильно, т.к. если создавать через cfdisk, то он начнёт отсчёт с 63-его сектора из за чего потом grub-install не сможет вам заинсталить загрузчик из за не достаточного места:

    warning: your core.img is unusually large.  It won't fit in the embedding area.
    error: embedding is not possible, but this is required for RAID and LVM install.
    

    fdisk в свою очередь по умолчанию начинает отсчёт с 2048 сектора, чего в полне хватает для grub загрузчика с поддержкой lvm.


  1. evgkul
    13.02.2017 21:13

    Ещё можно qemu использовать для проверки того, не накосячил ли где


  1. ogost
    14.02.2017 10:09
    +1

    Можно проще, идея с хабра:
    1. ставим «новую» систему на swap при помощи debootstrap, настраиваем GRUB, грузимся с неё
    2. размечаем диск как хотим
    3. копируем со swap-а новую систему на вновь размеченную, перенастраиваем GRUB, грузимся с нового раздела
    4. возвращаем swap.
    Сам неоднократно проделывал такие операции, единожды терял доступ к новой системе по собственной ошибке (на ssh отключил доступ рута, а нового пользователя не создал)


    1. legioner
      15.02.2017 06:23

      именно так (или почти так) работает depenguinator


  1. ioannes
    14.02.2017 10:18
    +1

    Не пройдет.
    В истории о которой я писал, было так:
    1. Один диск.
    2. Система установлена в MBR разделы, без LVM.
    3. Необходимо сконфигурировать LVM.

    При попытке сделать pvceate на существующий раздел, LVM отвечает, что раздел занят.
    Удаление и создание раздела не приводит к резильтату, т.к. ядре не обновляет таблицу разделов т.к. разделы заняты.
    Тупик.

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


    1. arheops
      14.02.2017 20:22

      Ну так перегрузиться после установки системы в swap, не?


    1. ogost
      15.02.2017 08:36

      Оу, а lvm-то мы не заметили. Извиняюсь, правда ваша


      1. ioannes
        15.02.2017 10:20

        Если нужно просто переставить и переразбить слегка разделы, свап самое то.

        Сейчас я без LBM'а Linux не ставлю.


  1. mikhailnk
    14.02.2017 11:10
    +2

    Интересный вариант. Видимо, в шахте особо ограничений на канал нет :)

    Как альтернатива:

    1. локально сделать «эталон» (учитывая специфику железа, особенно контроллер и сеть). Естественно, диск разбить с LVM, но так, чтобы потом можно было растянуть на весь диск;
    2. используя связку dd/nc залить образ на диск по сети;
    3. отправить в ребут (можно тем же способом);
    4. пойти поставить свечку и молиться, чтобы не пришлось заказывать вертолёт до объекта;
    5. растянуть LVM как требуется;
    6. перенести приклад.


    Очень знакомая тема, выполнялось такое многократно.
    Про связь оборвалась — был подобный опыт, выкрутиться можно, но седые волосы появятся.


    1. ioannes
      14.02.2017 11:18

      О, да. так эффективней. Трафик экономится. Но практически нет контроля, нет фидбека от груба, на пример. Шаг в право, шаг в лево, небольшая разница в дисках и все.

      Думаю, можно консолидировать подходы. Микрочрут в памяти накатить таром, потом отрываем диски, возвращаем, заливаем образ dd, чрутимся в него и делаем grub-install.
      Контроля чуть больше.


      1. mikhailnk
        14.02.2017 11:23
        +1

        Да, в каждой ситуации свой подход (иногда человеческий фактор приводит к интересным ситуациям… с точки зрения восстановления). Разница в дискам не важна: все можно подправить после ребута, в том числе таблицу разделов. Главное чтобы диск и сеть были видны новой ОС.
        Желательно менеджмент порт на удаленных площадках. Либо второй хост с PXE и управление питанием.


  1. remzalp
    14.02.2017 11:51

    Слишком жестокий метод получился.
    Упущено сообщение fdisk:
    1. The new table will be used at the next reboot or
    2. after you run partprobe(8) or kpartx(8).
    В итоге пошли на сложные страшности.


  1. ioannes
    14.02.2017 11:56

    А вот я сейчас попробую на моем стенде так ли это!


    1. ioannes
      14.02.2017 13:55

      Попробовал.

      Неудача:
      # fdisk /dev/sda
      
      Command (m for help): p
      Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
      
      Device     Boot  Start      End  Sectors  Size Id Type
      /dev/sda1  *      2048   499711   497664  243M 83 Linux
      /dev/sda2       501758 16775167 16273410  7.8G  5 Extended
      /dev/sda5       501760 16775167 16273408  7.8G 8e Linux LVM
      
      Command (m for help): d
      ...
      
      Command (m for help): w
      Re-reading the partition table failed.: Device or resource busy
      
      The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
      
      # fdisk -l /dev/sda
      Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
      
      Device     Boot Start      End  Sectors Size Id Type
      /dev/sda1        2048 16777215 16775168   8G 8e Linux LVM
      
      # pvcreate /dev/sda1
        Cant open /dev/sda1 exclusively.  Mounted filesystem?
      
      
      # apt-get install  kpartx parted
      
      # partprobe
      Error: Partition(s) 1, 5 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
      
      # kpartx -l /dev/sda
      sda1 : 0 16775168 /dev/sda 2048
      
      # kpartx -a /dev/sda
      device-mapper: reload ioctl on sda1 failed: Invalid argument
      create/reload failed on sda1
      
      
      # kpartx -f /dev/sda
      sda1 : 0 16775168 /dev/sda 2048
      
      # kpartx -fa /dev/sda
      device-mapper: reload ioctl on sda1 failed: Invalid argument
      create/reload failed on sda1
      


      1. navion
        14.02.2017 22:39

        Может зависит от версии ядра? На CentOS 6 тоже не работает, зато прекрасно работает на семёрке.


        1. ioannes
          15.02.2017 10:18

          Возможно. У меня Дебиан:

          $ lsb_release -a
          No LSB modules are available.
          Distributor ID: Debian
          Description:    Debian GNU/Linux 8.0 (jessie)
          Release:        8.0
          Codename:       jessie
          
          $ uname -a
          Linux jessie0 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux
          
          


  1. dron_k
    14.02.2017 12:57

    Получился отличный сценарий для сцены фильма где хакеру нужно чтото пошаманить.
    Думаю айтишники бы заценили попадись такое в кино ))


  1. orthanner
    14.02.2017 13:00

    Чумовая статья. Читал, затаив дыхание.


  1. Zegaldis
    14.02.2017 17:22

    Однозначно чумовая статья! :)


  1. Rulin
    14.02.2017 19:03
    -1

    > местного админа попросить что-то сделать было можно, но занять это могло неделю
    А описанный в статье действия, сколько недель суммарно заняли?


  1. arheops
    14.02.2017 20:13
    +1

    а еще все современные дистрибутивы умеют установку по vnc, и это делается в пару строчек.
    в случае отсутвия cd/dvd, они так же поддерживают vnc инсталяцию с загрузкой образа по сети.


    1. ioannes
      14.02.2017 20:20

      А как запустить установку без доступа к апаратной консоли/KVM? Плюс статический реальный IP в чужой сети?


      1. arheops
        14.02.2017 20:27
        +1

        В смысле? Это ж стандартная практика. Вы в grub вписываете строчку, которая запускает вместо kernel образ netinstall с ISO диска. netinstall как параметры получает адреса сети и пароли, все запускается и не зависит от потери связи. Ну вот пример для centos 7 http://www.danpros.com/2016/02/how-to-install-centos-7-remotely-using-vnc. Если у вас нет такого образа netinstall, он элементарно делается на основе isolinux с вашего диска.


        1. ioannes
          15.02.2017 10:23

          Ок, следующая статья будет про мою неудавшуюся попытку более подробно.
          А точнее про конфигурацию и компиляцию debian-installer'а. Крутейшая вещь!


      1. arheops
        14.02.2017 20:32

        Просто kvm это реально редкий зверь в мире дешевых хостингов, удаленных серверов в говно-датацентрах и аутсорс-админов. Люди давно подсуетилися, еще лет 5 назад.


  1. ioannes
    14.02.2017 20:15

    Да, тут вы меня поймали! Мне, по разным причинам, совсем не хотелось с тамошними админами общаться.


  1. ony
    15.02.2017 10:34
    +2

    Может можно использовать pivot_root как это делает initrd обычно? Т.е. сделать тоже самое что и initrd только на оборот.


    1. создаём RAM disk (если нет возможности создать раздел на диске)
    2. pivot_root внутрь.
    3. подымаем нужные сервисы явно
    4. гасим все сервисы из старой системы.
    5. отмонтируем старую файловую систему.
    6. делаем что хотим с дисками

    Вариант с initrd — кажется более надёжным. Только эксперементировать с загрузкой, наверное, стоит через kexec. И стоит внутри initrd сделать какой-то watchdog который перезагрузит систему назад если в течении какого-то времени никто не зайдёт в неё по ssh. Ну и panic должен быть указан так чтобы в случае такой ситуации система перезагрузилась.


    1. ioannes
      15.02.2017 10:52

      Я думал о watchdog, но я так и не придумал, как обойти вот это:
      1. Прописываем в груб как пункт по умолчанию ядро и initrd установщика. Мы ведь не можем выбрать другой пункт меню груба, у нас же нет доступа к консоли?
      2. Доступа мы не получаем, срабатывает собака, мы перегружаемся. Но как мы поменяем пункт по умолчанию в грубе? как выбрать при первой перезагрузке один пункт меню, а при второй другой?

      Может я чего-то в грубе не раскопал?


      1. ony
        15.02.2017 13:44
        +1

        watchdog нужен для загрузки через kexec. Т.е. grub вообще не загружается в этом случае. Если загруженная система через kexec детектится как нерабочая (kernel panic или watchdog срабатывае), то происходит обычная перезагрузка и grub загружает обычную систему.


        Если всё же хочется через grub, то во второй версии, вроде по умолчанию запоминается последний выбранный пункт (при включенном GRUB_SAVEDEFAULT). Скорее всего, как-то связанно с grub-editenv. Наверное, можно и скрипт написать в нём или уже в initrd.
        Но я всегда боюсь трогать grub. И незнаю почему, но с первой версией grub'а я чувствовал себя немного уверенее.


        1. ioannes
          15.02.2017 14:10

          kexec это, похоже, то что надо!
          Обязательно попробую.

          И да, grub2 это тот еще монстр. Первый был сильно проще.
          А еще лучше lilo!


  1. imintsev
    15.02.2017 15:04

    Мало что понял в силу необразованности, но жутко интересно. :)
    Спасибо за статью. Узнал много нового.


  1. steamoor
    16.02.2017 07:31
    +1

    Была у меня схожая задача, когда мне нужно было с Редхата переехать на Дебьян.
    году так в 2002-м.
    Удалённый сервер в коло, где то в штатах. Опции поставить Деб у них не было. КВМ тоже.
    Слава богу кто то такой же добрый написал в Интернете примерные шаги, как сделать всё красиво.
    Свободного места там не было, пришлось форматить свап партицию и бутстрапить деб там. Grub'ом тогда не особо пользовались, поэтому был Lilo, у которого есть замечательная команда -R, позволяющая временно загрузиться со второго диска. И если обломится то по перегрузу или резету загрузиться обратно в основную систему.
    Сделал я тогда всё. Обломался только на индексации сетевых интерфейсов в новом ядре. Пришлось пользоваться услугой техников датацентра, чтобы зашли и поменяли файл в системе.


    Я смотрю с тех пор шаги почти не поменялись, только с Grub'ом пляски :)


  1. ElegantBoomerang
    16.02.2017 09:46
    +1

    А не думали ли вы сделать pivot_root в tmpfs? Получили бы корректно примонтированный (но пустой) неиспользуемый диск, не надо на уровне железа развлекаться. По-сути быстро перезагрузились бы в tmpfs, получили себе как будто LiveCD, но с ssh.


  1. ioannes
    16.02.2017 09:49

    Нет, я был не в курсе таких прекрасных инструментов.
    Но мне выше написали про pivot_root и kexec. Буду пробовать.