Linux, geçici olarak çöktükten sonra HDD durumunu ReadOnly'dan nasıl değiştirebilirim?


17

Şu anda bu sorunla ilgilenmiyoruz.

Genellikle aygıtı engellemek için okuma veya yazı ile ilgili bazı sorunlardan sonra, çekirdek BÜTÜN CİHAZ için bayrağı salt okunur olarak değiştirmeye karar verir. Bundan sonra, bu cihazda bulunan herhangi bir bölüm / dosya sistemine yapılan yazılar, cihaz durumu ile birlikte salt okunur olarak değiştirilmesine neden olur, çünkü herhangi bir yazı imkansızdır.

Dmesg örneği, bu defrag konukların cihaz resmini çektiğinde VirtualBox kullanan windows8'deki konuk linux simülasyonudur:

[11903.002030] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11903.003179] ata3.00: failed command: READ FPDMA QUEUED
[11903.003364] ata3.00: cmd 60/08:00:a8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11903.003385]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11903.004074] ata3.00: status: { DRDY }
[11903.004248] ata3: hard resetting link
[11903.325703] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11903.327097] ata3.00: configured for UDMA/133
[11903.328025] ata3.00: device reported invalid CHS sector 0
[11903.329664] ata3: EH complete
[11941.000472] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11941.000769] ata3.00: failed command: READ FPDMA QUEUED
[11941.000952] ata3.00: cmd 60/08:00:c8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11941.000961]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11941.001353] ata3.00: status: { DRDY }
[11941.001504] ata3: hard resetting link
[11941.320297] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11941.321252] ata3.00: configured for UDMA/133
[11941.321379] ata3.00: device reported invalid CHS sector 0
[11941.321553] ata3: EH complete
[11980.001746] ata3.00: exception Emask 0x0 SAct 0x11fff SErr 0x0 action 0x6 frozen
[11980.002070] ata3.00: failed command: WRITE FPDMA QUEUED
[11980.002255] ata3.00: cmd 61/18:00:28:23:59/00:00:00:00:00/40 tag 0 ncq 12288 out
[11980.002265]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
-------------------
There are many other errors, like "lost write page", "Journal has aborted", "Buffer I/O error", "hard resetting link" and many others.

Bundan sonra, yeniden neden:

mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected

çünkü sda1 rootfs'i tutan WHOLE cihazı sda READONLY.

Benim durumumda bu, aşağıdaki durumlarda gerçekleşir:

  1. HDD gerçekten hasarlı. İade yazma sorunları HDD durumuna bağlıdır
  2. Ana makine aşırı yüklendi, ardından linux konuk sanal HDD yazıları zaman aşımına uğradı
  3. FC kablosu veya SAN cihazı (Fiber Kanal üzerinden dizi diskleri) aşırı yüklenmiş
  4. FC veya FCoE üzerinden anlık bağlantı kesildi. Belki kayıp / zaman aşımı olan FC paketi

Bu durumlarda cihaz gerçekten okuma-yazmadır, ancak linux çekirdeği bu cihazı dahili olarak salt okunur olarak işaretler ve salt okunur olarak kullanılır. Bu, hasarın önlenmesi için oluşturulmuş çekirdek işlevselliğidir, ancak yalnızca 1. noktada kullanılabilir.

Soru şu ki. Çekirdeğe manuel olarak nasıl söylenir, hdd blok cihazı normal çalışır?

Bunun üzerine, çekirdek hizmeti aygıtı 'CD-ROM' gibi salt okunur olarak sunulur ve mount / remount -o read-write, fsck ve diğerleri de dahil olmak üzere başka hiçbir komutun düzgün çalışma şansı yoktur.

Kullanılamaz yanıtlar, gerçekten yardım etmek isteyen ancak sorun niteliğini anlamayan kişilerden spam olarak nitelendirilmiş:

  1. Yeniden yazmayı okuma-yazma olarak deneyin (imkansız, cihaz RO)
  2. fsck this (ne için? cihaz RO, hiçbir onarım mümkün değildir)
  3. 'Bilmiyorum' (önce mantıklı ama kullanılamaz)
  4. 'Cihazınızı değiştirin' * (genellikle sorun başka bir şeydir)

Yukarıda soru için herhangi bir formül var mı? Salt okunur durumdan okuma-yazma durumuna geri döndüren yazılabilir blok aygıtı için bayrak değiştirilsin mi? Şu anda kimse nasıl olduğunu bilmiyor gibi görünüyor.

Bazı geçici çözümlerdir, ancak genellikle yarı yarıya veya kullanılamaz:

  1. Modül kaldır, belirtilen hdd veya depolama dizisine erişimi destekler. Ne yazık ki genellikle hasarlı aygıt rootf'leri tutar veya sürücü hem hasarlı aygıtı hem de rootf'leri tutan aygıtı tutar
  2. Cihaza FC erişimini kaldırın ve buna tekrar katılın (fctools), her zaman mümkün değil, her zaman işe yaramıyor.
  3. BÜTÜN makineyi yeniden başlatın. Genellikle sadece bu her zaman mümkündür ve hep zorlanırız.

1. ve 2. noktalarda, çekirdeğe cihazın bağlantısını tamamen kesip tekrar bağladığımızı söylüyoruz. Çekirdek bunu doğru şekilde çalışan yeni bir aygıta katmak olarak kabul etti. Bunu USB cihazı ve anlık kaldırma gücünü kullanarak simüle edebiliriz. 3. nokta son şanstır ve genellikle işe yarar. Ama neden hepsini yeniden başlatmalıyız? Maalesef her noktada tüm dergi güncellemelerini ve kirli arabellekleri kaybettik.

