Проблема: зависание загрузки Ubuntu после обновления с сообщением EFI stub

Симптомы

После выполнения apt upgrade (об этом я вспомнил уже после того как разобарлся с пробелмой) и перезагрузки система перестала загружаться. На экране последнее сообщение:

EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path

После этого — полное зависание. GRUB работает, выбор ядра доступен. Ошибок ядра (kernel panic, Oops) нет.

Окружение

• ОС: Ubuntu (ядро 6.8.0-111-generic)
• Видеокарта: NVIDIA RTX 5060 Ti (архитектура Blackwell)
• Дисковая подсистема: программный RAID1 (mdadm)

Диагностика

1. Аппаратная часть исправна: диски определяются в BIOS, SMART — PASSED, RAID-суперблоки на месте (mdadm --examine показал корректные UUID).
2. RAID собирается: mdadm --assemble --scan активен, /proc/mdstat — массив в состоянии [UU]. Проверял на соседней машине.
3. LiveUSB с Ubuntu/Debian не загружается — аналогичное зависание на той же строчке.
4. UEFI Shell работает, загрузчик GRUB физически присутствует на EFI-разделе.

Решение

Загрузка с параметром ядра:

nomodeset

После добавления этого параметра в строку загрузки GRUB система стартует штатно. Механизм nomodeset отключает Kernel Mode Setting (KMS), предотвращая инициализацию DRM/драйвера видеокарты на раннем этапе загрузки.

Причина

Ядро 6.8.0 не имеет полной поддержки видеокарт на базе архитектуры Blackwell (RTX 5060 Ti вышла позже релиза ядра). При попытке инициализации видеорежима через nouveau (или фолбэк-механизмы) происходит зависание на этапе настройки дисплейного контроллера.

nomodeset исключает этот этап, оставляя управление видеорежимом за прошивкой UEFI. Система загружается, но без ускорения графики — что для сервера в большинстве случаев некритично.

Постоянное применение

1
2

echo 'GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"' | sudo tee /etc/default/grub
sudo update-grub

Корректное решение (убрать nomodeset)

1. Установить проприетарный драйвер NVIDIA версии 570 или новее.
2. Или обновить ядро до версии 6.12+, где поддержка Blackwell добавлена в nouveau.

Вывод

Проблема не в дисках, не в RAID и не в памяти. Причина — отсутствие поддержки современной видеокарты в текущей версии ядра. Параметр nomodeset — рабочий временный обход, позволяющий сохранить функциональность системы до установки актуального драйвера или ядра.

Дополнение

Я думал переустановить систему, залив Debian. Но после выбора параметра установки в загрузочном меню, я опять получал зависшую систему. Решилась пробелма что сложнее, одного параметра nomodeset не хватило, БЯМ подсказала расширенную версию:

Вот перечень параметров, которые вы должны добавить все вместе:

nomodeset acpi=off noapic nolapic pci=nomsi pci=nommconf console=tty0 console=ttyS0,115200

Как это ввести:

1. Загрузитесь с Ventoy, выберите Debian.
2. Нажмите e для редактирования.
3. Найдите строку с linux.
4. Удалите всё содержимое после --- (или в конце строки) и вставьте туда эту строку.
5. Нажмите Ctrl+X.

Что эти флаги делают:

• acpi=off noapic nolapic: Отключают продвинутое управление питанием и прерываниями (часто выручает на серверном железе).
• pci=nomsi pci=nommconf: Отключают альтернативные методы обработки прерываний PCIe.
• console=tty0 console=ttyS0: Говорят ядру дублировать вывод на обычный экран и на «виртуальный последовательный порт» — это часто сдвигает процесс с мертвой точки

Расскажу про то как один параметр в кофиге Wireguard причинил мне опыт по разбору половины сетевых настроек Ubuntu. Один с виду безобидный параметр… IaC блин нужен обязательно. Я просто забыл что и для чего менял, а потом уже поздно было вспоминать.

Симптомы: тишина в эфире и гора dropped пакетов

