Автоматизируем тестирование железа с помощью StressLinux::Журнал СА 7.2006
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Подписка
Архив номеров
Где купить
Наука и технологии
Авторам
Рекламодателям
Контакты
   

  Опросы
  Статьи

Событие  

В банке рассола ждет сисадмина с полей фрактал-кукумбер

Читайте впечатления о слете ДСА 2024, рассказанные волонтером и участником слета

 Читать далее...

Организация бесперебойной работы  

Бесперебойная работа ИТ-инфраструктуры в режиме 24/7 Как обеспечить ее в нынешних условиях?

Год назад ИТ-компания «Крок» провела исследование «Ключевые тренды сервисного рынка 2023». Результаты

 Читать далее...

Книжная полка  

Читайте и познавайте мир технологий!

Издательство «БХВ» продолжает радовать выпуском интересных и полезных, к тому же прекрасно

 Читать далее...

СУБД PostgreSQL  

СУБД Postgres Pro

Сертификация по новым требованиям ФСТЭК и роль администратора без доступа к данным

 Читать далее...

Критическая инфраструктура  

КИИ для оператора связи. Готовы ли компании к повышению уровня кибербезопасности?

Похоже, что провайдеры и операторы связи начали забывать о требованиях законодательства

 Читать далее...

Архитектура ПО  

Архитектурные метрики. Качество архитектуры и способность системы к эволюционированию

Обычно соответствие программного продукта требованиям мы проверяем через скоуп вполне себе понятных

 Читать далее...

Как хорошо вы это знаете  

Что вам известно о разработках компании ARinteg?

Компания ARinteg (ООО «АРинтег») – системный интегратор на российском рынке ИБ –

 Читать далее...

Графические редакторы  

Рисование абстрактных гор в стиле Paper Cut

Векторный графический редактор Inkscape – яркий представитель той прослойки open source, с

 Читать далее...

День сисадмина  

Учите матчасть! Или как стать системным администратором

Лето – время не только отпусков, но и хорошая возможность определиться с профессией

 Читать далее...

День сисадмина  

Живой айтишник – это всегда движение. Остановка смерти подобна

Наши авторы рассказывают о своем опыте и дают советы начинающим системным администраторам.

 Читать далее...

Виртуализация  

Рынок решений для виртуализации

По данным «Обзора российского рынка инфраструктурного ПО и перспектив его развития», сделанного

 Читать далее...

Книжная полка  

Как стать креативным и востребованным

Издательский дом «Питер» предлагает новинки компьютерной литературы, а также книги по бизнесу

 Читать далее...

Книжная полка  

От создания сайтов до разработки и реализации API

В издательстве «БХВ» недавно вышли книги, которые будут интересны системным администраторам, создателям

 Читать далее...

Разбор полетов  

Ошибок опыт трудный

Как часто мы легко повторяем, что не надо бояться совершать ошибки, мол,

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 6186
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 6896
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

12.03.2018г.
Просмотров: 4178
Комментарии: 0
Глубокое обучение с точки зрения практика

 Читать далее...

12.03.2018г.
Просмотров: 2986
Комментарии: 0
Изучаем pandas

 Читать далее...

12.03.2018г.
Просмотров: 3791
Комментарии: 0
Программирование на языке Rust (Цветное издание)

 Читать далее...

19.12.2017г.
Просмотров: 3801
Комментарии: 0
Глубокое обучение

 Читать далее...

19.12.2017г.
Просмотров: 6295
Комментарии: 0
Анализ социальных медиа на Python

 Читать далее...

19.12.2017г.
Просмотров: 3150
Комментарии: 0
Основы блокчейна

 Читать далее...

19.12.2017г.
Просмотров: 3445
Комментарии: 0
Java 9. Полный обзор нововведений

 Читать далее...

16.02.2017г.
Просмотров: 7261
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 10627
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 12347
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 13979
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 9108
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

12.02.2014г.
Просмотров: 7063
Комментарии: 0
Рисуем наши мысли

 Читать далее...

10.02.2014г.
Просмотров: 5373
Комментарии: 3
Страна в цифрах

 Читать далее...

