web-gelistirme-sc.com

Bölüm tablosunu yeniden başlatmadan tekrar oku?

Bazen, bir diskteki bölümlerle yeniden boyutlandırırken veya başka bir şekilde mucking yaparken cfdisk şunları söyler:

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

(Bu diğer bölümleme araçlarıyla da olur, bu yüzden bunun cfdisk sorunu yerine bir Linux sorunu olduğunu düşünüyorum.) Neden bu ve neden sadece bazen ve ne yapabilirim? önlemek için?

Not: Lütfen gerçekten düzenlemekte olduğum bölümlerin hiçbirinin açık, monte edilmiş veya kullanımda olmadığını varsayalım.

Güncelleme:

cfdisk, Linux'a bölüm tablosunu yeniden okumasını söylemek için ioctl(fd, BLKRRPART, NULL) kullanır. Şimdiye kadar önerilen diğer araçlardan ikisi (hdparm -zDEVICE, sfdisk -RDEVICE) tamamen aynı şey. partprobeDEVICE komutu ise BLKPG adlı yeni bir ioctl kullanıyor gibi görünüyor ki bu daha iyi olabilir; Bilmiyorum. (BLKPG başarısız olursa da BLKRRPART'a geri döner.)

BLKPG "bu bölüm değişti; işte yeni boyut" işlemi gibi görünüyor ve partprobe gibi görünüyordu, cihazdaki tüm bölümlerde ayrı ayrı çağırdı, bu yüzden ayrı bölümler kullanılmayan. Ancak, bunu deneme fırsatım olmadı.

partitionfdisklinux
71
Teddy

IMHO en güvenilir/en iyi cevap

partprobe /dev/sdX
68
knweiss

Bölüm tablosu bilgilerini yeniden okuma her zaman işe yaramaz, ancak deneyin

hdparm -z /dev/sda

veya

sfdisk -R /dev/sda

Çalışırsa/proc/bölümlerdeki değerler değişecektir.

19
ko-dos

Centos7'de:

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

Denemelisin :

partx -u <partition>

Benim için çalıştı.

10
uus

Not: Lütfen gerçekten düzenlemekte olduğum bölümlerin hiçbirinin açık, monte edilmiş veya kullanımda olmadığını varsayalım.

Bu varsayım dikkate alındığında, bölüm tablosu can başarıyla yeniden taranabilir ve sorun ortaya çıkmaz. Bu hatayı alıyorsanız, bölüm tablosu is şu anda kullanımdadır ve bu nedenle tutarsızlıklar oluşturulmadan yeniden taranamaz.

8
womble

Düzenlemekte olduğunuz bölüme dayalı değildir.

Yalnızca bir sabit diskiniz (/dev/sda) Ve iki bölümünüz (/dev/sda1, /dev/sda2) Olduğunu ve yalnızca bir disk bölümünüz olduğunu varsayalım (/dev/sda1). Hatta bağlı olmayan diğer bölümle ilgili herhangi bir şeyi silerseniz veya değiştirirseniz (/dev/sda2) Bölüm tablosunun yeniden okunmasında başarısız olur ve çekirdek eski tabloyu kullanır.

Ancak iki sabit diskiniz varsa (/dev/sda, /dev/sdb) Ve (/dev/sdb) Bölümlerinin hiçbiri kullanılmıyor. Daha sonra /dev/sdb Bölümlerini ekleyebilir/silebilir/yeniden boyutlandırabilir/düzenleyebilirsiniz; bunlar sorunsuz bir şekilde yeniden okunur. Ancak değişiklik sırasında/dev/sdb'nin bir bölümü monte edilmiş olsa bile. Sonra çekirdek eski tabloyu kullanmaya devam edecektir.

6
Saurabh Barjatiya

Ben (asıl soru soran) birkaç gün önce diğer cevaplardan hiçbirinin (partprobe /dev/sdX, şu anda kabul edilen ve en çok oy verilen cevap) çalıştı. Ancak işe yarayan işe yarayan şuydu:

blockdev --rereadpt /dev/sdX

