И там я увидел отсылку на древнейшую программу Nikon View, которую снёс очень давно. Задумался о двух вещах – как посмотреть путь к этой программе и где эти Login Items сконфигурированы. Google мне, как обычно, помог, отослав к отличной статье MacWorld “See paths to Login Items“.

В простой методе достаточно навести указатель мыши на программу и в подсказке покажется полный путь (но ввод этого путь непрост – его нужно вбивать вручную):

А более правильный, но слегка “гиковский” метод – это использование defaults. Конечно же, Login Items описаны в логичном для этого месте – в конфигурации loginwindow (это процесс, отвечающий за вход в систему):

$ defaults read loginwindow | grep Path
Path = "/Users/ctrld/Library/PreferencePanes/Hazel.prefPane/Contents/Resources/HazelHelper.app";
Path = "/Users/ctrld/Library/PreferencePanes/RedHand.prefPane/RedHand.app";
Path = "/Applications/Zooom2.app";
Path = "/Applications/Chax.app";
Path = "/Applications/Skype.app";
Path = "/Applications/Things.app";
Path = "/Applications/LaunchBar.app";
Path = "/Applications/Mailplane.app";
Path = "/Applications/Tweetie.app";
Path = "/Applications/Evernote.app/Contents/Resources/EvernoteHelper.app";
Path = "/Applications/Dropbox.app";
Path = "/Applications/SizeUp.app";

Найти, где именно находятся эти Login Items, можно было на примере одного из них (я взял Hazel):