Dikkat edin, aynı durumlarda Windows (masaüstü ve sunucu) ile hiçbir sorunum yok.


Yanıt değil, ancak muhtemelen # 2 (yüksek ana bilgisayar yükü, konuk hdd zaman aşımı) durumunda ilgili: Konuk sistemindeki hdd zaman aşımlarının neden olduğu dosya sistemi bozulmasını önlemek için Linux hdd zaman aşımını artırın.
basic6

@Znik, bu konuk sanal makineler Citrix XenServer üzerinde çalışıyor mu? Yoksa fiziksel donanım mı? StorageServer'ımız, ethernet ülkesinden mini sas ülkesine köprü kurar. Bu köprü makinesi paniklediğinde, zorla yeniden başlatılması gerekir. Windows konuk VM'leri geri gelir. Linux konuk sanal makineleri aynı sorunu sergiliyor. Burada önerilen hiçbir şey bağlama noktalarını geri döndürmez.
rjt

@rjt, bu birçok durumda ortaya çıkar. Ana durum, cihazın fiziksel hasar, cihaz aşırı yüklenmesi, kablolama, Eth ve eth üzerinden harici FC aşırı yüklenmesi gibi bazen aşırı derecede yavaşladığı, bazen transfer bloğu, zaman aşımı, kayıp paket vb. ancak salt okunur olarak işaretlendi. Yeniden başlatma çözüm değildir, ana soru / sorun açıklamasında açıkladığım şekilde geçici bir çözümdür.
Znik

Yanıtlar:


12

ile dene blockdev --setrwveyahdparm -r 0


teşekkürler, bu yararlı olmalı.
FC

Eklenmesi gereken önemli bir bölüm: Bazen fscktekrar monte edilebilmesi için önce salt okunur dosya sisteminde bir yapılması gerekir.
Evi1M4chine

3
Benim için işe yaramaz. benzer bir sorunum var
jonneymendoza

1
Fsck ile bile benim için çalışmadı. Citrix XenServer Linux konukları.
rjt

Çalışmıyor ! Bu komutlar etkili görünüyor, ancak donanım kilidi hala RO. (yazılım, ama nereden ???) Denemek istiyorsanız, herhangi bir Debian iso 9.4 alın.
Sandburg

5

Jose Luis Martin'in blockdev kullanımını önerdiği gibi, benim 2cent bir rw rw ve forcefsck yapmak

(sda'nın sizin diskiniz olduğunu varsayalım)

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck

1
Daha fsckönce koşmak daha mantıklıdır mount, çünkü olmadan monte edilemez fsck. (En azından benim durumumda oldu.)
Evi1M4chine

`# blockdev --setrw / dev / xvda1 # # touch / tmp / date +%Y%m%d-%H%M%Stouch: dokunamıyor musunuz? / tmp / 20170722-221904 ?: Salt okunur dosya sistemi # # mount -o remount, rw / dev / xvda1 [137010.709883] EXT4 -fs hatası (cihaz xvda1): ext4_remount: 4824: Kullanıcı montajı tarafından zorla iptal: cihaz / dev / xvda1 okuma-yazma işlemini yeniden bloklayamaz, yazma korumalı `
rjt

2

Bu wiki sayfasını kontrol edin, libata tarafından atılan hatayı açıklar:

https://ata.wiki.kernel.org/index.php/Libata_error_messages

Yukarıda gördüğüm kadarıyla, zaman aşımı sorunu var ve belirtilen belgeye göre:

Denetleyici etkin bir ATA komutuna yanıt veremedi. Bu, herhangi bir sayıda sebep olabilir. Çoğu zaman bu, donanımdan bir tane beklediğimizde bir kesinti sağlamayan, ilişkisiz bir kesme alt sistemi hatası ('pci = nomsi' veya 'acpi = off' veya 'noapic' ile önyüklemeyi deneyin) nedeniyle oluşur.

ACPI'yi devre dışı bırakmak (dağıtımınıza nasıl dayanacağınızı kontrol edin) veya bilinen hatalar için çekirdeğinizi kontrol etmek ve muhtemelen en son değilse (veya eski sürüme geçirmiyorsanız) güncellemek isteyebilirsiniz.


Evet, bu gerçekten zaman aşımı. Genellikle bu, dizi cihazı aşırı yüklendiğinde FC kontrol cihazında meydana gelir. Haklısınız, yerel ATA alt sisteminde bu genellikle herhangi bir donanım hatası veya sürücü / yonga seti uygulamasıdır
Znik

Yani bir zaman aşımı mı? Ne sudo hdparm -I /dev/sdX | grep lockeddiyor? Bu gerekir ki: 'kilitli değil'. Bir HDD ATA parolasıyla kilitlendiğinde (bu önceki güvenlik silmesinden ve daha sonra güvenlik pw'sinin tekrar temizlenmemesine neden olan bir sistem çökmesinden dolayı) geçmişte bu esrarengiz zaman aşımlarını gösterdi . Bu parolaların gerçekten de sinirleriniz üzerinde büyük bir etkisi vardır . :) HD sürücü satıcınız tarafından gönderilen standart araçlar bile, parola etkinken HDD ölmek üzereymiş gibi çılgınca davranır. Yıllar içinde yırtılmış saç sayısız tutamlar için suçlu.
syntaxerror

1

Windows 10'da yeniden başlatın, güç seçeneklerine gidin ve hızlı kapatmayı kapatın. sonra linux ..gbamm her şeyi yeniden başlatın.

Windows 10'da hızlı kapatma bazı dosyaları hazırda bekletir ve sürücü kısmen kullanılır. linux'un gördüğü kadar meşgul.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.