Dmesg linux что делает. Получение информации об аппаратном обеспечении Linux-компьютера без использования отвертки. Изменение размера буфера dmesg


Если коротко, то:

  • контекст процесса SELinux менять можно, если подобная операция описана в правилах sepolicy. В версии Android 4.4 (KitKat) есть возможность повысить привилегии, изменяя контекст. Но начиная с 5.x это уже сделать нельзя.
  • существуют контексты файлов.
  • Кроме контекста файлов и процессов в Android реализованы контексты для параметров property_contexts .

adbd и консоль

Единственный доступный способ получения относительно привилегированного shell в production устройствах Android - developer mode. Developer mode запускает демон adbd, который может выступать в том числе и как аналог ssh/telnet. В Android KitKat он находится в initramfs по пути /sbin/adbd и не доступен для чтения для не-root пользователей. Изначально adbd запускается под пользователем root и работает в SELinux контексте/домене init (используется процессом init и как правило имеет больше привилегий, чем другие домены). Если в /init.rc явно указан контекст процесса, например seclabel u:r:adbd:s0 , то процесс запускается сразу в указанном контексте. При инициализации adbd в зависимости от параметров компиляции ( и параметров Android (properties) понижает привилегии, а именно меняет текущего пользователя с root на shell, устанавливает SELinux context в shell и урезает все системные capabilities кроме CAP_SETUID и CAP_SETGID (что требуется для отладки приложений через run-as). Так называемый Capability Bounding Set не позволяет дочерним приложениям повышать capabilities, только понижать. Эти привилегии позволяют делать на телефоне чуть больше, чем ничего. Просмотреть capabilities текущего процесса можно командой cat /proc/self/status | grep CapBnd . А расшифровать их можно с помощью команды capsh (не доступна на Android), например:


$ capsh --decode=0000001fffffffff

Текущий SELinux context можно просмотреть командой id или cat /proc/self/attr/current . Предыдущий контекст процесса можно просмотреть командой cat /proc/self/attr/prev .


Просмотр context"а файлов: ls -Z
Просмотр context"а запущенных процессов: ps -Z

Получаем root доступ

root, да не тот

Первое, что я сделал это использовал dirtycow по прямому назначению - подменил /system/bin/run-as , который задал UID/GID в 0 (тоже самое делает su). Однако монтировать файловую систему я не мог, даже tmpfs. Загружать модули ядра я тоже не мог. Просматривать dmesg - нет. Я даже не мог просматривать директории, которые имели права 700 и принадлежали другим системным пользователям. Я мог лишь читать и писать в блочные устройства, а просмотр файлов или директорий был возможен благодаря заданию UID/GID определенного пользователя (написал свой велосипед - аналог su, который мог задавать selinux context и пользователя/группу).


Первым делом я сделал дамп всей прошивки, boot и recovery:


$ dd if=/dev/block/mmcblk0 of=/storage/sdcard1/mmcblk0.img $ dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/storage/sdcard1/boot.img $ dd if=/dev/block/platform/msm_sdcc.1/by-name/recovery of=/storage/sdcard1/recovery.img

Изучить дамп можно утилитами kpartx и unpackbootimg . Команда kpartx -a mmbblk0.img создает виртуальное блочное устройство, доступное по пути /dev/mapper/loop0 . С ним можно работать как с любым другим блочным устройством. Дампы разделов boot и recovery распаковал утилитой unpackbootimg .


Потом попробовал записать в recovery /dev/zero , проверить и сразу восстановить из дампа.


Раз я мог писать в блочные устройства, значит я мог записать custom recovery. Нашел TWRP от Brigadier, прошил в recovery и перезагрузился в него adb reboot recovery . TWRP я не увидел, а лишь иконку Android"а с восклицательным знаком. Так выглядит стандартный recovery, а значит TWRP не прошился.


Перезагружаюсь в обычный режим, запускаю эксплойт, проверяю hash recovery раздела - hash соответствует оригинальному. Пробую записать данные опять - hash поменялся! Вспоминаю про page cache, чищу (echo 3 > /proc/sys/vm/drop_caches) - hash старый. Т.е. всё, что я пишу в блочное устройство улетает без ошибок в /dev/null и иногда оседает в Linux cache. Но обновление прошивки ведь как-то происходит? И пользовательские данные как-то записываются во внутреннюю память. Надо копать дальше.

Пробуем отключить SELinux

На тот момент я думал, что все ошибки об отсутствии привилегий вызваны SELinux (я полностью забыл о том, что могут быть урезаны capabilities). Логов dmesg я не видел, logcat ничего релевантного не показывал. И я начал думать как отключить SELinux.


Первая зацепка, которую я смог найти:


$ grep -A2 reload_policy boot/ramfs/init.rc on property:selinux.reload_policy=1 restart ueventd restart installd

Т.е. перед тем как применить ZIP, recovery отмонтирует все разделы, но в моём случае что-то идёт не так.

Копаем исходники ядра

Лицензия GPL обязывает производителей смартфонов выкладывать исходники ядра. Спасибо Линусу и Столлману за это. Иногда производители выкладывают что-то левое, иногда правильные исходники, но без defconfig файла, иногда правильные и очень редко с инструкцией как их собирать (например LG).


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


Через продолжительное время я остановился на двух файлах:

hooks

Kyocera долго не думала, а просто запилила хуки на потенциально опасные операции в Android: mount , umount , insmod (к загрузке разрешен всего один модуль - wlan и только если его загрузит init процесс), и прочее. Вот где крылась проблема recovery. Он не мог отмонтировать файловую систему /system ! Эти операции позволялись только init процессу. В том числе я не мог отключить SELinux потому что эта возможность была отключена при компиляции ядра. Обойти эти хуки можно было только, если ядро загружено с определенными параметрами (kcdroidboot.mode=f-ksg или androidboot.mode=kcfactory , о них чуть позже).

restart

Тоже интересный для изучения файл. В нем описываются возможные варианты загрузки телефона:

  • adb reboot bootloader - режим fastboot, в моём телефоне не доступен (0x77665500 - hex метка 00556677 в разделе sbl1)
  • adb reboot recovery - режим recovery (0x77665502 - hex метка 02556677 в разделе sbl1)
  • adb reboot rtc - так называемый ALARM_BOOT. Так и не понял для чего, метки в sbl1 нет. Возможно имеется в виду https://developer.android.com/reference/android/app/AlarmManager.html
  • adb reboot oem-X (в моём случае oem-1, 0x6f656d01 - hex метка 016d656f в разделе sbl1). Что происходит во время этого режима устанавливается производителем. Судя по исходникам, в этот режим телефон перезагружается при ошибке аутентификации прошивок из раздела modem.
  • adb reboot edl - emergency download, переводит телефон в штатный qualcomm"овский download mode. Телефон определяется как QHSUSB__BULK COM port, по которому можно передать подписанный загрузчик (если не ошибаюсь, то каждый загрузчик предназначен для одного типа SoC и производителя телефонов) и выполнять низкоуровневые операции с телефоном, в том числе и прошить. Обычно используется вкупе с QPST. Для некоторых телефонов загрузчики утекают в сеть, например для Kyocera KYL22. Откуда они берутся - мне неизвестно.
  • Некий download mode , в который через adb reboot не зайти. Вот тут интересно… Но об этом позже.

Немного о том, как происходит загрузка на телефонах с процессором Qualcomm:


Встроенный ROM загрузчик Qualcomm (pbl - primary bootloader) загружает раздел sbl1 (secondary bootloader). sbl1 загружает tz (trust zone), затем aboot (android boot, little kernel, lk). Aboot в свою очередь загружает boot, recovery или fota.


Описание разделов, участвующих при загрузке:

  • tz - Qualcomm Trust Zone. Выполняет низкоуровневые операции, в том числе работает с QFuses (раздел rpmb).
  • rpm - Resource and Power Manager firmware. Прошивка для специализированного SoC, отвечающего за ресурсы и питание.
  • sdi - trust zone storage partition. Данные, которые используются Trust Zone.

Все эти разделы подписаны цепочкой сертификатов.

fota

В некоторых случаях полезно игнорировать обновления прошивки.


FOTA - firmware over the air. В отличие от boot и recovery, fota - это неофициальный режим загрузки Android. Задача fota - обновить прошивку. В Kyocera для этого используется решение от компании Red Bend , которое в 35Mb умещает обновление не только ядра но и раздела /system . Потому запись в раздел /system запрещена, иначе наложение патча на неправильные данные может окирпичить телефон.


На мой телефон имелось обновление. Отважиться на него я мог потому, что я уже имел возможность писать в /cache и прервать обновление в любой момент.


Изучив исходники отвечающего за обновление Java приложения , мне стало ясно как оно происходит:

  • Java приложение скачивает специальный файл /cache/delta/boot_delta.bin , создает файл /cache/delta/Alt-OTA_dlcomplete , подтверждающий успешную загрузку файла, и другие файлы с header"ами.
  • При подтверждении обновления еще раз проверяется наличие этих файлов.
  • Если файлы на месте, то через библиотеку libjnialtota.so происходит модификация раздела fotamng .

Пишу команду, которая непрерывно делает дамп раздела и переименовывает /cache/delta/boot_delta.bin . Запускаю её сразу после соглашения о перезагрузки телефона. Телефон перезагружается в режим FOTA, рапортует об отсутствии обновления и перезагружается в обычный режим.


Начинаю изучать данные, которые сдампил. В разделе /cache бонусом получаю логи fota, в которых даже есть логи dmseg! Сама перезагрузка в fota инициализируется байтами "1" в разделе fotamng:


$ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=16 bs=1 count=1 $ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=24 bs=1 count=1 $ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=131088 bs=1 count=1 $ dd if=/data/local/tmp/one_bit.bin of=/dev/block/platform/msm_sdcc.1/by-name/fotamng seek=131096 bs=1 count=1

После перезагрузки они обнуляются. В dmesg я обратил внимание на наличие параметра ядра kcdroidboot.mode=f-ksg . Вот оно! Т.е. загрузчик снимает защиту для fota. И чисто теоретически, если я запишу раздел boot в fota и перезагружу телефон в этот режим, то я получу ядро с отключенной защитой Kyocera. Но писать в системные разделы я всё еще не могу.

Изучение исходников little kernel (lk)

То, что находится в разделе aboot - загрузчик Android, ванильные исходники которого находятся по адресу:


Там можно найти и информацию как происходит загрузка в некоторые из режимов. Например я нашел информацию о том, что если в раздел misc записать "boot-recovery", то без adb reboot recovery . При загрузке в recovery эта . И если recovery загрузиться не может, то телефон попадёт в boot loop и вы его потеряете. Так что будьте осторожны, а лучше избегайте этого варианта перезагрузки.


Там же можно найти код, который переводит системную область emmc в режим . Ответ на вопрос, почему невозможно перезаписать recovery. Эту защиту можно отключить из ядра Linux , если написать соответствующий модуль ядра. Уже всё написано товарищем из страны восходящего солнца, который, похоже, тоже неровно дышит к телефонам компании Kyocera. Модуль с первого раза не сработал, иногда подвешивает mmc в claim mode. Возможно не всё так однозначно и требуется детальное исследование.


Вот так происходит проверка подписи загрузочных разделов:

Первые успехи

dmesg

Google мне помог ответить на вопрос, почему я не могу прочитать логи ядра: /proc/sys/kernel/dmesg_restrict . Значение этого параметра задается в 1 во время загрузки телефона. Если у пользователя нет CAP_SYS_ADMIN capability, то логи ему не доступны.

uevent_helper

В моём случае, на удивление, была возможность задать /sys/kernel/uevent_helper . Если в этот параметр записать путь до executable файла (shell script тоже сойдёт), то он с определенным интервалом будет запускаться от процесса init в контексте init и что самое важное с full capabilities.


Я написал скрипт:


#!/system/bin/sh echo 0 > /proc/sys/kernel/dmesg_restrict

Загрузил его на телефон и записал его путь в /sys/kernel/uevent_helper . У меня появилась возможность видеть dmesg!

Патченный adbd


Т.к. мне надоело иметь доступ к урезанной консоли Android, а патчить бинарник adbd мне лень, то я решил собрать свой adbd с блэкджеком и шлюхами. Для этого пришлось скачать 70 Gb исходников Android, чтобы не возиться с каждой зависимостью по отдельности. Убрал проверку при которой происходит урезание capabilities, скомпилировал, подменил /sbin/adbd и получил полноценную root консоль. Теперь я могу монтировать файловые системы, смотреть dmesg без отключения dmesg_restrict , спокойно просматривать и редактировать файлы, которые не принадлежат root и многое другое. Но я пока не могу монтировать /system раздел и загружать модули в ядро.


Кстати, этой процедуры можно избежать, скомпилировав lsh и подставить его путь в /sys/kernel/uevent_helper . Желательно обернув запуск lsh в скрипт, который задаёт PATH environment, иначе придется задавать полный путь к каждой команде.

WiFi

WiFi в моем телефоне работает через модуль ядра. WiFi включен - модуль загружен. WiFi выключен - модуль выгружен. Если подменить модуль на свой, то при включении WiFi должен загрузиться подставной модуль. На моё счастье цифровая подпись модулей не проверялась. Первое, что я попробовал, это собрать и загрузить модуль, который отключает SELinux путем замены памяти ядра на Amazon Fire Phone: https://github.com/chaosmaster/ford_selinux_permissive


Чтобы собрать модуль, требуется более-менее соответствующие исходники ядра и файл Module.symvers. Если исходники точно соответствуют тому ядру, что используется на телефоне, то Module.symvers , сгенерированный автоматически при сборке ядра должен подойти.


Если при загрузке модуля ядро будет ругаться (disagrees about version of symbol module_layout ), то потребуется извлечь Module.symvers из boot раздела. Это можно сделать, используя скрипт https://github.com/glandium/extract-symvers :


$ unpackbootimg -i boot.img -o boot $ extract-symvers.py -e le -B 0xc0008000 boot/boot.img-zImage > %PATH_TO_KERNEL%/Module.symvers

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




С каждым решением очередной проблемы, процесс всё больше напоминает апорию об Ахиллесе и черепахе . Не знаю на сколько еще хватит моего энтузиазма. Возможно здесь есть знающие люди, которые помогут достичь дна кроличьей норы.


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


P.S. Огромное спасибо Николаю Еленкову (Nikolay Elenkov), автору книги Android security internals . Его пояснения о работе bootloader"а помогли понять процесс загрузки Android.


P.P.S. Еще один специалист по мобильной ИБ, Justin Case, сказал, что он знает уязвимость, которой подвержены все современные процессоры Qualcomm, но раскрывать её детали он не будет.

Теги:

  • android
  • bootloader Отправить анонимно

Знаете ли вы, что ядро Linux загружает несколько драйверов устройств при загрузке системы?

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

Конечно, ядро также делает много других вещей.

Что делать, если вы хотите узнать информацию, связанную с этими действиями ядра?

Что ж, существует команда — dmesg — которую вы можете использовать, если хотите получать доступ к сообщениям, выведенные ядром.

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

Команда Linux dmesg

Синтаксис команды dmesg:

Dmesg

Ниже приведены примеры Вопрос & Ответ, которые помогут вам лучше понять, как работает команда dmesg.

В1. Как использовать команду dmesg?

Вы можете начать использовать команду dmesg без любой опции командной строки.

Например, вот небольшая часть вывода команды, созданной в моем случае:

В2. Как ограничить вывод только ошибками и предупреждениями?

Если вы запустите dmesg в своей системе, вы увидите, что он выводит множество информации.

В зависимости от того, что вы ищете, вы можете фильтровать или ограничивать вывод.

Со своей стороны, dmesg предлагает вам эту способность через «уровни».

Ниже приведен полный список уровней (вместе с их объяснением):

Emerg - system is unusable alert - action must be taken immediately crit - critical conditions err - error conditions warn - warning conditions notice - normal but significant condition info - informational debug - debug-level messages

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

Dmesg --level=err,warn

В моем случае, вот часть вывода выведенной выше команды:

В3. Как создать dmesg для создания временных меток?

Иногда вам может понадобиться связать временную метку с сообщениями, которые создает dmesg.

Это можно сделать, используя опцию командной строки -T, которая создает человекочитаемые метки времени.

Dmesg -T

Пример вывода:

В4. Как сделать, что dmesg отображал информацию об определенном устройстве?

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

Вот как вы можете это сделать:

Dmesg | grep -i eth0

Пример вывода:

В5. Как заставить dmesg отображать только сообщения в пользовательском пространстве?

Если вы хотите ограничить вывод dmesg только сообщениями пользовательского пространства, используйте параметр командной строки -u.

Dmesg -u

Согласитесь, dmesg — это не та команда, которая вам понадобится каждый день.

Но это инструмент, к которому нужно обратиться, когда кто-то (которого вы попросили о помощи по определенной теме) просит вас предоставить сообщения ядра.

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

Источник: Finding Hardware Details of your Linux Machine without Using Screw Driver
Перевод: В.Костромин , 11.01.2007 г.

Многие неопытные пользователи Linux затрудняются, если им необходимо определить какие-то характеристики аппаратной части их Linux-компьютера, пользуясь только командами, доступными в консоли (в командной строке). Графические оболочки в последнее время имеют в своем составе специальные утилиты, которые предоставляют такую информацию в достаточно удобном виде. Однако администраторы и пользователи домашних компьютеров не всегда имеют возможность ими воспользоваться.

В этом небольшом руководстве мы научимся тому, как можно получить спецификацию вашего Linux- компьютера в командной строке. Дочитав это руководство до конца, вы сможете в течение минуты получить полный перечень всех компонент вашего компьютера с их характеристиками. Это может, например, помочь вам в поиске нужных драйверов и адресов служб поддержки для вашего оборудования.

Часть 1: Получение информации об оборудовании с помощью команды lspci

Утилита lspci предназначена для вывода информации о всех PCI-шинах в системе, а также о всех устройствах, присоединенных к этим шинам. По умолчанию она показывает краткий список таких устройств. Однако вы можете использовать многочисленные опции lspci для получения более подробной информации или информации, ориентированной на последующую обработку с помощью других программ.

# /sbin/lspci
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
03:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 02)
....

