¿Volver a leer la tabla de particiones sin reiniciar?

A veces, cuando se cambia el tamaño o de alguna otra manera muck con particiones en un disco, cfdisk dirá:

Wrote partition table, but re-read table failed. Reboot to update table.

(Esto también sucede con otras herramientas de particionamiento, por lo que creo que este es un problema de Linux en lugar de un problema de cfdisk). ¿Por qué es esto y por qué solo ocurre a veces y qué puedo hacer para evitarlo?

Nota: Suponga que ninguna de las particiones que estoy editando están abiertas, montadas o en uso.

Actualizar:

cfdisk usa ioctl(fd, BLKRRPART, NULL)para decirle a Linux que vuelva a leer la tabla de particiones. Dos de las otras herramientas recomendadas hasta ahora ( hdparm -z DEVICE, sfdisk -R DEVICE) hacen exactamente lo mismo. El partprobe DEVICEcomando, por otro lado, parece usar un nuevo ioctl llamado BLKPG, que podría ser mejor; No lo sé. (También recurre a BLKRRPART si BLKPG falla).

BLKPG parece ser una operación de "esta partición ha cambiado; aquí está el nuevo tamaño", y parecía partprobellamada individualmente en todas las particiones en el dispositivo pasado, por lo que debería funcionar si las particiones individuales no se utilizan. Sin embargo, no he tenido la oportunidad de probarlo.

En mi humilde opinión la respuesta más confiable / mejor es

partprobe /dev/sdX

Volver a leer la información de la tabla de particiones no siempre funciona, pero intente

hdparm -z /dev/sda

o

sfdisk -R /dev/sda

Si funciona, los valores en / proc / partitions cambiarán.

En Centos7:

De acuerdo con https://access.redhat.com/solutions/199573

Deberías intentarlo :

partx -u <partition>

A mi me funciono.

Nota: Suponga que ninguna de las particiones que estoy editando están abiertas, montadas o en uso.

Dado ese supuesto, la tabla de particiones se puede volver a analizar con éxito, y el problema no surgirá. Si obtiene ese error, es porque la tabla de particiones está actualmente en uso y, por lo tanto, no se puede volver a escanear sin crear inconsistencias.

No se basa en la partición que está editando.

Supongamos que solo tiene un disco duro ( /dev/sda) y dos particiones ( /dev/sda1, /dev/sda2) y ha montado solo una partición ( /dev/sda1). Si elimina o cambia algo sobre otra partición que ni siquiera está montada ( /dev/sda2), recibirá el error de que la relectura de la tabla de particiones falló y el núcleo usará la tabla anterior.

Pero si tiene dos discos duros ( /dev/sda, /dev/sdb) y ninguna de las particiones de ( /dev/sdb) está en uso. Luego puede agregar / eliminar / cambiar el tamaño / editar particiones /dev/sdby se volverán a leer sin ningún problema. Pero incluso si se montó una partición de / dev / sdb durante el cambio. Entonces el núcleo seguirá usando la tabla anterior.

Yo (el interrogador original) tuve una situación hace unos días cuando ninguna de las otras respuestas (incluida partprobe /dev/sdX, actualmente, la respuesta aceptada y mejor votada) funcionó. Lo que funcionó, sin embargo, fue esto:

blockdev --rereadpt /dev/sdX

(No sé por qué funcionó esto y los otros no, pero estoy feliz de que funcionó, ya que me ahorró un reinicio en un servidor ocupado).

estoy en centos 6.5 x64; kernel 2.6.32. y estoy probando el truco de fdisk para cambiar el tamaño.

/dev/sda1 /boot
/dev/sda2 /

Todos los siguientes comandos no hicieron la partición releída del núcleo:

• partprobe / dev / sda (advertencia: el núcleo no pudo volver a leer ...)
• hdparm -z / dev / sda (BLKRRPART falló: dispositivo o recurso ocupado)
• blockdev -rereadpt / dev / sda (BLKRRPART falló: dispositivo o recurso ocupado)
• sfdisk -R / dev / sda (BLKRRPART falló: dispositivo o recurso ocupado)

