Не загружался сервер с программным RAID1 на MD

Вчера ночью на одном из серверов вылетел жесткий диск из программного RAID1. Один из вариантов решения проблемы - программно отключить сбойный диск и затем вернуть его обратно, запустив поиск на SATA шине. Я уже как-то описывал этот способ тут.

Недостаток этого способа в том, что не всегда удается надолго вернуть в строй диск подобным способом. Более надежным будет отключить питание от диска и затем подключить его обратно. Поскольку у того сервера нет hot-swap корзины и была возможность отключить сервер, то я выключил и включил сервер (просто перезагрузить или нажать reset может быть недостаточно).

Однако после меню grub'а не последовала загрузка системы, а вместо этого меню ждала ошибка вида VolGroup00/swap not found. Через несколько секунд вывалилось приглашение initramfs и появилась возможность посмотреть причину сбоя.

Поскольку VolGroup00/swap - логический том поверх RAID1В /proc/mdstat не было ни одного массива (на сервере их два: md0 и md1). Смотрю в /etc/mdadm/mdadm.conf - нужные массивы на месте. Пробую запустить их вручную:

initramfs> mdadm -A /dev/md0
initramfs> mdadm -A /dev/md1

После этого нужные массивы появились в /proc/mdstat. Последним штрихом была активация томов LVM2

initramfs> vgchange -ay

Далее выхожу из initramfs (Ctrl+D) и система продолжает нормальную загрузку. После добавления сбойного диска обратно в массив и окончания ребилда, пробую снова перезагрузить сервер и спотыкаюсь о ту же ошибку.

После перепроверки всех настроек, пересборки initramfs я решил сравнить вывод mdadm --detail --scan и соответствующих секций в /etc/mdadm/mdadm.conf. И вот тут нашлось различие:

# mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name=finnix:0 UUID=d5824c5a:ecf39d9a:89c3b877:ec43e0c0
ARRAY /dev/md1 metadata=1.2 name=finnix:1 UUID=4c287c75:edef1139:07ca6e74:b0fcb0e6

# grep ^ARRAY /etc/mdadm/mdadm.conf
ARRAY /dev/md0 metadata=1.2 name=0 UUID=d5824c5a:ecf39d9a:89c3b877:ec43e0c0
ARRAY /dev/md1 metadata=1.2 name=1 UUID=4c287c75:edef1139:07ca6e74:b0fcb0e6

Различие в значении параметров name=. Заменяю описание актуальным и пересобираю initramfs.

# sed -i -e '/^ARRAY/d' /etc/mdadm/mdadm.conf
# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
# update-initramfs -u

После всех манипуляция перезагрузка прошла без проблем.

Wine 1.5.22 для Debian Squeeze/Wheezy

Собрал пакеты для свежей версии Wine 1.5.22. Анонс новой версии тут. Пакеты собраны для Debian Squeeze (i386, amd64) и Debian Wheezy (пока только i386). Взять можно в моем репозитарии.

В планах попробовать собрать multiarch для Wheezy, мне уже подкинули пару полезных ссылок, но пока не хватает свободного времени для этого.

Настройка планировщика ввода/вывода для дисков с поддержкой NCQ

Появление NCQ в SATA II дисках дало возможность перенести упорядочивание очереди запросов к жесткому диску на плечи самого диска. Сегодня мне довелось тестировать работу базы данных на программном RAID-0 и я решил попробовать NCQ для этой задачи. Чтобы исключить влияние планировщика Linux (сейчас по-умолчанию им является CFQ) я включаю планировщик noop (на самом деле noop не занимается переупорядочиванием запросов и служит для того, чтобы выключить планирование ввода/вывода для конкретного блочного устройства) для всех дисков, которые поддерживают управление очередью запросов.

Руками это можно сделать записав noop в /sys/block/sda/queue/scheduler, но проблема в том, что в тестовый сервер собран на базе простого десктопного железа но с дополнительными SATA контроллерами на шине PCI-E x1. Системный диск и вовсе IDE.

Один из способов решить проблему - задать elevator=noop в параметрах ядра, но тогда придется руками найти системный жесткий диск и вернуть ему cfq в качестве планировщика. Но мне больше нравится идея оставить cfq по-умолчанию, а для жестких дисков с NCQ включить noop в из скрипта при загрузке системы.

$ cat /root/bin/noop4ncq.sh
#!/bin/bash

