Hi,

On Sun, Apr 29, 2007 at 12:23:24AM +0400, Konstantin A. Lepikhov wrote:
> Friday 27, at 02:14:26 AM you wrote:
> 
> ...
> > Если не будет обнаружено критических (на мой взгляд) ошибок, то это
> > последний снапшот перед релизом.
> сегодня поставил это на типа серверную мать от intel (D845WD). Система
> старая, думал проблем не будет (Trustix на нее ставился на ура). Ан нет.
> Проблемы начались сразу:
> 
> 1) lilo не умеет ставится на массивы, созданные недорейдами от promise.

Это кто такие?  Не имел счастья лицезреть.

> Т.е. говорит что поставился, а при загрузке пишет LI 99 99 99 ... Не
> сильно страшно, но выяснение минут 20 отняло (почему именно массив
> недорейда долгая история, вкраце - если не создавать массив, биос не видит
> дисков и не дает с них грузиться). Для себя я эту проблему решил создав 2
> массива по 1-му диску в каждом и указав в типе массива обычный span.

Интересно, жалуется ли lilo, когда устанавливается на такое устройство?

> 2) отсутствие нормального /dev это большая проблема, если даже не полная Ж
> в виду наличия udev который полон race'ов. У меня после установки система
> даже не грузилась с руганью на Unable to open /dev/root/console после
> загрузки initramfs. Комментирование UUID'а (заменил на реальный дивайс) и
> прописывание noudev помогло. Грабли 100% в удефф, потому как _один_ раз
> оно таки загрузилось без проблем. Итого убил минут 60.

А в чём специфика системы, как это воспроизвести?
Я ни разу с этим не сталкивался.

> 3) alterator-vsftpd сломан, или сломан alterator-proxy потому как после
> создания контейнера ftp-server попытка зайти и настрить службу
> обламывается со словами "бакенд не найден" (хотя внутри контейнера
> alterator-vsftpd в процессах висит). Потеря времени некритична (бо
> vsftpd.conf я и ручками осилю).

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

> 5) alterator-vm. Не нравится все - от невозможности создать LVM на RAID,
> до ужостных рамочек и рулеров во всех диалогах (особенно если рулер
> предлагает промотать одну строчку). В общем разбил fdisk'ом из rescue
> по-быстрому, потом там только точки монтирования поставил, а уже
> окончательно все сделал evmsn в HWN. Т.е. удобства во дворе и сопоставимы
> с установкой системы с livecd и распаковкой тарболла на base root. Времени
> потратил минут 30 + время на синхронизацию массивов. С синхронизацией
> вообще весело - сначала диалог alterator-vm появился минут через 10. Полез
> в логи и ужаснулся - оно оказывается собрало raid'ы (до установки там
> была система на root raid1) и начало их синхрить причем на _максимальной_
> скорости (2ldv@ этот side effect мы уже видели в пятницу). Имхо скорость
> синхронизации надо понижать сразу, где-то в alterator-install2.

К сожалению, при создании новых raid'ов alterator-vm'ом переход в консоль
для того, чтобы снизить скорость синхронизации, сейчас является
необходимым условием завершения установки системы в разумное время.
Это bug #11511.
К сожалению, хак в alterator-install2, если он будет туда добавлен,
не решит проблему очень долгого форматирования тома, построенного на
свежесозданном raid'е.

Другими словами, приемлемого решения за пределами alterator-vm мне не
известно.

> PS Насчет rescue - оно конечно годится для сборки sysreport и для
> восстановления lilo по-быстрому, но вот для всего остального я бы
> использовал rescue из spt. Он какой-то более человечный.

Я вчера-сегодня привёл rescue к более-менее пригодному виду.
А чем отличается этот rescue от rescue из spt?


-- 
ldv