Bug 4668

1. Наоборот, скорее пусть наверное cardbus этого не делает. Ибо hotplug не
сможет понять кем обслуживается эта плата ;-(
2) Поддержка remove для net.agent добавлена в 2004_03_29-alt3

Кстати, наблюдаю в hotplug следующий код:
            # Run ifrename as needed - Jean II
            # Remap interface names based on MAC address. This workaround
            # the dreaded configuration problem "all my cards are 'eth0'"...
            # This needs to be done before ifup otherwise ifup will get
            # confused by the name changed and because iface need to be
            # down to change its name.
            if [ -x /sbin/ifrename ] && [ -r /etc/iftab ]; then
                debug_mesg invoke ifrename for $INTERFACE
                NEWNAME=`/sbin/ifrename -i $INTERFACE`
                if [ -n "$NEWNAME" ]; then
                    debug_mesg iface $INTERFACE is remapped to $NEWNAME
                    INTERFACE=$NEWNAME
                fi;
            fi

У нас есть поддержка этого добра в net-scripts ?

Насколько я вижу, при наличии ifrename и iftab должно работать само собой.
Интересный ход.
Миша, попробуй залочить свои две карты через MAC.

как? :) (echo HWADDR=... >> ifcfg-eth?)

да, и если это заработает - необходимо IMHO добавить во все тулзы
конфигурирования прописывание MAC адреса (инсталятор, драки).

Не вижу здесь особой сложности.

Погоди :-)

Починили, работает -- главное теперь ничего не трогать.  Ну их нафиг, эти драки,
лучше в своем не забыть...

В том то и дело, что нифига не починили, ибо - на 2.6 ядре загружается драйвер
eth1394 и мы получаем eth0, определенный на eth1394 а то что было как eth0
становится eth1. Соответственно опять ничего не работает ;-(

Чинить надо правильно и до конца. А драки все равно придется патчить (для
USE_HOTPLUG, например).

Не, 2.6 меня тут не интересует и ломать эту хлипкую конструкцию ради него не стоит.

В том плане, что для переезда на 2.6 все равно нужны действия вроде echo psmouse
>> /etc/modules, игры с версионированием в modules.conf и прочее
рукоприкладство.  Т.е. поддержка есть, и довольно -- а пытаться автоматизировать
это с учетом никакой поддерживаемости этой автоматики -- нунафиг.

Ты вот лучше придумай, что с этим psmouse делать, а 2 eth -- это уже мелочи по
сравнению с.

"Чинить правильно и до конца" -- поддерживаю в теории, но на практике пупок
лопнет: не стоит забывать, что мир крив и софт -- тоже, и ничего с этим
кардинально не поделаешь.

Остается делать, чтоб хоть как-то работало... :-)

Про USE_HOTPLUG -- угу.

с psmouse, как раз, все очень просто.

Детектить наличие psmouse через ACPI и загружать его в input.rc в hotplug'е.

А вот с сетью - надо решать. Ибо сейчас это - нерешаемо на 2.6 так как нужно. А
миграция с 2.4 на 2.6 будет необходима уже в следующем Master.

Так вот за время жизни ALM2.4 и будем ее решать.