Теперь я знаю, что у меня стоит графический чип Intel Corporation 82865G Integrated Graphics Controller и могу поискать драйвер для него в Интернет. Посмотрим, какую информацию содержит строка, соответствующая этому чипу:

Чтобы получить больше информации, вы можете воспользоваться опциями -v или -vv. Например, когда я задал команду lspci -v , я получил следующий результат:

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 )
Subsystem: IBM Unknown device 0285
Flags: bus master, fast devsel, latency 0, IRQ 185
Memory at f0000000 (32-bit, prefetchable)
Memory at e8000000 (32-bit, non-prefetchable)
I/O ports at 1800
Capabilities: Power Management version 1

Утилита lspci вначале считывает информацию с PCI-шины, а потом дополнительную информцию ищет в собственной базе данных, которая находится в файле /usr/share/hwdata/pci.ids и содержит такие данные как идентификатор обрудования, производитель, устройства, классы и подклассы. Команда

# cat /usr/share/hwdata/pci.ids | grep "82865G Integrated Graphics Controller"
82865G Integrated Graphics Controller

позволяет убедиться, что наше устройство тоже содержится в этой базе. Данный список оборудования поддерживается на страничке , и вы можете использовать утилиту update-pciids для того, чтобы получить самую последнюю его версию.

Часть 2: Получение информации об оборудовании с помощью команды dmesg

