Как узнать UUID’ы разделов? Команды blkid и vol_id

Статья из серии «HuMan»

Предисловие

Удобство понимания и заполнения таких конфигурационных файлов как, скажем, /etc/fstab «значительно повысилось». Стало невозможным понять о каком разделе идет речь. Хорошо если у вас всего пять-шесть разделов, еще можно помнить, на каком своп, а на каком корень. А если разделов в три раза больше? Да если еще и постоянно удаляешь одни, и создаешь другие? Мода требует жертв.

Кому же нужны UUID’ы и для кого они действительно удобны? Сисадминам больших серверов, у которых одновременно присутствуют носители всевозможных типов, да еще и объединенные во всякие RAID’ы и прочие сиадминские заморочки. Для них, когда возникает необходимость перенести содержимое с одного носителя на другой, потом встает большая проблема правильно внести изменения в ту же /etc/fstab вручную. С UUID’ами же ядро, при помощи специальных программ, автоматически находит и размечает разделы по соответствующим носителям. Это им экономит много сил и времени.

Простым же смертным, имеющим два компьютера с тремя винчестерами на обоих, эти UUID’ы нужны как зайцу стоп-сигнал. Я лично первым делом безжалостно удаляю все эти номера из файлов /etc/fstab и /boot/grub/menu.lst. Это позволяет мне избежать головной боли при клонировании разделов, когда возникают два раздела с одинаковыми «Уникальными номерами».

Но многим почему-то нравятся UUID’ы, и они озабочены, если какой-нибудь раздел, например подкачки, вдруг прописан по «имени-отчеству». В Сети иногда встречаются такие вопли о помощи: «Мой раздел своппига не имеет UUID’а. Как мне узнать его и вписать в /etc/fstab?». Для вас, любители UUID’ов, эта статья.

Команда blkid

Однако программа blkid по умолчанию не считывает информацию о разделах непосредственно из соответствующих нод устройств, а считывает ее из файла /etc/blkid.tab. Этот файл зачем-то называется в мане команды blkid кэш файлом, а всем известно, что слово cache имеет множесто значений, а потому совершенно бессмысленно. Должен вас сразу предупредить, что в файле /etc/blkid.tab со временем накапливается устаревшая информация о давно несуществующих разделах, поэтому не думайте читать сам файл в поисках UUID’ов, можете жестоко обмишулиться. Пользуйтесь командой blkid с соответсвующими опциями.

Команда blkid без опций

Я предупреждал. Тут, конечно, можно разобраться при желании, но непонятно, откуда может взяться такое желание, когда можно поступить проще. А именно запустить команду blkid с опцией -c.

Команда blkid с опцией -c

Совсем другое дело, не правда ли?

Поэтому советую сохранить старые файлы blkid.tab и blkid.tab.old под другими именами, тогда при следующей загрузке будет создан новенький чистенький файлик blkid.tab, где все будет как в выводе команды blkid -c /dev/null . Стоит после этого проверить /etc/fstab и /boot/grub/menu.lst.

Остальные опции команды крайне невыразительны и бесполезны. Чем трудиться запоминать их, проще запустить команду вовсе без опций или с опцией -c /dev/null. Тем не менее:

Опция

Выдает сведения об указанном устройстве.

Опция -t

Найдет все устройства, отвечающие заданному критерию, будь то TYPE, LABEL, или UUID. Можно сужать круг поиска, вводя в командную строку имена интересующих устройств:

Опция -s

Выдаст только указанный критерий нужного устройства.

Опция -o

Опция -l

Опция -g

Опция -w

По моему, проще переадресовать в файл «file» вывод команды.

Опция -h

Опция -v

Вот все, что касается команды blkid. Однако существуют и другие возможности узнать UUID раздела.

Самая очевидная — заглянуть в директорию /dev:

Там четыре субдиректории, одна из которых by-uuid. Посмотрим:

Вот поди, догадайся, что к чему относится! Нет, это не метод.

Команда vol_id

Хорошая и удобная команда, жаль, что не во всех дистрибутивах встречается.

Заключение