for _blkdev in `ls -1d /sys/block/*`
do
 # Check if block device has support for NOOP IO scheduler
 if [ -e "$_blkdev/queue/scheduler" ]; then
  if `grep -q noop "$_blkdev/queue/scheduler"`; then
   if [ ! -e "$_blkdev/device/queue_depth" ]; then
    continue
   fi
   if [ `cat "$_blkdev/device/queue_depth"` -gt 1 ]; then
    echo -n "Selecting NOOP I/O scheduler for $_blkdev: "
    echo noop >"$_blkdev/queue/scheduler" 2>/dev/null && echo OK || echo FAIL
   else
    continue
   fi
  else
   continue
  fi
 fi
done

Из скрипта видно, что noop включается не для всех блочных устройств, а только для тех, у которых queue depth > 1. Это связано с тем, что для правильной планирования очереди запросов на аппаратном уровне недостаточно иметь только SATA II жесткий диск. Еще нужна поддержка NCQ в SATA контроллере и операционной системе хоста.

Осталось прописать вызов /root/bin/noop4ncq.sh в /etc/rc.local и все.

UPDATE: Альтернативное решение с использованием UDEV описано тут.

Wine 1.5.21 для Debian Squeeze/Wheezy

С горем пополам залил свежий билд Wine 1.5.21 в свой репозитарий. Для squeeze есть сборка для i386/amd64. Для wheezy только i386 (из-за перехода на multiarch и отсутствия свободного времени мне пока не удалось осилить amd64). Анонс версии 1.5.21.

Debian preseed

Пост из разряда смотрю в книгу, а вижу фигу.

Пол-часа перечитываю документацию к debian unattended install, но не могу понять почему она не стартует. После N-го прочтения доки таки рассмотрел строку "When the graphical installer menu appears, press ESC", а я пытался жать Tab и редактировать параметры.

Чтобы не забыть

• Нажать Esc (должно пропасть графическое меню и появиться приглашение boot:);
• Вбить auto url=http://1.2.3.4/path/to/preseed.cfg;
• Давить Enter и идти пить чай.

Пакеты Wine под x86_64

Не первый раз меня спрашивают, почему я пакетирую Wine только под i386. Чтобы восполнить этот пробел я попробовал собрать последнюю версию для i386/amd64. Пока сборка только для squeeze.

Установить можно через APT

deb http://www.tataranovich.com/debian squeeze experimental

Или руками из http://www.tataranovich.com/debian/pool/squeeze/experimental/w/wine-unstable/

Оставить отзыв можно в комментариях или в ветке форума на linux.org.ru.

could not configure /dev/net/tun: Operation not permitted

Давненько для виртуализации я пользовался KVM (в основном VirtualBox), но сегодня потребовался именно KVM. Если запускать без сети, то все работает как и полагается, а если создать host-only сеть, то выдает ошибку could not configure /dev/net/tun: Operation not permitted.

Host-only сеть создана через tunctl (входит в пакет uml-utilities). Соответсвующая секция /etc/network/interfaces:

auto tap0
iface tap0 inet static
    address 10.168.90.100
    netmask 255.255.255.0
    tunctl_user uml-net

Пользователь, под которым запускается kvm, входит в группу uml-net, но при запуске выдается ошибка

$ kvm -m 1024 -drive file=inet.it.img,if=virtio,boot=on,media=disk,aio=native -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no -vga std
could not configure /dev/net/tun: Operation not permitted

Проверяю права на /dev/net/tun

$ ls -l /dev/net/tun
crw-rw---- 1 root uml-net 10, 200 Дек 27 15:22 /dev/net/tun

Выходит, что для группы uml-net, в которую входит пользователь запускающий KVM, доступ есть. Если же запустить KVM через трассировку, то видно чего ему не хватает

...
timer_create(CLOCK_REALTIME, {(nil), SIGALRM, SIGEV_SIGNAL, {...}}, {(nil)}) = 0
open("/dev/net/tun", O_RDWR|O_LARGEFILE) = 7
ioctl(7, TUNGETFEATURES, 0xbfe1633c)    = 0
ioctl(7, TUNSETIFF, 0xbfe1631c)         = -1 EPERM (Operation not permitted)
write(2, "could not configure /dev/net/tun"..., 58could not configure /dev/net/tun: Operation not permitted
) = 58
close(7)                                = 0
exit_group(1)
...

Как подсказал google не хватает привилегии CAP_NET_ADMIN. Чтобы ее выдать нужно установить пакет libcap2-bin и выполнить команду

$ sudo setcap CAP_NET_ADMIN=ep /usr/bin/kvm

После этого KVM запускается и работает без ошибок.