при первом входе:
login: admin
password: admin
Проблемы, с которыми я сталкивался, которые я решал, и, скорее всего, решил.
среда, 1 мая 2013 г.
вторник, 4 октября 2011 г.
XenServer и LinuxRaid level 1
Материал
основан на двух англоязычных статьях:
Я
всего лишь постараюсь собрать инструкцию,
проверенную на практике, но на родном
языке.
Исходные
данные:
Сервер,
два винчестера одинаковой модели
емкостью 500Gb.
Задача:
Поднять
на сервере XenServer, но таким образом, чтобы
система работала на LinuxRaid уровня 1,
настроенном на вышеупомянутых винтах.
Инструкция:
В
качестве небольшого предисловия добавлю,
что все попытки поставить XenServer на
software raid, предоставляемый некоторыми
материнскими платами, провалились. Даже
при настройке в BIOS оного "девайса",
XenServer при установке не видит Raid, а видит
отдельные диски-устройства.
Далее,
XenServer
сам по себе не поддерживает загрузку с
LinuxRaid и не предлагает, как, например,
Debian при установке, ничего похожего. Но
есть возможность "сконвертировать"
файловую систему и "перебросить"
на нее уже установленный XenServer.
Дело
в том, что несмотря на отсутствие
встроенной возможности использовать
LinuxRaid, в системе после установки есть
все необходимые компоненты для его
использования. Необходимо только
правильно ими воспользоваться......
Итак,
будем считать, что в сервер вставлены
оба винчестера, первый - загрузочный,
дистрибутив XenServer установлен в
опт.привод, инсталлятор запущен
и отработан, установленная система
загрузилась и показала свою синюшную
консоль, дистрибутив из привода извлечен.
Далее
можно действовать либо с удаленной
консоли, либо с родной.
В
системе теперь два жестких диска - sda с
системой, и sdb - пустой.
Смотрим,
что у нас с разделами на sda:
#
fdisk -l /dev/sda
Disk
/dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 499 4008186 83 Linux /dev/sda2 500 998 4008217+ 83 Linux /dev/sda3 999 60801 480367597+ 83 Linux
В
первую очередь необходимо создать точно
такую же схему разделов на sdb:
# sfdisk -d /dev/sda | sfdisk /dev/sdb
Здесь
внимательно посмотрите на вывод: возможно
потребуется добавить ключ "--force".
Проверяем,
результат должен быть таким:
# fdisk -l /dev/sdb Disk /dev/sdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 499 4008186 83 Linux /dev/sdb2 500 998 4008217+ 83 Linux /dev/sdb3 999 60801 480367597+ 83 Linux
Меняем
тип разделов sdb на "Linux raid autodetect".
Так как наиболее удобная для этого
утилита cfdisk в системе отсутствует,
используем нетривиальный метод:
# echo -e "\nt\n1\nfd\nt\n2\nfd\nt\n3\nfd\nw\nx" | fdisk /dev/sdb
Результат:
# fdisk -l /dev/sdb Disk /dev/sdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 499 4008186 fd Linux raid autodetect /dev/sdb2 500 998 4008217+ fd Linux raid autodetect /dev/sdb3 999 60801 480367597+ fd Linux raid autodetect
Для
чистоты исполнения этого этапа необходимо
перегрузиться, чтобы система перечитала
и проинициализировала вновь созданную
структуру sdb:
# reboot
Следующий
этап: подготовка sdb для использования
в будущем Raid-массиве.
Создадим
три Raid устройства, но с указанием
пропущенных девайсов:
# mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdb3 missing # mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing # mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb2 missing
Таким
образом, рейд создан, но только с участием
sdb.
Теперь
прежде всего копируем данные Xen Storage
Manager на созданный Raid.
ВНИМАТЕЛЬНО:
далее "VG_XenStorage-3e954146-82c7-03df-3dd5-0a5464842579"
- это uuid существующего в системе хранилища,
но на каждой системе он свой. Используемый
в вашей системе uuid необходимо предварительно
определить с помощью команды "pvscan",
а затем вставить в соответствующие
команды, указанные ниже.
Создаем
новое устройство в хранилище.
# pvcreate /dev/md2
Расширяем
на него хранилище.
# vgextend VG_XenStorage-3e954146-82c7-03df-3dd5-0a5464842579 /dev/md2
Копируем
данные хранилища на новое устройство.
# pvmove /dev/sda3 /dev/md2
Эта
операция займет некоторое время, после
чего останется еще пара команд.
Сужаем
пространство хранилища за счет исходного
раздела.
# vgreduce VG_XenStorage-3e954146-82c7-03df-3dd5-0a5464842579 /dev/sda3
Удаляем
из хранилища исходное устройство.
# pvremove /dev/sda3
Монтируем
/dev/md0 и копируем на него файлы системы
с исходного раздела:
# mkfs.ext3 /dev/md0 # mount /dev/md0 /mnt # cd / # cp -axv . /mnt
Следующий
этап: настраиваем процесс загрузки с
Raid.
Придется
редактировать несколько файлов, для
чего используем редактор vi. Надеюсь,
что трудностей не возникнет, так как по
командам редактора в Интернете достаточно
информации.
Итак,
во-первых, редактируем /mnt/etc/fstab таким
образом, чтобы система монтировала
корень с /dev/md0. Для этого заменяем в файле
строку "LABEL=/-main" на "/dev/md0",
чтобы получилось нечто подобное:
# cat /mnt/etc/fstab /dev/md0 / ext3 defaults 1 1 /var/swap/swap.001 swap swap defaults 0 0 none /dev/pts devpts defaults 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0
Создаем
образ загрузки и распаковываем его:
# mkdir /mnt/root/initrd-raid # mkinitrd -v --fstab=/mnt/etc/fstab /mnt/root/initrd-raid/initrd-`uname -r`-raid.img `uname -r` # cd /mnt/root/initrd-raid # zcat initrd-`uname -r`-raid.img | cpio -i
Теперь
необходимо внедрить необходимые
raid-устройства в загрузку:
# vi init
Тут
сразу после строки "echo
Scanning and configuring dmraid supported devices" нужно
добавить:
raidautorun /dev/md1 raidautorun /dev/md2
В
результате эта часть файла должна
выглядеть примерно так:
. . . stabilized --hash --interval 250 /proc/scsi/scsi mkblkdevs echo Scanning and configuring dmraid supported devices raidautorun /dev/md0 raidautorun /dev/md1 raidautorun /dev/md2 resume /var/swap/swap.001 echo Creating root device. mkrootdev -t ext3 -o defaults,ro /dev/md0 echo Mounting root filesystem. . . .
Копируем
новый ram-диск
в /mnt/boot и
модифицируем меню загрузки:
# find . -print | cpio -o -Hnewc | gzip -c > /mnt/boot/initrd-`uname -r`-raid.img # rm /mnt/boot/initrd-2.6-xen.img rm: remove symbolic link `/mnt/boot/initrd-2.6-xen.img’? y # ln -s initrd-`uname -r`-raid.img /mnt/boot/initrd-2.6-xen.img
# vi /mnt/boot/extlinux.conf
Тут
необходимо заменить все вхождения
строки "root=LABEL=root-xyz" на "root=/dev/md0",
то есть модификацию надо сделать в
каждом пункте меню.
Осталось
назначить в качестве MBR диск
/dev/sdb.
Так
как Since XenServer до сих пор использует
extlinux вместо GRUB, это нетрудно. Достаточно
просто изменить опции bootloader:
# cat /usr/lib/syslinux/mbr.bin > /dev/sdb # cd /mnt # extlinux -i boot/
Отцепляем
/dev/md0 от временной точки монтирования:
# cd # umount /dev/md0 # sync
Теперь
нужно перегрузиться.
!!!
Внимательно: тут перезагрузку нужно
выполнить со ВТОРОГО ж.диска, изменив
очередь загрузки в BIOS.
Если
все было сделано правильно, то система
должна загрузиться уже с raid-массива
и точка монтирования «/» будет находиться
на /dev/md0.
# reboot
Итак,
после перезагрузки мы имеем все еще
рабочую систему, но уже загруженную с
настроенного raid-массива.
Осталось теперь подготовить sda
для использования в raid
и подключить туда его
разделы в качестве недостающих устройств.
Изменяем
тип файловых разделов sda на
«Linus raid autodetect»:
# echo -e "\nt\n1\nfd\nt\n2\nfd\nt\n3\nfd\nw\nx" | fdisk /dev/sda
Результат:
# fdisk -l /dev/sda
Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 499 4008186 fd Linux raid autodetect /dev/sda2 500 998 4008217+ fd Linux raid autodetect /dev/sda3 999 60801 480367597+ fd Linux raid autodetect
Подключаем
недостающие разделы в Raid:
# mdadm -a /dev/md0 /dev/sda1 mdadm: hot added /dev/sda1 # mdadm -a /dev/md1 /dev/sda2 mdadm: hot added /dev/sda2 # mdadm -a /dev/md2 /dev/sda3 mdadm: hot added /dev/sda3
После
этого начинается долгий, но приятный
процесс синхронизации разделов Raid1, за
которым можно проследить:
# watch cat /proc/mdstat
Дожидаемся
окончания процесса, и остается еще два
важных действия, которые обеспечат
правильную работу системы с рейдом.
Копируем
конфигурацию запущенного рейда в
/etc/mdadm.conf:
# mdadm --detail --scan >> /etc/mdadm.conf
Редактируем
/etc/mdadm.conf так, чтобы вначале файла
обязательно присутствувала строка
«DEVICE partitions». Это необходимо для корректной
инициализации дисков при загрузке
компонентов рейда.
На
этом занавес можно закрывать и распускать
зал... :)
понедельник, 3 октября 2011 г.
Intel s5000pal + SR1500ALR: Status LED
Судя по интернет-поискам, тема имеет право на жизнь.
Коротко о самой проблеме:
На серверной корпусной системе Intel SR1500ALR присутствует так называемый Status LED. Расположен он прямо на передней панели справа. В нашем случае, это дублирующий индикатор, "оригинал" которого находится на материнской плате: на задней части платы между гнездами rj-45 и VGA-портом. Если исходить из различных описаний, инструкций и руководств по плате и корпусной системе, в нормальном состоянии, когда нет никаких причин для паники, этот индикатор должен просто гореть зеленым цветом. При возникновении каких-то проблем при тестировании устройств системой, индикатор может изменить нормальный статус на другой: либо мигание желтым цветом, либо, просто постоянный желтый цвет.
В руководстве к мат.плате есть описание, что может быть в этом случае, и куда еще нужно глянуть, чтобы более точно определить проблему.
Суть поднимаемой темы в том, что даже если сервер работает как надо, Status LED может вести себя не совсем корректно: в моем случае, к примеру, 3 года сервер работал с мигающей лампой... что так или иначе нервировало и меня и моих коллег... но поиски в Интернете не дали никаких объяснений... пока не пришло время обновить BIOS.
Оказалось все очень тонко.... :)
Дело в том, что BIOS у такой серьезной платы - это не файл или пара файлов, а целый пакет обновлений, охватывающий несколько чипов памяти, отвечающих за разные компоненты системы. В случае платы s5000pal, в пакет входят обновления собственно BIOS, BMC - контроллер управления шиной, и FRUSDR (точнее FRU&SDR) - Field Replaceable Unit (Заменяемое устройство) & Sensor Data Record (Запись показаний датчика).
Не будем вдаваться в смысл аббревиатур последнего компонента, так как суть не в его названии, а в нем самом. При обновлении FRUSDR задается много вопросов о вводе модели и серийного номера шасси (корпуса). Методом проб и ошибок выяснено, что имеет смысл согласиться на ввод модели (Part.No в оригинале) и серийного номера системы и шасси. И в том, и в другом случае просто вводим модель и серийник с наклейки на корпусе.
Суть в том, что, очевидно, это важная информация для материнки.
Она похоже по ней определяет, какая внутренняя периферия (типа БП) подключена к ней.
Именно после этого обновления Status LED у меня стала показывать полную норму, то есть гореть зеленым цветом.
Коротко о самой проблеме:
На серверной корпусной системе Intel SR1500ALR присутствует так называемый Status LED. Расположен он прямо на передней панели справа. В нашем случае, это дублирующий индикатор, "оригинал" которого находится на материнской плате: на задней части платы между гнездами rj-45 и VGA-портом. Если исходить из различных описаний, инструкций и руководств по плате и корпусной системе, в нормальном состоянии, когда нет никаких причин для паники, этот индикатор должен просто гореть зеленым цветом. При возникновении каких-то проблем при тестировании устройств системой, индикатор может изменить нормальный статус на другой: либо мигание желтым цветом, либо, просто постоянный желтый цвет.
В руководстве к мат.плате есть описание, что может быть в этом случае, и куда еще нужно глянуть, чтобы более точно определить проблему.
Суть поднимаемой темы в том, что даже если сервер работает как надо, Status LED может вести себя не совсем корректно: в моем случае, к примеру, 3 года сервер работал с мигающей лампой... что так или иначе нервировало и меня и моих коллег... но поиски в Интернете не дали никаких объяснений... пока не пришло время обновить BIOS.
Оказалось все очень тонко.... :)
Дело в том, что BIOS у такой серьезной платы - это не файл или пара файлов, а целый пакет обновлений, охватывающий несколько чипов памяти, отвечающих за разные компоненты системы. В случае платы s5000pal, в пакет входят обновления собственно BIOS, BMC - контроллер управления шиной, и FRUSDR (точнее FRU&SDR) - Field Replaceable Unit (Заменяемое устройство) & Sensor Data Record (Запись показаний датчика).
Не будем вдаваться в смысл аббревиатур последнего компонента, так как суть не в его названии, а в нем самом. При обновлении FRUSDR задается много вопросов о вводе модели и серийного номера шасси (корпуса). Методом проб и ошибок выяснено, что имеет смысл согласиться на ввод модели (Part.No в оригинале) и серийного номера системы и шасси. И в том, и в другом случае просто вводим модель и серийник с наклейки на корпусе.
Суть в том, что, очевидно, это важная информация для материнки.
Она похоже по ней определяет, какая внутренняя периферия (типа БП) подключена к ней.
Именно после этого обновления Status LED у меня стала показывать полную норму, то есть гореть зеленым цветом.
пятница, 15 июля 2011 г.
WDTV gen 1: подключение к сети
Девайс: WDTV HD Gen1
Задача: Подключить аппарат к компьютерной сети, настроить доступ с него к сетевым ресурсам для показа/проигрывания медиа-контента.
Решение:
1. Общее описание.
Используем альтернативную прошивку, позволяющую решить вышепоставленную задачу.
2. Мое решение.
Сначала была опробована прошивка от 1.03.01_B-RAD.CC_WDLXTV-0.5.8.1 (http://b-rad.cc).
При этом не было ничего из вспомогательных "железок", так как видимо поначалу было желание увидеть в принципе рабочий после перепрошивки девайс.
После были заказаны три адаптера USB-RJ45, два с китайского интернет-магазина, и один в российском интернет-магазине. В итоге на руках оказались модели: [1] KY-QF9700 (http://www.dealextreme.com/p/usb-10-100-rj45-ethernet-network-adapter-dongle-2797), [2] безымянная модель (http://www.dealextreme.com/p/usb-2-0-10-100mbps-rj45-lan-ethernet-network-adapter-dongle-34691) и [3] TRENDnet TU-ET100C (http://trendnet.ru/products/catalog/detail/TU-ET100C).
Далее все адаптеры были предварительно протестированы на ноутбуке с linux (просто потому, что будущая рабочая прошивка WDTV основана на linux-ядре). В качестве теста я просто произвел подключение каждого из них и командой ifconfig посмотрел состояние сетевых интерфейсов системы. 1й девайс никак себя не обнаружил, 2й и 3й сразу были показаны, как дополнительный сетевой интерфейс.
Итак, флешка с альтернативной прошивкой была подготовлена: архив с прошивкой был распакован, содержимое скопировано в корень флешки, затем был отредактирован файл net.config для настройки адреса и других сетевых параметров будущего сетевого интерфейса WDTV.
Устанавливаю флешку в боковой usb-разъем WDTV, адаптер 3 - в задний usb-разъем WDTV.
Девайс обнаруживает обновление. Я перехожу в режим обновления прошивки и запускаю процесс. Прошивка проходит успешно и девайс окончательно перегружается.
Во-время загрузки в какой-то момент сверху логотипа загружаемой системы указывается IP адрес (если адаптер схватился удачно и настройки были корректно считаны с флешки и применены) . В случае неудачи там будет надпись "IP: No IP".
После перезагрузки именно второй случай имел место.
Попытка использовать другие адаптеры ничего не дал.
Поиск в Интернете вывел меня на еще одну прошивку, основанную на такой же что я использовал: 1.03.01_B-RAD.CC_WDLXTV-0.5.8_ru-eldrako.
По описанию, прошивка более протестированная и кроме того (приятная неожиданность) русифицирована. Нюанс: эта прошивка требует постоянного нахождения флешки с конфигурационными файлами в одном из разъемов usb в WDTV.
После перепрошивки, как ни странно, сеть "схватилась" сразу, как только я вставил адаптер 2. Ни адаптер 1, ни адаптер 3 никакого положительного результата не дали.
Далее я просто опишу необходимые действия для окончательного решения задачи, не в даваясь в подробности поиска вариантов этих действий.
Так как WDTV теперь в сети, осталось только разобраться с подключением сетевых ресурсов, чтобы через стандартный интерфейс WDTV можно было их использовать для проигрывания и просмотра хранящегося в сети медиаконтента.
В "новом" WDTV появилась альтернативный способ управления - telnet.
Первый вход:
telnet xxx.xxx.xxx.xxx
на запрос login отвечаем:
root
пароль по-умолчанию пустой, если необходимо это изменить, то первая команда, которую нужно использовать:
passwd
вводим новый пароль для root и при следующем входе в сеанс telnet придется отвечать не только на запрос "login:" но и "password:".
Вообще, в этом telnet работает большинство команд linux типа ls, можно убедиться в этом:
ls /bin
Но, ближе к делу: монтирование ресурсов.
Все просто, две команды:
# xmount //IP/share_name mount_name cifs user=<username>,pass=<password>
и
# xmount IP:/share_name mount_name nfs
Первая - для монтирования samba-ресурса (или windows-ресурсов) .
Вторая - для монтирования nfs-ресурсов.
НО
сейчас реакция на эти команды будет примерно такой: "module cifs not found" или "module nfs not found".
Это потому, что для правильной обработки этих команд прошивке требуются дополнительные модули. Называются они соответственно samba.app.bin и nfs.app.bin. Скачиваются с упомянутого выше сайта http://b-rad.cc. После скачивания содержимое архивов надо просто скинуть в корень флешки с прошивкой и ее настройками, после чего просто перегружаем устройство. (Кстати, теперь это можно сделать не только физическим отключением от блока питания, но и через telnet, дав команду reboot).
Если после перезагрузки ничего не изменилось, то можно просто повторить перепрошивку, изменив содержимое первой строки файла wdtv.ver на флешке с прошивкой, например, на такую строку "VERSION='1.03.01.WDLXTV-0.5.8'". Это искусственно создаст ситуацию, когда девайс обнаружит "обновление" прошивки и даст возможность повторить перепрошивку.
P.S. При дальнейшей эксплуатации обнаружилось, что, при проигрывании медиаконтента с подключенных шар, аппарат нормально начинает процесс, но при этом полностью отказывается реагировать на какие-либо команды с пульта... Этот период длится около 1,5 минут, после чего можно, к примеру, остановить проигрывание или поставить паузу. Однако, после запуска вновь или снятия с паузы 1,5-минутный "зависон" будет иметь место вновь.
Это пока единственное неприятное последствие вышеописанных действий. И не факт, что так у всех.
Задача: Подключить аппарат к компьютерной сети, настроить доступ с него к сетевым ресурсам для показа/проигрывания медиа-контента.
Решение:
1. Общее описание.
Используем альтернативную прошивку, позволяющую решить вышепоставленную задачу.
2. Мое решение.
Сначала была опробована прошивка от 1.03.01_B-RAD.CC_WDLXTV-0.5.8.1 (http://b-rad.cc).
При этом не было ничего из вспомогательных "железок", так как видимо поначалу было желание увидеть в принципе рабочий после перепрошивки девайс.
После были заказаны три адаптера USB-RJ45, два с китайского интернет-магазина, и один в российском интернет-магазине. В итоге на руках оказались модели: [1] KY-QF9700 (http://www.dealextreme.com/p/usb-10-100-rj45-ethernet-network-adapter-dongle-2797), [2] безымянная модель (http://www.dealextreme.com/p/usb-2-0-10-100mbps-rj45-lan-ethernet-network-adapter-dongle-34691) и [3] TRENDnet TU-ET100C (http://trendnet.ru/products/catalog/detail/TU-ET100C).
Далее все адаптеры были предварительно протестированы на ноутбуке с linux (просто потому, что будущая рабочая прошивка WDTV основана на linux-ядре). В качестве теста я просто произвел подключение каждого из них и командой ifconfig посмотрел состояние сетевых интерфейсов системы. 1й девайс никак себя не обнаружил, 2й и 3й сразу были показаны, как дополнительный сетевой интерфейс.
Итак, флешка с альтернативной прошивкой была подготовлена: архив с прошивкой был распакован, содержимое скопировано в корень флешки, затем был отредактирован файл net.config для настройки адреса и других сетевых параметров будущего сетевого интерфейса WDTV.
Устанавливаю флешку в боковой usb-разъем WDTV, адаптер 3 - в задний usb-разъем WDTV.
Девайс обнаруживает обновление. Я перехожу в режим обновления прошивки и запускаю процесс. Прошивка проходит успешно и девайс окончательно перегружается.
Во-время загрузки в какой-то момент сверху логотипа загружаемой системы указывается IP адрес (если адаптер схватился удачно и настройки были корректно считаны с флешки и применены) . В случае неудачи там будет надпись "IP: No IP".
После перезагрузки именно второй случай имел место.
Попытка использовать другие адаптеры ничего не дал.
Поиск в Интернете вывел меня на еще одну прошивку, основанную на такой же что я использовал: 1.03.01_B-RAD.CC_WDLXTV-0.5.8_ru-eldrako.
По описанию, прошивка более протестированная и кроме того (приятная неожиданность) русифицирована. Нюанс: эта прошивка требует постоянного нахождения флешки с конфигурационными файлами в одном из разъемов usb в WDTV.
После перепрошивки, как ни странно, сеть "схватилась" сразу, как только я вставил адаптер 2. Ни адаптер 1, ни адаптер 3 никакого положительного результата не дали.
Далее я просто опишу необходимые действия для окончательного решения задачи, не в даваясь в подробности поиска вариантов этих действий.
Так как WDTV теперь в сети, осталось только разобраться с подключением сетевых ресурсов, чтобы через стандартный интерфейс WDTV можно было их использовать для проигрывания и просмотра хранящегося в сети медиаконтента.
В "новом" WDTV появилась альтернативный способ управления - telnet.
Первый вход:
telnet xxx.xxx.xxx.xxx
на запрос login отвечаем:
root
пароль по-умолчанию пустой, если необходимо это изменить, то первая команда, которую нужно использовать:
passwd
вводим новый пароль для root и при следующем входе в сеанс telnet придется отвечать не только на запрос "login:" но и "password:".
Вообще, в этом telnet работает большинство команд linux типа ls, можно убедиться в этом:
ls /bin
Но, ближе к делу: монтирование ресурсов.
Все просто, две команды:
# xmount //IP/share_name mount_name cifs user=<username>,pass=<password>
и
# xmount IP:/share_name mount_name nfs
Первая - для монтирования samba-ресурса (или windows-ресурсов) .
Вторая - для монтирования nfs-ресурсов.
НО
сейчас реакция на эти команды будет примерно такой: "module cifs not found" или "module nfs not found".
Это потому, что для правильной обработки этих команд прошивке требуются дополнительные модули. Называются они соответственно samba.app.bin и nfs.app.bin. Скачиваются с упомянутого выше сайта http://b-rad.cc. После скачивания содержимое архивов надо просто скинуть в корень флешки с прошивкой и ее настройками, после чего просто перегружаем устройство. (Кстати, теперь это можно сделать не только физическим отключением от блока питания, но и через telnet, дав команду reboot).
Если после перезагрузки ничего не изменилось, то можно просто повторить перепрошивку, изменив содержимое первой строки файла wdtv.ver на флешке с прошивкой, например, на такую строку "VERSION='1.03.01.WDLXTV-0.5.8'". Это искусственно создаст ситуацию, когда девайс обнаружит "обновление" прошивки и даст возможность повторить перепрошивку.
P.S. При дальнейшей эксплуатации обнаружилось, что, при проигрывании медиаконтента с подключенных шар, аппарат нормально начинает процесс, но при этом полностью отказывается реагировать на какие-либо команды с пульта... Этот период длится около 1,5 минут, после чего можно, к примеру, остановить проигрывание или поставить паузу. Однако, после запуска вновь или снятия с паузы 1,5-минутный "зависон" будет иметь место вновь.
Это пока единственное неприятное последствие вышеописанных действий. И не факт, что так у всех.
пятница, 15 апреля 2011 г.
PosgreSQL - первый доступ (создание суперпользователя)
После установки PostgreSQL у многих возникает проблема первой авторизации в клиенте (любом). Это нормально, с пользователями по-умолчанию в pgsql строго.
Для создания/добавления пользователя использовал http://www.cyberciti.biz/faq/howto-add-postgresql-user-account/, но у этого пользователя не будет роли суперюзера. Поэтому далее действуем в консоли:
su postgre
под пользователем postgre используем команды вида psql -c "<command>", где <command> - SQL-команда postgreSQL.
psql -c "ALTER ROLE user LOGIN"
psql -c "ALTER ROLE user PASSWORD 'xxx'"
psql -c "ALTER ROLE user SUPERUSER"Если процесс изменения не прокатит, то надо созданного пользователя удалить и три вышеупомянутые команды выполнить через CREATE вместо ALTER.
под пользователем postgre используем команды вида psql -c "<command>", где <command> - SQL-команда postgreSQL.
psql -c "ALTER ROLE user LOGIN"
psql -c "ALTER ROLE user PASSWORD 'xxx'"
psql -c "ALTER ROLE user SUPERUSER"Если процесс изменения не прокатит, то надо созданного пользователя удалить и три вышеупомянутые команды выполнить через CREATE вместо ALTER.
суббота, 26 февраля 2011 г.
VirtualBox: Разрешение экрана гостевой ОС не более 800 на 600.
ОС: Linux Mint Debian Edition 201101
Установка: февраль 2011
Проблема:
Установлен VirtualBox, сконфигурирована виртуальная машина, установлена гостевая ОС Windows XP. В гостевой ОС разрешение видео устанавливается в довольно приличном диапазоне, но не все устройства определены и установлены. После установки "дополнений гостевой ОС", входящих в состав VirtualBox, устройства устанавливаются полностью, но разрешение экрана больше чем на 800х600 не устанавливается. При этом следует учесть, что работа с окном гостевой ОС шла в "режиме масштабирования".
Примечание:
На самом деле, проблема общая для любой ОС. Скорее даже не проблема, а правильная интерпретация одного из нюансов VirtualBox.
Решение:
По сути, решение не нужно, так как проблема только в правильном понимании работы видеосистемы виртуальной машины. После установки "дополнений гостевой ОС" в системе устанавливается видеодрайвер "VirtualBox Graphics Adapter". В "режиме масштабирования" в окне виртуальной машины даже при переключении в "полный экран" не получается средствами ОС изменить разрешение экрана. Однако достаточно окно переключить в режим "Подгонять размер экрана гостевой ОС", и проблема более не возникает. Разрешение, например, в Windows XP автоматически подстраивается под возможное для данного размера окна разрешение. Например, при переключении в "полный экран" у меня сразу устанавливается разрешение 1366х768, максимальное для экрана моего ноутбука.
Резюмирую:
1. Обязательно установить "Дополнения гостевой ОС".
2. Лучше всего использовать режим окна гостевой ОС "Подгонять размер экрана гостевой ОС".
Установка: февраль 2011
Проблема:
Установлен VirtualBox, сконфигурирована виртуальная машина, установлена гостевая ОС Windows XP. В гостевой ОС разрешение видео устанавливается в довольно приличном диапазоне, но не все устройства определены и установлены. После установки "дополнений гостевой ОС", входящих в состав VirtualBox, устройства устанавливаются полностью, но разрешение экрана больше чем на 800х600 не устанавливается. При этом следует учесть, что работа с окном гостевой ОС шла в "режиме масштабирования".
Примечание:
На самом деле, проблема общая для любой ОС. Скорее даже не проблема, а правильная интерпретация одного из нюансов VirtualBox.
Решение:
По сути, решение не нужно, так как проблема только в правильном понимании работы видеосистемы виртуальной машины. После установки "дополнений гостевой ОС" в системе устанавливается видеодрайвер "VirtualBox Graphics Adapter". В "режиме масштабирования" в окне виртуальной машины даже при переключении в "полный экран" не получается средствами ОС изменить разрешение экрана. Однако достаточно окно переключить в режим "Подгонять размер экрана гостевой ОС", и проблема более не возникает. Разрешение, например, в Windows XP автоматически подстраивается под возможное для данного размера окна разрешение. Например, при переключении в "полный экран" у меня сразу устанавливается разрешение 1366х768, максимальное для экрана моего ноутбука.
Резюмирую:
1. Обязательно установить "Дополнения гостевой ОС".
2. Лучше всего использовать режим окна гостевой ОС "Подгонять размер экрана гостевой ОС".
среда, 23 февраля 2011 г.
Linux Mint DE: не печатает принтер HP LaserJet P1005 [решено]
ОС: Linux Mint Debian Edition 201101
Установка: февраль 2011
Проблема: Принтер HP LasetJet P1005 подключен через USB. Система его определяет, но при отправке на печать заданий, на принтер они не выходят.
Диагностика: Проблема с моделью P1005 и подобными, начинающимися с "P" возникает из-за отсутствия в принтере собственной прошивки, позволяющей принтеру корректно функционировать. В windows-системах это решает установка соответствующего драйвера, который при необходимости подгружает прошивку в принтер прежде, чем на него отправляют задания на печать. В linux-клонах debian (это касается не только mint, но и прочих клонов) по умолчанию система ничего не знает об этом недостатке упомянутых моделей принтеров. Проблему решить помогает правильная настройка библиотеки hplip.
Решение:
Не буду вдаваться в подробности причин выбора именно такого комплекса действий. Главное, что проблема реально решается при соблюдении следующих шагов:
1. Через Synaptic установливаем hplip-gui (по умолчанию у меня он установлен не был).
2. В терминале от root запускаем hp-setup. Запускается графический мастер "HP Device Manager - Setup".
3. На шаге 1 этого мастера выбираем способ подключения принтера (в моем случае USB). Жмем "Next>".
4. На шаге 2 выбираем модель принтера из списка обнаруженных. Жмем "Next>".
5. После некоторой задержки (до 30 сек) запускается дополнительный мастер "HP Device Manager - Plug-In Installer".
6. На шаге 1 нового мастера выбираем способ установки плагина (в моем случае - закачка с Инета, вариант по умолчанию). Жмем "Next>".
7. После очередной задержки (до 30-40 сек) открывается окно с "Соглашением", в котором просто надо поставить галку согласия и нажать "Next>".
8. После продолжительного перерыва (более минуты) мастер снова возвращается на шаг 1, но перед этим принтер прошумит, приняв прошивку, что говорит о том, что плагин скачан и установлен. Повторное попытки нажатия "Next>" лишь повторяют пункты 7-8 и снова возвращают мастер на шаг 1. Поэтому жмем "Cancel".
9. Окно второго мастера закрывается, а окно первого мастера активируется на шаге 3. Здесь можно изменить имя принтера и поставить галку для печати тестовой страницы. Жмем "Add Printer".
10. Мастер закрывается, а принтер (при установке галки печати тестовой страницы в предыдущем пункте) распечатывает тестовую страницу. С этого момента система будет подгружать при необходимости прошивку в принтер самостоятельно. А после перезагрузки в трее появляется значок HP.
Установка: февраль 2011
Проблема: Принтер HP LasetJet P1005 подключен через USB. Система его определяет, но при отправке на печать заданий, на принтер они не выходят.
Диагностика: Проблема с моделью P1005 и подобными, начинающимися с "P" возникает из-за отсутствия в принтере собственной прошивки, позволяющей принтеру корректно функционировать. В windows-системах это решает установка соответствующего драйвера, который при необходимости подгружает прошивку в принтер прежде, чем на него отправляют задания на печать. В linux-клонах debian (это касается не только mint, но и прочих клонов) по умолчанию система ничего не знает об этом недостатке упомянутых моделей принтеров. Проблему решить помогает правильная настройка библиотеки hplip.
Решение:
Не буду вдаваться в подробности причин выбора именно такого комплекса действий. Главное, что проблема реально решается при соблюдении следующих шагов:
1. Через Synaptic установливаем hplip-gui (по умолчанию у меня он установлен не был).
2. В терминале от root запускаем hp-setup. Запускается графический мастер "HP Device Manager - Setup".
3. На шаге 1 этого мастера выбираем способ подключения принтера (в моем случае USB). Жмем "Next>".
4. На шаге 2 выбираем модель принтера из списка обнаруженных. Жмем "Next>".
5. После некоторой задержки (до 30 сек) запускается дополнительный мастер "HP Device Manager - Plug-In Installer".
6. На шаге 1 нового мастера выбираем способ установки плагина (в моем случае - закачка с Инета, вариант по умолчанию). Жмем "Next>".
7. После очередной задержки (до 30-40 сек) открывается окно с "Соглашением", в котором просто надо поставить галку согласия и нажать "Next>".
8. После продолжительного перерыва (более минуты) мастер снова возвращается на шаг 1, но перед этим принтер прошумит, приняв прошивку, что говорит о том, что плагин скачан и установлен. Повторное попытки нажатия "Next>" лишь повторяют пункты 7-8 и снова возвращают мастер на шаг 1. Поэтому жмем "Cancel".
9. Окно второго мастера закрывается, а окно первого мастера активируется на шаге 3. Здесь можно изменить имя принтера и поставить галку для печати тестовой страницы. Жмем "Add Printer".
10. Мастер закрывается, а принтер (при установке галки печати тестовой страницы в предыдущем пункте) распечатывает тестовую страницу. С этого момента система будет подгружать при необходимости прошивку в принтер самостоятельно. А после перезагрузки в трее появляется значок HP.
Подписаться на:
Сообщения (Atom)