Если говорить о разделах жесткого диска, то UUID’ы присваиваются им в процессе создания файловой системы (некоторые утверждают, что они вычисляются из характеристик раздела), и записываются где-нибудь в суперблоках. Во всяком случае, еще не отформатированный раздел не имеет UUID’а. А при клонировании раздела командой dd, раздел, в который устанавливают клон, меняет свой UUID на идентификатор клона.

При загрузке компьютера, программа udev записывает UUID раздела в его ноду — файл блочного устройства в директории /dev. В доступной пользователю части файловой системы, UUID’ы разделов можно найти в файле /etc/blkid.tab, но информация эта может оказаться устаревшей.

Нравится мне это или нет, но UUID’ы прочно вошли в повседневный быт линуксоида. И нет в них никакой мистики.

Установка Windows 7 — Часть 18: Определение UUID компьютера

Посетителей: 6018 | Просмотров: 7761 (сегодня 0) Шрифт:

В части 16 этого цикла вы научились использовать базу данных MDT для настройки установки Windows 7 на основании UUID каждого целевого компьютера. В той же статье вы узнали, как использовать WMI для определения UUID в случае, если этот UUID не отображается в системном BIOS’е или в сопутствующей документации. Однако тот метод, который мы использовали, был несколько неряшлив, плюс на том компьютере, UUID которого вы собираетесь определять, уже должна быть установлена операционная система Windows.

Возникает вопрос: а можно ли использовать WMI для определения UUID компьютера, если на нем еще не установлена никакая операционная система? Ответ — да. Для этого нам сначала нужно удалить все те сценарии, которые мы насоздавали в двух предыдущих статьях. Затем нам нужно сделать образ Windows Preinstallation Environment (WinPE), добавить в этот образ сценарии и прожечь образ на CD. Потом этот CD можно использовать для загрузки чистого компьютера в WinPE и запуска сценария для определения UUID системы.

Именно этому посвящены эта и следующая статьи. Сначала, в данной статье, мы создадим небольшой сценарий, который просто отобразит UUID компьютера. А в следующей статье мы научимся создавать «инструменты»WinPE на CD, которые вы можете использовать для запуска сценария на пустой системе, на которой не установлена никакая операционная система, чтобы определить UUID системы. После использования WinPE-CD для запуска сценария на некотором количестве целевых компьютеров, вы можете внести эти UUID в базу данных MDT и установить образы Windows на каждый компьютер, что и требовалось.

Подсказка: Если вы новичок в написании сценариев для WMI, посмотрите мой 14-частный вводный цикл статей на WindowsNetworking.com под названием Управление сетями Windows с помощью сценариев.

Сценарий для определения UUID компьютера

В 16-й части нашего цикла мы видели, как можно определить UUID компьютера с помощью WMI:

1. Мы начали со сценария DisplayClassProperties.vbs из 13-й части моего предыдущего цикла статей о сценариях, который отображает названия всех параметров класса WMI вместе со значениями этих параметров.
2. Затем мы запустили WBEMTEST на компьютере, чтобы определить, что нам нужно внести в строку strWMIQuery = нашего сценария, чтобы он мог работать на определенном компьютере. Вот необходимые для этого шаги: (a) запустить WBEMTEST (b) подключиться к пространству имен root\cimv2 (c) щелкнуть Enum Instances (d) ввести Win32_ComputerSystemProduct (e) нажать OK. Затем результат WBEMTEST используется в качестве значения в вышеприведенной строке нашего сценария. Причем все это нужно делать вручную, так как копирование результата WBEMTEST в буфер обмена не поддерживается!
3. После настройки сценария мы запускали его на компьютере, и в числе прочего в результате выводили UUID компьютера.

Все это выглядело, конечно, немного неряшливо: не слишком хорошо запускать WBEMTEST на компьютере или подстраивать сценарий каждый раз, когда его нужно запустить. И, кроме того, предпочтительнее было бы выводить только UUID компьютера, без кучи прочих вещей впридачу.

Вот как это сделать. Начнем с модифицированного сценария DisplayClassProperties.vbs, взятого из части 16 цикла статей:

Теперь для завершения того, что делает WBEMTEST, и возврата экземпляров класса Win32_ComputerSystemProduct, нам понадобится воспользоваться методом SWbemServices.InstancesOf объекта SWbemServices. Чтобы разобраться, как это нужно делать, я просто адаптировал следующий сценарий со страницы старого доброго Windows 2000 Scripting Guide (см. здесь):

