> > Попробовал поставить cd-20070726 по сети: результат отрицательный, > > первая стадия попадает в бесконечный цикл > > "настроили сеть"->"указали источник на ftp"->"полчили файл по > > ftp"->"настроили сеть"... и т.д. > > > > Использую vsftpd, > > изучение логов даёт следующее: > > Sat Jul 28 13:57:58 2007 [pid 14533] [vsftpd] FTP response: Client > > "192.168.0.254", "150 Opening BINARY mode data connection for > > /pub/desktop4.0/altinst (54534144 bytes)." > > Sat Jul 28 14:07:25 2007 [pid 14517] [vsftpd] FTP response: Client > > "192.168.0.254", "426 Failure writing network stream." > > Sat Jul 28 14:07:25 2007 [pid 14517] [vsftpd] FAIL DOWNLOAD: Client > > "192.168.0.254", "/pub/desktop4.0/altinst", 0.00Kbyte/sec > > > > При первом соединении, и дальше повторные соединения уже без этой > > ошибки, но, похоже, обрываемые самим клиентом, пока лимит соединений > > на сервере не кончится. > > > > Права доступа на каталог с образом были поставлены 777, в конфиге > > выставлена опция use_sendfile=NO, не помогает. Помогает установка при загрузке параметра ramdisk_size=65536 Если невозможно обходиться без явной установки этого параметра, то хотелось бы видеть внятную диагностику от пропагатора и отсутствие вечного цикла.
следовало бы просто подавать этот параметр из isolinux/syslinux/gfxboot, а не пытаться сначала диагностировать, а затем добавлять, вынуждая пользователя дважды закачивать образ ramdisk. Напомню, это параметр ядра, а не propagator.
(In reply to comment #1) > следовало бы просто подавать этот параметр из isolinux/syslinux/gfxboot, > а не пытаться сначала диагностировать, а затем добавлять, > вынуждая пользователя дважды закачивать образ ramdisk. > Напомню, это параметр ядра, а не propagator. Согласен, что этот параметр можно проще передавать при загрузке, однако остается в силе замечание о том, что пропагатор должен выдавать более внятную диагностику при несовпадении образа рамдиска с его ожиданиями и не должен западать в вечный цикл в этой ситуации (равно как и ни в какой другой ;)
propagator не ожидает никакого специального размера рамдиска -- это не его дело и не его ответственность.
fixed
(In reply to comment #3) > propagator не ожидает никакого специального размера рамдиска -- это не его дело > и не его ответственность. Прошу объяснить происхождение вечного цикла в описанной ситуации. Возможно, ошибка эта действительно не в propagator, но тем не менее исправить ее нужно.
