+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблемы с монтированием дисков на ядре 6.14.8-2-pve после обновления до PVE9, Proxmox Виртуальная Среда

andymdoyle

Guest

11.08.2025 19:54:00

У меня есть мини-ПК, который больше года без проблем работал на PVE, и недавно я использовал последнюю версию PVE8, точнее 6.8.12-13-pve. Сегодня я сделал обновление на месте до PVE9, следуя инструкции https://pve.proxmox.com/wiki/Upgrade_from_8_to_9, и процесс прошёл гладко до самого момента перезагрузки. При загрузке я увидел следующее: Загрузка в расширенном режиме с выбором варианта восстановления 6.14.8-2-pve приводила к тем же ошибкам и постоянному потоку сообщений, типа: В любой момент, если я перезагружался обратно в 6.8.12-13-pve, система загружалась нормально. fstab выглядит так:
# /dev/pve/root / ext4 errors=remount-ro 0 1
UUID=4C18-6924 /boot/efi vfat defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0

Я попытался загрузиться, изменив UUID=4C18-6924 на /dev/sda2 согласно выводу lsblk:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 476.9G 0 disk
├─sda1 8:1 0 1007K 0 part
├─sda2 8:2 0 1G 0 part /boot/efi
└─sda3 8:3 0 475.9G 0 part
├─pve-swap 252:0 0 8G 0 lvm [SWAP]
├─pve-root 252:1 0 96G 0 lvm /
├─pve-data_tmeta 252:2 0 3.6G 0 lvm
│ └─pve-data-tpool 252:4 0 348.8G 0 lvm
│ ├─pve-data 252:5 0 348.8G 1 lvm
│ ├─pve-vm--103--disk--0 252:6 0 4G 0 lvm
│ ├─pve-vm--104--disk--0 252:7 0 2G 0 lvm
│ ├─pve-vm--101--disk--0 252:8 0 5G 0 lvm
│ ├─pve-vm--102--disk--0 252:9 0 8G 0 lvm
│ ├─pve-vm--107--disk--0 252:10 0 10G 0 lvm
│ ├─pve-vm--106--disk--0 252:11 0 4M 0 lvm
│ ├─pve-vm--106--disk--1 252:12 0 32G 0 lvm
│ └─pve-vm--108--disk--0 252:13 0 8G 0 lvm
└─pve-data_tdata 252:3 0 348.8G 0 lvm
└─pve-data-tpool 252:4 0 348.8G 0 lvm
├─pve-data 252:5 0 348.8G 1 lvm
├─pve-vm--103--disk--0 252:6 0 4G 0 lvm
├─pve-vm--104--disk--0 252:7 0 2G 0 lvm
├─pve-vm--101--disk--0 252:8 0 5G 0 lvm
├─pve-vm--102--disk--0 252:9 0 8G 0 lvm
├─pve-vm--107--disk--0 252:10 0 10G 0 lvm
├─pve-vm--106--disk--0 252:11 0 4M 0 lvm
├─pve-vm--106--disk--1 252:12 0 32G 0 lvm
└─pve-vm--108--disk--0 252:13 0 8G 0 lvm

Filesystem Size Used Avail Use% Mounted on
udev 8.3G 0 8.3G 0% /dev
tmpfs 1.7G 2.8M 1.7G 1% /run
/dev/mapper/pve-root 101G 24G 72G 25% /
tmpfs 8.3G 36M 8.3G 1% /dev/shm
efivarfs 197k 90k 102k 47% /sys/firmware/efi/efivars
tmpfs 5.3M 0 5.3M 0% /run/lock
tmpfs 1.1M 0 1.1M 0% /run/credentials/systemd-journald.service
tmpfs 8.3G 0 8.3G 0% /tmp
/dev/sda2 1.1G 9.2M 1.1G 1% /boot/efi
/dev/fuse 135M 46k 135M 1% /etc/pve

Есть идеи, что может быть причиной такой проблемы с последним ядром?

mazixoom

Guest

01.09.2025 06:01:00

Привет! У меня дома есть три таких мини-ПК N100 (Firebat T8 Plus), объединённых в кластер. Только один из них ведёт себя странно с жёстким диском при использовании ядра 6.14. Либо он не может найти диск после GRUB и продолжить загрузку, либо загружается нормально, но через пару часов зависает (если память не изменяет, срабатывают ATA hard resets) и требует перезагрузки. Два остальных работают без проблем с 6.14 с тех пор, как я обновился до PVE9.

Эти устройства покупались в разное время, и «зависающий» — самый первый из них. Версия BIOS (5.26) у всех вроде бы одинаковая, хотя даты BIOS разные: 26.09.2023 у первых двух и 16.01.2024 у третьего. Но прошивки дисков у всех разные:
Device Model: N900-512
Firmware Version: W0825A (тот, что с проблемами)
Firmware Version: W0220A0 (без проблем)
Firmware Version: W0704A0 (без проблем)

С этими устройствами довольно сложно найти свежие версии BIOS, а прошивку для диска — вообще почти невозможно. И если вдруг повезёт найти обновление, вероятность «окирпичивания» слишком высока, потому что никогда не знаешь точно схему именования и версий для этих устройств.

Что я ещё не пробовал — поставить другой диск, установить и обновить Proxmox, посмотреть, проявится ли та же проблема.

Пока что обходной путь — запускать на проблемном устройстве последнее ядро 6.8, с которым стабильность не подводит.

mazixoom Guest	#3 0 20.10.2025 20:23:00 Для полного завершения, в итоге проблему решила добавленная в аргументы загрузки строка: Code: libata.force=nolpm.

IreuN

Guest

11.11.2025 14:52:00

Хмм... Ты меня заставил задуматься. У меня тоже были проблемы с загрузкой Firebat T8 на ядрах 6.14 и 6.17. Но я думал, что это связано с моим адаптером ASM1064 (ссылка) — libata.force=nolpm позволял загружаться нормально, хотя, пожалуй, я даже не пробовал загружаться без адаптера ASM1064. Только что проверил SSD N900-512 (я так и не поменял его на что-то более качественное), и у него такая же прошивка, как у тебя — `W0825A0`. Так что, может, виноват именно SSD, а не ASM1064. В любом случае я уже заказал NVMe-диск — помни, что слот M.2 поддерживает PCIe 3.0 x2, что даст примерно 1700 МБ/с, тогда как N900 — SATA-диск. Эти дешёвые N900, как известно, быстро выходят из строя, у моего сейчас скорость записи всего около 25 МБ/с (почему-то, после 14 тысяч часов эксплуатации).

IreuN

Guest

14.11.2025 18:52:00

Привет снова! Сегодня я заменил N900 на Corsair MP600 (R2) 1 ТБ — и ты был прав! Проблема была не в ASM1064, а в N900 с прошивкой W0825A0! Как только я установил NVMe в свой Firebat T8, мне больше не понадобился параметр `libata.force=nolpm`, что, думаю, только к лучшему. Ещё один совет от меня — сделайте себе одолжение и тоже поменяйте свои диски, потому что использовать дешёвый SATA SSD (который, как мой, может выйти из строя или начать глючить) — это пустая трата ресурсов, особенно когда можно пользоваться NVMe на скорости PCIe 3.0 x2.

drpks Guest	#6 0 03.01.2026 00:24:00 У меня были такие же проблемы с моим Firebat T8. Вот ещё один параметр ядра, который помог мне: Код: ahci.mobile_lpm_policy=0 Источник: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2091777

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры