Son güncelleme:

Bu sorunu çözmek için ne yapmam gerektiğini zaten biliyordum; Sadece nasıl yapacağımı bilemedim . Bunu otomatik olarak yapmak için hazır bir araç olacağını umuyordum - ancak bulamadım. Rod'un cevabını kabul ediyorum, çünkü doğrudan sorunumu çözmeme rağmen, sektörün büyüklüğü konusunda çok iyi bir arka plan veriyor ve konunun gerçekten bölünme ve hitap etme konusunda bana güven verdi. Bu soruna aynı soruna gelenler için, herhangi bir şey yapmadan önce yorumlar da dahil olmak üzere, dikkatlice ve dikkatlice okuyun.

Başlangıçta

Bilgisayarım vardı ve daha fazla alana ihtiyacım var 500 GB'lık yeni bir sürücü ve bir USB kasası aldım. Yakında, sürücüyü kasaya bölmüştüm ve bilgisayara taşıdım, bölmeleri (ve tersi) tanımayacağını fark ettim. Muhafaza ile ilgili bir sorun olduğunu varsaydım ve endişelenmedim.

O zaman, trajedi

Harika bir gün, bilgisayarım artık açılmaya karar verdi. Anakart ortaya çıktı (markasız, üzerine basılmış olan ÇİN'DE ÇOK MADE) öldü. Bir dosya sunucusu olarak kullanıyorum ve 500 GB'lık bir disk artık kaybedemeyeceğim verilerle dolu. Şimdi kırıldım ve yeni bir bilgisayar alamam, bu yüzden tek umudum "kusurlu" USB muhafazasıydı.

Soruşturma

Çeşitli Linux dağıtımları, bir dizüstü bilgisayar, VirtualBox ve kapalı kasa ile donanmış durum hakkında adli bir analiz yaptım. dmesg, bölüm boyutunun sürücü sonunun ötesinde olduğunu bildirdi. Bu yüzden sabit disk veri sayfalarına baktım, hesaplanan sektör sıfırdan sayım yaptı, sürücü sınırlarını dd ile manuel olarak test etti ve fdisk'i başlatana kadar şunu söyledi:

    Note: Sector size is 4096 (not 512).

Fdisk ne kadar mütevazı. Bu "not" tüm sorunların kökü idi. Biraz daha karışıklıktan sonra bu sonuçlar çıkarıldı:

• USB muhafazası arızalı değil.

• Ölü anakart üzerindeki SATA denetleyicisi, en azından "tuhaf" olanı. İşletim sistemine 4096 bayt sektör bildirmedi, bu nedenle OS 512 bayt sektör adreslerini kullanarak MBR'yı mutlu bir şekilde oluşturdu.

• Şimdi bölüme erişmeye çalıştığımda, işletim sistemi 512 bayt tabanlı adresleri 4096 bayt sektördeki bir sürücüde kullanmaya çalışıyor ve elbette işe yaramayacak.

Soru

• Öyleyse, MBR'deki adresleri nasıl düzeltebilirim ki, 4096 bayt sektör boyutunda MBR'yi onaltılı düzenleyicide el ile düzenlemenin yanı sıra geçerli olurlar ve

• Bölümler, 4096 bayt sektörler için hizalı değil. Başka bir sürücünün içine ve dışına kopyalamayı bir kenara koyacak bir araç var mı? (Yedek disklerim yok), yoksa verileri bir kenara biraz kaydırıp "kaydırır" bazı araçlar oluşturmam gerekir mi? Bölümler ext3.

Teşekkürler!

Güncelleştirme:

Bu sorudaki bölümü kaydırmak için dd kullanmanın akıllıca bir yolu olduğunu gördüm: Bir bölüm GNU / Linux'ta nasıl taşınır? Ama yine de bir sektör diliminde çalışıp çalışmayacağını bilmiyorum. Şu anda test edemiyorum, ancak zamanım olduğunda yapacak.

Güncelleme 2:

Bu nedenle, yukarıdaki yöntemi kullanarak bölümü başarıyla hizaladım ve onaltılı düzenleyicide MBR'yi elden düzenledik. HDD’yi yeniden taktığımda, bom bölümü otomatik olarak monte edildi! Ancak bunu önermiyorum, işlem sırasında G / Ç hataları vardı ve her şeyini kaybedebilirdim, Rod'in cevabı hakkında yorumlara bakın. Diğer bölüm için risk almayacağım ve eski bir HDD kullanacağım ve parçaları kopyalayarak ve ardından farklı bir konuma tekrar yapıştırarak aynı anda hizalayacağım.

Sektör büyüklüğü sorunları oldukça karmaşık hale geliyor. 2009'un sonuna kadar, sabit disklerin büyük çoğunluğu 512 bayt sektör kullandı ve bu kadardı. 2009 yılının sonlarında, disk üreticileri 4096 bayt sektörleri kullanan Gelişmiş Format (AF) diskleri sunmaya başladılar . Bu ilk AF diskleri (ve AFAIK, bugün tüm AF diskleri), her 4096 bayt fiziksel sektörü sekiz 512 baytlık mantıksal sektöre bölündüğünü gösteren bilgisayara bir arayüz sunar . Bu dönüştürme, çalışmaya devam etmek için 512 baytlık varsayımlarla oluşturulan birçok BIOS da dahil olmak üzere eski araçların kullanılmasına olanak sağlar. Diskinizin AF kullanıp kullanmadığını bilmiyorum, ancak her iki durumda da, neredeyse kesinlikle bir 512 bayt mantıksal kesim boyutu kullanıyor, yani işletim sistemi arabiriminin 512 bayt kesim kullanması gerektiği anlamına geliyor.

Karmaşık konular bazı USB disk muhafazalarıdır. Bu muhafazaların bazıları AF'nin yaptıklarının tersini yapar: Sekiz disk sektörünü alır ve bunları yeni bir 4096 bayt sektörde bir araya getirir. Bu hareketin arkasındaki nedenin ne olduğundan emin değilim, ancak pratik avantajlardan biri, 2 MB'den büyük disklerin eski MBR bölümleme sistemiyle kullanılabiliyor olmasıdır. En büyük dezavantaj, bu muhafazalardan birinde bölümlenmiş bir diskin doğrudan veya bu çeviri türünü yapmayan bir kutuda kullanılamamasıdır. Aynı şekilde, bu çeviri olmadan hazırlanan bir disk böyle bir kasaya aktarıldığında kullanılamaz. Bu sorunun MBR'nin kendisinin ötesine geçtiğini unutmayın; diskiniz ilk bölümü (512 bayt) sektör 2048'de başlıyor olarak tanımlayabilir, ancak işletim sisteminiz (4096 bayt) sektör 2048'i aramak istiyorsa,bu bölümün başlangıcını bul! Bu problemle karşılaştın. Bu nedenle, ilk olarak USB kasasının arızası olduğunu düşündüğünüz işaret, anakartınızın bozduğunu düşündüğünüzden daha yakındır. Ben ettik asla bu şekilde bir anakart çeviri sektörü büyüklüğünün duydu. (Bazı donanım RAID aygıtları bunu yapar.)

Linux'u sektör boyutuyla ilgili fikrini ayarlamaya zorlamanın bir yolunu bilmiyorum, ancak yeterli disk alanınız varsa, düşük seviyeli bir disk kopyasının başka bir diske kopyalanması yardımcı olabilir. Örneğin:

dd if=/dev/sdb of=~/image.img

Bu, diskinizi /dev/sdb(USB diski; gerektiği gibi ayarlayın) dosyaya kopyalar ~/image.img. Görüntünün bölümlerini monte etmek için aşağıdaki betiği kullanabilirsiniz:

#!/bin/bash
gdisk -l $1 > /tmp/mount_image.tmp
let StartSector=`egrep "^   $2|^  $2" /tmp/mount_image.tmp | fmt -u -s | sed -e 's/^[ \t]*//' | head -1 | cut -d " " -f 2`

let StartByte=($StartSector*512)

echo "Mounting partition $2, which begins at sector $StartSector"

mount -o loop,offset=$StartByte $1 $3

rm /tmp/mount_image.tmp

Komut dosyasını söyleyin mount_imageve şöyle kullanın:

./mount_image ~/image.img 2 /mnt

Bu bölünmesini 2 monte edecek image.imgkadar /mnt. Komut dosyasının , çoğu dağıtımın veya adlı bir pakette içerdiği GPT fdisk ( gdisk) işlevine dayandığını unutmayın .gptfdiskgdisk

Uzun vadede, sektör boyutu çevirisini yapmayacak diski bağlamak için daha iyi bir çözüm bulmaktır. Yeni bir anakartla doğrudan bağlantı, hile yapmalı; veya muhtemelen çeviriyi yapmayan bir dış kasa bulabilirsiniz. Aslında, bazı kasalar çeviriyi USB bağlantı noktalarında yapar ancak eSATA bağlantı noktalarında yapmaz, bu nedenle kasanızın bir eSATA bağlantı noktası varsa, bunu kullanmayı deneyebilirsiniz. Bu çözümlerin, size sahip olmadığınızı söyleyeceğiniz paraya mal olacağının farkındayım, ama belki de çeviri kasanızı çeviriyi yapamayan biri için takas edebilirsiniz.

Başıma gelen bir seçenek de VirtualBox gibi bir sanal makine kullanmayı denemek. Böyle bir araç, çeviriyi etkin bir şekilde geri alarak, disk cihazına erişirken 512 baytlık bir sektör büyüklüğü alabilir; veya dd if=/dev/sdc of=/dev/sdbsanal makine içindeki diskin içeriğini ham ( içeride olduğu gibi ) kopyalayabilirsiniz, bu da içeriği sıkıştırmayla kopyalar ve böylece görüntünün orijinalden daha az disk alanına sığmasını sağlar.

Bu senaryo, bir Baskın ya da Kripto bulunduğunda, Rod Smith'in önerisini genelledi. Garanti yok. Bunu geliştirmek için çekinmeyin! (Mdadm hakkında en son bulgularla güncellendi)

#!/bin/sh
#
# This script solve the following problem:
#
# 1. create a GPT partition on a large disk while attached directly via SATA
#    when the device present itself with 512 bytes of block size:
#    sd 3:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 2. try to use a SATA to USB adapter like ID 067b:2773 Prolific Technology, Inc.
#    this present the device with 4096 bytes of block size:
#    sd 19:0:0:0: [sdc] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 3. The kernel is unable to read correctly the partition table with
#    the USB adaper.
#
#
# With the current tools (kernel and gdisk) in debian wheezy is
# possible to use losetup to remap the partitions to loop devices so
# you can use them as usual with any filesystem, raid or crypto
#
# I still do not know if this issue is originated by the adapter or by
# the disk and if there are any others workarounds.
#
# Known version of the software:
# $ apt-show-versions linux-image-3.2.0-4-amd64
# linux-image-3.2.0-4-amd64/wheezy uptodate 3.2.54-2
# $ apt-show-versions gdisk
# gdisk/wheezy uptodate 0.8.5-1


attach_device() {

    device="$1";

    MYTMPDIR=`mktemp -d`
    trap "rm -rf $MYTMPDIR" EXIT

    # gdisk on the device use the 4096 sector size
    # but we need to force it to 512
    # this is a knwon workaround from http://superuser.com/a/679800
    # basically we make a copy of the gpt partition table on a file
    dd if="/dev/$device" bs=16384 count=1 of="$MYTMPDIR/gpt" 2> /dev/null

    # we extract the offset and the size of each partition
    #
    # FIXME: the "+ 1" seems strange, but it is needed to get the same
    #        size value from:
    #
    #        blockdev --getsize64
    #
    #        without the "+ 1" some funny things happens, for example
    #        you will not be able to start a recognized md device:
    #
    #        md: loop1 does not have a valid v1.2 superblock, not importing!
    #        md: md_import_device returned -22
    #
    #        even if
    #
    #        mdadm --examine /dev/loop1
    #
    #        does not complaint

    gdisk -l \
     "$MYTMPDIR/gpt" 2> /dev/null | \
     awk '/^ *[0-9]/ {printf "%.0f %.0f\n", $2 * 512, ($3 - $2 + 1) * 512}' > $MYTMPDIR/offset-size

    # we create a loop device with the give offset and size
    while read line;
    do
        offset=$(printf "$line" | cut -d ' ' -f 1);
        size=$(printf "$line" | cut -d ' ' -f 2);
        losetup --verbose --offset "$offset" --sizelimit "$size" `losetup -f` /dev/$device;
    done < $MYTMPDIR/offset-size;
}

detach_device() {

    device="$1";

    for loopdevice in `losetup -a | grep "$device" | cut -d : -f 1`;
    do
        losetup --verbose --detach "$loopdevice";
    done;
}

usage() {
cat <<EOF
Usage:
- $0 -h to print this help
- $0 sda to attach the gpt partitions of sda
- $0 -d sda to detach the gpt partitions of sda
EOF
}


detach=0;

while getopts hd action
do
    case "$action" in
        d) detach=1;;
        h) usage;;
    esac
