Железо
Ребилд RAID-5
Внезапно сервак стал жаловаться на здоровье, а именно — на то, что по данным SMART одного из дисков, стало этому диску плохеть. Диск у нас этот трудится в HP Proliant DL380 G5, в RAID-5, собранном на контроллере Compaq SmartArray P400.
Ну, винты на замену были, но диск пока вроде работает. Решили подоткнуть новый диск и пометить его как hot spare, на случай если диск из массива самозапилится, то будет подхвачен новый HS-диск. Диск подоткнули, но вот с hot spare получился облом — оказывается, этот контроллер умеет в массив вставлять HS только в момент создания. А в уже существующий массив — нет.
Так что надо менять диск. Я старательно всё забэкапил, тщательно прицелился, из какого отсека диск вынимать, запалил там лампочку-индикатор, и товарищ, находящийся на месте, диск заменил. Всё вроде понялось, спросило у меня «тут это, новый диск. Будем ребилдить массив?» Я грю — конечно, бро, надо ребилдить! И процесс пошёл. Поскольку на сервере стоит FreeBSD, а там особо никаких утилит нет, позволяющих получить кровавые подробности о состоянии массива, то удовольствоваться пришлось командой:
<COMPAQ RAID 5 VOLUME reco> at scbus0 target 0 lun 0 (da0,pass0)
<TEAC DV-W28E-RW G.B1> at scbus2 target 0 lun 0 (pass1,cd0)
Я так полагаю, что VOLUME reco должно индицировать, что volume recovering. Ну, сидим курим, ждём окончания ребилда. Час, два ждём... И тут кончается рабочий день.
В общем, на следующий день к часу дня статус массива так и не изменился. Тут-то я и насторожился. И обратился к коллективному разуму с вопросом — а нормально ли это, для 150-гигового винта в RAID-5 такое время ребилда? Коллективный разум однозначно решил, что ненормально, но посоветовал использовать утилиту sysutils/cciss_vol_status, каковую я немедленно и проинсталлировал. Утилита английским по белому сказала:
Controller: Smart Array P400
Board ID: 0x3234103c
Logical drives: 1
Running firmware: 7.18
ROM firmware: 7.18
/dev/ciss0: (Smart Array P400) RAID 5 Volume 0 status: OK.
Physical drives: 7
connector 1I box 1 bay 7 HP DG146BABCF BS05P8708AUE0827 HPD6 OK
connector 1I box 1 bay 6 HP DG146ABAB4 3NM14RAG00009821Q0QZ HPDD OK
connector 1I box 1 bay 5 HP DG146BABCF BS05P86088T90827 HPD6 OK
connector 2I box 1 bay 4 HP DG146BABCF BS05P8608A890827 HPD6 OK
connector 2I box 1 bay 3 HP DG146BABCF BS05P8607UYT0826 HPD6 OK
connector 2I box 1 bay 2 HP DG146ABAB4 3NM15CQ500009822WG3Q HPDA OK
connector 2I box 1 bay 1 HP DG146BABCF BS05P8607V070826 HPD6 OK
То есть, она считает, что массив уже вполне ОК. Но это расходится с показаниями camcontrol. В общем, похоже, camcontrol не перечитал данные с контроллера. Почему-то. Пришлось ему принудительно сделать
Только после этого camcontrol ответил, что
Вот и думай теперь, как ему после этого доверять. Придётся, видимо, в мониторинге переделывать получение данных о состоянии массива с camcontrol на cciss_vol_status :-(
Отвал микрофона в гарнитуре Koss
Есть у меня замечательная во всех отношениях гарнитура, Koss SB45. Вот такая:
И что-то в один прекрасный момент все мои телефонно-скайпные корреспонденты начали жаловаться, что стали меня плохо слышать. Я начал рыться в настройках звуковой карты, производить различные магические пассы, пытаясь отыскать причину. Выкрутил на максимум усиление микрофона. Всё было бестолку — шума прибавлялось, не фона 50 гц, как это бывает, а именно шума, белый шум.
Поставил даже валяющийся у меня в столе бесхозный SB Live!, поставил дрова от kx project, поскольку на компе сейчас Win2008 Server стоит. Ни фига — не работает микрофон как раньше.
В общем, после трех дней курения интернета, манипуляций с настройками звуковухи в микшере и других заклинаний, а также срочного поиска гарнитуры на замену я подключил вместо микрофона обычные наушники-вкладыши, и насторожился... Шум исчез. Наушники в качестве микрофона, конечно, плоховато работают, но главное — шума нет. Ага! Похоже, это что-то с микрофоном, а не с драйверами, звуковухой или иными делами.
Разобрал аккуратно микрофон гарнитуры, отцепил один проводок от него и начал тестировать. Прозвонил все провода, идущие к микрофону, провода в порядке. Тогда включил микрофон в гнездо и прижал к контакту отпавший провод. В колонках сразу зашумело. Из чего я смело заключил, что дрова наступили самому микрофону. В итоге купил за 190 рублей в ЧипДипе (хороший магазин, но дорогой — ппц) электретный кетайский микрофон UME-2 (он единственный подходил по размерам) и припаял на место скисшего в гарнитуре. И всё чудесно заработало обратно. Горжусь собой! Терпение и труд избавили от покупки новой гарнитуры! :-)
Настройка MikroTik под Корбину
В конторе купили маршрутизаторы MikroTik RB750. Мега-вещь, кстати. И надо их как-то настроить, чтобы они раздавали интернет корбиновский в офисе. Но сходу фокус не прокатил, в силу описанных выше причин. Поиск по интернету привёл к очень толковой методичке, разработанной неким ООО «Виджет-Про». За что выражаю им благодарность перед строем с занесением в карму.
От себя добавлю, что нужно также в настройках dhcp-клиента на WAN-интерфейсе убрать галку «Add default route», иначе в системе получалось два машрута по умолчанию, и хотя VPN не отваливался, но интернета всё равно не было.
Ошибки при опросе демоном hald некоторых устройств
Но лучшее — враг хорошего. С выходом FreeBSD 8.0 я подумал, что не грех было бы перевести всю наличную технику на неё — сервак и этот самый ноут. Поставил 8-ку на ноут, и обнаружил, что при включении hald ноут постоянно с интервалом примерно в секунду ругается на первой консоли, что acd0: FAILURE — unknown CMD (0x03) ILLEGAL REQUEST asc=0x20 ascq=0x00. И приводит это к невозможности смонтировать диски в CDROM. Полез в интернет, копался там дня три — ничего толком нет, кроме совета убрать драйвер atacdrom из ядра и воткнуть вместо него atapicam.
Я эту операцию немедленно проделал. Налицо эффект, надпись сменилась на:
unknown: FAILURE — unknown CMD (0x03) ILLEGAL REQUEST asc=0x20 ascq=0x00
Короче, не помогло. Полез рыться в районе конфигов hald. Оказывается, ему можно запретить опрос определённых устройств. Кровавые подробности можно вкурить тут.
Описаный по ссылке способ помог, ошибки перестали сыпаться. Создал файл /usr/local/share/hal/fdi/preprobe/20thirdparti/10-ignore-acd0.fdi следующего содержания:
<deviceinfo version=«0.2»>
<device>
<match key=«freebsd.driver» string=«acd»>
<match key=«freebsd.unit» int=«0»>
<merge key=«info.ignore» type=«bool»>true</merge>
</match>
</match>
</device>
</deviceinfo>
Перезапустил hal, вроде ему полегчало, болезному. Посмотреть, какой freebsd.driver и freebsd.unit нужен, чтобы вписать в файл, можно с помощью утилиты lshal.
Установка XP на ноут без CD и дисковода
Городить огород с загрузкой по сети или ещё чем-нибудь подобным мне не хотелось (и, блин, совершенно напрасно, как показали дальнейшие события!), поэтому я решил по-быстрому всё сделать — вытащить винт из этого ноута, и поставить в свой ровер, отформатировать там всё, начать инсталляцию винды, а после текстовой фазы установки переткнуть винт обратно.
Дальше под катом Сказано — сделано. Вынимаю винты из обоих ноутов, ставлю винт из омнибука к себе. Загружаюсь с BartPE, размечаю акронисом диск, перезагружаюсь с установочного компакта русской XP, прохожу текстовый этап установки, при перезагрузке проверяю, что всё путём и инсталляция пойдёт дальше, жму Ctrl-Alt-Del, выключаю ноут, вынимаю из него винт и ставлю винт на родину — в омнибук. Включаю омнибук и получаю БОЛЬШОЙ БОЛТ! На омнибуке инсталлятор винды не грузится.
И тут началось нетрадиционное порно с элементами BDSM и скотоложества... Что я только не делал. Форматировал этот винт в FAT16, FAT32, создавал разные конфигурации разделов и файловых систем. Везде было одно и то же — пока винт загрузочный в MS DOS — с него омнибук грузится. Копирую инсталлятор винды, запускаю его из ДОСа прямо на омнибуке, инсталляция проходит первый этап копирования файлов, после перезагрузки получаем БОЛТ. Либо омнибук глухо зависает без всяких сообщений, лиоб NTLDR is missing.
Капец, как я там извращался. Винт между ноутами за всё время порева я переставил раз не менее 50, снося разделы и создавая их заново. Смеха ради даже создавал разделы с помощью FreeBSD. Вот кстати фря стала и запустилась на омнибуке без вопросов, у меня уже начала появляться мысль, что товарищу будет проще освоить KDE, чем мне поставить ему на ноут винду... :-) Протрахался, короче, с 10 утра воскресенья до 3 ночи понедельника. Результат нулевой.
Наутро встал, почитал, что на мой вопрос по этому поводу пишут в ЖЖ. Ничего путного не обнаружил. Стал думать.
В общем, вскрытие показало, что
Выставление прямой геометрии вручную в БИОСе омнибука не дают ничего — он виснет наглухо даже при попытке грузануть DOS. Понять, что грабли связаны с тем, какую геометрию пытается подсунуть винту ноут, я смог только тогда, когда настроил сетевую загрузку через PXE и попытался загрузить омнибук с нескольких своих ремонтных образов дискет. Так вот, при любых параметрах, даже самых прямых, но отличающихся от «Auto» при загрузке DOS омнибук вис даже при загрузке через сеть. И выводилась интересная надпись: Int13 08 failed. Не помню, что за функция 08, но судя по всему, с прямой геометрией этот BIOS работать не будет.
В итоге я выставил определение винта в «Auto», сделал дискету с Partition Magic 8, загрузил омнибук по сети, разбил PM винт, отформатировал на самом омнибуке с его кривым биосом, криво определяющим геометрию, потом переставил винт на свой ноут, переписал инсталлятор XP на винт, вернул винт обратно и загрузившись ещё раз по сетке с чистым DOS'ом и smartdrive'ом, запустил установку XP. Файлы копируются, первая перезагрузка, затаили дыхание... И о чудо! Оно грузится и продолжает установку, ссучара бацильная, скока крови попил! Вот так человеческий разум в очередной раз победил бездушную технику :-)
Перенос Windows XP на другую материнку
Если есть возможность загрузить винду как-нибудь, то самый простой способ подготовить её к переносу на другую материнку — это в диспетчере устройств вместо дискового контроллера материнки поставить «Cтaндapтный двyxкaнaльный кoнтpoллep PCI IDE». После этого можно завершать работу Windows и менять материнку. После замены и запуска винды на новой матери можно уже поставить правильные драйвера под дисковый контроллер новой материнки.
Хорошо, если есть возможность предугадать замену материнской платы и подготовиться. А если же такой возможности нет, т. е. мать сгорела начисто, и другой аналогичной нет в наличии, то существует другой рецепт.
Для его реализации потребуется загрузочный LiveCD с какой-нибудь из вариаций Windows. Я пользуюсь BartPE. И reg-файл, который пропишет в реест сведения о стандартном контроллере IDE.
После импортирования reg-файла остаётся дело за малым (гы-гы, придёт малый, и доделаем ) — нужно переписать драйвера стандартного контроллера IDE в каталог system32. Вот эти файлы:
atapi.sys
intelide.sys
pciide.sys
pciidex.sys
Затем можно грузиться с винта, всё должно заработать.
Рецепт проверен, всё железно работает.
Материал подготовлен по мотивам курения форума http://forum.ru-board.com. Там также обсуждаются варианты переноса XP с материнки Intel на не-Intel и прочие извращения.
Vista не работает с USB-устройствами
Вытащить флешку, удалить из директории %SYSTEMROOT%\inf файлы DRVINDEX.DAT, INFPUB.DAT, INFSTOR.DAT, INFSTRNG.DAT, INFCACHE.*, SETUPAPI.*.
Вставить флешку.
Если автоматически драйвера не установятся — из диспетчера устройств установить драйвер вручную с опцией автоматического поиска (для поиска указать директорию %SYSTEMROO%\system32). Флешка должна успешно установиться.
Пправда сразу удалить может не получится, нужно стать владельцем этих файлов. В настройках безопасности прописать себя владельцем и поставил себе полный доступ.
Рецепт не проверен, при случае надо будет проверить.
Звук воспроизводится замедленно на Foxconn NF4UK8AA
Потом добрые люди подсказали, что это известная бага для этой материнки. Оказывается, такой эффект у неё вызывает включенный в BIOS'е spread spectrum. Выключил его — всё заработало как надо.
Hint: spread specturm — исходя из описаний, я так понял, что включение этой функции заставляет генераторы тактовых частот менять частоту в некоторых очень небольших пределах, чтобы исключить либо уменьшить взаимные наводки проводников на матери друг на друга.