18.12.2013г.
Просмотров: 4603
Комментарии: 0
Большие данные меняют нашу жизнь

 Читать далее...

18.12.2013г.
Просмотров: 3412
Комментарии: 0
Компьютерные технологии – корень зла для точки роста

 Читать далее...

04.12.2013г.
Просмотров: 3142
Комментарии: 0
Паутина в облаках

 Читать далее...

03.12.2013г.
Просмотров: 3388
Комментарии: 0
Рецензия на книгу «MongoDB в действии»

 Читать далее...

02.12.2013г.
Просмотров: 3010
Комментарии: 0
Не думай о минутах свысока

 Читать далее...

Друзья сайта  

 Автоматизируем тестирование железа с помощью StressLinux

Архив номеров / 2006 / Выпуск №7 (44) / Автоматизируем тестирование железа с помощью StressLinux

Рубрика: Администрирование /  Автоматизация

Дмитрий Волков

Автоматизируем тестирование железа с помощью StressLinux

На основе компьютера с ОС Linux и StressLinux можно создать инструмент для автоматического тестирования железа всех узлов локальной сети.

Бывают дефекты оборудования, которые могут проявиться только при высоких нагрузках, в этом случае поможет дистрибутив Linux, который может использовать ресурсы ваших комплектующих на 100%. В первую очередь тестирование будет полезно для компьютеров, на которых возлагаются задачи, требующие большой загрузки процессора. Такие компьютеры должны работать 24 часа в сутки и не давать сбоев. Поэтому их как следует нужно проверить на прочность.

В настоящее время существует множество утилит для тестирования железа как из Windows, так из Linux. Но необязательно, что на компьютерах находятся две ОС: Linux и Windows. Поэтому для тестирования удобно использовать дистрибутивы LiveCD. Но такой путь ведет к потере времени, если у вас много хостов, требующих тестирования. Каждый компьютер необходимо загружать с CD/DVD и прогонять тесты вручную, при этом другие узлы сети будут простаивать и ждать своей очереди. Для решения проблемы можно использовать тестирование с загрузкой тестов через сеть по вашему собственному сценарию, при этом все результаты тестирования будут сохраняться на сервере. Что мы и попытаемся реализовать.

На сегодняшний день существует единственный специализированный для тестирования LiveCD-дистрибутив – StressLinux. Он работает только в режиме консоли и занимает порядка 50 Мб, но этого будет достаточно чтобы провести полноценное тестирование. StressLinux содержит основные утилиты для тестирования комплектующих компьютера при высоких нагрузках, утилиты для считывания информации с датчиков процессорной платы, а также обладает высокой гибкостью в настройках сценариев для тестирования. Вы сами сможете задавать сценарии тестирования, добавляя или убирая тесты. В качестве оболочки в StressLinux используется busybox. Она содержит набор общих UNIX-утилит для работы в Linux, позаимствованных из GNU пакетов fileutils, shellutils и т. д. С помощью busybox можно создать ОС Linux, умещающуюся на одну дискету. Подробную информацию о проекте вы можете найти на сайте http://www.busybox.net.

Как насчет гарантии?

Разработчики тестов, входящих в состав StressLinux, сообщают: «Эти программы разработаны для создания высокой нагрузки процессоров, поэтому неохлаждаемые, разогнанные или по другой причине «непрочные» (weak) системы при прохождении тестирования могут вызвать потерю данных (повреждение файловой системы), также есть вероятность нанести повреждения компонентам микросхем».

Поэтому если ваше железо еще на гарантии, можете проводить тесты, а если нет, то использовать тестирование вы будете на свой страх и риск.

Конфигурация тестового комплекса

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

