Re: Сетевуха работает только в promisc режиме
On 21.05.2012 15:08, Артём Н. wrote: Кстати, мы всё рассуждаем про eth1, а что с eth0? Существует ли он, подключен ли к сети, если да, то не к той же случайно? Кстати, хотел вас об этом спросить. :-) Ядро самосборное (изначально с oldconfig). Всё, что не нужно выкинуто. Всё, в чём сомневался, - оставил модулем. Как я понял, есть PHY и M-II подсистемы. Нет. Подсистема PHY одна. Почти все (а может и вообще все) современные Эзернеты состоят из двух чипов: MAC и PHY, связанных между собой шиной MDIO (конфигурация и служебная информация) и (каким-нибудь вариантов) MII (данные). При этом чипы вовсе не должны быть одного производителя. Изначально (при установке на дистр. ядре) был eth0. После какого-то из изменений стал eth1. Это, скорее всего, значит, что у карточки поменялся MAC. Повод задуматься. Я вкомпилил два драйвера (на всякий случай): 1. Drivers for Realtek PHYs. (Supports the Realtek 821x PHY.) PHY у Вас может быть совершенно другого производителя. 2. Realtek 8169 gigabit ethernet support (CONFIG_R8169) (Realtek 8169 PCI Gigabit Ethernet adapter). Очевидно, что PHY не работает. И я его сейчас убрал вообще. Очевидно как раз обратное. При неработающем PHY у Вас не прошла бы негоциация, да и вообще карта не смогла бы ничего не отправить, не получить. Другое дело, что, возможно, работает оно вовсе не реалтековским драйвером, а с generic. Но вопрос: почему две подсистемы и в чём отличия (я мало знаю по адаптерам)? И почему остался eth1? Как я уже написал: это уж точно не из-за драйвера PHY. Драйвер PHY -- не есть драйвер сетевой карты, он не может появиться, как интерфейс. Скорее всего, интерфейс Вам переименовывает udev. Насколько мне известно, это может быть только при смене MAC адреса. Это факт No1. Факт No2: где-то в Ваших логах был кусок вида DHCPREQUEST DHCPNACK то есть а. Обмен пакетами прошёл успешно. б. Сервер отказался выдать адрес, который хост запомнил с прошлого раза, т.е. скорее всего, сервер считает, что этот адрес отдан другому MAC'у. Факт No3: Promisc помогает. Факт No4: Как Вы сами пишете, точно так же может не работать и ifupdown, а после перезагрузки снова работать. Всё это заставляет меня думать, что неправильно идентифицировали источник проблемы, как nm, а реально у вас глючит карточка (возможно, плавает MAC адрес в EEPROM'е). Попробуйте задавать MAC руками. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jpdem9$r23$1...@dough.gmane.org
Re: Конфигурация grub 2
Привет, On 19.05.2012 00:55, Mikhail Ramendik wrote: У меня squeeze, на котором до недавнего времени работал grub 0.97 и всё было отлично. После очередного apt-get update apt-get upgrade система перешла на grub 2. А в его навороченной конфигурации я накрепко запутался. Гугль курил, но не смог сделать простую вещь: - Имеются ядра 2.6.32, 2.6.35, 3.0.0 - Первым (он же дефолтный) пунктом в меню должно быть 2.6.32 с моим специализированным коммандлайном - А дальше - все имеющиеся ядра с дефолтным коммандлайном Конфиг генерится путём запуска шелл-скриптов в /etc/grub.d/ Добавьте 09_my_beloved_kernel, который будет генерировать первый пункт меню, как Вам нужно. Точнее, я это успешно делаю редактированем /boot/grub/grub.cfg . Но он при обновлении перезаписывается :( Как это сделать grub2, или же - как снести напрочь grub2 и вернуть замечательный grub 0.97? (Меня бы также устроило запретить перезапись grub.cfg, но если я правильно понимаю, руту её никак не запретить, даже chmod o-w не поможет?) Как поставить GRUB Legacy Вам уже подсказали. Запретить перезапись: man chattr /immutable -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jp6dtd$hu8$1...@dough.gmane.org
Re: Конфигуратор файрволла
On 17.05.2012 15:15, Artem Chuprina wrote: Я, кстати, ожидаю форка - на интерфейсы для 90% населения и интерфейсы для тех, кому надо дело делать. Ох, скорей бы уж... -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jp3eel$5n0$1...@dough.gmane.org
Re: ffmpeg вылетает
Привет, On 16.05.2012 20:08, Dmitrii Kashin wrote: Причем надо заметить, что вылетает на любом файле при переконвертировании 1080p в 1080p. При переконвертировании в 720p проблем не возникает. Подскажите, в каком направлении искать решение проблемы? В чем может быть дело? Я пока думаю, что это не нормально, и надо багрепорт вешать - но прежде хотелось бы услышать мнение сообщества. ffmpeg сожрал всю память и героически погиб от рук OOM killer'а? Судя по тому, что с меньшим разрешением работает, похоже. В dmesg на эту тему ничего не написано? Хорошо бы узнать, что за сигнал ему прилетел, для этого можно в strace, например, запустить. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jp0qqn$op8$1...@dough.gmane.org
Re: [fat][mlabel][mtools] Назначение метки флэшке — при 8 и более символах дополняется мусором до 11 символов.
Привет, On 10.05.2012 21:52, Dmitry Alexandrov wrote: Собственно вот: $ mlabel -i /dev/sdb1 ::ABCDEF $ ls /dev/disk/by-label/ ABCDEF DATA HOME WHEEZY $ mlabel -i /dev/sdb1 ::ABCDEFG $ ls /dev/disk/by-label/ ABCDEFG DATA HOME WHEEZY $ mlabel -i /dev/sdb1 ::ABCDEFGH $ ls /dev/disk/by-label/ ABCDEFGH\xf0gA DATA HOME WHEEZY $ mlabel -i /dev/sdb1 ::ABCDEFGHI $ ls /dev/disk/by-label/ ABCDEFGHIgA DATA HOME WHEEZY $ mlabel -i /dev/sdb1 ::ABCDEFGHIJ $ ls /dev/disk/by-label/ ABCDEFGHIJA DATA HOME WHEEZY $ mlabel -i /dev/sdb1 ::ABCDEFGHIJK $ ls /dev/disk/by-label/ ABCDEFGHIJK DATA HOME WHEEZY От флэшки, вроде бы, не зависит. GParted’ом с рутовыми правами — то же самое. Debian Wheezy. Linux 3.2.0-2-amd64. mtools 4.0.12-1. На багтрэкере за mtools’ами такого, вроде бы, не числится (http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mtools). Это только у меня наблюдается? Проверьте на своих машинах, пожалуйста. Это баг mtools, пофикшенный в апстриме (начиная с 4.0.14). gparted просто зовёт mtools для FAT. Надо бы повесить баг и попросить мейнтейнера обновиться. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jop7fj$2hj$1...@dough.gmane.org
Re: HDD problem
On 08.04.2012 13:35, Maksym Tiurin wrote: Пробовал грузиться с параметрами 'ide-pci-generic.all-generic-ide Модуля ide-pci-generic у Вас, скорее всего, вообще нет. Погуглив нашел описание аналогичной проблемы с таким-же Drive Caddy на форуме пользователей ноутов HP. В качестве решения там человеку предложили пользоваться нормальной операционной системой, а не морочить голову всякими линуксами. Куда копать и что делать чтоб диск заработал нормально? Сложно сказать наверняка, но похоже на проблему в PATA драйвере. Ищите желающего ковыряться с драйвером с таким же железом. Ну или можно попробовать собрать ядро со старыми IDE драйверами. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jls67r$6k1$1...@dough.gmane.org
Re: не запустились иксы после обновления
On 28.03.2012 13:48, Aleksey Andreev wrote: Вопросы: 1. Все ли я правильно сделал? В принципе -- да, только у меня вот такой файлик пришёл из пакета: $ cat /etc/modprobe.d/nvidia-kernel-common.conf alias char-major-195* nvidia options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660 # To enable FastWrites and Sidebus addressing, uncomment these lines # options nvidia NVreg_EnableAGPSBA=1 # options nvidia NVreg_EnableAGPFW=1 # see #580894 blacklist nouveau ilya@mefesto:~/phd_study$ cat /etc/modprobe.d/nvidia-kernel-common.conf alias char-major-195* nvidia options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660 # To enable FastWrites and Sidebus addressing, uncomment these lines # options nvidia NVreg_EnableAGPSBA=1 # options nvidia NVreg_EnableAGPFW=1 # see #580894 blacklist nouveau $ dpkg -S /etc/modprobe.d/nvidia-kernel-common.conf nvidia-kernel-common: /etc/modprobe.d/nvidia-kernel-common.conf У Вас nvidia-kernel-common установлен? Если нет, надо разбираться, почему его не притянуло зависимостями. 2. Почему так получилось? noveau загрузился coldplug'ом, заблокировав загрузку проприетарного модуля. Почему не грузился раньше? Ну, видимо вашей карточки не было в списке поддерживаемых VID:PID. В новом ядре добавили. 3. Будет ли мне что то за это? :) Ведь модули зависимые так и не подгрузились. Из тех что помню: drm, video и еще штучки три. Дело было ночью, память уже отказывала. Не загрузились -- значит не нужны ;) -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkuuka$372$1...@dough.gmane.org
Re: не запустились иксы после обновления
On 28.03.2012 16:19, Aleksey Andreev wrote: # see #580894 blacklist nouveau у меня такого нету. Хм, может это, конечно, я сам дописал, но как-то не похоже на меня, чтоб с номером бага ;) -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jkuvvv$edc$1...@dough.gmane.org
Re: как убить transmission-da ?
On 09.03.2012 13:34, -=Devil_InSide=- wrote: а почему попытки убить именно 1300й ? бить всех, бог узнает своих (с) на самом деле отвалились процессы с defunct, а 1300й запуститься не может. kill -9 749 1300 32103 32200 можно несколько раз. Нельзя убить того, кто уже мёртв ;) defunct -- это процессы-зомби, убитые, но ожидающие, когда их reap'нут. А 1300, судя по всему, застрял в TASK_UNINTERRUPTABLE -- в этом состоянии сигналы процессу не доставляются, поэтому kill и не работает. ну ето, как бы, может, и да; но тем не менее, когда прекрасная сборка doublecmd, не рассчитанная на дебиановские glibc умирала, картина была такая ж. пара дефункшенов и один, который непоймичо. и помогало лишь убитие всех. Помогало вам убитие того одного, скорее всего. Никто не запрещает посылать сигналы процессам-зомби, однако это абсолютно бесполезно: все связанные с процессом ресурсы уже освобождены, в том числе адресное пространство и ядерный тред, так что исполнять обработчик сигнала просто некому. Вообще, с самими зомби всё в полном порядке -- это совершенно штатная ситуация, проблема в родительском процессе, не желающем вызвать wait(2) (из-за того, что завис или просто криво написан). В вашем случае вы прибили родительский процесс, осиротевшие зомби были переданы процессу init, а он уже вызвал wait(waitpid). -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jjcn0u$l4t$1...@dough.gmane.org
Re: как убить transmission-da ?
On 09.03.2012 01:58, -=Devil_InSide=- wrote: root@storhost:/mnt# pkill -KILL transmission-da root@storhost:/mnt# ps -A | grep trans 749 ?00:00:01 transmission-da defunct 1300 ?01:42:49 transmission-da 32103 ?00:00:00 transmission-da defunct 32200 ?00:00:01 transmission-da defunct А конкретно kill -KILL 1300 тот же результат дает? Тогда, насколько я представляю себе устройство юниксов, это значит, что застряло оно в ядре, и вопрос надо ставить как выкрутиться из ситуации, когда внутри ядра что-то застряло, и непонятно, когда и как оно в итоге грохнется? И как к тому времени, когда таки грохнется, таки обеспечить возможность перезапустить сервер? Логи соответствующей ругани ядра, если они были, вероятно, уже почистились ротацией, нет? а почему попытки убить именно 1300й ? бить всех, бог узнает своих (с) на самом деле отвалились процессы с defunct, а 1300й запуститься не может. kill -9 749 1300 32103 32200 можно несколько раз. Нельзя убить того, кто уже мёртв ;) defunct -- это процессы-зомби, убитые, но ожидающие, когда их reap'нут. А 1300, судя по всему, застрял в TASK_UNINTERRUPTABLE -- в этом состоянии сигналы процессу не доставляются, поэтому kill и не работает. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jjbaul$3ue$1...@dough.gmane.org
Re: omapfb black screen
On 27.02.2012 07:50, Eugene Prokopiev wrote: Пытаюсь завести Х в Squeeze или Wheezy c ядрами 2.6.32 или 3.2 на OMAP3 Beagle board с драйвером xserver-xorg-video-omapfb или xserver-xorg-video-omap3 и с таким конфигом - http://elinux.org/BeagleBoardDebian#xorg.conf. Во всех случаях после xinit /usr/bin/xterm получаю черный экран, в логе ничего слишком криминального, но на всякий случай его прикладываю. Не будет ли у кого идей насчет лечения? А консолька-то видна на фреймбуфере? Покажите dmesg. Попробуйте xserver-xorg-video-fbdev. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jifkhf$bra$1...@dough.gmane.org
Re: Ядро 3.2.0 из бэкпортов и CVE-2012-0056
On 14.02.2012 16:43, Mikhail A Antonov wrote: Для проверки я пользуюсь тестом на уязвимость, который был описан у redhat: https://bugzilla.redhat.com/attachment.cgi?id=556461 На ядрах от RH оно выдает: write: : Invalid argument not vulnerable а на linux-image-3.2.0-0.bpo.1-amd64 оно дает vulnerable Может ли кто проверить этот тест на ядре из Testing/Unstable? vulnerable, однако эксплоиты, описанные в баге, не работают. Как же может быть vulnerable, если эксплойт не работает? :) RH тест на уязвимость не полный, он проверяет, есть ли в ядре ломающий коммит (как там написано в начале), но не проверяет, есть ли фиксящий. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jhe15p$m3f$1...@dough.gmane.org
Re: Настройка pppd
On 22.01.2012 20:42, Dmitrii Kashin wrote: Что мне больше всего не нравится, так это то, что я в принципе не очень понимаю, что я делаю. Направьте в нужную сторону, пожалуйста. Я вот тоже не понимаю. Как Вы собираетесь PPP на удалённый роутер поднимать, если Вам интернет отключили? Есть отдельный канал до него? Dial-up? -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jfhtpo$bq7$1...@dough.gmane.org
Re: AMD APU
On 27.12.2011 22:23, Alexander Konotop wrote: Если никто подобным железом не пользуется - посоветуйте хоть шо делать, куда кричать (на github думал, но они вроде оттуда снова сваливают), по английски если шо умею - не вопрос. Мог бы и просто подождать, на самолёт я не опаздываю, но если могу чем-то помочь как владелец данного железа - то почему бы и нет? Попробуйте написать в рассылку dri-de...@lists.freedesktop.org, изложив все подробости. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jddlbn$n2a$1...@dough.gmane.org
Re: broadcom 5.100.82.112 + ядро 3.1.5
On 27.12.2011 14:21, Pavel Vorob`ev wrote: 2. странное поведение - при перезагрузки с ядра i386 на amd64 постоянно чекается фс root, если перезагружаешься наоборот то чеканья не происходит (при повторной перезагрузке с amd64 - amd64 уже фс root не проверяет) Хм. Sounds like bug. ФС-то какая? / ext3 /home ext4 Ну чекается-то /, то есть ext3? Может он тупо не размонтируется при перезагрузке? (хотя это тоже баг) Если перейти в single, перемонтировать в ro, а потом уже перегружаться -- воспроизводится? Надо будет на праздниках попробовать в виртуалках, если воспроизведётся -- половить... 3. чисто субъективно ядро amd64 грузится быстрее в 32 битном окружении чем родное ядро о_О Ядро грузится до юзерленда. Это у вас, видимо, 64-бит юзерленд дольше 32-х битного грузится. возможно не так объяснил, у меня стоит дебиан тестинг i386 с самого начала (на ноутбуке с процессором i3 и памяти 3 Г), пытаюсь баловаться с ядрами - изначально стояло i686-pae (2.6.38, 2.6.39, 3.0.0, 3.1.5), сейчас попробовал поставить amd64 (3.1.5), и вот машинка с ядром amd64 в 32 битном окружении чисто субъективно грузится быстрее, включая даже рабочий стол xfce возможно это не так =) меряю на глаз А, понял. То есть один и тот же 32-бит юзерленд с 64-бит ядром грузится быстрее, чем с 32-бит? Странно конечно, я бы ожидал одинакового времени, тем более на глаз :) -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jddlns$ouj$1...@dough.gmane.org
Re: broadcom 5.100.82.112 + ядро 3.1.5
pavka vorobev2002 at mail.ru writes: 1. свежий пакет собирается без нареканий, но с ядром 3.1.5 wl не работает =( Ничего сказать не могу, железа такого нет и не было... Если есть время и желание, можете с бисектом поиграться. 2. странное поведение - при перезагрузки с ядра i386 на amd64 постоянно чекается фс root, если перезагружаешься наоборот то чеканья не происходит (при повторной перезагрузке с amd64 - amd64 уже фс root не проверяет) Хм. Sounds like bug. ФС-то какая? 3. чисто субъективно ядро amd64 грузится быстрее в 32 битном окружении чем родное ядро о_О Ядро грузится до юзерленда. Это у вас, видимо, 64-бит юзерленд дольше 32-х битного грузится. -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20111226t222318-...@post.gmane.org
Re: broadcom 5.100.82.112 + ядро 3.1.5
pavka vorobev2002 at mail.ru writes: LD [M] /usr/src/modules/broadcom-sta/i386/wl.o ld: Relocatable linking with relocations from format elf32-i386 (/usr/src/modules/broadcom-sta/i386/lib/wlc_hybrid.o_shipped) to format elf64-x86-64 (/usr/src/modules/broadcom-sta/i386/wl.o) is not supported Он пытается собрать 32-битный драйвер, а надо 64-битный. возможно ли собрать драйвер broadcom для 64 ядра в 32-битном окружении ? Это баг пакета, забыли про вариант 64-бит ядро, 32-бит юзерленд. Самое начало debian/rules: DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) ifeq ($(DEB_HOST_ARCH),amd64) SOURCEDIR=$(CURDIR)/amd64 else # i386 SOURCEDIR=$(CURDIR)/i386 Он смотрит на DEB_HOST_ARCH, а надо на архитектуру ядра (uname -m, например). -- Илья -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20111225t02301...@post.gmane.org
