ядро 4.4.0 не перестает радовать :)

Что-то сломанное в поддержке >4Gb RAM в i386 - хрен с ним!

Но зачем ломать мост ?!

Есть замечательная фича «brctl setageing brX 0» превращающая свитч в хаб.

эти гады запретили нам ставить время меньше 10 секунд!

brctl судя по всему тоже сломан. Не ожидает он отсутствия /sys/class/net/brX/ageing_time который уже давно зачем-то переехал в /sys/class/net/br10/bridge/ageing_time. В 4.0/4.1 он еще работает через SIOCDEVPRIVATE, а в 4.4 - хрен!

А пропихивание в netdev патчей - еще то развлечение...

Есть тестовая система на базе слаки 14.х

Собрал на для ознакомления сначала 4.3.1 (потом 4.4.0rc4)

Не грузится, говорит нет у тебя корневого раздела! Не верю ему, запускаю

# vgscan                                                       
  Reading all physical volumes.  This may take a while...      
  No volume groups found                                     
# vgscan                                                    
  Reading all physical volumes.  This may take a while...
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum                    
# vgscan                                                       
  Reading all physical volumes.  This may take a while...    
  No volume groups found                                     
# vgscan                                                       
  Reading all physical volumes.  This may take a while...      
  Found volume group "V0" using metadata type lvm2             
  WARNING: This metadata update is NOT backed up
# pvscan
umovestr: Input/output error                                 
  /dev/sda2: Checksum error                                  
  /dev/sdb2: Checksum error                                  
  /dev/sda2: Checksum error                                  
  /dev/sda2: Checksum error                                  
  /dev/sdb2: Checksum error                                  
  /dev/sdb2: Checksum error                                  
  PV /dev/sda2         lvm2 [461.76 GB]                      
  PV /dev/sdb2         lvm2 [476.69 GB]                      
  Total: 2 [938.45 GB] / in use: 0 [0   ] / in no VG: 2 [938.45 GB]

«vgchange -ay» срабатывает на 3-5 раз, даже rootfs можно смонтировать после этого, но все равно не загружается из-за ошибок запуска init.

Весь что нужно для старта вкомпилено в ядро. С этим же initrd грузятся ядра от 3.4 до 4.1

google про все эти ошибки отсылает в 2007-2009 год с проблемами у древних ядер или описывает проблемы с поврежденными данными.

Есть предположения из-за чего эта фигня происходит?

Как правильно поступить в случае

All checks have failed

1 failing check

continuous-integration/travis-ci/pr — The Travis CI build failed

Отменить реквест, исправить и сделать новый реквест или закоммитить исправление в ветку?

не прошло и 10 лет как в новых ядрах (3.10.93, 3.14.57, 4.1.13, 4.2.6) появилось

mm: make sendfile(2) killable

Видать кого-то достало :)

Есть keepalived c vrrp

Хочу часть заданий хрона выполнять только если хост мастер, а другую часть заданий только в режиме бекап.

Запускать каждое задание через проверяющий скрипт - крайний случай. Генерировать crontab - не предлагать!

Религия позволяет менять crond и собирать из исходников.