(Bunun neden işe yaradığını bilmiyorum ve diğerleri işe yaramadı, ancak meşgul bir sunucuda yeniden başlatmamı sağladığı için işe yaradığı için mutluyum.)

5
Teddy

6.5 x64 centos üzerindeyim; çekirdek 2.6.32. ve yeniden boyutlandırmak için fdisk hilesini test ediyorum.

/dev/sda1 /boot
/dev/sda2 /

Aşağıdaki tüm komutlar değil çekirdeği yeniden okuma bölümü yaptı:

  • partprobe/dev/sda (uyarı: çekirdek tekrar okunamadı ....)
  • hdparm -z/dev/sda (BLKRRPART başarısız oldu: cihaz veya kaynak meşgul)
  • blockdev -rereadpt/dev/sda (BLKRRPART başarısız oldu: cihaz veya kaynak meşgul)
  • sfdisk -R/dev/sda (BLKRRPART başarısız oldu: cihaz veya kaynak meşgul)

çalışması için hala yeniden başlatmaya ihtiyacım var

5
Max

Tüm montaj noktaları sökülmüşken, Yocto 2.4'ü çalıştırın:

partprobe /dev/sda

Aygıtta bölümler silindikten sonra bölüm tablosunu yeniden yükleyemedim. Ayrıca denendi - ve başarısız oldu:

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

Tüm benzer "BLKRRPART başarısız oldu: aygıt veya kaynak meşgul ..." hataları yeniden başlatmamı bildiriyor. Daha önce çalışma yöntemlerinin başarısızlığı, muhtemelen udev'in şimdi systemd kontrolü altında olması nedeniyle mi? Denediğim bu çizgiler boyunca:

systemctl restart systemd-udevd.service

Ve aniden diskim tekrar kullanılabilir, yeniden başlatmadan!

3
Camp Waub-O-Jeeg

Ayrıca deneyebilirsiniz:

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

(Ama işe yaramaz, aşağıdaki yoruma bakın)

1
bogdano

blockdev --rereadpt /dev/sdX Gibi bir komut başarısız olduğunda

blockdev: ioctl error on BLKRRPART: Device or resource busy

bu genellikle bazı (eski) bölümlerin çekirdek tarafından hala bir şekilde kullanıldığı anlamına gelir.

Olası nedenler/düzeltmeler:

  1. bir sdX bölümü - diyelim ki sdX1 - hala bağlı - mount ile kontrol edin ve onu ekleyin
  2. /dev/sdX1 Yazılım baskısının bir parçasıdır - cat /proc/mdstat 'U kontrol edin ve muhtemelen ilgili dizileri durdurun, ör. mdadm --stop /dev/md126
  3. /dev/sdX1 Bir LVM fiziksel biriminin bir parçasıdır - pvdisplay/vgdisplay ile kontrol edin ve muhtemelen vgchange ile devre dışı bırakın
  4. /dev/sdX1 Bazı cihaz eşlemelerinin bir parçasıdır - ör. cryptsetup - /dev/mapper ve lsblk üzerinden kontrol edin ve muhtemelen eşlemeyi kaldırın (örneğin cryptsetup luksClose)
  5. Bazı udev problama ile yarış durumu - ps ile çalışan işlemleri kontrol edin ve muhtemelen birini öldürün

Bir araç - blockdev --rereadpt Genellikle (partx -uv, kpartx, partprobe, kpartprobe) gibi benzer araçlarda başarısız olursa kök neden ortadan kaldırılıncaya kadar.

1
maxschlepzig

kpartx -a <partition> sistemi yeniden başlatmak yerine .... yeni oluşturulan bölüm üzerinde iki kez çalıştırılabilir.

0
Kailas Kadam

Benim için partprobe veya blockdev çözümü işe yaramadı. Bununla birlikte, bu işe yarıyor:

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

Udev hizmetinin çalışıp çalışmadığını kontrol etmeyi unutmayın. Bu, özellikle partprobe, hdparm, blockdev ve diğer çeşitli komutların/dev/dizininde hangi aygıt dosyalarının kullanılabilir olduğunu fark etmediği durumlarda kullanışlıdır.

0
kerolasa