Связанный сетевой интерфейс не доступен после перезагрузки

Взгляд luks/dm-crypt. Можно использовать ssh-закрытый-ключ в качестве ключа шифрования при помощи подходящего варианта.

Обновление: шифрование В качестве примера с помощью LUKS с блочным устройством LV (тест LV в системе VG):

KEY=/home/youraccount/.ssh/id_dsa
DEVICE=/dev/system/test
cryptsetup luksFormat $DEVICE $KEY
cryptsetup luksOpen $DEVICE test_crypt --key-file $KEY

Это должно gnerate блочное устройство/dev/mapper/test_crypt, который можно использовать, чтобы хранить данные на (после форматирования его с файловой системой по Вашему выбору).

Избавиться от него, umount он, и использование cryptsetup luksClose test_crypt.

6
28.01.2013, 22:41
1 ответ

modprobe.d

На инструкции относительно этого сайта RHEL6 сделал Вы создаете файл /etc/modprobe.d/bonding.conf и добавьте Ваш bondm устройство в тот файл?

alias bondm bonding

пропавшие без вести ТИПА для 2-го NIC

Также я не то, если это имеет значение, но Ваше eth2 устройство пропускает эту строку:

TYPE=Ethernet

Отключенный NetworkManager?

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

% chkconfig off NetworkManager

UDEV

Вы используете udev на этих полях? Я столкнулся с проблемами, где udev заполнил файл здесь, /etc/udev/rules.d/70-persistent-net.rules. Этот файл имел избыточные записи для NICs на полях, и я должен был вручную отредактировать этот файл. Мой похож на это:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# net device () (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="54:52:00:ff:ff:f5", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

UDEV присваивает устройства на основе MAC-адресов, можно вынудить это присвоиться на основе позиции, которую NIC занимает в шине PCI.

Можно использовать эту команду для определения информации о PCI NIC:

% for i in /sys/class/net/*;do printf "device: %6s - %s\n" `basename $i` `readlink -f $i`;done
device:    br0 - /sys/devices/virtual/net/br0
device:   eth0 - /sys/devices/pci0000:00/0000:00:1c.5/0000:09:00.0/net/eth0
device:   eth1 - /sys/devices/pci0000:00/0000:00:2d.5/0000:03:00.0/net/eth1
device:     lo - /sys/devices/virtual/net/lo

На основе этого вывода Вам был бы нужен к заполненному Ваш собственный файл правил udev:

% cat > /etc/udev/rules.d/70-persistent-net.rules << EOF
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:1c.5", \
    NAME="eth0"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:2d.5", \
    NAME="eth1"
EOF

Примечание: Также удостоверьтесь, что Вы удаляете/запрещаете любое существование ранее udev файл правил, который может уже пытаться установить Ваш NICs.

Ошибка с CentOS 6.3

Я столкнулся с этой ошибкой на системе отслеживания ошибок CentOS. Информация о версии для 6,3 списков это также.

Выборка из информации о версии Centos 6.3:

Кажется, существует проблема при использовании 802.1q VLANing на связанном (802.3ad) интерфейсы и определенный NICs. Посмотрите эту восходящую запись Bugzilla и эту запись CentOS bugzilla для деталей. CentOS-плюс Ядро, выпущенное с 6,3, содержит патч для устранения этой проблемы. При запуске с ядра устраняются 2.6.32-279.2.1 этих проблемы.

Эта проблема suspicously походит на тот, с которым Вы имели дело. Какое ядро Вы выполняете? (uname -a).

3
27.01.2020, 20:30
  • 1
    Да, строка псевдонима присутствует в /etc/modprobe.d/bonding.conf. Я не заметил различия в eth2 файле. Я также сомневаюсь, что это оказывает любое влияние, но они, вероятно, должны быть тем же. Я попытаюсь сделать их тем же и перетестом сегодня или завтра. –  wolfcastle 31.01.2013, 16:59
  • 2
    , который я повторно протестировал путем удаления BOOTPROTO и строк ТИПА от ifcfg-eth0 (так, чтобы он соответствовал eth2 и всем другим интерфейсам) и все еще получил ту же проблему. –  wolfcastle 06.02.2013, 00:48
  • 3
    спасибо за обновление. Та ошибка действительно звучит очень похожей на то, что я вижу здесь. Я попытаюсь разыскать версию SL патча и проверить его. Так как щедрость истечет, прежде чем я получу шанс проверить ее, у меня есть предоставление ее Вам теперь для всей Вашей справки. спасибо –  wolfcastle 06.02.2013, 16:50
  • 4
    @slm хорошая udev информация и разыскивание связанной с потенциалом ошибки!! 1 спасибо всем –  John Siu 07.02.2013, 04:39
  • 5
    Для записи, я встречался с ошибкой CentOS 6.3. После перемещения в 6,4, когда это было выпущено (который включал фиксацию @sim упомянутый), ушла проблема. –  wolfcastle 08.11.2013, 18:20

Теги

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