Обнаружил, что исчез com-порт, а вместе с ним и apc-шный ups. Год назад в 3.14 эту хрень ( acpi pnp ) уже чинили. Сейчас тоже самое :(

Погуглив «serial 00:06: disabled» понял, что я не один такой.

Чудаки в asus прописали в acpi com-порт с нулевой длиной области портов и ядро считает, что там никого нет :(

Ацкий хак решил проблему.

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index f1c966e..5138247 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -140,6 +140,9 @@ static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
 static void acpi_dev_get_ioresource(struct resource *res, u64 start, u64 len,
                                    u8 io_decode)
 {
+       // FIXME: buggy ACPI bios
+       if((start == 0x3f8 || start == 0x2f8) && !len)
+               len = 8;
        res->start = start;
        res->end = start + len - 1;
        acpi_dev_ioresource_flags(res, len, io_decode);

Может есть более элегантный вариант решения?

Мать asus P8Z77WS. Биос-а новее 2013-го года не нашел :( Ссылке на асусевом сайте ведут на 404.

Продолжение длинной истории

Оригинальный рецепт для тех кто умеет самостоятельно прикладывать патчи и собирать ядра/софт.

Отдельно и более подробно для Ubuntu и CentOS от as_lan

На большом потоке ( ~300мбит/с ) cо всеми протоколами используется примерно 50-60% одного ядра Intel(R) Xeon(R) CPU E31230@3.20GHz. Если поток больше или процессор слабее, то включаем RPS или используем сетевые карты с multi-queue и irq-affinity. У меня оно тестируется на трафике до 400Мбит/~100к conntrack/~90kpps для x86 и x86_64.

В понятиях netfilter оно умеет проверять пакеты на принадлежность к протоколам (match) и ставить на пакеты метки/классы (target) по аналогии с MARK & CLASSIFY. Есть поддержка NET_NS и IPv6.

Требуется много памяти. На каждое соединение расходуется примерно ~850+280*0.7 байт. Этот объем варьируется в зависимости от 32/64 бита, с/без IPv6.

Исходники теперь есть на https://github.com/vel21ripn/nDPI/tree/netfilter

От основной ветки на github/ntop/nDPI/1.7-stable отличается меньшим потреблением памяти и «улучшением» определения bittorrent.

из-за значительных изменений пока не ясно, можно ли будет включить в оригинальный проект.

Есть живая тема nDPI как замена l7filter

Почему она в архив ушла?

Есть кто успешно его использует как кеширующий прокси хотя бы на 300-500 клиентов?

На хабре не так давно была статейка про использование сквида 3.5. Потыкав его тут же нашел баг в ftp. Что-то они там такое адское замутили с ftp, аж страшно смотреть (в 3.5 ftp переписан полностью).

Прекрасный пример СПО в действии - 4 дня переписки в squid-dev и багу в ftp пофиксили ( на третий раз они согласились с моим патчем ). Разработчик живет в Новой Зеландии с GMT+13 :) так что переписка была не очень оживленной.

две машинки с интегрированными 82574L после обновления ядра не проработали и 30 минут - умерли. У одной на консоле было несколько мессаг про «disable irq #XXX» от сетевух и мертвый вис, вторая успела сказать oops с чем-то про irqpoll.

До этого одна была на 3.18.21, другая на 4.0.8 и работали без проблем. Активно используется jumbo-фреймы.

Гугление отсылает к событиям 5-летней давности.

Может заменить драйвер на интеловский e1000e с sourceforge? Помнится от какой-то проблемы с ванильными драйверами e1000e однажды он помог, но потом и в ядре его починили и ставить интеловский уже было не нужно.

Вроде как 3.5 объявлена stable, дошли до 3.5.9, а ftp не может отдать сообщение об отсутствии файла. Дожили :(

PS в bugzill-е оно уже есть.

Обнаружил, что в 3.3.15 странно работает поиск русских слов, точнее он не находит некоторые слова.

слово «профессионального» он не находит, но при этом слово «профессиональный» находится замечательно.

база на постгресе (тип blob), поиск по дампу баз показывает, что в body слово встречается.

Есть какие-нибудь рецепты борьбы с такими проблемами или не протухшая howto?

Вчера обновился список релизов.

Greg Kroah-Hartman ломает стереотипы - 4.1 longterm! Что-то не помню, чтоб ветки с нечетными номерами были longterm.

Есть adaptec ASR5805

Хочу заменить в RAID5 4 диска ( по-очереди ) с 1ТБ на 2ТБ.

Вопрос: после ребилда последнего диска размер тома автоматически измениться?

после обновления FF (а может и чуть раньше) ТОЛЬКО на роликах с coub.com нет звука, о чем говорит крестик на динамике. Если его пытаешься включить, то ничего не происходит.

Профиль новый создавал, выносил все плагины - не помогло. Гугль полезного не подсказал.

Как починить ? Кто виноват?

EOL пришел на 4.0.9, видать совсем скоро 4.2 придет.

Похоронили бы лучше все до 3.10...

Есть куча типов ключей для хоста rsa1,dsa,rsa,ecdsa,ed25519.

Может есть смысл сократить до какого-то одного rsa ? Не хочется пихать в dns кучу sshfp.

Старинных/тормозных клиентов нет. Кто обломается без rsa1,dsa или новомодных ecdsa,ed25519. На работоспособность клиентских ключей этих типов оно влияет?

Хочу странного: каталог видимый из контейнеров в RO, но доступный с основной системы на RW и не через сеть.

«mount --bind» не подходит, т.к. сказав в контейнере «mount ... remount,rw» оно становится rw.

Может есть способ запретить в контейнере mount (CAP_SYS_ADMIN запрещать нельзя)? И без SELinux...

PS ядра >= 3.18

На опеннете появлся анонс про расширение адресного пространства FAN созданный Марком Шаттлворт

идея описана хорошо, но вот как оно реализовано? Сомневаюсь, что было написано что-то ядерно.

В принципе задача решается с помощью iptables + ivs + ovs vlan/vxlan

В lxc очень не хватает интеграции с ivs. Хорошо бы сделать при запуске контейнера маппинг некоторого внешнего ip:port в ip:port контейнера и натить все коннекты из контейнера неким внешним адресом.

Перемещено leave из talks

Одна и та же версия на х86

Name:   ovs-vswitchd
VmPeak:    56636 kB
VmSize:    52540 kB
VmHWM:      6500 kB
VmRSS:      3888 kB
VmData:    46644 kB

на x86_64 с более простой конфигурацией

Name:   ovs-vswitchd
VmPeak:   751252 kB
VmSize:   686128 kB
VmHWM:      6492 kB
VmRSS:      6468 kB
VmData:   664544 kB

просто запущеный ovs-vswitchd на x86_64 сразу 300М

Если разница была бы в 2-3 раза, я бы не удивился, но в 12 раз это овердофига!

Есть идеи? Или спасение утопающих дело рук самих утопающих?