Обновления Bke CIFS / SMB Mounts в 16.04

На этой неделе я получил apt-get обновление наших систем Ubuntu. Теперь сетевые адаптеры разбиваются на наши системы 16,0 раз каждые 5-10 минут. Мы получаем такие ошибки:

ls: cannot access '/mnt/server_a/dir_a': Host is down

Хост определенно не работает, я одновременно обновил систему из 14.04 и у них нет никаких проблем. Это похоже на перезагрузку или umount & amp; & amp; крепление сломанного крепления фиксирует его на несколько минут, затем он снова ломается (даже если система полностью не работает). Строки в /etc/fstab:

//server_a/dir_a /mnt/server_a/dir_a cifs uid=my_user,soft,rw,exec,credentials=/root/creds/mnt_server_a,file_mode=0777,dir_mode=0777,iocharset=utf8,sec=ntlm 0 0 //server_b/dir_b /mnt/server_b/dir_b cifs uid=my_user,soft,rw,exec,credentials=/root/creds/mnt_server_b,file_mode=0777,dir_mode=0777,iocharset=utf8,sec=ntlm 0 0

Кэш-файл для server_a является локальным пользователем (две строки: «username = foo» и «password = bar»).

Похоже, что обновление было одним из них (из /var/apt/install/history.log):

update-manager-core:amd64 (1:16.04.5, 1:16.04.6) libapt-inst2.0:amd64 (1.2.19, 1.2.20) update-notifier-common:amd64 (3.168.3, 3.168.4) libgtk-3-common:amd64 (3.18.9-1ubuntu3.2, 3.18.9-1ubuntu3.3) apt:amd64 (1.2.19, 1.2.20) libgtk-3-0:amd64 (3.18.9-1ubuntu3.2, 3.18.9-1ubuntu3.3) snapd:amd64 (2.22.6, 2.24.1) snap-confine:amd64 (2.22.6, 2.24.1) dnsmasq-base:amd64 (2.75-1ubuntu0.16.04.1, 2.75-1ubuntu0.16.04.2) grub-legacy-ec2:amd64 (0.7.9-48-g1c795b9-0ubuntu1~16.04.1, 0.7.9-90-g61eb03fe-0ubuntu1~16.04.1) libapt-pkg5.0:amd64 (1.2.19, 1.2.20) cifs-utils:amd64 (2:6.4-1ubuntu1, 2:6.4-1ubuntu1.1) ntp:amd64 (1:4.2.8p4+dfsg-3ubuntu5.3, 1:4.2.8p4+dfsg-3ubuntu5.4) libgtk-3-bin:amd64 (3.18.9-1ubuntu3.2, 3.18.9-1ubuntu3.3) python3-update-manager:amd64 (1:16.04.5, 1:16.04.6) ubuntu-core-launcher:amd64 (2.22.6, 2.24.1) apt-utils:amd64 (1.2.19, 1.2.20) pciutils:amd64 (1:3.3.1-1.1ubuntu1, 1:3.3.1-1.1ubuntu1.1) apt-transport-https:amd64 (1.2.19, 1.2.20) libpci3:amd64 (1:3.3.1-1.1ubuntu1, 1:3.3.1-1.1ubuntu1.1)

Я попытался вернуться, но apt-get только позволил мне понизить список, указанный ниже, и никто из них не исправил проблему (хотя я действительно подозревал, что cifs или dnsmasq могут быть виноваты):

cifs -utils: amd64 = 2: 6.4-1ubuntu1 dnsmasq-base: amd64 = 2.75-1ubuntu0.16.04.1 ntp: amd64 = 1: 4.2.8p4 + dfsg-3ubuntu5.3 pciutils: amd64 = 1: 3.3.1-1.1ubuntu1 libpci3: amd64 = 1: 3.3.1-1.1ubuntu1

Есть ли у кого-нибудь идеи, как заставить мои монтировки работать снова? Я серьезно отчаялся, это шоу-стоппер для нас, если я не смогу заставить его работать в ближайшие несколько дней, нам придется переключить всю нашу инфраструктуру обратно на Ubuntu 14.04.

4
задан 30 April 2017 в 12:49

12 ответов

У меня была такая же проблема, но мне помогает удалить последнее ядро. Я сделал это так:

