Иногда, изменяя размер или иным образом копаясь в разделах на диске, cfdisk скажет:
_
Wrote partition table, but re-read table failed. Reboot to update table.
_
(Это также происходит с другими инструментами разбиения, поэтому я думаю, что это проблема Linux, а не проблема cfdisk.) Почему это так и почему это происходит только иногда, и что я могу сделать чтобы избежать этого?
Примечание: Пожалуйста, предположите, что ни один из разделов, которые я редактирую, не открыт, не смонтирован и не используется иным образом.
Обновление:
cfdisk использует ioctl(fd, BLKRRPART, NULL)
, чтобы сказать Linux перечитать таблицу разделов. Два других рекомендованных инструмента (_hdparm -z
_ DEVICE
, _sfdisk -R
_ DEVICE
) выполняют в точности то же самое. Команда partprobe
DEVICE
, с другой стороны, похоже, использует новый ioctl под названием BLKPG, который может быть лучше; Я не знаю. (Он также возвращается к BLKRRPART в случае сбоя BLKPG.)
BLKPG выглядит как операция "этот раздел изменился; вот новый размер", и он выглядел как partprobe
, который вызывал его индивидуально на всех переданных разделах устройства, поэтому он должен работать, если отдельные разделы неиспользованными. Однако у меня не было возможности попробовать это.
ИМХО самый надежный/лучший ответ
partprobe /dev/sdX
Перечитывание информации таблицы разделов не всегда работает, но попробуйте
hdparm -z /dev/sda
или
sfdisk -R /dev/sda
Если это работает, значения в/proc/partitions изменятся.
В Centos7:
Согласно https://access.redhat.com/solutions/19957
Тебе стоит попробовать :
partx -u <partition>
Это сработало для меня.
Примечание: Пожалуйста, предположите, что ни один из разделов, которые я редактирую, не открыт, не смонтирован и не используется иным образом.
Учитывая это предположение, таблица разделов может будет успешно повторно проверена, и проблема не возникнет. Если вы получаете эту ошибку, это потому, что таблица разделов is используется в настоящее время, и, следовательно, не может быть повторно проверена без создания несоответствий.
Он не основан на разделе, который вы редактируете.
Предположим, у вас есть только один жесткий диск (/dev/sda
) и два раздела (/dev/sda1
, /dev/sda2
) и вы смонтировали только один раздел (/dev/sda1
). Если вы удалите или измените что-либо в другом разделе, который даже не смонтирован (/dev/sda2
) вы получите ошибку, что перечитывание таблицы разделов не удалось и ядро будет использовать старую таблицу.
Но если у вас есть два жестких диска (/dev/sda
, /dev/sdb
) и ни один из разделов (/dev/sdb
) используются. Затем вы можете добавлять/удалять/изменять размер/редактировать разделы /dev/sdb
и они будут перечитаны без проблем. Но даже если один раздел/dev/sdb был смонтирован во время изменения. Тогда ядро продолжит использовать старую таблицу.
У меня (первоначального спрашивающего) была ситуация несколько дней назад, когда ни один из других ответов (включая partprobe /dev/sdX
, в настоящее время принятый и получивший наибольшее количество голосов) работал. Что сделал работа, однако, было это:
blockdev --rereadpt /dev/sdX
(Я не знаю, почему это сработало, а другие нет, но я рад, что это сработало, поскольку это спасло меня от перезагрузки на занятом сервере.)
я нахожусь на Centos 6,5 х64; ядро 2.6.32. и я проверяю трюк fdisk, чтобы изменить размер.
/dev/sda1 /boot
/dev/sda2 /
Все следующие команды не заставили ядро перечитать раздел:
мне все еще нужна перезагрузка, чтобы она заработала
При всех несмонтированных точках монтирования работает Yocto 2.4:
partprobe /dev/sda
Не удалось перезагрузить таблицу разделов после удаления разделов на устройстве. Также попробовал - и не удалось:
udevadm trigger --subsystem-match=block; udevadm settle
hdparm -z /dev/sda
blockdev --rereadpt /dev/sda
Все сообщали об аналогичных ошибках "Ошибка BLKRRPART: устройство или ресурс занят ...", указывающие на перезагрузку. Возможно, этот сбой ранее использовавшихся методов связан с тем, что udev теперь находится под контролем systemd? Размышляя в том же духе, я попытался:
systemctl restart systemd-udevd.service
И вдруг мой диск снова доступен, без перезагрузки!
Вы также можете попробовать:
echo 1 > /sys/block/sdX/device/rescan
(Но не сработает, см. Комментарий ниже)
Когда команда, как blockdev --rereadpt /dev/sdX
терпит неудачу с
blockdev: ioctl error on BLKRRPART: Device or resource busy
это обычно означает, что какой-то (старый) раздел действительно все еще каким-то образом используется ядром.
Возможные причины/исправления:
sdX1
- все еще подключен - проверьте с помощью mount
и размонтируйте его/dev/sdX1
является частью программного рейда - проверьте cat /proc/mdstat
и, возможно, остановите соответствующие массивы, например, mdadm --stop /dev/md126
/dev/sdX1
является частью физического тома LVM - проверьте с помощью pvdisplay
/vgdisplay
и, возможно, деактивируйте с помощью vgchange
/dev/sdX1
является частью сопоставления некоторых устройств - например, через cryptsetup
- проверьте /dev/mapper
и lsblk
и, возможно, удалите сопоставление (например, cryptsetup luksClose
)ps
и, возможно, уничтожьтеЕсли один инструмент - скажем blockdev --rereadpt
обычно не схожи (partx -uv
, kpartx
, partprobe
, kpartprobe
) аналогичным образом завершают работу до тех пор, пока не будет устранена основная причина.
kpartx -a <partition>
можно запустить два раза на только что созданном разделе .... вместо перезагрузки системы.
Для меня ни partprobe
, ни blockdev
решение не сработало. Хотя, этот работает:
udevadm settle --exit-if-exists=/dev/sdb1
Не забудьте проверить, что сервис udev запущен. Это особенно полезно, когда partprobe, hdparm, blockdev и различные другие команды, кажется, не имеют никакого значения, какие файлы устройств доступны в каталоге/dev /.