Всё началось с того, полсе смерти системного диска в моем домашнем сервере, я перестал крутить его 24/7 и набегами по выходным конифгурировал его, пытаясь вернуть привычный набор сервисом. И вот однажды включаю я сервер, а у меня проблема с системным резолвом DNS. Так-то напрямую nslookup ya.ru 8.8.8.8 выдает всё нормально. но система ни в какую не хочет резолвить адреса. Так-то я забыл, что неделей ранее я настраивал Wireguard со своими VPS, и что именно после настройки Wireguard сервер потерял доступ к локальной сети и интернету. начал ковырять, ИИшка подсказала что на Ubuntu надо netplan копать, начал фигачить yamlики, тут время вышло и я еще на неделю забросил комп. И вот вчера, сейчас далеко за полночь, я его включил и опять начал разбираться, естественно забыл не только то что я две недели назад делал, но и то чем неделю назад занимался. И вот картинка, сервер загрузился, подозрительно долго грузился кстати, но по сети недоступен.

Первая диагностика через ip -s link show показала тревожную картину на интерфейсе eno1:

• RX: 53 000+ пакетов принято.
• Dropped: 21 000+ пакетов отброшено.
• TX: Всего 40 пакетов отправлено.

Команда ip route show выводила только маршрут для интерфейса wg0. Маршрута по умолчанию через физический интерфейс не было. Система «не видела» шлюза.

Команда ip a показала, что на всех интерфейсах, кроме loopback, ip-адреса отсутствуют.

Попытки перезапустить службы или применить конфигурацию через sudo netplan apply не давали результата. Интерфейс зависал в состоянии configuring, а адрес не присваивался.

Расследование: кто виноват?

1. Конфликт маршрутизации

Первоначальная гипотеза была в том, что WireGuard перехватывает весь трафик. Однако в конфиге wg0.conf параметр AllowedIPs был ограничен подсетью туннеля (10.8.0.0/24). Он не должен был блокировать локальную сеть.

Проблема оказалась глубже: отсутствие маршрута по умолчанию для eno1 означало, что ядро просто не знало, куда девать исходящие пакеты, кроме как в туннель (если бы он был активен) или в никуда.

2. Почему DHCP молчал?

Ubuntu 24.04 использует стек systemd-networkd для управления сетью на серверных сборках. Конфигурация задается через Netplan (YAML-файлы).

Проверка статуса показала:

1
2

networkctl status eno1
State: routable (configuring)

Статус configuring в сочетании с routable — это классический признак того, что демон ждет завершения какой-то операции. В логах journalctl -u systemd-networkd не было ошибок получения адреса IPv4, зато постоянно терялась аренда IPv6 (DHCPv6 lease lost).

Оказалось, что systemd-networkd по умолчанию пытается настроить и IPv4, и IPv6. Если сервер DHCPv6 не отвечает или есть проблемы с Router Advertisements (RA), демон может зависнуть в ожидании, блокируя переход интерфейса в полностью рабочее состояние для IPv4.

3. Долгая загрузка

При перезагрузке я заметил, что система висит на этапе Job systemd-networkd-wait-online.service. Однако служба wait-online держала систему, пока сеть не поднимется. Поскольку сеть не могла подняться из-за зависшего DHCP-клиента, загрузка затягивалась.

Решение: поэтапный демонтаж проблем

Шаг 1. Отключение ожидания сети

Чтобы система загружалась быстро, даже если сеть сбоит, отключил службу ожидания:

1
2

sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl mask systemd-networkd-wait-online.service

Шаг 2. Отключение IPv6

Возможно проблема долгой загрузки была в ожидании ответов IPv6, а поскольку в моей инфраструктуре он пока не критичен, то я отключил его на уровне ядра. Это сузило площадь ошибок в конфигурации systemd-networkd, я сосредоточился только на IPv4.

В /etc/sysctl.conf добавил:

1
2
3

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1

И применил изменения: sudo sysctl -p.

Шаг 3. Переход на прямую конфигурацию systemd-networkd

