1. При вставке PCMCIA-карты ifup (на ifdown я не обратил внимания, тоже возможно) запускают и cardmgr (service pcmcia) и hotplug. Я думаю, что hotplug сюда пусть лучше не лезет. 2. При вставке CardBus-карты ifup запускает только hotplug. Но при её извлечении ifdown не запускается.
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 - это работает нормально.