Команда dmesg обычно используется в Linux для того, чтобы просмотреть содержимое кольцевого буфера ядра. Она позволяет пользователю вывести содержание сообщений, выдаваемых в процессе загрузки системы.

Утилита lspci хорошо помогает при обнаружении PCI-устройств, однако нам часто требуется список всех устройств в системе. Используя dmesg мы можем просмотреть характеристики всех устройств, которые обнаружены нашей операционной системой.

# dmesg | less
Normal zone: 59248 pages, LIFO batch:15
DMI present.
Allocating PCI resources starting at 20000000 (gap: 10000000:eec00000)
Detected 2793.055 MHz processor.
Built 1 zonelists. Total pages: 63344
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet
Enabling fast FPU save and restore... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c07ae000 soft=c078e000

.....

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

# dmesg | grep -i memory
Memory: 244136k/253376k available (2139k kernel code, 8732k reserved, 866k data, 240k init, 0k highmem)
Freeing initrd memory: 2124k freed
Total HugeTLB memory allocated, 0
Non-volatile memory driver v1.2
agpgart: Detected 8060K stolen memory.
Freeing unused kernel memory: 240k freed
.....

Подобным образом вы можете вычленить информацию о любом устройстве, которое вас интересует или с которым в данный момент возникли проблемы, например, о центральном процессоре (CPU), USB-устройствах и т.д.

