Падает на VIA C3

From

Anna Nikolaeva (2:450/102.112)

To

Victor Sudakov

Date

2008-02-12T09:50:38Z

Area

RU.UNIX.SOLARIS

Hello, Victor!

On 12 Feb 08 09:33, Victor Sudakov (2:5020/400) wrote to Anna Nikolaeva:

VS> From: Victor Sudakov <vas@mpeks.tomsk.su>

VS> Anna Nikolaeva wrote:
>> >> AN> А если смувить /etc/path_to_inst ?

>> >> Только мувить его надо в бутархиве.
>> >> Например, на изначальном сервере сделать так:
>> >> mv /etc/path_to_inst /etc/path_to_inst.orig
>> >> mv /platform/`uname -i`/boot_archive /platform/`uname
>> >> -i`/boot_archive.orig bootadm update-archive

>> VS> Поясни пожалуйста, какую роль играет path_to_inst и почему его
>> VS> удаление должно помочь?

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

>> Идея проста: в path_to_inst сидит, грубо говоря, описание конфигурации
>> конкретного компутера.

VS> А если поподробнее? Кто именно в системе *пользуется* этой привязкой
VS> physical device names to instance numbers? А то создалось впечатление,
VS> что path_to_inst ведут только ради mknod. Без mknod я как-нибудь переживу.

Мне больше верится, что ведется оно для того, чтобы между ребутами
имена устройств не плавали. Т.е. переставили девайс на выключенной
системе, в другой слот - получили _новый_ экземпляр этого девайса.
Вернули его назад - получили старый. При этом система уже знает,
что по такому-то аппаратному пути когда-то был тот самый _новый_
экземпляр. Это _я_ так понимаю. По аналогии с /etc/ioconfig на hpux.


VS> А остальная часть системы, похоже, пользуется или симлинками в /dev,
VS> или непосредственно physical device names (bootpath в eeprom,
VS> например).

В /dev, как правильно было замечено, живут _только_ симлинки. Сами же
файлы устройств живут именно в /devices. И именно оттуда берется
информация о том, какой драйвер и с какими параметрами (major/minor)
необходимо пользовать при доступе к конкретному устройству.
Из man path_to_inst видим:
<quote>
     The instance number of a device  is  encoded  in  its  minor
     number, and is the way that a device driver determines which
     of the possible devices that it may drive is referred to  by
     a given special file.
</quote>

Я сильно подозреваю, что в Вашем случае проблема именно с кашей
в файле path_to_inst

>> Если его удалить, система сгенерит новый. И этот
>> новый не будет содержать хвостов от старой системы.

VS> Не помогло удаление. Более того, если его удаляешь и потом запускаешь
VS> "bootadm update-archive", то "bootadm list-archive" таки показывает
VS> наличие какого-то path_to_inst в архиве.

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

Вариантов обхода я вижу два:
1) заменить файл /etc/path_to_inst его аналогом из /boot/x86.miniroot-safe
   Оно - загзипаное ufs, кстати, с очень любопытным параметром (если оно
   параметр, конечно). bootadm update-archive -v
2) удалить /etc/path_to_inst прямо из бутархива (/platform/i86pc/boot_archive)
   Оно - загзипаное hsfs

>> VS> Чтение man path_to_inst и man devfs не внесло ясности. То есть
>> VS> стало
>> VS> только понятно, что хитрые имена в /devices живут своей жизнью под
>> VS> управлением devfs, devfsadm создаёт на них удобочитаемые линки в /dev,
>> VS> а path_to_inst тогда нужен зачем?

>> Ну и по ходу, boot -r, наверное не помешет.

VS> Пробовал.
VS> Ещё "boot -a" попробую и расскажу, что получилось.

Anna.

--- GoldED+/W32 snapshot-2001.5.29
 * Origin: By. (2:450/102.112)
SEEN-BY: 45/128 236/100 450/77 102 1024 451/13 452/123 4500/1 5000/5000
SEEN-BY: 5011/13 5015/28 5019/40 5020/400 545 2238 4441 5021/29 5025/3
SEEN-BY: 5030/1957 5035/38 5045/7 5054/1 4 8 9 28 37 5061/120 5062/10 5064/7
SEEN-BY: 5085/13 5095/20 5096/18 6001/10

PATH: 450/102 1024 5020/545 5054/1 37