Моя собственная версия вышеприведенного сценария выглядит так:

Зачем мне понадобилось, чтобы этот сценарий определял значения трех параметров — IdentifyingNumber, Name и Version? Потому что у класса Win32_ComputerSystemProduct есть три ключевых параметра, а именно (вы правильно угадали): IdentifyingNumber, Name и Version. Чтобы увидеть все это собственными глазами, обратитесь к документации по этому классу в MSDN. Помните, что ключевым параметром является параметр, обеспечивающий уникальный идентификатор экземпляра класса, а чтобы подключиться к экземпляру класса, вам нужно будет указать на конкретный экземпляр с помощью ключевого параметра класса. Ключевые параметры отмечены квалификатором «Key» в документации в MSDN; обратитесь к 13-й части моего предыдущего цикла статей о сценариях за более подробной информацией, касающейся ключевых параметров.

Теперь мне нужно соединить настроенный выше сценарий с другим моим сценарием — DisplayClassProperties.vbs — чтобы создать следующий новый сценарий, который я назвал UUID.vbs (обратите внимание на то, что я упростил этот сценарий, опустив определения переменных и обработку ошибок):

Смотрите: самое сложное здесь – убедиться в правильности строк в предложении strWMIQuery = . К примеру, предложение заканчивается на & chr(39), то есть одинарную кавычку, необходимую для правильного синтаксиса завершения предложения. Понадобилось немного потанцевать вокруг этого места, чтобы заставить его работать; тут мне помог такой трюк: временно вставить предложение Wscript.echo strWmiQuery сразу после предложения strWMIQuery = , чтобы я мог запустить сценарий и вывести содержимое строки, чтобы увидеть, правильный ли синтаксис у строки, после чего внес изменение и запускал сценарий снова, пока не получил правильный синтаксис.

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

Давайте теперь посмотрим, работает ли наш сценарий, если запустить его из командной строки на компьютере, на котором установлена Windows XP (Рисунок 1):

Рисунок 1: Запуск UUID.vbs на компьютере с операционной системой

Давайте еще упростим запуск нашего сценария, создав дополнительный batch-файл под названием UUID.bat, который выглядит следующим образом:

Запуск сценария становится еще проще, а выходные данные — чище (Рисунок 2):

Рисунок 2: Запуск UUID.bat на компьютере с операционной системой

Заключение

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

Установка Windows 7 — Часть 18: Определение UUID компьютера

Посетителей: 6018 | Просмотров: 7761 (сегодня 0) Шрифт:

В части 16 этого цикла вы научились использовать базу данных MDT для настройки установки Windows 7 на основании UUID каждого целевого компьютера. В той же статье вы узнали, как использовать WMI для определения UUID в случае, если этот UUID не отображается в системном BIOS’е или в сопутствующей документации. Однако тот метод, который мы использовали, был несколько неряшлив, плюс на том компьютере, UUID которого вы собираетесь определять, уже должна быть установлена операционная система Windows.

Возникает вопрос: а можно ли использовать WMI для определения UUID компьютера, если на нем еще не установлена никакая операционная система? Ответ — да. Для этого нам сначала нужно удалить все те сценарии, которые мы насоздавали в двух предыдущих статьях. Затем нам нужно сделать образ Windows Preinstallation Environment (WinPE), добавить в этот образ сценарии и прожечь образ на CD. Потом этот CD можно использовать для загрузки чистого компьютера в WinPE и запуска сценария для определения UUID системы.

Именно этому посвящены эта и следующая статьи. Сначала, в данной статье, мы создадим небольшой сценарий, который просто отобразит UUID компьютера. А в следующей статье мы научимся создавать «инструменты»WinPE на CD, которые вы можете использовать для запуска сценария на пустой системе, на которой не установлена никакая операционная система, чтобы определить UUID системы. После использования WinPE-CD для запуска сценария на некотором количестве целевых компьютеров, вы можете внести эти UUID в базу данных MDT и установить образы Windows на каждый компьютер, что и требовалось.

Подсказка: Если вы новичок в написании сценариев для WMI, посмотрите мой 14-частный вводный цикл статей на WindowsNetworking.com под названием Управление сетями Windows с помощью сценариев.