done
shift $(($OPTIND-1))

if [ $# -ne 1 ];
then
    usage;
fi

if [ "x$detach" = "x0" ]; then
    attach_device $1;
else
    detach_device $1;
fi

Bunu yapmanın oldukça basit bir yolu da, partinin kurtarma işlevini kullanmak. Bu, yeni bir disk etiketi oluşturmanızı gerektirir, bu yüzden riskleri içerir. Parted doğrudan diske etki eder bu yüzden parted çalıştırmadan önce gerekli yedeklemeleri yapın. Sonra başlat:

parted /dev/sdb

bölümlenmiş, bölüm tablosunun oluşturulduğundan farklı sektör boyutuna sahip bir diski okumaya çalışırken bu satırlar boyunca size bir şey söyleyecektir:

Error: /dev/sdb: unrecognised disk label                                  

Daha önce kullandıklarınıza göre yeni bir MBR veya GPT oluşturmak için mklabel kullanın.

(parted) mklabel
New disk label type? mbr

Ardından eski bölümünüzü bulmak için kurtarmaya gidin

(parted) rescue
Start? 0
End? 4001GB
Information: A ext4 primary partition was found at 1049kB -> 2000GB.  Do you
want to add it to the partition table?
Yes/No/Cancel? y

Daha fazla bölümünüz varsa kurtarma işlemini tekrarlayın. Şimdi bitti.

WD My Book harici kasasından bir 4TB diski çıkardığımda bu sorunu yaşadım. Problem şu:

1. MBR bölümleme tablosu 8 faktörü ile kapalıdır ve
2. Sektör boyutu 512 olduğunda MBR bölümleme tablosu> 2TB'yi işleyemez.

Çözüm: 512 bayt sektörleri kullanmak için değerleri dönüştürerek bölüm tablosunu bir GPT'ye yeniden yazın.

Benim durumumda bölüm 1 MB'lık bir ofsetle başladı ve disk bitmeden önce (~ 856kB) bitti. Bu iyidir, çünkü bölümden önce MBR + GPT (17408 bytes) ve diskin sonundaki yedek GPT'ye (16896 bytes) izin verilir.

Her iki bölgenin de resimlerini dd kullanarak çekmiştim.

Çıkışını not aldım fdisk -l /dev/sde.

İlk bölümü silmek için gdisk kullandım. İsterseniz, yaptığım gibi yapabilirsiniz ve mümkün olduğunca fazla boşluk kullanmak için hizalama değerini 8 (4096) olarak değiştirebilirsiniz. Daha sonra, 2048'de başlayan ve diskin sonunda bulunan yeni bir bölüm oluşturdum. Daha sonra dosya sistemini büyüteceğim.

Neyse ki, sektör boyutundaki değişiklik dosya sistemini, LVM'yi veya LUKS'i etkilemiyor.