Файлы Netplan (/etc/netplan/*.yaml) генерируют конфиги для бэкенда. У меня их было два, и они могли конфликтовать или содержать избыточные параметры, тем более я уже и не помнил как и почему я их именно так писал. Изолировал прослойку Netplan, создав файл-заглушку /etc/systemd/network/10-eno1.network с настройками для systemd-networkd:

1
2
3
4
5
6
7
8

[Match]
Name=eno1

[Network]
DHCP=ipv4
IPv6AcceptRA=no
DNS=1.1.1.1
DNS=8.8.8.8

Ключевой момент здесь — DHCP=ipv4. Тут явно говорим демону: «Используй только IPv4, игнорируй IPv6». Параметр IPv6AcceptRA=no дополнительно страхует от ожидания сообщений роутера.

Удалил старые файлы из /etc/netplan/, чтобы избежать двойного применения настроек, и перезапустил службу:

1

sudo systemctl restart systemd-networkd

Интерфейс сразу получил адрес 192.168.1.3 и перешел в статус routable (configured). Системный резолв DNS заработал.

Шаг 4. Финальный босс: DNS и WireGuard

Пинги пошли, но nslookup ya.ru выдавал таймауты на 127.0.0.53 (локальный stub-resolver systemd-resolved). Вот про эту штуку я не знал, поэтому теперь знаю что не нужно поднимать на каждом сервер unbound, в systemd все есть из коробки.

Проверка resolvectl status показала странность:

• Link 2 (eno1): DNS Servers: 1.1.1.1, 8.8.8.8
• Link 5 (wg0): DNS Domain: ~.

Правда я её не заметил сперва, но консультации с ИИ не всегда являются потерей времени. Символ ~. означает «глобальный поиск». WireGuard, увидев в своем конфиге строку DNS = 1.1.1.1, автоматически сообщил системе, что этот DNS-сервер должен обрабатывать все запросы, перекрывая настройки физического интерфейса. Но так как туннель до собственных серверов и маршрутов до внешних DNS в нём нет, разрешения имен не работали.

Решение: В файле /etc/wireguard/wg0.conf я закомментировал всего лишь одну строку, как потом выяснилось добавленной в конфиг по рекомендаци такой же ИИшечки:

1

# DNS = 1.1.1.1

Переподнял туннель:

1
2

sudo wg-quick down wg0
sudo wg-quick up wg0

Теперь wg0 имеетв выводк networkctl status eno1 Current Scopes: none, а все DNS-запросы идут через основной интерфейс eno1 на публичные серверы Cloudflare и Google.

Итоги и выводы

1. WireGuard и DNS: Параметр DNS в конфиге WireGuard — это не просто рекомендация, а команда для системы изменить глобальные настройки резолвинга. Если ты не хочешь, чтобы туннель перехватывал все DNS-запросы, не указывай этот параметр в конфиге клиента, либо используйте более тонкие настройки Domains (если клиент поддерживает).
2. Ubuntu 24.04 и IPv6: По умолчанию включенный IPv6 может вызывать задержки при получении адреса IPv4, если инфраструктура не готова к v6. В домашних лабораториях его часто проще отключить, чем дебажить RA и DHCPv6.
3. Netplan vs systemd-networkd: Netplan удобен, но иногда прямая конфигурация systemd-networkd дает больше прозрачности и контроля, особенно при отладке сложных случаев с DHCP.
4. systemd-networkd-wait-online: На серверах, где сеть может падать или долго подниматься, эту службу лучше маскировать, иначе она будет тормозить загрузку всей ОС.

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

(Ссылка на диалог с Qwen)[https://chat.qwen.ai/s/0cfbc11b-dae3-4dba-bfaf-b0788172d07c?fev=0.2.45]

Сейчас я занимаюсь построением инфраструктуры для своей домашней лаборатории. В планах задействовать три сервера: один локальный машину дома и два VPS от разных провайдеров. Соответственно мне нужно организовать между ними защищенный канал связи для взаимодействия без лишних открытых наружу портов. Открыть порты сервисов наружу не хочется, поэтому лучшим решением стала виртуальная частная сеть на базе WireGuard.

Я пробовал разные варианты, но пришел к выводу, что лучше всего ставить WireGuard нативно прямо на хост-систему Ubuntu. Вариант с Docker тоже возможен, но он добавляет лишнюю сложность с пробросом портов и правами доступа. Нативная установка работает быстрее, управляется через стандартный systemd и проще интегрируется с фаерволом.

Начнем с установки. Это нужно сделать на всех машинах, которые будут участвовать в сети. В терминале выполняем обновление пакетов и установку утилит:

1
2

sudo apt update
sudo apt install wireguard wireguard-tools -y

После установки проверим, что модуль ядра загружен командой wg. Если увидели справку или пустой список интерфейсов, значит все прошло успешно.

1

wg

Следующий шаг - генерация ключей. Это нужно делать локально на каждом сервере. Приватный ключ никогда не должен покидать машину, а публичный мы будем передавать партнерам по сети.

1
2
3

cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey

Сохраните содержимое файлов privatekey и publickey в надежное место. Для примера в статье я буду использовать заглушки вида PRIVATE_KEY_HERE и PUBLIC_KEY_HERE.

Теперь создадим конфигурацию. Допустим, мы выделили под нашу сеть подсеть 10.8.0.0/24. Серверу с белым IP адресом назначим 10.8.0.1, а клиентам адреса вроде 10.8.0.2 и 10.8.0.3.

На сервере с белым IP создаем файл /etc/wireguard/wg0.conf. В секции Interface указываем его приватный ключ и слушаемый порт. В секции Peer добавляем публичные ключи клиентов.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.8.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT

[Peer]
PublicKey = CLIENT1_PUBLIC_KEY_HERE
AllowedIPs = 10.8.0.2/32

[Peer]
PublicKey = CLIENT2_PUBLIC_KEY_HERE
AllowedIPs = 10.8.0.3/32

Обратите внимание на строки PostUp и PostDown. Они нужны для того, чтобы при подъеме интерфейса автоматически применялись правила фаервола, разрешающие пересылку пакетов.

На клиенте, который находится за NAT (например, домашний сервер), конфигурация будет проще. Ему нужно знать публичный ключ сервера и его белый IP адрес.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[Interface]
PrivateKey = CLIENT1_PRIVATE_KEY_HERE
Address = 10.8.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25

Параметр PersistentKeepalive важен для клиентов за натом. Он отправляет служебные пакеты каждые 25 секунд, чтобы роутер не забывал об открытом соединении.

Прежде чем запускать туннель, нужно подготовить сеть. На сервере обязательно включаем пересылку пакетов (IP Forwarding), иначе трафик не будет ходить между интерфейсами.

1
2

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Также нужно настроить фаервол. Если у вас активен UFW, откройте порт UDP 51820 и разрешите маршрутизацию для интерфейса wg0.

1
2
3
4

sudo ufw allow 51820/udp
sudo ufw route allow in on wg0 out on wg0
sudo ufw route allow in on wg0 out on eth0
sudo ufw route allow in on eth0 out on wg0

В командах выше замените eth0 на имя вашего основного сетевого интерфейса.

Теперь самый важный момент, на котором я лично споткнулся. После любого изменения файла конфигурации wg0.conf необходимо перезапускать сервис интерфейса. Правила PostUp выполняются только в момент создания интерфейса. Если вы просто отредактировали файл и забыли перезапустить службу, новые правила фаервола не применятся, и соединения не будет.

Правильный порядок действий после правки конфига выглядит так:

1
2

sudo wg-quick down wg0
sudo wg-quick up wg0

Или через системную службу:

1

sudo systemctl restart wg-quick@wg0

Не пренебрегайте этим шагом. Именно отсутствие перезагрузки часто приводит к тому, что интерфейс поднят, ключи верны, но пакеты теряются по пути.

Чтобы сеть поднималась автоматически после перезагрузки сервера, включите службу в автозагрузку:

1

sudo systemctl enable wg-quick@wg0

Для диагностики состояния туннеля используйте команду wg show. Запустите ее в режиме мониторинга, чтобы видеть изменения в реальном времени:

1

watch -n 1 wg show

Смотрите на поле latest handshake. Если время там постоянно обновляется (например, 5 seconds ago, 10 seconds ago), значит соединение активно и пакеты ходят. Если время застыло или указано none, значит пакеты не доходят. Проверьте фаерволы и убедитесь, что порт открыт у провайдера VPS.

Также проверяйте счетчики трафика transfer. Если при пинге счетчик received растет, значит пакеты доходят до интерфейса WireGuard. Если пинга нет, но трафик есть, проблема скорее всего в маршрутизации внутри системы или блокировке ICMP фаерволом.

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

Удачи в построении вашей лаборатории!

Почему я выбрал mdadm

Есть два основных пути: mdadm и LVM RAID. Я остановился на mdadm. Для нашей задачи это проще и прозрачнее. LVM даёт крутую гибкость в управлении томами, но если нужна именно защита от смерти диска, mdadm справляется лучше. Восстановление после сбоя понятнее, мониторинг проще, и меньше шансов запутаться в конфигурации.

Важный нюанс про EFI

Тут есть подвох. UEFI не умеет загружаться с mdadm массивов. Поэтому EFI разделы нельзя объединять в RAID. Я оставил их отдельными на каждом диске. Просто синхронизирую содержимое вручную через rsync. Это небольшая плата за возможность загрузки с любого диска.

В самом инсталляторе Ubuntu я не догадался выделить отдельный раздел для EFI, чтобы правильно разбить диски при устанвоке. Так что я поставил систему целиком на один диск, а потом на втором создал программный RAID 1, перенёс данные и после этого добавил в RAID первый диск.

Пошаговая инстуркция

После первой загрузки новой системы я сначала проверил какие диски есть в системе:

1
2
3
4
5

lsblk -f
# Показывает структуру дисков и файловые системы

sudo fdisk -l | grep "Disk /dev/sd"
# Находим второй диск для RAID. Я ориентировался по размеру.

Установил mdadm:

1
2
3

sudo apt update
sudo apt install mdadm
# Устанавливаем утилиту управления RAID массивами. В убунте она по-умолчанию уже есть.

Скопировал таблицу разделов с первого диска на второй:

1
2

sudo sfdisk -d /dev/sda | sudo sfdisk /dev/sdb
# Копируем структуру разделов с sda на sdb

Создал RAID1 массив. Важный момент - создавал в деградированном режиме, чтобы не затереть работающую систему:

1
2
3

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb2 missing
# Создаём массив пока только с одним диском (sdb2)
# Второй диск (sda2) добавим позже

Отформатировал и скопировал данные:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

sudo mkfs.ext4 /dev/md0
# Создаём файловую систему на новом RAID массиве

sudo mkdir -p /mnt/new-root
sudo mount /dev/md0 /mnt/new-root
# Монтируем новый массив

sudo rsync -axHAWX --numeric-ids --info=progress2 \
  --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run --exclude=/tmp \
  / /mnt/new-root/
# Копируем все данные с сохранением прав и атрибутов
# Исключаем виртуальные файловые системы

Подготовил chroot и обновил конфигурацию:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Монтируем необходимые директории для chroot
for dir in /dev /dev/pts /proc /sys /run; do
    sudo mount --bind $dir /mnt/new-root$dir
done

# Монтируем EFI раздел
sudo mount /dev/sda1 /mnt/new-root/boot/efi

# Заходим в систему
sudo chroot /mnt/new-root

# Внутри chroot обновляем fstab
sed -i 's|/dev/sda2|/dev/md0|g' /etc/fstab
# Меняем корневой раздел с sda2 на md0

# Добавляем конфигурацию mdadm
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

# Обновляем initramfs чтобы RAID собрался при загрузке
update-initramfs -u -k all

# Переустанавливаем GRUB
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Ubuntu --recheck
update-grub

# Выходим из chroot
exit

Отмонтировал и перезагрузился для проверки:

1
2
3

sudo umount -R /mnt/new-root
sudo reboot
# Перезагружаемся - система должна загрузиться с RAID

После успешной загрузки добавил оригинальный диск в массив:

1
2
3
4
5
6

sudo mdadm /dev/md0 --add /dev/sda2
# Добавляем sda2 в массив - начнётся синхронизация

watch cat /proc/mdstat
# Следим за прогрессом синхронизации
# Это может занять от одного до четрёх  часов. У меня чуть больше часа заняло.

Настроил второй EFI раздел:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

sudo mkfs.vfat -F 32 -n EFI /dev/sdb1
# Форматируем EFI раздел второго диска в FAT32

sudo mkdir -p /boot/efi2
sudo mount /dev/sdb1 /boot/efi2
# Монтируем второй EFI раздел

sudo rsync -a /boot/efi/EFI/ /boot/efi2/EFI/
# Копируем файлы загрузчика

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi2 --bootloader-id=Ubuntu /dev/sdb
# Устанавливаем GRUB на второй диск

sudo umount /boot/efi2

Настроил уведомления:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

sudo apt install postfix
# Устанавливаем почтовый сервер
# При настройке выбираем "Local only"

sudo nano /etc/mdadm/mdadm.conf
# Добавляем строку: MAILADDR username. Где username это ник твоей учтёки.

sudo systemctl enable --now mdmonitor
# Включаем мониторинг RAID массивов

sudo mdadm --monitor --test --oneshot /dev/md0
# Тестируем отправку уведомлений

Как проверить что всё работает

После настройки прогони несколько команд для спокойствия:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

cat /proc/mdstat
# В строке md0 должны быть две буквы U в скобках [UU]
# Это значит что оба диска активны и синхронизированы

sudo mdadm --detail /dev/md0
# State должно быть active
# Working Devices должно быть равно 2

df -h | grep " / "
# Корневая файловая система должна быть на /dev/md0

sudo efibootmgr -v
# Проверяем что запись Ubuntu есть в списке загрузочных устройств

cat /etc/mdadm/mdadm.conf | grep ARRAY
# Проверяем что конфигурация массива сохранена

Что делать после обновления ядра

После apt upgrade файлы загрузчика обновляются только на основном EFI разделе. Нужно вручную синхронизировать второй диск:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

sudo mkdir -p /boot/efi2
sudo mount /dev/sdb1 /boot/efi2
# Монтируем второй EFI раздел

sudo rsync -a /boot/efi/EFI/ /boot/efi2/EFI/
# Синхронизируем файлы загрузчика

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi2 --bootloader-id=Ubuntu /dev/sdb
# Обновляем GRUB на втором диске

sudo umount /boot/efi2

Я добавил эти команды в скрипт /usr/local/bin/sync-efi.sh и если не забуду про его существоавание, то буду запускать его после обновлений. Занимает минуту, зато спокойнее.

Что делать при сбое диска

Если пришло уведомление о проблеме, сначала проверь статус массива:

1
2
3

cat /proc/mdstat
sudo mdadm --detail /dev/md0
# Проверяем какой диск вышел из строя

Если диск помечен как failed, действуй по плану:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

sudo mdadm /dev/md0 --fail /dev/sdX2 --remove /dev/sdX2
# Отмечаем диск как неисправный и удаляем из массива
# Замените sdX2 на имя проблемного раздела

# После физической замены диска добавляем новый:
sudo mdadm /dev/md0 --add /dev/sdX2
# Добавляем новый диск в массив

watch cat /proc/mdstat
# Следим за восстановлением
# Система продолжает работать во время синхронизации

Важные заметки на будущее

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

Сохрани вывод efibootmgr в файл:

1
2

sudo efibootmgr -v > ~/efiboot-backup.txt
# Это поможет восстановить загрузочные записи если настройки UEFI сбросятся

Не прерывай синхронизацию массива. Это может повредить данные.

Итог

Настройка заняла пару часов включая время на синхронизацию дисков. Теперь сервер защищён от выхода из строя одного из SSD. Если хочешь сделать так же и возникнут вопросы - пиши, помогу разобраться.

Простая аналогия:

Представьте, что в офисе есть сейф, который может открывать только начальник. Обычным сотрудникам вход запрещен. Но начальник дает секретарю особый пропуск (setuid-бит), с помощью которого секретарь может открыть сейф, хотя сам не является начальником.

Для чего нужны setuid биты?

Основные случаи использования:

1. Смена пароля (/usr/bin/passwd)

   1 2	ls -la /usr/bin/passwd -rwsr-xr-x 1 root root 68208 апр 8 10:15 /usr/bin/passwd

   • Обычный пользователь должен менять свой пароль
   • Пароли хранятся в защищенном файле /etc/shadow, доступном только root
   • Setuid позволяет passwd временно получить права root для записи в /etc/shadow

2. Команда sudo (/usr/bin/sudo)

   1 2	ls -la /usr/bin/sudo -rwsr-xr-x 1 root root 232416 фев 9 2024 /usr/bin/sudo

   • Позволяет выполнять команды от имени root
   • Без setuid sudo не сможет повысить привилегии

3. Другие примеры:

   • ping — требует root для создания сетевых сокетов
   • su — переключение на другого пользователя
   • mount/umount — монтирование файловых систем

Как распознать setuid биты?

Визуальное обозначение:

1
2
3
4
5
6
7
8

# Обычный файл
-rwxr-xr-x  # нет setuid

# Файл с setuid (s вместо x в позиции владельца)
-rwsr-xr-x  # есть setuid

# Файл с setgid (s вместо x в позиции группы)
-rwxr-sr-x  # есть setgid

Буква s в позиции execute (x) означает, что установлен setuid/setgid бит.

Как просмотреть все файлы с setuid:

1. Поиск по всей системе:

   1	sudo find / -type f -perm -4000 -ls 2>/dev/null

2. Только в стандартных директориях:

   1	sudo find /usr/bin /usr/sbin /bin /sbin -type f -perm -4000 -ls

3. С подробной информацией:

   1 2 3 4 5

   # С владельцем и правами sudo find /usr -type f -perm -4000 -exec ls -la {} \; 2>/dev/null # Или более компактно sudo find /usr/bin -type f -perm -4000 | xargs ls -la

4. Числовое представление:

   1	stat /usr/bin/sudo | grep Access

   Setuid бит = 4000 в восьмеричной системе (4 = setuid, 2 = setgid, 1 = sticky bit)

Как установить/убрать setuid бит:

Символический способ:

1
2
3
4
5

# Установить setuid
sudo chmod u+s /path/to/file

# Убрать setuid
sudo chmod u-s /path/to/file

Числовой способ:

1
2
3
4
5

# Установить (4755 = setuid + 755 права)
sudo chmod 4755 /path/to/file

# Убрать (755 = обычные права)
sudo chmod 755 /path/to/file

Почему это важно для безопасности?

Риски:

1. Вредоносные программы могут использовать setuid для получения root-доступа
2. Ошибки в setuid-программах — частая причина взломов
3. Лишние setuid биты расширяют поверхность атаки

Аудит безопасности:

1
2
3
4
5

# Найти все setuid файлы для проверки
sudo find / -type f -perm -4000 -ls 2>/dev/null | sort

# Сравнить с "чистой" системой
# Неожиданные setuid файлы должны настораживать

Практический пример из моей практики:

Я где-то ошибся и сделал своего пользвоателя владельцем /usr/, слом судо и пока пытался починить выполнил find /usr -type d -exec chmod 755 {} \;, это не затронуло файлы. Но когда следом сделал:

1

sudo find /usr -type f -exec chmod 644 {} \;

Эта команда сбросила setuid биты на всех файлах, включая sudo, passwd и другие. Поэтому sudo опять перестал работать.

Правильно было бы:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Сначала сохранить список setuid файлов
sudo find /usr -type f -perm -4000 > /tmp/setuid_backup.txt

# Потом менять права
sudo find /usr -type f -exec chmod 644 {} \;

# И восстановить setuid биты из сохраненного списка
while read file; do
  sudo chmod 4755 "$file"
done < /tmp/setuid_backup.txt