В 5-35 плавными движениями была предпринята попытка запуска sysinst из мак-бутера. 2 минуты 20 секунд заняла распаковка сжатого образа системы. Загрузка ядра и sysinst произошла намного быстрее. Дальше я видел стандартный sysinst (точно такой же как и на i386), но новый трабл коварно поджидал меня уже на стадии форматирования диска!

Команда newfs упорно рушилась с ошибкой Segmentation Fault. В руководстве по установке утверждали, что сие проявление непокорности есть прямое следствие мизерного объема доступной памяти. Чтож.. возможно. Однако это мало утешало. К счастью, в дистрибутиве netbsd3.0.1/mac68k есть мак-программа Mkfs.

Уже привычные телодвижения с выниманием дискеты из мака, переброской шнура монитора с видеовыхода мака на видеовыход PC, копирование Mkfs с КД-ПЗУ в виртуальный диск эмулятора через утиль TransMac, загрузка эмуля, тыкание на Mkfs (живая ли вообще), её копирование на мак-флоппи, извлечение дискеты (в виртуале)/вставка дискеты (в реале)... А вы что думаете, куда ушло 90% всего времени, затраченного на предыдущие и последущие действия?

Занимательное наблюдение - созданный программой sysinst слайс НэтБСД макинтошевская утилита Apple_HDST опознавала как раздел A/UX. И наоборот - созданный с помощью Apple_HDSC слайс A/UX NetBSD видела как родной. Кстати говоря, программа Apple_HDST называет мак-участки Volume, а A/UX-участки (и соответственно NetBSD-участки) Slices. В тоже время, слайсами в NetBSD/i386 называются Четыре Основных Раздела, а внутренние по отношению к слайсу NetBSD участки винта зовутся Partitions и нумеруются от a до p. По всей видимости, в NetBSD/mac68k слайсы и разделы являются синонимами. Хотя.... хотя нет.. участки, занесеные в метку диска (disklabel) как раз и называются разделами, а участки, не занесеные в её - слайсами. Это с точки зрения NetBSD. А с точки зрения программы AppleHDST всё что прописано в 16-кБ таблице разделов является слайсами, если это не мак-раздел. Тогда он будет томом (Volume). Надеюсь, я запарил вас достаточно, чтобы вы поверили в то, что я не сидел на месте, а упорно грыз гранит (науки). Еще один факт, макинтошевский инсталлер автоматически создает устройства дисковых накопителей с буквами от a до h - как в старых вариантах BSD (но я забежал вперед).

Вот один из примеров схемы разбивки мак-винта с точки зрения Apple HD Setup. Раздел #0 - содержит список всех остальных разделов.

0 кБ.
Раздел #0 - Partition table
16кБ.
Раздел #1 - Macintish Drivers
64кБ.
Раздел #2 - Macintosh Volume "Мой Макинтош"
A кБ.
Раздел #3 - A/UX Swap Slice
B кБ.
Раздел #4 - A/UX Root
C кБ.
Раздел #5 - A/UX Usr
D кБ.
Раздел #6 - Macintosh Volume "f"
E кБ.
Раздел #7 - Scratch
F кБ.

Поскольку его длина составляет 16 кБ то, по приблизительным оценкам, сюда может поместится 32-64 таких участков, которые в i386 зовутся PRIMARY PARTITIONS. Что значит тип Scratch я пока что не понял. Но (предположительно) - это свободный кусок, который можно прицепить к разделу типа mac-volume, тем самым увеличив его.
___________________________________________________________________

Вы наверное воображаете, будто на примере такой мелочи я пытаюсь доказать техническое превосходство архитектуры Macintosh над i386?? Да! Ежели вы истинный нэтбээсдэшник и 1)вам совершенно не нужна Windows/i386 2) вам хватит 200-700мГц то рекомендую немедленно отдать мне свой PC и купить себе любой подержаный Макинтош (например у меня :-D. А если вы живете в Москве, то выбор вообще колоссален. Помимо Макинтошей там пачками и за бесценок можно достать машины класса Sun SPARC и DEC Alpha.
___________________________________________________________________

Итак, Mkfs на реальном макинтоше повела себя следущим образом:
1) Сказала, что она является частью проекта "АЛИСА" по портированию "BSD UN*X on Mac68k"
2) Увидела A/UX раздел и предложила форматнуть его
3) Спросила параметры форматирования с возможностью автоматической их оптимизации по статьям скорости/емкости на выбор
4) форматнула

Оставалось загрузить sysinst и оценить эту работу с точки зрения NetBSD:

# mount /dev/sd0a /mnt

Маунт порычал-порычал насчет "нечистой" файловой системы, да и умолк родив директорий /mnt/lost+found .

Вроде все было готово для заливки дистрибутива. Однако простейшая проверка вроде

# cat > /mnt/file
lalala<РЕТУРН>

выдавала:

cat: /mnt/file: file too large

Неплохо, да? Продолжительный секс с перезагрузками, добавлениями подкачки, изменения объема доступной памяти, попыток избавится от проблем перейдя с образа INSTALLSBC.gz на INSTALL.gz и повторения вышеперечисленных и ряда вовсе непонятных приемов прямого результата, как всегда, не дали, причем не забыли отнять добрые 6 часов.

В интернете я нашел единственный форум на котором единственный человек выдвинул единственный вопрос, че блин за file too large? Местные сильно активничающие в том треде !профессионалы после такого вопроса куда-то испарились. Стало быть, придется искать решение самостоятельно.

NFS работала как надо - т.е. работающий с ней tar и gunzip заливали в буфера ОЗУ небольшие куски данных и пытались сбрасывать их на свежеиспеченный раздел. Это им, естественно не удавалось, поскольку любая запись в раздел /mnt заканчивалась созданием файла с нулевой длиной с криками file too large и file system full... Это начинало нервировать.

Как говорил хороший знакомый одного моего хорошего знакомого, когда его переезжал паровой каток "во всем нужно искать положительные стороны". И вправду, у меня появился реальный шанс-стимул изучить подробнее дисковую подсистему NetBSD - почему происходит такое? А может быть, на i386 это тоже возможно и когда в один прекрасный момент забьется вся виртуальная память мне придется смирится и на глазах у истерически смеющейся публики скромно нажать Ctrl-Alt-Reset? Именно такие сны мне привидились в тот день. В 21-00 начался самый жестокий этап