Требования к рабочей станции – наличие сетевой карты с поддержкой PXE. Список поддерживаемых карт можно узнать здесь: (http://www.bootix.com/adapters/adapters_en.html). В качестве рабочей станции я буду использовать VMWare, так как это удобно для создания скриншотов в моменты загрузки системы. Тесты загружать в VMWare бесполезно, потому что при тестировании будет использоваться только та часть ресурсов, которая выделена под виртуальную систему. Поэтому тестирование надо проводить на реальной машине. А вот настройки загрузки через сеть StressLinux под VMWare проводить очень удобно, не придется бегать от сервера к клиенту и проверять, что же там опять не работает.

Со стороны сервера потребуется:

  • дистрибутив StressLinux;
  • дистрибутив Linux, функционирующий на сервере (я использую ASP Linux 9.0);
  • серверная часть пакетов: pxe, dhcp, tftp, nfs.

Как будет работать тестовый комплекс

Перезапускаем клиентскую машину и в BIOS выбираем загрузку по сети. После перезагрузки сетевая карта будет выполнять поиск dhcp-сервера. Сервер принимает запрос и присваивает клиенту IP-адрес, pxe предлагает выбрать загрузку:

  • Local boot – с жесткого диска;
  • PXELinux – появится меню для выбора загрузки одного из ядер StressLinux, или загрузки отдельного теста, например теста памяти – memtest.

При выборе ядра происходит передача его по протоколу tftp с последующей загрузкой корневой файловой системы nfs, находящейся на сервере. Выполняется тестирование в автоматическом режиме, а результаты записываются в текстовые файлы на сервере.

Конфигурация сервера

Я использую дистрибутив ASP Linux 9.0 на rpm-пакетах. Вам нужно использовать пакеты, входящие в состав вашего Linux.

Для начала скачиваем последнюю версию дистрибутива StressLinux 0.3.1 с http://www.stresslinux.org/release/stresslinux-0.3.1.pxe.tgz с поддержкой загрузки через PXE. Распаковываем каталог с корневой системой StressLinux (_stresslinux) в директорию на сервере /tftpboot/X86PC/_stresslinux.

Скачиваем http://www.stresslinux.org/release/stresslinux-0.3.1.pxe_sample_configs.tgz архив с примерами конфигурационных файлов pxe, dhcp, tftp, nfs. Распаковываем в каталог /tftpboot/X86PC/pxelinux содержимое из папки pxes. Этот каталог будет использоваться для создания сценариев загрузки рабочих станций через pxe. Каждой рабочей станции можно присвоить свой сценарий загрузки на основе её IP-адреса, за подробной информацией можно обратиться на сайт http://syslinux.zytor.com/pxe.php. Применим одинаковый сценарий загрузки для всех клиентов – default. В файл внесем изменения, указав в nfsroot адрес вашего сервера и расположение корневого каталога _stresslinux. Сервер имеет IP-адрес: 192.168.12.191. После изменений файл /tftpboot/X86PC/pxelinux/pxelinux.cfg/default будет выглядеть так:

default stress

prompt 1

timeout 600

display loader.msg

F1 loader.msg

label stress     # Stresslinux

  kernel ../_stresslinux/boot/vmlinuz

  append rw video=vesafb:640x480-32@75,nomtrr,ywrap root=/dev/nfs \

    nfsroot=192.168.12.191:/tftpboot/X86PC/_stresslinuxip=dhcp hda=scsi hdb=scsi hdc=scsi hdd=scsi

  • default – имя сценария для загрузки по умолчанию;
  • prompt – может принимать значения 1 или 0. Если значение 1, то перед загрузкой будет выведена строка «boot: <Имя загружаемого сценария>». Если же значение 0, то эта строка выводится только при: нажатии <Alt> или <Shift>, или при включенном CapsLock, или Scroll lock;
  • timeout – содержит количество секунд до начала автоматической загрузки;
  • display – параметр, указывающий на файл-приветствие, будем использовать по умолчанию loader.msg:

Welcome to StressLinux Boot Server!

0fTo start the stresslinux distribution enter press ?

    <return>.07

Available boot options:

  stress        - Boot Stresslinux via PXE with initrd

09F1:0f Stresslinux

  • F1 – здесь можно создать файл-help и указать все возможные параметры ядер;
  • label – это имя сценария загрузки, а сценарий может содержать в себе 3 параметра:
  • kernel – путь к ядру Linux или к отдельной загружаемой программе, например memtest;
  • append – список параметров, передаваемых ядру;
  • ippappend – параметр, используемый PXELinux для указания настроек сети. Он нам не нужен, так как предполагаем, что загрузка для всех узлов сети общая. Параметры сети для каждого клиента указывает dhcp сервер. Описание всех возможных конфигураций файла default можно узнать (http://syslinux.zytor.com/faq.php).

Далее будем настраивать dhcp-сервер. Для этого необходимо установить его из вашего дистрибутива Linux, в ASP Linux это rpm – Uvh dhcp-3.0pl1-23.i386.rpm, а если же такого под рукой не имеется, тогда скачиваем его с http://ftp.isc.org/isc/dhcp. На момент написания статьи последней версией была – 3.0.4. Создаем конфигурационный файл /etc/dhcpd.conf, указав MAC-адрес одного из клиентов. Я буду указывать MAC-адрес VMWare. После изменений файл должен выглядеть так:

Subnet 192.168.12.0 netmask 255.255.255.0 {

    option subnet-mask 255.255.255.0;

    default-lease-time 21600;

    max-lease-time 43200;

    host some_host{

           # Указываю MAC-адрес VMWare

           hardware ethernet 00:0C::29:50:84:D7;

           fixed-adress 192.168.12.242;

           option vendor-class-identifier "PXEClient"

    }

}

Надо уделить внимание опции ‘option vendor-class-identifier “PXEClient”’. Она требуется для того, чтобы dhcp передал управление серверу pxe в момент присвоения IP-адреса клиенту, а pxe в свою очередь смог отобразить меню для выбора загрузки (это меню появляется путем запуска бинарного файла pxelinux.0 на сетевой карте). Службы dhcp и tftp можно запустить на разных узлах сети, тогда необходимо добавить в конфигурационный файл параметр next-server, указывающий на имя или IP-адрес tftp-сервера. Мы же будем использовать один хост, поэтому этот параметр не указываем.

Перейдем к настройке предзагрузочной среды запуска – pxe. Для её установки в ASP Linux выполняю rpm –Uvh pxe-0.1-36.i386.rpm, если в вашем дистрибутиве такого пакета нет, то скачиваем с сайта http://www.kano.org.uk/projects/pxe. Изменяем конфигурационный файл /etc/pxe.conf, установив 2 значения:

  • interface – номер интерфейса на сервере, по которому соединены сервер с клиентом;
  • default_address – IP-адрес сервера.

Остальные параметры оставляем без изменений. Вид файла после изменений смотрите на рис. 1.

Рисунок 1. Пример конфигурационного файла pxe.conf

Рисунок 1. Пример конфигурационного файла pxe.conf

Устанавливаем tftp-server, взяв его из дистрибутива (tftp-server-0.33-1asp.i386.rpm) или с http://www.kernel.org/pub/software/network/tftp. Tftp-сервер будет использоваться для передачи ядра и образа ядра клиентам. Запуск его можно реализовать из-под xinetd, для этого в файле /etc/xinet.d/tftp исправить значение параметра disable с «yes» на «no» и убедиться, что в качестве рабочего каталога установлен /tftpboot. А запуск из консоли можно выполнить:

# in.tftpd –v –l –s /tftpboot

Теперь подходим к финальному шагу по настройке загрузки StressLinux – конфигурированию nfs, который будет использоваться для доступа к корневой файловой системе StressLinux загружаемыми станциями.

Устанавливаем nfs-utils, в ASP Linux выполнив rpm –Uvh nfs-utils-1.0.1-2.9.i386.rpm), иначе скачиваем с ресурса http://prdownload.sourceforge.net/nfs). Все настройки nfs сводятся к конфигурации трех файлов:

  • /etc/exports – указывает каталоги, доступные через nfs;
  • /etc/hosts.allow и /etc/hosts.deny – файлы управления доступом к серверу.

Переходим непосредственно к конфигурации nfs-сервера – файлу /etc/exports. Более подробно о настройках nfs можно узнать на http://nfs.sourceforge.net/nfs-howto. Откроем доступ к каталогу /tftpboot/X86PC/_stresslinux на чтение и запись для всех узлов сети 192.168.12.0/24, указав строку:

/tftpboot/X86PC/_stresslinux 192.168.12.0/255.255.255.0 (rw,insecure,sync,no_root_squash)

Теперь запускаем программы dhcpd, pxe, tftp, nfs. Перезагружаем клиента и выбираем загрузку по сети, в результате появится приглашение (см. рис. 2).

Рисунок 2. Приглашение для выбора варианта загрузки

Рисунок 2. Приглашение для выбора варианта загрузки

Выбираем PXELinux (см. рис. 3). Отображается меню StressLinux для выбора загрузочного ядра в нашем случае  – это будет одно-единственное 2.6.16. Но это пока, в дальнейшем можно будет расширить список ядер и отдельных программ для тестирования.

Рисунок 3. Отображение содержимого файла loader.msg

Рисунок 3. Отображение содержимого файла loader.msg

Выбираем ядро и загружаемся. Если оно загрузилось успешно, тогда выводится приглашение (см. рис. 4) для ввода логина. Вводим root без пароля.

Рисунок 4. Пример успешной загрузки ядра

Рисунок 4. Пример успешной загрузки ядра

Друг за другом появятся 2 меню для выбора раскладки клавиатуры и выбора процессорной платы соответственно (см. рис. 5, 6).

Рисунок 5. Программа для ручного выбора типа клавиатуры

Рисунок 5. Программа для ручного выбора типа клавиатуры

Рисунок 6. Программа для ручного выбора процессорной платы

Рисунок 6. Программа для ручного выбора процессорной платы

Если на вашей процессорной плате есть сенсоры температуры и напряжений, то тогда во время тестирования можно будет наблюдать за состоянием компьютера. Вывод данных реализован программой sensors из пакета lm_sensors. Список поддерживаемых процессорных плат можно узнать на http://secure.netroedge.com/~lm78/supported.html. Для поиска требуемых модулей можно воспользоваться программой sensors-detect.

В этой версии StressLinux используется ядро 2.6.16. Если вас устраивает это ядро, тогда следующий пункт можно пропустить, если же нет, тогда перейдем к настройке собственного ядра.

Конфигурация нового ядра

Ядро, входящее в дистрибутив StressLinux, не имеет поддержки некоторых SCSI-контроллеров. Поэтому можно использовать собственное ядро с поддержкой всего необходимого железа. При нго конфигурировании необходимо не забыть установить параметр CONFIG_ROOT_NFS, для того чтобы использовать корневую файловую систему nfs. Также можно добавить последнюю версию пакета lm_sensors. Для загрузки нового ядра копируем его в каталог /tftpboot/X86PC/_stresslinux/boot/ и назовем vmlinuz-<номер версии ядра>. Все модули этого ядра копируем в /tftpboot/X86PC/_stresslinux/lib/<номер версии ядра>. Добавляем следующие строки в файл /tftpboot/X86PC/pxelinux/pxelinux.cfg/default:

label  my  # Stresslinux (my kernel)

  kernel ../_stresslinux/boot/vmlinuz-<номер версии ядра>

  append initrd= rw video=vesafb:640x480-32@75,nomtrr,ywrap \

    root=/dev/nfs nfsroot=192.168.12.191:/tftpboot/X86PC/_stresslinux ip=dhcp hda=scsi hdb=scsi hdc=scsi hdd=scsi

Не забываем добавить пункт в файл loader.msg. Перезапускаем клиента и выбираем созданное ядро.

Список доступных утилит для тестирования

Список основных утилит представлен в файле /tftpboot/X86PC/_stresslinux/etc/motd (см. рис. 7).

Рисунок 7. Список программ для тестирования с кратким описанием

Рисунок 7. Список программ для тестирования с кратким описанием

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

  • серию программ для высокой загрузки процессоров – burn-оптимизированных под разные процессоры (http://pages.sbcglobal.net/redelm);
  • stress – используемую в качестве инструмента для установки определенной загрузки процессора, памяти, ввода/вывода, жесткого диска (http://weather.ou.edu/%7Eapw/projects/stress);
  • netio – для тестирования производительности сети;
  • smartctl – для тестирования устройств с поддержкой S.M.A.R.T.;
  • lshw – для сбора информации обо всей системе;
  • x86info – информация о процессорах;
  • программы мониторинга – hddtemp, sensors.

Сценарии тестирования

Для создания сценария достаточно создать скрипт на bash или другом языке программирования и указать его выполнение в файле /tftpboot/X86PC/_stresslinux/etc/bash.bashrc.

Создадим сценарий – test.sh и разместим его в /tftpboot/X86PC/_stresslinux/etc/init.d/. Предполагаем, что компьютеров для тестирования будет много, поэтому результаты прохождения тестов для каждого узла будем сохранять в отдельную папку, в качестве имени папки будем использовать IP-адрес этого узла. Реализовать это можно следующим образом:

#!/bin/bash

// Получаем IP-адрес узла

IP=`ifconfig|grep inet|perl -nle @ar=split(/\s+/,$_);@ar2=split(/\:/,\\$ar[2]); print \\$ar2[1]`

// Создаем каталог, если такого еще не существует

if[ ! -d /home/result/$IP ]

then

echo

Making results dir /home/result/$IP

/bin/mkdir -p result/$IP

fi

// все результаты тестирования будем записывать сюда

cd /home/result/$IP

Далее загружаем модули для вывода информации, модули для вашей процессорной платы можно определить с помощью скрипта detect-sensors.

VAL=`/sbin/lsmod | grep i2c-isa`

if [

x$VAL

 ==

x

 ]

then

echo

trying insert module i2c-isa

modprobe i2c-isa

fi

Перед тестированием собираем информацию об узле и сохраняем ее на сервере:

echo

Collecting information

# собираем информацию о PCI-устройствах

/sbin/lspci | tee lspci

sleep5

# собираем информацию о процессорах

/usr/bin/x86info | tee x86info

sleep5

# собираем расширенную информацию о системе

/usr/bin/lshw | tee lshw

sleep5

Программа tee выдает результаты на экран и одновременно записывает в указанный ей файл на сервер.

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

TM=20 # Таймер

echo

Starting 1st test

 | tee stress1

echo

Spanning 10 workers spinning on sqrt()

| tee -a stress1

echo

waiting for $TM seconds

| tee -a stress1

/usr/bin/stress -v -c 10 -t $TM | tee -a stress1 &

Запускаем stress с порождением 10 процессов на период, указанный в переменной $TM, равной 20 секундам. Результаты сохраняем в файл stress1. Пример успешного завершения теста приведен на рис. 8.

Рисунок 8. Пример успешного завершения теста по вычислению квадратного корня

Рисунок 8. Пример успешного завершения теста по вычислению квадратного корня

В результате видим, что все 10 процессов запустились и завершились успешно, тест был проведен в течение 20 секунд. Если вы загрузили модули для считывания информации с датчиков, то после каждого теста можно использовать функцию, которая будет отображать состояние системы с интервалом в  1 секунду.

sens "Spanning 10 workers spinning on sqrt() stress1" "$TM"

SENSORS=`/usr/bin/sensors | grep 'No sensors found'`

sens()

{

    if [ "x$SENSORS" == "x" ]

    then

      for((i=1;i<=$2;i++))

        do

                /usr/bin/clear

                /usr/bin/sensors

                echo "Time limit $2 s"

                echo "seconds $i $1"

                sleep1

        done

    fi

}

Постоянное отображение состояния системы с периодичностью в 2 секунды можете наблюдать на /dev/tty12. Пример состояния системы во время тестирования представлен на рис. 9.

Рисунок 9. Пример считывания информации с датчиков процессорной платы

Рисунок 9. Пример считывания информации с датчиков процессорной платы

Напутствие

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

Дальнейшая функциональность тестирования может быть расширена добавлением других программ в составе StressLinux, и не только. Например, можно добавить образы дискет загружаемых по сети для конфигурирования сетевых карт 3com или позаимствовать некоторые dos-утилиты для восстановления mbr из дистрибутива Ultimate Boot CD. Дальнейшие улучшения будут зависеть только от ваших фантазий и времени, которое вы можете затратить.

Желаю успешного тестирования!


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-45
E-mail: sa@samag.ru