Часть 3: Получение информации об оборудовании из /proc

Иногда вам может потребоваться получить информацию об оперативной памяти или центральном процессоре в реальном времени на работающей системе. Для того, чтобы сделать это, вы можете воспользоваться виртуальной файловой системой /proc . Может быть вы вспомните и об утилите top , но знайте, что она просто считывает данные из файловой системы /proc . Только помните, что не следует вносить какие-либо изменения в файлы, расположенные в каталоге /proc , можно только воспользоваться командой cat для просмотра этих файлов.

Выполнив команду ls в каталоге /proc , вы увидите различные каталоги и файлы, которые содержат информацию о вашей системе.

Давайте посмотрим, что в этих файлах содержится, начиная, например, с cpuinfo.

# cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 15
model: 2
model name: Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping: 9
cpu MHz: 2793.055
cache size: 512 KB
....

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

# cat /proc/ide/ide0/hda/driver
ide-disk version 1.18
# cat /proc/ide/ide0/hda/capacity
78156288
# cat /proc/ide/ide0/hda/model
IC35L060AVV207-0

Часть 4: Получение дополнительной информации о вашем жестком диске, используя fdisk

На предыдущем этапе, используя /proc , мы получили только основную, но довольно ограниченную информацию о параметрах нашего жесткого диска. Теперь давайте получим более полные данные, используя доступную в Linux команду fdisk . С ее помощью можно получить информацию о разделах жесткого диска, объеме достуного пространства, объеме занятого пространства, свопе и многое еще.