Сценарий для определения UUID компьютера

В 16-й части нашего цикла мы видели, как можно определить UUID компьютера с помощью WMI:

1. Мы начали со сценария DisplayClassProperties.vbs из 13-й части моего предыдущего цикла статей о сценариях, который отображает названия всех параметров класса WMI вместе со значениями этих параметров.
2. Затем мы запустили WBEMTEST на компьютере, чтобы определить, что нам нужно внести в строку strWMIQuery = нашего сценария, чтобы он мог работать на определенном компьютере. Вот необходимые для этого шаги: (a) запустить WBEMTEST (b) подключиться к пространству имен root\cimv2 (c) щелкнуть Enum Instances (d) ввести Win32_ComputerSystemProduct (e) нажать OK. Затем результат WBEMTEST используется в качестве значения в вышеприведенной строке нашего сценария. Причем все это нужно делать вручную, так как копирование результата WBEMTEST в буфер обмена не поддерживается!
3. После настройки сценария мы запускали его на компьютере, и в числе прочего в результате выводили UUID компьютера.

Все это выглядело, конечно, немного неряшливо: не слишком хорошо запускать WBEMTEST на компьютере или подстраивать сценарий каждый раз, когда его нужно запустить. И, кроме того, предпочтительнее было бы выводить только UUID компьютера, без кучи прочих вещей впридачу.

Вот как это сделать. Начнем с модифицированного сценария DisplayClassProperties.vbs, взятого из части 16 цикла статей:

Теперь для завершения того, что делает WBEMTEST, и возврата экземпляров класса Win32_ComputerSystemProduct, нам понадобится воспользоваться методом SWbemServices.InstancesOf объекта SWbemServices. Чтобы разобраться, как это нужно делать, я просто адаптировал следующий сценарий со страницы старого доброго Windows 2000 Scripting Guide (см. здесь):

Моя собственная версия вышеприведенного сценария выглядит так:

Зачем мне понадобилось, чтобы этот сценарий определял значения трех параметров — IdentifyingNumber, Name и Version? Потому что у класса Win32_ComputerSystemProduct есть три ключевых параметра, а именно (вы правильно угадали): IdentifyingNumber, Name и Version. Чтобы увидеть все это собственными глазами, обратитесь к документации по этому классу в MSDN. Помните, что ключевым параметром является параметр, обеспечивающий уникальный идентификатор экземпляра класса, а чтобы подключиться к экземпляру класса, вам нужно будет указать на конкретный экземпляр с помощью ключевого параметра класса. Ключевые параметры отмечены квалификатором «Key» в документации в MSDN; обратитесь к 13-й части моего предыдущего цикла статей о сценариях за более подробной информацией, касающейся ключевых параметров.

Теперь мне нужно соединить настроенный выше сценарий с другим моим сценарием — DisplayClassProperties.vbs — чтобы создать следующий новый сценарий, который я назвал UUID.vbs (обратите внимание на то, что я упростил этот сценарий, опустив определения переменных и обработку ошибок):

Смотрите: самое сложное здесь – убедиться в правильности строк в предложении strWMIQuery = . К примеру, предложение заканчивается на & chr(39), то есть одинарную кавычку, необходимую для правильного синтаксиса завершения предложения. Понадобилось немного потанцевать вокруг этого места, чтобы заставить его работать; тут мне помог такой трюк: временно вставить предложение Wscript.echo strWmiQuery сразу после предложения strWMIQuery = , чтобы я мог запустить сценарий и вывести содержимое строки, чтобы увидеть, правильный ли синтаксис у строки, после чего внес изменение и запускал сценарий снова, пока не получил правильный синтаксис.

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

Давайте теперь посмотрим, работает ли наш сценарий, если запустить его из командной строки на компьютере, на котором установлена Windows XP (Рисунок 1):

Рисунок 1: Запуск UUID.vbs на компьютере с операционной системой

Давайте еще упростим запуск нашего сценария, создав дополнительный batch-файл под названием UUID.bat, который выглядит следующим образом:

Запуск сценария становится еще проще, а выходные данные — чище (Рисунок 2):

Рисунок 2: Запуск UUID.bat на компьютере с операционной системой

Заключение

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