проверьте, что есть второе старое ядро: dpkg --list | grep linux-image, если есть более старый, удалить новейший: apt удалить --purge 4.4.0-75- * update grub: update-grub

Теперь ему нужна перезагрузка, и после этого

Если вам нужно позже новое ядро, вы должны установить их с помощью: apt install linux-generic

Еще одно решение - добавить vers=3.0 в инструкцию fstab mount.

2
ответ дан 22 May 2018 в 23:06
  • 1
    Интересно! Похоже, обновления ядра происходят автоматически, эта проблема, вероятно, поразила бы меня в следующий раз, когда я перезапустил эти системы. Когда я пил это в пятницу, пытаясь определить частоту неудачных соединений, я заметил, что активное использование mounts, казалось, предотвращало состояние отказа. Я покинул эти системы, работающие в выходные, со следующей строкой в ​​их кронтабах, и они, похоже, работают счастливо! */1 * * * * ls /mnt/* Моя кишка говорит мне, что было бы предпочтительнее оставить эту работу на месте, чтобы получить последние обновления для системы безопасности. Есть предположения? – EJP 1 May 2017 в 20:18
  • 2
    Обновления ядра устанавливаются только apt(-get) dist-upgrade. У вас также установлено последнее ядро ​​(4.4.0-75)? Для cifs-utils они добавляют только pam_cifscreds , поэтому никаких исправлений, связанных с безопасностью, и обновление ядра, я думаю, также не так важно, но вы можете взглянуть на журнал изменений. Я открываю билет с ошибкой, здесь вы можете видеть, когда они исправляют его: bugtracker – jb_alvarado 1 May 2017 в 20:48
  • 3
    Ах, я вижу, вы используете unattended-upgrade . Мне было интересно, как вы автоматически устанавливаете обновления ядра :). – jb_alvarado 1 May 2017 в 20:59
  • 4
    Глядя на history.log, я вижу, что unattended-upgrade запущен, и он установил новое ядро. Это набросило меня с 4.4.0.72.78 до 4.4.0.75.81 25 апреля. Я отключил работу cron на одной из наших систем и наблюдаю за ней, я хотел посмотреть, не получилось ли что-то интересное в журналах ядра (но сегодня никаких сбоев нет). Как только он начнет сбой, и я получу журналы, я попробую использовать пакеты hold. – EJP 1 May 2017 в 21:03
  • 5
    Да, я не уверен, что было бы разумно иметь автоматические обновления, включенные в этих системах, я не уверен, почему это было сделано. Думаю, после этого опыта мы это отключим! – EJP 1 May 2017 в 21:04

У меня была такая же проблема, но мне помогает удалить последнее ядро. Я сделал это так:

проверьте, что есть второе старое ядро: dpkg --list | grep linux-image, если есть более старый, удалить новейший: apt удалить --purge 4.4.0-75- * update grub: update-grub

Теперь ему нужна перезагрузка, и после этого

Если вам нужно позже новое ядро, вы должны установить их с помощью: apt install linux-generic

Еще одно решение - добавить vers=3.0 в инструкцию fstab mount.

2
ответ дан 18 July 2018 в 14:05

У меня была такая же проблема, но мне помогает удалить последнее ядро. Я сделал это так:

проверьте, что есть второе старое ядро: dpkg --list | grep linux-image, если есть более старый, удалить новейший: apt удалить --purge 4.4.0-75- * update grub: update-grub

Теперь ему нужна перезагрузка, и после этого

Если вам нужно позже новое ядро, вы должны установить их с помощью: apt install linux-generic

Еще одно решение - добавить vers=3.0 в инструкцию fstab mount.

2
ответ дан 24 July 2018 в 20:19

У меня была такая же проблема, но мне помогает удалить последнее ядро. Я сделал это так:

проверьте, что есть второе старое ядро: dpkg --list | grep linux-image, если есть более старый, удалить новейший: apt удалить --purge 4.4.0-75- * update grub: update-grub

Теперь ему нужна перезагрузка, и после этого

Если вам нужно позже новое ядро, вы должны установить их с помощью: apt install linux-generic

Еще одно решение - добавить vers=3.0 в инструкцию fstab mount.

2
ответ дан 31 July 2018 в 13:00

У меня была точно такая же проблема - в течение последних 3 или 4 дней мой медиа-сервер Plex в качестве виртуальной машины ESXi потерял бы свое постоянное монтирование SMB (определенное в fstab) с безпорогового сервера Freenas, а «Host» отсутствует сообщение об ошибке; даже umount не работает, указывая, что цель занята.

Возвращение к 4.4.0-72-generic просто сделало трюк.

0
ответ дан 22 May 2018 в 23:06

Похоже, что это ошибка в ядре 4.4.0. Какое-то состояние гонки каждые 15 минут вызывает наводнение и отключается.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856843

I повышен до 4.9.30, и, похоже, он разрешил проблемы. Следующие шаги были следующими:

Загрузите все файлы

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900_4.9.0-040900.201612111631_all.deb

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.30/linux-headers-4.9.30-040930_4.9.30-040930.201705251131_all.deb

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb

Kernel debug. Затем установите с помощью:

sudo dpkg -i *.deb

Затем перезагрузитесь в новое ядро. Подтвердите с помощью:

uname -r

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

0
ответ дан 22 May 2018 в 23:06

Похоже, что это ошибка в ядре 4.4.0. Какое-то состояние гонки каждые 15 минут вызывает наводнение и отключается.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856843

I повышен до 4.9.30, и, похоже, он разрешил проблемы. Следующие шаги были следующими:

Загрузите все файлы

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900_4.9.0-040900.201612111631_all.deb wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.30/linux-headers-4.9.30-040930_4.9.30-040930.201705251131_all.deb wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb

Kernel debug. Затем установите с помощью:

sudo dpkg -i *.deb

Затем перезагрузитесь в новое ядро. Подтвердите с помощью:

uname -r

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

0
ответ дан 18 July 2018 в 14:05

У меня была точно такая же проблема - в течение последних 3 или 4 дней мой медиа-сервер Plex в качестве виртуальной машины ESXi потерял бы свое постоянное монтирование SMB (определенное в fstab) с безпорогового сервера Freenas, а «Host» отсутствует сообщение об ошибке; даже umount не работает, указывая, что цель занята.

Возвращение к 4.4.0-72-generic просто сделало трюк.

0
ответ дан 18 July 2018 в 14:05

Похоже, что это ошибка в ядре 4.4.0. Какое-то состояние гонки каждые 15 минут вызывает наводнение и отключается.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856843

I повышен до 4.9.30, и, похоже, он разрешил проблемы. Следующие шаги были следующими:

Загрузите все файлы

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900_4.9.0-040900.201612111631_all.deb wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.30/linux-headers-4.9.30-040930_4.9.30-040930.201705251131_all.deb wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb

Kernel debug. Затем установите с помощью:

sudo dpkg -i *.deb

Затем перезагрузитесь в новое ядро. Подтвердите с помощью:

uname -r

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

0
ответ дан 24 July 2018 в 20:19

У меня была точно такая же проблема - в течение последних 3 или 4 дней мой медиа-сервер Plex в качестве виртуальной машины ESXi потерял бы свое постоянное монтирование SMB (определенное в fstab) с безпорогового сервера Freenas, а «Host» отсутствует сообщение об ошибке; даже umount не работает, указывая, что цель занята.

Возвращение к 4.4.0-72-generic просто сделало трюк.

0
ответ дан 24 July 2018 в 20:19

Похоже, что это ошибка в ядре 4.4.0. Какое-то состояние гонки каждые 15 минут вызывает наводнение и отключается.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856843

I повышен до 4.9.30, и, похоже, он разрешил проблемы. Следующие шаги были следующими:

Загрузите все файлы

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900_4.9.0-040900.201612111631_all.deb wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.30/linux-headers-4.9.30-040930_4.9.30-040930.201705251131_all.deb wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb

Kernel debug. Затем установите с помощью:

sudo dpkg -i *.deb

Затем перезагрузитесь в новое ядро. Подтвердите с помощью:

uname -r

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

0
ответ дан 31 July 2018 в 13:00

У меня была точно такая же проблема - в течение последних 3 или 4 дней мой медиа-сервер Plex в качестве виртуальной машины ESXi потерял бы свое постоянное монтирование SMB (определенное в fstab) с безпорогового сервера Freenas, а «Host» отсутствует сообщение об ошибке; даже umount не работает, указывая, что цель занята.

Возвращение к 4.4.0-72-generic просто сделало трюк.

0
ответ дан 31 July 2018 в 13:00

Другие вопросы по тегам:

Похожие вопросы: