Rileggere la tabella delle partizioni senza riavviare?

A volte, quando si ridimensiona o si scherza con le partizioni su un disco, cfdisk dirà:

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

(Ciò accade anche con altri strumenti di partizionamento, quindi sto pensando che si tratti di un problema di Linux piuttosto che di un cfdisk.) Perché è questo e perché succede solo a volte e cosa posso fare per evitarlo?

Nota: supponiamo che nessuna delle partizioni che sto effettivamente modificando sia aperta, montata o altrimenti utilizzata.

Aggiornare:

cfdisk usa ioctl(fd, BLKRRPART, NULL)per dire a Linux di rileggere la tabella delle partizioni. Due degli altri strumenti consigliati finora ( hdparm -z DEVICE, sfdisk -R DEVICE) fanno esattamente la stessa cosa. Il partprobe DEVICEcomando, d'altra parte, sembra usare un nuovo ioctl chiamato BLKPG, che potrebbe essere migliore; Non lo so. (Ritorna anche su BLKRRPART se BLKPG fallisce.)

BLKPG sembra essere un'operazione "questa partizione è cambiata; ecco la nuova dimensione", e sembrava partprobechiamarla individualmente su tutte le partizioni sul dispositivo passate, quindi dovrebbe funzionare se le singole partizioni non vengono utilizzate. Tuttavia, non ho avuto l'opportunità di provarlo.

IMHO è la risposta più affidabile / migliore

partprobe /dev/sdX

Rileggere le informazioni sulla tabella delle partizioni non sempre funziona, ma provare

hdparm -z /dev/sda

o

sfdisk -R /dev/sda

Se funziona, i valori in / proc / partitions cambieranno.

Su Centos7:

Secondo https://access.redhat.com/solutions/199573

Dovresti provare :

partx -u <partition>

Ha funzionato per me.

Nota: supponiamo che nessuna delle partizioni che sto effettivamente modificando sia aperta, montata o altrimenti utilizzata.

Dato questo presupposto, la tabella delle partizioni può essere rieseguita con successo e il problema non si presenta. Se ricevi questo errore, è perché la tabella delle partizioni è attualmente in uso e quindi non può essere scansionata nuovamente senza creare incoerenze.

Non si basa sulla partizione che si sta modificando.

Supponiamo di avere solo un disco rigido ( /dev/sda) e due partizioni ( /dev/sda1, /dev/sda2) e di aver montato solo una partizione ( /dev/sda1). Se elimini o modifichi qualcosa su un'altra partizione che non è nemmeno montata ( /dev/sda2) otterrai l'errore che la rilettura della tabella delle partizioni non è riuscita e che il kernel userà la vecchia tabella.

Ma se hai due hard disk ( /dev/sda, /dev/sdb) e nessuna delle partizioni di ( /dev/sdb) è in uso. Quindi è possibile aggiungere / eliminare / ridimensionare / modificare le partizioni /dev/sdbe verranno rilette senza alcun problema. Ma anche se una partizione di / dev / sdb è stata montata durante il cambio. Quindi il kernel continuerà a usare la vecchia tabella.

Io (l'interrogatore originale) ho avuto una situazione qualche giorno fa in cui nessuna delle altre risposte (inclusa partprobe /dev/sdX, attualmente la risposta accettata e più votata) ha funzionato. Ciò che ha funzionato, tuttavia, è stato questo:

blockdev --rereadpt /dev/sdX

(Non so perché questo abbia funzionato e gli altri no, ma sono contento che abbia funzionato, poiché mi ha salvato un riavvio su un server occupato.)

sono su centos 6,5 x64; kernel 2.6.32. e sto testando il trucco di fdisk per ridimensionare.

/dev/sda1 /boot
/dev/sda2 /

Tutti i seguenti comandi non hanno fatto eseguire la rilettura della partizione del kernel:

• partprobe / dev / sda (attenzione: il kernel non è riuscito a rileggere ....)
• hdparm -z / dev / sda (BLKRRPART non riuscito: dispositivo o risorsa occupata)
• blockdev -rereadpt / dev / sda (BLKRRPART non riuscito: dispositivo o risorsa occupata)
• sfdisk -R / dev / sda (BLKRRPART non riuscito: dispositivo o risorsa occupata)

ho ancora bisogno di un riavvio per farlo funzionare

Con tutti i punti di montaggio smontati, con Yocto 2.4 in esecuzione:

partprobe /dev/sda 

Impossibile caricare nuovamente la tabella delle partizioni dopo che le partizioni sono state eliminate sul dispositivo. Anche provato - e fallito sono stati:

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

Tutti hanno riportato errori simili "BLKRRPART non riusciti: dispositivo o risorsa occupata ..." che mi indicavano di riavviare. Questo fallimento di metodi precedentemente funzionanti è forse dovuto al fatto che udev è ora sotto il controllo del sistema? Pensando in tal senso ho provato:

systemctl restart systemd-udevd.service

E improvvisamente il mio disco è nuovamente disponibile, senza riavvio!

Quando un comando come blockdev --rereadpt /dev/sdXfallisce

blockdev: ioctl error on BLKRRPART: Device or resource busy

questo di solito significa che alcune (vecchie) partizioni sono effettivamente ancora in qualche modo utilizzate dal kernel.

Possibili cause / correzioni:

1. una partizione SDX - diciamo sdX1- è ancora montata - controlla mounte smonta
2. /dev/sdX1fa parte di un raid software - controlla cat /proc/mdstated eventualmente ferma gli array rilevanti, ad esmdadm --stop /dev/md126
3. /dev/sdX1fa parte di un volume fisico LVM: verificare con pvdisplay/ vgdisplaye possibilmente disattivarlo convgchange
4. /dev/sdX1è parte di alcuni mappatura dispositivo - ad esempio tramite cryptsetup- controllare /dev/mappered lsblkeventualmente eliminare la mappatura (es cryptsetup luksClose)
5. Condizioni di gara con alcuni sondaggi udev - controlla i processi in esecuzione con psed eventualmente uccidine uno

Se uno strumento - dire blockdev --rereadptnon quelli normalmente simili come ( partx -uv, kpartx, partprobe, kpartprobe) sicuro in modo analogo fino la causa principale viene eliminata.

Puoi anche provare:

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

(Ma non funzionerà, vedi il commento qui sotto)

kpartx -a <partition> può essere eseguito due volte sulla partizione appena creata .... invece di riavviare il sistema.

Ricordarsi di verificare che il servizio udev sia in esecuzione. Ciò è particolarmente utile quando partprobe, hdparm, blockdev e vari altri comandi non sembrano fare alcuna differenza sui file di dispositivo disponibili nella directory / dev /.

Per me né partprobeo blockdevsoluzione ha funzionato. Anche se questo funziona:

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

Se leggi la manpage di "man oracleasm-scandisks" noterai il testo qui sotto. oracleasm sta usando / proc / partitions come la fonte di tutte le scansioni che esegue. Devi avere i tuoi dispositivi grezzi elencati in / proc / partitions prima di poter fare uno scandisk. I parametri Scanorder e Scanexclude inseriti in / etc / sysconfig / oracleasm si riferiscono ai nomi trovati in / proc / partitions (!!!!).

---------- man oracleasm-scandisks ------ ...

COME SI EFFETTUA LA SCANSIONE La scansione procede in quattro fasi di base.

   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.