Bug 12412 - вечный цикл при установке по ftp (при отсутствии параметра ramdisk_size=65536)
: вечный цикл при установке по ftp (при отсутствии параметра ramdisk_size=65536)
Status: CLOSED FIXED
: ALT Linux Desktop
(All bugs in ALT Linux Desktop/bugs)
: snapshot
: all Linux
: P2 normal
Assigned To:
:
:
:
:
: 12100
  Show dependency tree
 
Reported: 2007-07-29 13:17 by
Modified: 2008-07-03 10:21 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-07-29 13:17:03
> > Попробовал поставить 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

Если невозможно обходиться без явной установки этого параметра,
то хотелось бы видеть внятную диагностику от пропагатора и 
отсутствие вечного цикла.
------- Comment #1 From 2007-07-29 14:50:03 -------
следовало бы просто подавать этот параметр из isolinux/syslinux/gfxboot,
а не пытаться сначала диагностировать, а затем добавлять,
вынуждая пользователя дважды закачивать образ ramdisk.
Напомню, это параметр ядра, а не propagator.
------- Comment #2 From 2007-07-29 18:06:46 -------
(In reply to comment #1)
> следовало бы просто подавать этот параметр из isolinux/syslinux/gfxboot,
> а не пытаться сначала диагностировать, а затем добавлять,
> вынуждая пользователя дважды закачивать образ ramdisk.
> Напомню, это параметр ядра, а не propagator.

Согласен, что этот параметр можно проще передавать при загрузке,
однако остается в силе замечание о том, что пропагатор должен выдавать более
внятную диагностику при несовпадении образа рамдиска с его
ожиданиями и не должен западать в вечный цикл в этой ситуации (равно как и ни в
какой другой ;)
------- Comment #3 From 2007-07-29 19:34:24 -------
propagator не ожидает никакого специального размера рамдиска -- это не его дело 
и не его ответственность.
------- Comment #4 From 2007-08-01 15:08:57 -------
fixed
------- Comment #5 From 2007-08-02 12:01:51 -------
(In reply to comment #3)
> propagator не ожидает никакого специального размера рамдиска -- это не его 
дело 
> и не его ответственность.

Прошу объяснить происхождение вечного цикла в описанной ситуации.
Возможно, ошибка эта действительно не в propagator, но тем не менее
исправить ее нужно.