$ defaults find Hazel | grep "in domain "
Found 1 keys in domain 'com.apple.Console.LSSharedFileList': {
Found 1 keys in domain 'com.apple.Console': {
Found 2 keys in domain 'com.apple.help': {
Found 1 keys in domain 'com.apple.loginitems': {
Found 12 keys in domain 'com.noodlesoft.Hazel': {
Found 4 keys in domain 'com.noodlesoft.HazelHelper': {
Found 1 keys in domain 'loginwindow': {

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

$ find ~ -name com.apple.loginitems\*
/Users/ctrld/Library/Preferences/com.apple.loginitems.plist

Как удалить конкретную программу через команду defaults, я не нашёл – по идее нужно сформировать то ли dict, то ли array, и его удалить. Проще либо удалить через настройки Login Items, то ли отредактировать файл ~/Library/Preferences/com.apple.loginitems.plist в любом редакторе.

Один из методов решения проблем, связанных с влиянием разнообразных программ, является загрузка Mac OS X в режиме Safe Mode.

Во время этой загрузки производятся такие операции:

• проверка файловой системы и исправление прав доступа (аналог Repair Permissions в Disk Utility)
• загружается только минимальный набор kernel extensions из /System/Library/Extensions
• отключаются все шрифты, кроме системных из каталога /System/Library/Fonts
• удаляются кеш шрифтов Apple Type Services из каталогов /private/var/folders/*/*/-Caches-/com.apple.FontRegistry. Аналог – команда “atsutil databases -remove”
• отключаются все startup и login items
• удаляются разделяемые кеши динамического загрузчика из /var/db/dyld

Все перечисленные действия дают хороший шанс решить проблемы с программами или файловой системой. Однако следует помнить, что не все функции Mac OS X работают в Safe Mode, например, DVD Player работать не будет. Поэтому после Safe Mode нужно перегрузиться в нормальном режиме.

Также нужно иметь в виду, что загрузка в Safe Mode длится дольше обычной загрузки.

Для загрузки в Safe Mode нужно выключить компьютер, включить его, и, как только прозвучит сигнал запуска (но не раньше), нажать и удерживать клавишу Shift. Отпустить Shift можно сразу же после появления серого значка Apple и индикатора загрузки.

Если нажать Shift невозможно (например, операция загрузки производится удалённо), то можно запустить команду:

$ sudo nvram boot-args="-x"

Но нужно не забыть потом восстановить нормальный режим загрузки:

$ sudo nvram boot-args=""

Просмотр списка дисков, с которых возможна загрузка:

$ sudo systemsetup -liststartupdisks
/Volumes/Mac OS X 10.6 Server/System/Library/CoreServices
/Volumes/Backup 2/System/Library/CoreServices
/System/Library/CoreServices

Установка нового загрузочного диска:

$ sudo systemsetup -setstartupdisk /System/Library/CoreServices
Set Startup Disk to Path: /System/Library/CoreServices

Через GUI сделать эту же операцию можно в System Preferences / Startup Disk:

Во время поиска информации, как склонировать систему в образ для разворачивания на другой рабочей станции или в VMWare, я наткнулся на интересную статью “How to Create a Bootable Backup of Mac OS X (Cloning Mac OS X disks)“, написанную разработчиком бесплатной утилиты “Carbon Copy Cloner“. В PDF-документе “Introduction to Command-Line Administration” Apple рекомендует три командно-строковые утилиты для резервного копирования данных – ditto, rsync и asr. Тема мне показалась интересной, поэтому я решил испытать эти методы.

Перед клонированием очень желательно на исходном диске сделать repair permissions с помощью Disk Utility и удалить все данные на диске, куда будет производиться клонирование. Я переразбил внешний USB-диск, создав по одному разделу для каждого метода клонирования, но в реальной ситуации достаточно создать один раздел (не забывайте, что нужно использовать схему разделов GUID). Раздел, на который производится клонирование, называется Backup.

ditto – copy directory hierarchies, create and extract archives

При копировании ditto сохраняет resource forks, метаданные HFS, расширенные файловые атрибуты и ACL. Ключ “-X” говорит о том, что не нужно копировать другие разделы, смонтированные в указанную файловую систему.

$ sudo ditto -X / /Volumes/Backup

Желающие наблюдать за ходом копирования могут включить опцию “-v” (выводить название копируемого каталога), а самые жадные до деталей – “-V” (сообщать о копировании каждого файла, симлинка и файла устройства).

После клонирования перезагружаемся с нажатой клавишей “Option” и выбираем нужный раздел:

Название самого исходного раздела не скопировалось – вместо “Mac OS X 10.6 Server” раздел называется “EFI Boot”. Операционная система загрузилась, но при старте выдалось сообщение о восстановлении шрифтов:

Ещё одна проблема – при старте, например, Terminal.app, стали выдаваться сообщения “dyld shared cache file was build against a different libSystem.dylib”:

Это обозначает, что необходимо перестроить кеши:

$ sudo update_dyld_shared_cache

Также не помешает сделать “repair permissions”:

$ diskutil repairPermissions /

После этого система работает нормально (глубоко функционирование я не тестировал, но основные сервисы работали).

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

Перед перезагрузкой можно удалить вспомогательные файлы, swap и кеши (afp548), но не все из них есть в Snow Leopard, поэтому нужно этот вопрос ещё проработать (пока привожу “asis”):

sudo rm /Volumes/Backup/var/db/BootCache.playlist
sudo rm /Volumes/Backup/var/db/volinfo.database
sudo rm /Volumes/Backup/System/Library/Extensions.kextcache
sudo rm /Volumes/Backup/System/Library/Extensions.mkext
sudo rm -r /Volumes/Backup/var/vm/swap*

rsync

Отличная альтернатива – rsync. В последнее время я его очень активно использую для резервного копирования. Огромное преимущество метода в том, что rsync позволяет делать обновление только изменённых с прошлого сеанса клонирования данных. Это позволяет делать инкрементальное обновление данных и иметь актуальную копию систему.

$ sudo rsync -xrlptgoEv --progress --delete / /Volumes/Backup

Ключи:

• -x. То же, что и -X у ditto – не копировать другие разделы. Или же не траверсировать на другие устройства. Или don’t cross filesystem boundaries. Что кому понятнее.
• -r. Рекурсивно копировать каталоги.
• -l. Копировать симлинки как симлинки, а не как файлы и каталоги.
• -p. Сохранять права.
• -t. Сохранять время (создания, модификации, etc).
• -g. Сохранять группы, файлы устройств и специальные файлы.
• -o. Сохранять владельца.
• -E. Копировать расширенные атрибуты и resource forks.
• -v. Сообщать о процессе работы (файлы, каталоги, etc).
• –progress. Сообщать о процессе копирования. -v можно отключить, но мне интересно наблюдать за процессом.
• –delete. Удалять файлы, отсутствующие в исходном каталоге, из каталога, в который производится копирование.

После завершения клонирования перегружаемся. Точно та же картина – раздел называется “EFI Boot”, фонты восстановлены и есть проблема с кешами. Выполняем команды обновление кеша и repair permissions.

asr – Apple Software Restore; copy volumes (e.g. from disk images)

Самый беспроблемный метод при использовании CLI – это ASR. При клонировании правильно был назван склонированный раздел, восстановления фонтов не было, кеши пересоздавать не пришлось. Ключи вполне понятны и без объяснения.

$ sudo asr -source / -target /Volumes/Backup -erase -noprompt

Можно также посмотреть статью на сайте afp548.com.

Carbon Copy Cloner

Это бесплатная утилита (принимаются пожертвования). Все функции можно посмотреть на сайте разработчика. Очень полезные возможности – инкрементальное клонирование (как в описанном выше rsync) и работа по расписанию.

Никогда с этой утилитой не работал. Мне выдалось сообщение “Backup is unsuitable given the source volume and options chosen”, так как раздел, на который я хотел клонировать свой диск, был слишком мал и протестировать я не смог.

Под Snow Leopard нужно ставить последнюю версию (3.3 и выше).

SuperDuper!

Коммерческая программа ($27.95), активно обновляется, поддержка Snow Leopard появилась сразу же в районе 28 августа. Я ею активно пользуюсь для клонирования дисков со своими проектами. На загрузочных дисках не испытывал, но должна работать без проблем.

Другие методы

Можно клонировать диски через Disk Utility (я всегда так и делаю при апгрейде диска), но очень желательно это делать не на живой системе, а загрузиться с установочного DVD. Также я не рассматриваю dd – для клонирования живой системы я бы не рискнул их применять, нужно грузиться с DVD или в Single User Mode. И dump не подходит – “This copy of dump is supplied only for completeness and is expected to have deficiencies. It will likely disappear in the future”.

Выводы

Все методы, описанные в обзоре, хороши. Я остановился на использовании asr для полного копирования, rsync для инкрементного из shell, и на SuperDuper! из GUI.

Как я писал ранее, схема разделов Apple Partition Map не приспособлена к использованию на больших дисках – из-за 32-битных счётчиков максимальный размер диска при размере блока 512 байт может быть лишь 2 TB.

Apple серьёзно прорабатывала возможность адаптации Apple Partition Map для поддержки больших дисков, однако требуемые изменения привели бы к неработоспособности всех инструментов, работающих с разделами, поэтому было принято разумное решение переключиться на принципиально новую схему. После серьёзных размышлений Apple решила использовать GPT.

Схема разделов GUID partition table (GPT) была представлена Intel как часть реализации комплексной задачи по переходу на современное firmware для Intel-совместимых компьютеров. Традиционно на них было установлено firmware BIOS, использующее схему разделов Master Boot Record (MBR). Схема MBR имела большое количество ограничений, не позволяющих использовать её на современных компьютерах. Для преодоления этих ограничений компания Intel разработала современное firmware Extensible Firmware Interface (EFI), включающее в себя новую схему разделов GPT.

Одним из больших преимуществ схемы GPT было то, что она была закреплена в формальных стандартах (документы доступны для списывания):

• Extensible Firmware Interface Specification 1.10, раздел 11.2.2, страница 367.
• UEFI Specification Version 2.3, раздел 5 “GUID Partition Table (GPT) Format”, страница 91.

В статье я использую такие источники:

• “Technical Note TN2166. Secrets of the GPT.“
• Книга “Mac OS X Internals. A Systems Approach”.
• Apple’s Transition from Apple Partition Map to the GUID Partition Tabl
• Стандарт “Extensible Firmware Interface Specification 1.10“
• Стандарт “UEFI Specification Version 2.3“

Вопрос о GPT не помещается в одну статью, поэтому я разобью его на три части:

1. Protective MBR
2. Partition Table Header
3. Partition Entry Array

Обзор GPT

GPT простая, но эффективная схема разделов. Общая схема использования блоков показана в таблице (n – количество блоков на диске, b – количество блоков, использующихся для описания массива с записями о разделах, обычно 32):

Меня лично восхитил блок 0 “Protective MBR” – это отличная “защита от дурака”. В нём в формате MBR вся область, используемая под схему разделов GPT и разделы GPT определены, как один раздел. Таким образом программы работы с разделами, ничего не знающие о GPT, не смогут случайно ничего изменить (конечно же, от намеренного изменения никто защитить не сможет). Такие программы видят диск GPT, как диск MBR с одним разделом неизвестного типа (0xEE).

GPT использует логическую адресацию блоков на диске Logical Block Addressing (LBA) в отличие от старой адресации Cylinder-Head-Sector (CHS). Размер блока обычно 512 байт, но он может быть и другим. Штатных утилит для просмотра размера блока я не нашёл, поэтому использую программу из книги “Mac OS X Internals” – для моего диска он действительно 512 байт.

В графическом виде GPT выглядит так (128 разделов – столько зарезервировано в Windows 2003 Server, насчёт Mac OS X посмотрим дальше):

Для экспериментов будем использовать USB-диск со схемой разделов GPT и двумя разделами:

LBA 0. Protective MBR

Формат MBR описан в таблице (из Unified Extensible Firmware Interface Specification):

PartitionRecord описан в следующей таблице. В описании указан общий формат, а после пометки GPT то, что должно быть для Protective MBR.

Первый (нулевой) блок содержит такие данные:

$ sudo dd if=/dev/disk4 of=/dev/stdout bs=512 count=1 skip=0 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 fe  |................|
000001c0  ff ff ee fe ff ff 01 00  00 00 af ea 42 25 00 00  |............B%..|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

MBR:
• 0000 440 bytes. BootCode. Все нули.
• 01B8 4 bytes. UniqueMBRSignature. 00 00 00 00.
• 01BC 2 bytes. Unknown. 00 00.
• 01BE 64 bytes. PartitionRecord (4 x 16-ти байтовых записей в формате IBM Partition Table). 00 fe ff ff ee fe ff ff 01 00 00 00 af ea 42 25
• 01FE 2 bytes. MBR signature (0xAA55). 55 AA – в обратной нотации (так уж повелось).
• Если размер блока больше 512 байт, то остальное – Reserved. Для нашего случая блок – 512

Рассмотрим информацию о разделе (00 fe ff ff ee fe ff ff 01 00 00 00 af ea 42 25)
• 0×00 1 byte. BootIndicator (0×80 = bootable/active, 0×00 = non-bootable, other = invalid). 00 – non-bootable.
• 0×01 3 bytes. StartingCHS. fe ff ff. Это древняя жуть, не будем искать разгадку – кто знает, куда нас заведёт это знание? Хорошо, что в EFI это не используется.
• 0×04 1 byte. OSType. Есть хороший ресурс со всеми типами разделов. 0xEE = Indication that this legacy MBR is followed by an EFI header.
• 0×05 3 bytes. EndingCHS. fe ff ff. Аналогично.
• 0×08 4 bytes. StartingLBA. 01 00 00 00 в обратной нотации читается как 00 00 00 01. Вспоминаем таблицу – “Must be 0×00000001″.
• 0x0C 4 bytes. SizeInLBA in little-endian format. af ea 42 25 = 0x2542eaaf = 625142447 блоков

Для проверки количества блоков посмотрим информацию по диску:

$ diskutil info disk4 | grep "Total Size"
   Total Size:               320.1 GB (320072933376 Bytes) (exactly 625142448 512-Byte-Blocks)

Количество блоков в разделе 625142447, один блок – MBR, что даёт требуемое количество блоков на диске 625142448. В итоге программы, знающие только об MBR будут действительно видеть диск MBR с одним разделом типа 0xEE.

To be continued…

В следующей части разберём “Partition Table Header”.

В предыдущей статье я привёл описание раскладки разделов “Universal HD” для Apple Partition Map. Спасибо @akaDimiG – он натолнул меня на мысль посмотреть на таблицу разделов на установочном диске Mac OS X. Здесь используется раскладка APM “Universal CD”.

Mac OS X 10.5 Install DVD

$ pdisk /dev/rdisk3 -dump

Partition map (with 2048 byte blocks) on '/dev/rdisk3'
 #:                type name       length   base    ( size )
 1: Apple_partition_map Apple          15 @ 1
 2:  Apple_Driver_ATAPI Macintosh  302596 @ 16      (591.0M)
 3:           Apple_HFS Mac_OS_X  3756752 @ 302612  (  7.2G)
 4:          Apple_Free                 4 @ 4059364

Device block size=2048, Number of Blocks=4059368 (7.7G)
DeviceType=0x0, DeviceId=0x0

Mac OS X 10.4 Install DVD

$ pdisk /dev/rdisk3 -dump

Partition map (with 512 byte blocks) on '/dev/rdisk3'
 #:                type name        length   base     ( size )
 1: Apple_partition_map Apple           63 @ 1
 2:  Apple_Driver_ATAPI*Macintosh        8 @ 64
 3:           Apple_HFS Mac_OS_X  11059160 @ 72       (  5.3G)
 4:          Apple_Free                 10 @ 11059232

Device block size=512, Number of Blocks=11059242 (5.3G)
DeviceType=0x0, DeviceId=0x0
Drivers-
1:   4 @ 64, type=0x701

Обратите внимание на раздел 2 (Apple_Driver_ATAPI) – здесь располагаются драйвера под Mac OS 9 для ATAPI CD.

Тот, кто купил Мак по крайней мере в районе 2006 года, при переходе на Snow Leopard мог столкнуться с неприятным сюрпризом – Snow Leopard устанавливается только на диски со схемой разделов GUID partition table (GPT), а диск изначально был размечен под Apple Partition Map. Для меня процесс “перетасовки” жёстких дисков привычен, но даже мне пришлось попотеть, занимаясь созданием на внешнем диске GPT, а затем с помощью SuperDuper! дважды переливать содержимое диска 320 GB. Процесс обновления до Snow Leopard в итоге у меня удлинился ровно на 20 часов.

В этой статье я хочу остановиться на схеме разделов “Apple Partition Map”, а в следующей рассмотреть GUID partition table (GPT). В процессе изучения я использовал такие материалы:

• “Technical Note TN2166. Secrets of the GPT“;
• “Apple’s Transition from Apple Partition Map to the GUID Partition Table“;
• Книга “Mac OS X Internals. A Systems Approach“.

Воспользуюсь случаем и порекомендую библиотеку O’Reilly Safari Books Online, подписавшись на которую, вы сможете получить доступ к огромному количеству технической литературы. Книгу “Mac OS X Internals” я списал в формате PDF, так как у меня накопилось достаточное количество Download Tokens.

Apple Partition Map

Схема разделов Apple Partition Map (APM) была представлена на Macintosh II в 1987 году. Её дизайн был хорош, и она продержалась с небольшими изменениями на протяжении двадцати лет. Но за последние годы начали проявляться её ограничения. Различные переменные, адресующие блоки, описаны как 32-битные unsigned long, в итоге со стандартным размером блока 512 байт максимальный размер диска может быть 2 TB. Диски размером 2 TB уже доступны даже в сегменте desktop-компьютеров – например, Barracuda XT Desktop Hard Drive (SATA), и 32-битное ограничение уже достигнуто. Поэтому Apple заранее внедрил новую систему GUID partition table (GPT), о ней поговорим в следующей статье.

В отличие от DOS APM не содержит загрузочного кода (вспомним MBR в первом секторе диска под DOS). Загрузчики Open Firmware и EFI сами содержат код для загрузки с дисков APM. Также, в отличие от DOS, APM может описывать столько разделов, сколько требуется (в DOS же есть 4 Primary partition, один из которых может быть описан как Extended partition, а у же в нём можно создавать достаточно большое количество разделов – я встречал упоминание о 670 логических разделах).

Работать с таблицей разделов Apple Partition Map можно с помощью утилиты pdisk (Apple partition table editor).

Посмотрим главу 11 книги “Mac OS X Internals”. Вот пример типичной раскладки “UNIVERSAL HD” с поддержкой Mac OS 9:

$ sudo pdisk /dev/rdisk0 -dump
Partition map (with 512 byte blocks) on '/dev/rdisk0'
 #:                type name                   length   base     ( size )
 1: Apple_partition_map Apple                      63 @ 1
 2:      Apple_Driver43*Macintosh                  56 @ 64
 3:      Apple_Driver43*Macintosh                  56 @ 120
 4:    Apple_Driver_ATA*Macintosh                  56 @ 176
 5:    Apple_Driver_ATA*Macintosh                  56 @ 232
 6:      Apple_FWDriver Macintosh                 512 @ 288
 7:  Apple_Driver_IOKit Macintosh                 512 @ 800
 8:       Apple_Patches Patch Partition           512 @ 1312
 9:          Apple_Free                        262144 @ 1824     (128.0M)
10:           Apple_HFS Apple_HFS_Untitled_1 24901840 @ 263968   ( 11.9G)
11:          Apple_Free                            16 @ 25165808

Device block size=512, Number of Blocks=25165824 (12.0G)

• Раздел 1, Apple_partition_map. Метаданные, относящиеся к таблице разделов. Размер 63 блока, каждый блок – 512 байт.
• Разделы 2-7. Разделы с дисковыми драйверами под Mac OS 9. Традиционно драйвера блочных устройств (например, дисков) могли загружаться из ROM, с устройств USB и Firewire, или со специального раздела на жёстком диске. Для поддержки нескольких операционных систем или же различных видов подключения, диск мог содержать несколько драйверов, установленных каждый на своём разделе. Например, раздел Apple_Driver43 содержит драйвер для SCSI Manager 4.3, а Apple_FWDriver – для подключения по Firewire. Mac OS X не использует эти драйвера.
• Раздел 8, Apple_Patches. Раздел, содержащий патчи, устанавливаемые на систему перед её загрузкой.
• Разделы 9 и 11, Apple_Free. Свободное место. Основная цель – “выравнять” раздел с данными, чтобы он начинался с определённого блока.
• Раздел 10. Здесь может уже располагаться файловая система с данными, например, HFS.

Кроме раскладки “UNIVERSAL HD” был также и “UNIVERSAL СD”, содержащий драйвера для ATAPI и SCSI Manager для дисковода CD.

Когда о Mac OS 9 все забыли, и необходимость в её поддержке отпала, то таблица APM стала выглядеть не так внушительно (я создал таблицу разделов на внешнем диске из-под Mac OS X 10.6):

$ pdisk /dev/rdisk2 -dump
Partition map (with 512 byte blocks) on '/dev/rdisk2'
 #:                type name      length   base      ( size )
 1: Apple_partition_map Apple         63 @ 1
 2:          Apple_Free           262144 @ 64        (128.0M)
 3:           Apple_HFS apm    624880224 @ 262208    (298.0G)
 4:          Apple_Free               16 @ 625142432

Device block size=512, Number of Blocks=625142448 (298.1G)
DeviceType=0x0, DeviceId=0x0

Все “legacy”-разделы с драйверами Mac OS 9 не создаются. Кроме раздела с файловой системой остались только раздел 1 с метаданными и Apple_Free.

Схема из “Mac OS X Internals” показывает детальную схему Apple Partition Map.

Первый физический блок диска содержат двухбайтовую сигнатуру 0×4552 (“ER”), затем идут 2 байта размера блока (0×0200 = 512 байт) и 4 байта количества блоков на диске (0x2542eab0 = 625142448 блоков = 320072933376 байт = 298 GB при использовании базы 1024, и 320 GB при использовании 1000):

$ sudo dd if=/dev/disk2 of=/dev/stdout bs=8 count=1 2>/dev/null | hexdump
0000000 45 52 02 00 25 42 ea b0
0000008

Начиная со второго блока идёт Apple_partition_map, описывающая таблицу разделов диска. Один блок – один раздел. Первый описывает себя же (Apple_partition_map). Количество разделов в APM не ограничено, но изменить их количество в дальнейшем невозможно. Подробная структура первого раздела Apple_partition_map приведена в таблице из статьи “Apple’s Transition from Apple Partition Map to the GUID Partition Table“:

Байты 88-91 описывают статус раздела:

Давайте посмотрим таблицу разделов на нашем USB-диске. Сначала берём вывод pdisk:

$ pdisk /dev/rdisk2 -dump
Partition map (with 512 byte blocks) on '/dev/rdisk2'
 #:                type name      length   base      ( size )
 1: Apple_partition_map Apple         63 @ 1
 2:          Apple_Free           262144 @ 64        (128.0M)
 3:           Apple_HFS apm    624880224 @ 262208    (298.0G)
 4:          Apple_Free               16 @ 625142432

Cчитываем раздел 1

$ sudo dd if=/dev/disk2 of=/dev/stdout bs=512 count=1 skip=1 2>/dev/null | hexdump -C
00000000  50 4d 00 00 00 00 00 04  00 00 00 01 00 00 00 3f  |PM.............?|
00000010  41 70 70 6c 65 00 00 00  00 00 00 00 00 00 00 00  |Apple...........|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  41 70 70 6c 65 5f 70 61  72 74 69 74 69 6f 6e 5f  |Apple_partition_|
00000040  6d 61 70 00 00 00 00 00  00 00 00 00 00 00 00 00  |map.............|
00000050  00 00 00 00 00 00 00 3f  00 00 00 03 00 00 00 00  |.......?........|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

• 00-01. Signature Value 0x504d
• 04-07. Total number of partitions = 00 00 00 04, да именно так, у нас есть 4 раздела.
• 08-11 (0×08-0x0b). Starting sector of partition = 00 00 00 01. Да, начинается с первого сектора.
• 12-15 (0x0c-0x0f). Size of partition in sectors = 00 00 00 3f = 63.
• 16-47 (0×10-0x2f). Name of partition in ASCII = “Apple”
• 48-79 (0×30-0x4f). Type of partition in ASCII = “Apple_partition_map”
• 80-83 (0×50-0×53). Starting sector of data area in partition = 00 00 00 00
• 84-87 (0×54-0×57). Size of data area in sectors = 00 00 00 3f = 63
• 88-91 (0×58-0x5B). Status of partition = 00 00 00 03 = 01 | 02 = “Entry is valid” | “Entry is allocated”

Apple_Free слабо интересует

$ sudo dd if=/dev/disk2 of=/dev/stdout bs=512 count=1 skip=2 2>/dev/null | hexdump -C
00000000  50 4d 00 00 00 00 00 04  00 00 00 40 00 04 00 00  |PM.........@....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000030  41 70 70 6c 65 5f 46 72  65 65 00 00 00 00 00 00  |Apple_Free......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Разберём раздел с данными

$ sudo dd if=/dev/disk2 of=/dev/stdout bs=512 count=1 skip=3 2>/dev/null | hexdump -C
00000000  50 4d 00 00 00 00 00 04  00 04 00 40 25 3e ea 60  |PM.........@%>.`|
00000010  61 70 6d 00 00 00 00 00  00 00 00 00 00 00 00 00  |apm.............|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  41 70 70 6c 65 5f 48 46  53 00 00 00 00 00 00 00  |Apple_HFS.......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 25 3e ea 60  40 00 00 33 00 00 00 00  |....%>.`@..3....|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

• 00-01. Signature Value 0x504d
• 04-07. Total number of partitions = 00 00 00 04, всего 4 раздела.
• 08-11 (0×08-0x0b). Starting sector of partition = 00 04 00 40 = 262208. Начинается с блока 262208.
• 12-15 (0x0c-0x0f). Size of partition in sectors = 25 3e ea 60 = 63. Размер 624880224 блоков = 320072933376 байт
• 16-47 (0×10-0x2f). Name of partition in ASCII = “apm”. Имя раздела – “apm”
• 48-79 (0×30-0x4f). Type of partition in ASCII = “Apple_HFS”. Файловая система HFS
• 80-83 (0×50-0×53). Starting sector of data area in partition = 00 00 00 00
• 84-87 (0×54-0×57). Size of data area in sectors = 25 3e ea 60
• 88-91 (0×58-0x5B). Status of partition = 40 00 00 33 = 01 | 02 | 10 | 20 | 40000000 = “Entry is valid” | “Entry is allocated” | “Partition is readable” | “Automatically mount at startup”

Последний Apple_Free тоже не рассматриваем:

$ sudo dd if=/dev/disk2 of=/dev/stdout bs=512 count=1 skip=4 2>/dev/null | hexdump -C
00000000  50 4d 00 00 00 00 00 04  25 42 ea a0 00 00 00 10  |PM......%B......|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000030  41 70 70 6c 65 5f 46 72  65 65 00 00 00 00 00 00  |Apple_Free......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Окончание

Со схемой разделов Apple Partition Map мы познакомились. Это полезно, несмотря на то, что она уже почти не используется на новых системах, особенно под управлением Snow Leopard. Статья получилась достаточно большая как для одного дня, поэтому GUID partition table (GPT) я рассмотрю в следующий раз.

Но это не помеха – есть LiveCD rEFIt. rEFIt – это система, которая может запуститься после включения Mac (вставляется CD и выбирается через Option, или же его можно установить на постоянной основе). Она представляет собой инструментарий для любых компьютеров, поддерживающих EFI, в частности поддерживает Intel Mac.

Давно хотел рассмотреть процесс загрузки Mac OS X, давайте сделаем это вместе. Предупрежу – это моя попытка разобраться, и не рассматривайте на эту статью, как истину в последней инстанции. Это первая часть, далее я буду рассматривать более детально начальную и завершающую стадии – BootROM/EFI и launchd.

В процессе написания я использовал такую информацию:

• “System Startup Programming Topics“
• man kextcache
• главу “Booting Mac OS X” из несколько устаревшей, но чрезвычайно полезной книги “Mac OS X Internals” (@alexmak, спасибо за рекомендацию).

Процесс загрузки Intel Mac (Snow Leopard):

1. При включении питания запускается BootROM firmware.

1.1. Выполняется POST (Power-On Self Test), инициализирующий некоторые системные интерфейсы, и проверяющий, что в системе установлено достаточное количество памяти и она находится в нормальном состоянии.

1.2. Запускается EFI (Extensible Firmware Interface), инициализируя остальное базовое системное “железо”, и производящий выбор операционной системы.

2. Управление передаётся загрузчику boot.efi , находящемуся на разделе выбранной Mac OS X. Его основная задача – подготовить всё для загрузки ядра. boot.efi находится в /System/Library/CoreServices/ (и копия – в /usr/standalone/i386/).

2.1. Дисплей закрашивается светло-серым цветом.

2.2. Загрузчик пытается загрузить прелинкованную версию ядра (самой ядро – /mach_kernel), включающую все драйвера, необходимые для загрузки. Из-за этого время загрузки значительно сокращается. Каталог /System/Library/Caches/com.apple.kext.caches/Startup/, файлы вида kernelcache_i386.2B109974 (здесь указана архитектура и 8 символов контрольной суммы, вычисляемой по алгоритму Adler-32).

2.3. Появляется лого Apple и появляется вращающийся курсор.

2.4. Если прелинкованная версия ядра отсутствует, устарела (например, время модификации драйвера новее, чем это ядро) или повреждена, загрузчик пытается загрузить все драйвера из кеша mkext /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext. Описание кеша находится в /usr/standalone/bootcaches.plist.

2.5. Если кеш отсутствует, устарел или повреждён, загрузчик ищет в каталоге /System/Library/Extensions драйвера и расширения ядра, и загружает те, у которых OSBundleRequired установлено в значение, соответствующее типу загрузки (например, локальная, сетевая, etc). Детальнее можно посмотреть в “Loading Kernel Extensions at Boot Time“. Например,

$ grep -1 OSBundleRequired /System/Library/Extensions/AppleBacklight.kext/Contents/Info.plist | tail -2
	</dict>
	<key>OSBundleRequired</key>
	<string>Safe Boot</string>

$ grep -1 OSBundleRequired /System/Library/Extensions/AppleRAIDCard.kext/Contents/Info.plist
	</dict>
	<key>OSBundleRequired</key>
	<string>Local-Root</string>

Варианты OSBundleRequired:
• Root. This KEXT is required to mount root, regardless of where root comes from – for example, platform drivers and families, PCI, or USB.
• Network-Root. This KEXT is required to mount root on a remote volume—for example, the network family, Ethernet drivers, or NFS.
• Local-Root. This KEXT is required to mount root on a local volume – for example, the storage family, disk drivers, or file systems.
• Console. This KEXT is required to provide character console support (single-user mode) – for example, keyboard drivers or the ADB family.
• Safe Boot. This KEXT is required even during safe-boot (unnecessary extensions disabled)—for example, mouse drivers or graphics drivers.

2.6. Когда ядро и все необходимые драйвера загружены (не запущены, а именно “loaded” в память), загрузчик запускает процедуру инициализации ядра. На этой стадии загружено достаточное количество драйверов для того, чтобы было найдено устройство, на котором расположена корневая файловая система (более понятно – root device).

2.7. Ядро инициализирует структуры данных Mach и BSD, а затем I/O Kit (коллекцию системных фреймворков и библиотек, поддерживающих остальные драйвера устройств). I/O Kit линкует драйвера в ядро, используя дерево устройств для определения, какие именно драйвера линковать. Это дерево строилось на стадии EFI. Посмотреть его уже из загруженной системы можно так:

$ ioreg -S -p IODeviceTree -l 0 -w
+-o Root  <class IORegistryEntry>
  | {
  |   "IOKitBuildVersion" = "Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I$
  |   "IOMaximumMappedIOByteCount" = 536870912
  |   "OSPrelinkPersonalityCount" = 571
  |   "OS Build Version" = "10B504"
  |   "OSKernelCPUSubtype" = 3
  |   "OSKernelCPUType" = 7
  |   "OSPrelinkKextCount" = 139
  |   "IORegistryPlanes" = {"IOACPIPlane"="IOACPIPlane","IOPower"="IOPower","IODeviceTree"="IODeviceTree","IOService"="$
  |   "IONDRVFramebufferGeneration" = <0400000004000000>
  |   "IOConsoleUsers" = ({"kCGSSessionConsoleSetKey"=0,"kCGSSessionOnConsoleKey"=Yes,"kSCSecuritySessionID"=3172743,"k$
  |   "IOKitDiagnostics" = {"Container allocation"=3295268,"Instance allocation"=6354490,"Pageable allocation"=20925644$
  | }
...
  +-o PCI0@0  <class IOACPIPlatformDevice>
  | | {
  | |   "compatible" = <"PNP0A03">
  | |   "IODTPersist" = <a2319300a2409300>
  | |   "_STA" = 15
  | |   "IOPCIConfigured" = Yes
  | |   "acpi-address-spaces" = <0200000000000000000000000000000000000000000000000000000000000000ff000000000000000000$
  | |   "#size-cells" = <02000000>
  | |   "acpi-pci-routing-table" = <2800000000000000ffff030000000000000000005c5f53425f2e504349302e4c534d4200000000002$
  | |   "#address-cells" = <03000000>
  | |   "_ADR" = 0
  | |   "device-properties" = {"acpi-device"="IOACPIPlatformDevice is not serializable","acpi-path"="IOACPIPlane:/_SB$
  | |   "acpi-path" = "IOACPIPlane:/_SB/PCI0@0"
  | |   "name" = <"PNP0A08">
  | |   "acpi-device" = "IOACPIPlatformDevice is not serializable"
  | | }
...

2.8. Как только найдено root device, ядро его монтирует в “/”.

3. Загружаются системные сервисы и ведётся подготовка системы для использования пользователями. До версии Mac OS X 10.4 этим занимались привычные для BSD Unix процессы mach_init и init (они запускали в том числе разнообразные системные скрипты /etc/rc), но с версии 10.4 они были заменены на launchd.
В дополнение к инициализации системы launchd обеспечивает вызов демонов в нужном порядке. Наподобие inetd, launchd вызывает демонов по необходимости (они могут останавливаться через определённое время неактивности и перезапускаться по необходимости).

$ cat /System/Library/LaunchDaemons/com.apple.loginwindow.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>com.apple.loginwindow</string>
        <key>ProgramArguments</key>
        <array>
		<string>/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow</string>
		<string>console</string>
        </array>
        <key>KeepAlive</key>
        <true/>
</dict>
</plist>

4. В завершение launchd запускает loginwindow (окно входа в систему).

Детальнее о launchd поговорим в следующей статье.

В дополнение – если вы хотите постоянно видеть процесс загрузки (сообщения об оборудовании, загрузке драйверов, сервисов), то можно в консоли установить параметр “Verbose”:

sudo nvram boot-args="-v"

Отключение:

sudo nvram boot-args=""