web-dev-qa-db-fra.com

Relire la table de partition sans redémarrer?

Parfois, lors du redimensionnement ou du nettoyage des partitions sur un disque, cfdisk dira:

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

(Cela se produit également avec d'autres outils de partitionnement, donc je pense que c'est un problème Linux plutôt qu'un problème cfdisk.) Pourquoi est-ce, et pourquoi cela ne se produit que parfois, et que puis-je faire pour l'éviter?

Remarque: Veuillez supposer qu'aucune des partitions que je modifie actuellement n'est ouverte, montée ou autrement utilisée.

Mise à jour:

cfdisk utilise ioctl(fd, BLKRRPART, NULL) pour dire à Linux de relire la table de partition. Deux des autres outils recommandés jusqu'à présent (hdparm -zDEVICE, sfdisk -RDEVICE) ne exactement la même chose. La commande partprobeDEVICE, d'autre part, semble utiliser un nouvel ioctl appelé BLKPG, qui pourrait être mieux; Je ne sais pas. (Il retombe également sur BLKRRPART si BLKPG échoue.)

BLKPG semble être une opération "cette partition a changé; voici la nouvelle taille", et il semblait que partprobe l'appelait individuellement sur toutes les partitions du périphérique passé, donc cela devrait fonctionner si les partitions individuelles sont inutilisé. Cependant, je n'ai pas eu l'occasion de l'essayer.

partitionfdisklinux
71
Teddy

À mon humble avis, la réponse la plus fiable/la meilleure est

partprobe /dev/sdX
68
knweiss

La relecture des informations de la table de partition ne fonctionne pas toujours, mais essayez

hdparm -z /dev/sda

ou

sfdisk -R /dev/sda

Si cela fonctionne, les valeurs dans/proc/partitions changeront.

19
ko-dos

Sur Centos7:

Selon https://access.redhat.com/solutions/19957

Tu devrais essayer :

partx -u <partition>

Ça a marché pour moi.

10
uus

Remarque: Veuillez supposer qu'aucune des partitions que je modifie actuellement n'est ouverte, montée ou autrement utilisée.

Compte tenu de cette hypothèse, la table de partition peut être analysée avec succès, et le problème ne se posera pas. Si vous obtenez cette erreur, c'est parce que la table de partition est actuellement utilisée, et ne peut donc pas être analysée à nouveau sans créer d'incohérences.

8
womble

Ce n'est pas basé sur la partition que vous éditez.

Supposons que vous n'ayez qu'un seul disque dur (/dev/sda) et deux partitions (/dev/sda1, /dev/sda2) et vous n'avez monté qu'une seule partition (/dev/sda1). Si vous supprimez ou modifiez quoi que ce soit sur une autre partition qui n'est même pas montée (/dev/sda2) vous obtiendrez l'erreur que la relecture de la table de partition a échoué et le noyau utilisera l'ancienne table.

Mais si vous avez deux disques durs (/dev/sda, /dev/sdb) et aucune des partitions de (/dev/sdb) sont en cours d'utilisation. Ensuite, vous pouvez ajouter/supprimer/redimensionner/modifier les partitions de /dev/sdb et ils seront relus sans aucun problème. Mais même si une partition de/dev/sdb a été montée lors du changement. Ensuite, le noyau continuera d'utiliser l'ancienne table.

6
Saurabh Barjatiya

J'ai (l'interrogateur d'origine) eu une situation il y a quelques jours où aucune des autres réponses (y compris partprobe /dev/sdX, actuellement la réponse acceptée et la plus votée) a fonctionné. Ce qui a fonctionné, cependant, était le suivant:

blockdev --rereadpt /dev/sdX

(Je ne sais pas pourquoi cela a fonctionné et les autres non, mais je suis heureux que cela ait fonctionné, car cela m'a évité un redémarrage sur un serveur occupé.)

5
Teddy

je suis sur centos 6.5 x64; noyau 2.6.32. et je teste l'astuce fdisk pour redimensionner.

/dev/sda1 /boot
/dev/sda2 /

Toutes les commandes suivantes n'ont pas fait une partition relue du noyau:

  • partprobe/dev/sda (avertissement: le noyau n'a pas pu relire ....)
  • hdparm -z/dev/sda (BLKRRPART a échoué: périphérique ou ressource occupé)
  • blockdev -rereadpt/dev/sda (BLKRRPART a échoué: périphérique ou ressource occupé)
  • sfdisk -R/dev/sda (BLKRRPART a échoué: périphérique ou ressource occupé)

j'ai encore besoin d'un redémarrage pour le faire fonctionner

5
Max

Avec tous les points de montage non montés, exécutez Yocto 2.4:

partprobe /dev/sda

Échec du rechargement de la table de partition après la suppression des partitions sur le périphérique. Également essayé - et échoué:

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

Tous ont signalé des erreurs similaires "BLKRRPART a échoué: périphérique ou ressource occupé ..." m'informant de redémarrer. Cet échec des méthodes de travail précédentes est-il probablement dû au fait que udev est maintenant sous le contrôle de systemd? En réfléchissant dans ce sens, j'ai essayé:

systemctl restart systemd-udevd.service

Et soudain, mon disque est à nouveau disponible, sans redémarrage!

3
Camp Waub-O-Jeeg

Vous pouvez également essayer:

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

(Mais ne fonctionnera pas, voir le commentaire ci-dessous)

1
bogdano

Lorsqu'une commande comme blockdev --rereadpt /dev/sdX échoue avec

blockdev: ioctl error on BLKRRPART: Device or resource busy

cela signifie généralement qu'une certaine (ancienne) partition est en effet encore en quelque sorte utilisée par le noyau.

Causes/correctifs possibles:

  1. une partition sdX - dites sdX1 - est toujours monté - vérifiez avec mount et démontez-le
  2. /dev/sdX1 fait partie d'un raid logiciel - vérifiez cat /proc/mdstat et éventuellement arrêter les tableaux pertinents, par exemple mdadm --stop /dev/md126
  3. /dev/sdX1 fait partie d'un volume physique LVM - vérifiez avec pvdisplay/vgdisplay et désactivez éventuellement avec vgchange
  4. /dev/sdX1 fait partie de certains mappages d'appareils - par exemple via cryptsetup - vérifiez /dev/mapper et lsblk et éventuellement supprimer le mappage (par exemple cryptsetup luksClose)
  5. Condition de concurrence avec quelques sondages udev - vérifiez les processus en cours avec ps et éventuellement en tuer un

Si un seul outil - dites blockdev --rereadpt échoue généralement des similaires comme (partx -uv, kpartx, partprobe, kpartprobe) échouent de la même manière jusqu'à ce que la cause première soit éliminée.

1
maxschlepzig

kpartx -a <partition> peut être exécuté deux fois sur la partition nouvellement créée .... au lieu de redémarrer le système.

0
Kailas Kadam

Pour moi, ni partprobe ni blockdev solution n'a fonctionné. Bien que celui-ci fonctionne:

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

N'oubliez pas de vérifier que le service udev fonctionne. Cela est particulièrement utile lorsque partprobe, hdparm, blockdev et diverses autres commandes ne semblent pas faire de différence quant aux fichiers de périphérique disponibles dans le répertoire/dev /.

0
kerolasa