Программа fdisk - это инструмент для работы с таблицей разбиения диска. Физические диски обычно разбиваются на несколько логических дисков, которые называются разделами диска. Информация о разбиении физического диска на разделы хранится в таблице разбиения диска, которая находится в нулевом секторе физического диска.

Чтобы посмотреть, какие разделы имеются на вашем диске, просто введите команду:

# fdisk -l
Disk /dev/hda: 40.0 GB, 40016019456 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 4865 38973690 8e Linux LVM

Если у вас два или более дисков (например, hda и hdb), и вы хотите получить данные о конкретном диске, укажите в команде желаемый диск, например, fdisk -l /dev/hda

Часть 5 (ДОБАВЛЕНА по откликам читателей) : Вывод информации BIOS с помощью команды dmidecode

Утилита dmidecode выводит содержимое таблицы DMI (Desktop Management Interface) вашей системы в формате, предназначенном для восприятия человеком. Эта таблица содержит информацию, относящуюся к компонентам аппаратного обеспечения системы, а также сведения о версии BIOS и т.д. В выводе dmidecode не только содержится описание текущей конфигурации системы, но и приводятся данные о максимально допустимых значениях параметров, например, о поддерживаемых частотах работы CPU, максимально возможном объеме памяти и так далее.

Если я хочу ограничить выводимую информацию только какими определенными областями DMI, я могу сделать это, используя опцию ─ t и указав какого типа информация меня нтересует. Например, информация о процессоре имеет тип 4, а информация о памяти имеет в DMI тип 17.