Todavía necesito reiniciar para que funcione

Con todos los puntos de montaje desmontados, ejecutando Yocto 2.4:

partprobe /dev/sda 

Todavía no se pudo volver a cargar la tabla de particiones después de que las particiones se hayan eliminado en el dispositivo. También probé, y fallé:

udevadm trigger --subsystem-match=block; udevadm settle
hdparm -z /dev/sda
blockdev --rereadpt /dev/sda

Todos informaron errores similares de "BLKRRPART falló: dispositivo o recurso ocupado ..." que me indican que reinicie. ¿Es posible que esta falla de los métodos que funcionaban anteriormente se deba al hecho de que udev está ahora bajo control de systemd? Pensando en esas líneas intenté:

systemctl restart systemd-udevd.service

Y de repente mi disco vuelve a estar disponible, ¡ sin reiniciar!

Cuando un comando como blockdev --rereadpt /dev/sdXfalla con

blockdev: ioctl error on BLKRRPART: Device or resource busy

esto generalmente significa que alguna partición (antigua) de hecho todavía es utilizada de alguna manera por el núcleo.

Posibles causas / soluciones:

1. una partición sdX - digamos sdX1- todavía está montada - verifique mounty desmonte
2. /dev/sdX1es parte de una redada de software: verifique cat /proc/mdstaty posiblemente detenga las matrices relevantes, por ejemplomdadm --stop /dev/md126
3. /dev/sdX1es parte de un volumen físico LVM - verifique con pvdisplay/ vgdisplayy posiblemente desactive convgchange
4. /dev/sdX1es parte de alguna asignación de dispositivos - por ejemplo, a través de cryptsetup- comprobar /dev/mappery lsblky quitar la asignación posiblemente (por ejemplo cryptsetup luksClose)
5. Condición de carrera con algunas pruebas de udev: compruebe los procesos en ejecución con psy posiblemente elimine uno

Si una de las herramientas - decir blockdev --rereadptno queridos por lo general similares como ( partx -uv, kpartx, partprobe, kpartprobe) fallará de manera similar hasta que se elimina la causa raíz.

También puedes probar:

echo 1 > /sys/block/sdX/device/rescan

(Pero no funcionará, mira el comentario a continuación)

kpartx -a <partition> se puede ejecutar dos veces en una partición recién creada ... en lugar de reiniciar el sistema.

Recuerde verificar que el servicio udev se esté ejecutando. Esto es especialmente útil cuando partprobe, hdparm, blockdev y varios otros comandos no parecen hacer ninguna diferencia sobre qué archivos de dispositivo están disponibles en el directorio / dev /.

Para mí no partprobeo blockdevsolución trabajado. Aunque, este funciona:

udevadm settle --exit-if-exists=/dev/sdb1

Si lee la página de manual de 'man oracleasm-scandisks', observará el texto a continuación. oracleasm está usando / proc / partitions como la fuente de todos los escaneos que realiza. Debe obtener sus dispositivos sin formato en / proc / particiones antes de poder hacer un scandisk. Los parámetros Scanorder y Scanexclude que coloca en / etc / sysconfig / oracleasm se relacionan con los nombres encontrados en / proc / partitions (!!!!).

---------- hombre-oracleasm-scandisks ------ ...

CÓMO SUCEDE EL ESCANEO El escaneo continúa en cuatro etapas básicas.

   First, the list of disks to scan is created. If disks were specified on the command line, this is the list.
   If not, /proc/partitions is read, and each block device is added, subject to the -o and -x options.

   Second, the partition tables of each disk in the scan are reloaded unless the -s option was specified. Any
   disks that no longer exist are dropped.

   Third, the list of disks is recreated based on the new partition tables.

   Finally, each disk in the list is checked to see if it is marked for ASM use. Disks that are marked are
   instantiated.