Сейчас поздно дергаться сильно и нет смысла дергаться чуть-чуть, если уже
работает (for me, да? -- см. тж. #4529) и как-то устраивает.

Здесь ситуация получилась практически искусственная -- ноутов с двумя сетевыми
немного, хотя вышел интересный тестодром в том плане, что есть чистый PCMCIA и
CardBus, который (насколько понимаю) почти прямо на PCI и усажен.  Меня ее
разрешение _после_ ALM2.4 -- целиком устраивает, т.к. это скорее подтверждение
работоспособности в "угловом" случае и приоритет соответственно ниже.

В остальном -- что Pilot скажет.

Я скажу: у нас фриз (если кто забыл). Давайте только исправлять ошибки.

(In reply to comment #10)
> Так вот за время жизни ALM2.4 и будем ее решать.
> 
> Сейчас поздно дергаться сильно и нет смысла дергаться чуть-чуть, если уже
> работает (for me, да? -- см. тж. #4529) и как-то устраивает.
> 
> Здесь ситуация получилась практически искусственная -- ноутов с двумя сетевыми
> немного, хотя вышел интересный тестодром в том плане, что есть чистый PCMCIA и
> CardBus, который (насколько понимаю) почти прямо на PCI и усажен.  Меня ее
> разрешение _после_ ALM2.4 -- целиком устраивает, т.к. это скорее подтверждение
> работоспособности в "угловом" случае и приоритет соответственно ниже.
> 
> В остальном -- что Pilot скажет.


Да почти каждый (не почти, а совсем каждый современный) ноут имеет на борту
FireWire, на который у нас вешается модуль eth1394.

сразу после этого поднимается eth0, который смотрит на самом деле на firewire.

Вот что... ну у меня eth1394 нету, машинка где-то 2000 года.

> сразу после этого поднимается eth0, который смотрит на самом деле на firewire.
Ну и пусть, что тут такого?

Так сеть то не работает ;-)

А eth1 и прочие кто будет настраивать?

по хорошему - hotplug, а так - пока network-scripts

Я имел в виду другое. Если для eth1 создан инсталлятором ifcfg-eth1 и в нём
ONBOOT=yes, то никакой проблемы нет. Какая разница пользователю, как называется
интерфейс, через который он ходит в сеть?
Что значит "сеть не работает"?

Дело в том, что в процессе установки eth1394 не загружается, соответственно eth1
нет а eth0 присваивается интерфейсу сетевой.

После загрузки в 2.6 ядро появляется eth0 -> eth1394, на него ложаться настройки
от сетевой платы, а сетевая плата становится eth1.

(In reply to comment #19)
> Дело в том, что в процессе установки eth1394 не загружается, соответственно eth1
> нет а eth0 присваивается интерфейсу сетевой.
Так загружайте. Инсталлятор и hotplug должны иметь общее мнение и имеющемся
оборудовании.

> После загрузки в 2.6 ядро появляется eth0 -> eth1394, на него ложаться настройки
> от сетевой платы, а сетевая плата становится eth1.
Так всё-так эта проблема специфична для 2.6? Задокументруйте как особенность тогда.

Инсталятор пока что базируется на ядре 2.4.

Да, проблема еще будет появляться если какая-то сетевая плата вдруг сядет на eth0.

Сегодня я это воспроизвел путем перезагрузки с вставленной PCMCIA сетевой платой.

Она села на eth0, а встроенная в ноутбук переползла на eth1.

Получаем опять нерабочую сеть ;-(

Чтобы такого не было, нам нужно заиметь ifrename в wireless-tools (или отдельно
от него), то есть вместо текущей версии 26 взять бету (!).
Есть ещё nameif, но насколько я вижу, он староват. 
Можно попытаться самим сделать что-то переименовывающее.
Я думаю, в 2.4 пока будет разумным компромиссом закрепить, что встроенные
сетевые интерфейсы будут появляться раньше вставных.

Я внес eth1394 в blacklist в hotplug, а вообще - будем фиксить. наверное после
Master'а.

hotplug-2004_03_29-alt7 теперь стартует после net-scripts.

(In reply to comment #1)
> 1. Наоборот, скорее пусть наверное cardbus этого не делает. Ибо hotplug не
> сможет понять кем обслуживается эта плата ;-(
Если так и не решено, то я делаю reopen.

На данный момент решено. После Master 2.4 продолжим ?

Продолжим.

(In reply to comment #2)
> Кстати, наблюдаю в hotplug следующий код:
[...]
> У нас есть поддержка этого добра в net-scripts ?

apt-get install ifrename

На бете мастера (Sisyphus 20040813) я вижу следующее:
1. Вставляю 1 pcmcia карту, отрабатывают и hotplug и pcmcia_cs (запускают ifup).
2. Вынимаю pcmcia, реагирует pcmcia_cs. hotplug сообщает, что NET unregister
event not supported.
3. Вставляю cardbus, реагирует hotplug.
4. При вставленной cardbus вставляю pcmcia, реагирует только hotplug.
Это неправильно.

ALT Linux Sisyphus (20040902), в net.agent я вижу только события remove, add и
register.

Если посмотреть вот сюда (http://linux-hotplug.sourceforge.net/?selected=net),
то видно, что должны приходить register и unregister. А вот тут
(http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/HOTPLUG.txt) это
дополнительно подтверждено в патче для net.agent.

Не подтверждается. На ядре 2.6 unregister приходит без проблем.

У нас используется 2.4. Это нужно было лишний раз сказать?

На 2.4 ядре функциональность hotplug уже не исправляема. А отсуствие события
unregister - проблема ядра.

Вообще как-то странно у нас выходит (хотя должно работать):

case $ACTION in
[...]
remove)
[...]
add|register)
[...]
remove|unregister)

Не пора ли сделать code cleanup?

Это я net.agent цитировал.

Сделал.

А что сейчас ?

в связке - ядро 2.6.12, udev-0.62, hotplug - это работает нормально.