Я надеюсь, что настоящее руководство поможет вам так же, как оно помогло одному моему другу, который устанавливал MythTV в систему на основе Fedora и до знакомства с этим руководством держал свой компьютер открытым, чтобы иметь возможность определять параметры некоторых устройств:)

Из откликов читателей

Finding hardware details without using screwdriver

Спасибо за отличную и очень информативную статью. Теперь я могу, наконец, закрыть крышку корпуса на своем компьютере:-)
TonyH

Попробуй DMIDECODE

С помощью dmidecode вы можете получить гораздо больше информации, причем в одном отчете.
Без подписи

В действительности возможно узнать гораздо больше о том, какой тип памяти используется в вашем компьтере, например, no. pins и скорость и тип...
Скажем, если я сижу на работе и могу удаленно залогироваться на свой домашний компьютер смогу ли я собрать достаточно данных для того, чтобы определить возможность апгрейда моей оперативной память...?
Я пытлся однажды это сделать и не смог - я подобрался довольно близко к решению этой проблемы, у меня осталось на выбор всего два варианта для типа чипсета материнской платы, я наугад выбрал один из них и... не угадал:-(!!
Без подписи

Попробуй что-нибудь еще!

lshw - отличное средство для этого.
Для него также есть GTK-интерфейс.
Без подписи

Другие хорошие утилиты

Попробуй еще dmidecode . В системах на основе RedHat/Fedora она обычно находится в каталоге /usr/sbin , а также доступна через портежи или в исходных кодах (www.nongnu.org/dmidecode/). Она многое расскажет тебе о твоей системе.

Для получения информации о дисках можно использовать smartd и smartctl .

Christopher Arnold (arnoldch AT yahoo-inc DOT com)

lsusb и файловая система /sys

Не забудь просмотреть файловую систему /sys . Кое в чем информация может быть избыточной... но не все.

Для обнаружения USB-устройств есть lsusb .

sensors раскроет детали относительно чипа вашего ОЗУ.

dmesg : иногда информация оказывается перезаписана более новыми сообщениями ядра. Если так, смотри /var/log/boot.log .

В SUSE системах: вы имеете инструмент с названием "yast2" для выполнения обычных администраторских задач. Он выдает и сведения об аппаратном обеспечении.

Без подписи

А как насчет dmidecode?

Взято из man-страницы по dmidecode .

dmidecode - это инструмент для вывода содержимого DMI-таблицы (иногда говорят SMBIOS-таблицы) вашего компьютера в формате, приспособленном для восприятия человеком. Эта таблица содержит описание компонент аппаратного обесечения системы, а также другоую полезную информацию, например, серийные номера и версию BIOS.

dmidecode

Выдает информацию bios на работающей ОС.
Работает не на всех аппаратных платформах.

Без подписи

Еще

смотри lshw и dmidecode

Без подписи

Еще одна...

Не забудь про lsusb ! Очень полезная утилита. Просто установи пакет usbutils из своего дистрибутива (есть по крайней мере в Ubuntu и Fedora, вероятно в других тоже).

Без подписи

hdparm

Для получения детальной информации о жестких дисках можно использовать hdparm .

Без подписи

А что же HAL?

Надо бы упомянуть еще, что если используется современная графическая оболочка (a modern desktop environment), команда lshal выдаст массу информации из HAL (the Hardware Abstraction Layer, иначе говоря, проект Utopia).

Без подписи

lshw

Вы можете еще воспользоваться утилитой lshw , которая позволяет вывести информацию от всех этих источников в виде единого списка (можно на дисплей).

Диагностика оборудования — достаточно важный вопрос, который никак нельзя упускать. Именно поэтому в серию «Шпаргалка сисадмина» для ОС Debian я не могу не добавить статью о средствах получения информации об устройствах. На этот раз я постараюсь коротко рассказать об основных утилитах для диагностики тех или иных компонентов сервера. Начну конечно же со встроенных по умолчанию в систему средств, поскольку знать их и уметь пользоваться должен любой сисадмин. Далее будет обзор пакетов с общим назначением. В конечно счете подойдем к знакомству с дополнительными расширенными инструментами, которые каждый может поставить по желанию.

Узнать информацию о процессоре можно с помощью команды:
root@debian7:~# cat /proc/cpuinfo

Или некоторые другие данные:
root@debian7:~# lscpu

Оперативная память

Краткая информация об использовании памяти:
root@debian7:~# free -m

Утилита также выводит информацию об использовании свопа. Вместо ключа -m, может быть даже лучше использовать -h — получите данные с обозначениями объема.

Расширенная информация:
root@debian7:~# cat /proc/meminfo

Жесткие диски

Отобразить список существующих разделов:
root@debian7:~# fdisk -l

Стоит отметить, что основное назначение утилиты fdisk — управление разделами дисков.

Вывести UUID и тип файловой системы для каждого раздела можно с помощью команды:
root@debian7:~# blkid

Информацию о разделах, точках монтирования и некоторые другие данные можно получить с помощью утилиты lsblk
root@debian7:~# lsblk

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

Сеть

Информация об интерфейсах:
root@debian7:~# ifconfig

Подробная информация о сетевой карте
root@debian7:~# mii-tool -v

Для проверки доступности узлов используйте общеизвестную утилиту ping.

Утилиты общего назначения

top

Утилита top служит для отображения информации о процессах и ресурсах, которые они потребляют. Информация обновляется с определенной периодичностью. Данные можно отсортировать, например, по использованию процессорной мощности или оперативной памяти (по умолчанию идет сортировка по CPU).
root@debian7:~# top

dmidecode

Получить подробную информацию об аппаратном обеспечении можно с помощью dmidecode. Утилита предоставляет данных, полученные от BIOS. В описании пакета приводится следующая справка:

Эта информация обычно включает в себя производителя системы, название модели, серийный номер, версию BIOS, дескриптор ресурса (asset tag) а также другую информацию различного уровня интереса и достоверности, устанавливаемую производителем. Часто содержит состояние занятых процессорных сокетов, слотов расширения (например, AGP, PCI, ISA), слотов памяти и список портов ввода/вывода (например, последовательные и параллельные порты, USB).

Помните, что данные, выдаваемые DMI, не настолько надёжные, чтобы им слепо доверять. Dmidecode не сканирует аппаратное обеспечение, он просто выводит те данные, которые ему предоставляет BIOS.

root@debian7:~# dmidecode

Вывод команды без аргументов слишком объемный, лучше использовать ключ —type и получать только необходимые разделы, например:
root@debian7:~# dmidecode —type 5,6

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

dmesg

Команда используется для вывода буфера сообщений ядра. С точки зрения аппаратного обеспечения, вывод может быть полезен для анализа проблем с оборудованием, да и вообще для полного представления имеющегося «железа». Вывод команды слишком объемный и для его анализа могут понадобиться другие инструменты, например, можно воспользоваться выводом в файл, можно перенаправить вывод команде less, а можно с помощью grep найти необходимые вам аппаратные компоненты.
root@debian7:~# dmesg | grep processor

Команда выведет только строки, содержащие слово processor.

lspci

Утилитой удобно пользоваться для вывода списка всех устройств, подключенных к pci-шине. Информация может быть использована в диагностических целях, а также для определения установленных устройств.
root@debian7:~# lspci

Используйте ключ -t для отображения информации в древовидном представлении, в котором будут отображены все шины и устройства, подключенные к ним. Ключи -v, -vv, -vvv отображают дополнительную информацию по каждому устройству; чем больше «v», тем более подробно выводятся данные.

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

vmstat

Показывает сводную информацию о состоянии виртуальной памяти, а также о свопе.
root@debian7:~# vmstat 2

Команда выше будет выводить обновленные данные каждые 2 секунды (вместо 2 можете указать любое другое число).

sysctl

Хоть и утилита предназначена главным образом для управления параметрами ядра на лету, анализ установленных значений может помочь в диагностике проблем.
root@debian7:~# sysctl -a

Команда отобразит все переменные и их значения.

Дополнительные утилиты

Все описанные ниже утилиты не входят в стандартную конфигурацию Debian, придется из ставить отдельно.

htop

Более сильная замена штатной утилиты top. В стандартной конфигурации с системой не поставляется. Предоставляет удобный интерактивный интерфейс со встроенной справкой и обновлением данных в реальном времени.
root@debian7:~# htop -d 10

Ключ -d выставляет значение в десятых долях секунды для обновления данных. Ключ -c переключает программу в монохромный режим работы.

lshw

Утилита предназначена для вывода подробной информации об аппаратном обеспечении. Наиболее удобно экспортировать данные в.html-вид и просматривать в браузере. Такой способ, конечно же, исключается при работе в консольном режиме, разве что если просматривать данные на другой системе.
root@debian7:~# lshw -C network

Команда выведет данные только о сетевой плате.

smartmontools

Пакет состоит из двух утилит (smartctl и smartd), которые следят за S.M.A.R.T-показателями жестких дисков. Для запуска демона необходимо произвести ряд настроек:

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

enable_smart=»/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde»
start_smartd=yes
smartd_opts=»—interval=1800″

Однако при запуске службы на виртуальной машине с Debian 7.7 у меня выдал ошибку (надо сказать, что отслеживание S.M.A.R.T на виртуальных жестких дисках достаточно бредовая идея, я это сделал лишь с целью протестировать):

Просмотреть состояние диска можно командой:
root@debian7:~# smartctl -a /dev/sda

Несмотря на это, утилита является достаточно распространенной и однозначно рекомендуется к использованию. Кроме того, в сети есть масса инструкций по настройке e-mail-уведомлений в случае проблем с жесткими дисками.

hdparm

Главное предназначение программы — тонкая настройка параметров IDE/SATA жестких дисков, тюнинг производительности. Помимо этого также можно просматривать характеристики устройств командой (укажите свой диск):
root@debian7:~# hdparm -i /dev/sda

Вопросы настройки дисков в рамках этой статьи рассматривать не планируется.

ethtool

Произвести диагностику сетевой платы вам поможет утилита ethtool. Конечно вытянуть информацию можно и с помощью ifconfig, и dmesg и др., но несравнимо больше полезных данных вы получите именно от ethtool. Надо отметить, что с виртуальными сетевыми интерфейсами программа работает достаточно криво. Например отображение статистики по интерфейсу у меня вообще было пустое:
root@debian7:~# ethtool -S eth0
no stats available

Общая информация об интерфейсе была примерно настолько же скудной:
root@debian7:~# ethtool eth0
Settings for eth0:
Link detected: yes

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

sysstat

Пакет содержит в себе ряд утилит, способных выдавать информацию о производительности тех или иных компонентов системы. Особо полезным может быть iostat, когда нужно проанализировать загрузку жестких дисков в срезе операций ввода/вывода.

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



Есть вопросы?

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: