Cập nhật cuối cùng:

Tôi đã biết những gì tôi cần làm để khắc phục vấn đề này; Tôi chỉ không biết làm thế nào để làm điều đó. Tôi đã hy vọng sẽ có một số công cụ làm sẵn để tự động làm điều đó - nhưng không thể tìm thấy bất kỳ công cụ nào. Tôi chấp nhận câu trả lời của Rod vì mặc dù không trực tiếp giải quyết vấn đề của tôi, nhưng nó cho một nền tảng rất tốt về vấn đề quy mô ngành và khiến tôi tự tin rằng vấn đề thực sự là liên kết phân vùng và giải quyết. Đối với những người đi đến câu hỏi này có cùng một vấn đề, hãy đọc kỹ và cẩn thận, bao gồm cả ý kiến, trước khi làm bất cứ điều gì.

Ở thời điểm bắt đầu

Tôi đã có một máy tính và cần thêm dung lượng Tôi đã mua một ổ đĩa 500 GB mới và một hộp đựng USB. Ngay sau đó tôi đã nhận thấy rằng nếu tôi phân vùng ổ đĩa trên vỏ và di chuyển nó vào máy tính, nó sẽ không nhận ra các phân vùng (và ngược lại). Tôi cho rằng đó là một vấn đề với vỏ bọc và không lo lắng về nó.

Sau đó, bi kịch

Một ngày tuyệt vời, máy tính của tôi quyết định không bật nữa. Hóa ra bo mạch chủ (không có thương hiệu, chỉ là một MADE IN TRUNG QUỐC lớn được in trên đó) đã chết. Tôi đã sử dụng nó như một máy chủ tệp và ổ đĩa 500 GB đó hiện chứa đầy dữ liệu mà tôi không thể để mất. Bây giờ tôi đã phá vỡ và không thể mua được một máy tính mới, vì vậy hy vọng duy nhất của tôi là vỏ USB "bị lỗi".

Cuộc điều tra

Được trang bị một số bản phân phối Linux, máy tính xách tay, VirtualBox và bao vây tôi đã phân tích pháp y về vấn đề này. dmesg báo cáo kích thước phân vùng vượt quá cuối ổ đĩa. Vì vậy, tôi đã đi qua các bảng dữ liệu ổ cứng, tính toán số lượng khu vực từ đầu, kiểm tra ranh giới ổ đĩa bằng tay với dd và mọi thứ đều ổn, cho đến khi tôi kích hoạt fdisk và nó nói:

    Note: Sector size is 4096 (not 512).

Làm thế nào khiêm tốn của fdisk. "Ghi chú" này là gốc rễ của tất cả các vấn đề. Sau một số khó khăn hơn, những kết luận này đã được rút ra:

• Vỏ USB không bị lỗi.

• Bộ điều khiển SATA trên bo mạch chủ đã chết, ít nhất là "lạ". Nó không báo cáo các cung 4096 byte cho hệ điều hành, vì vậy HĐH đã vui vẻ tạo MBR bằng cách sử dụng các địa chỉ sector 512 byte.

• Bây giờ khi tôi cố gắng truy cập vào phân vùng, HĐH sẽ cố gắng sử dụng các địa chỉ dựa trên 512 byte trên ổ đĩa 4096 byte, và tất nhiên, nó sẽ không hoạt động.

Câu hỏi

• Vì vậy, làm cách nào tôi có thể sửa các địa chỉ trong MBR để chúng hợp lệ trên kích thước cung 4096 byte, ngoài việc chỉnh sửa thủ công MBR trên trình soạn thảo hex và

• Các phân vùng không được căn chỉnh cho các lĩnh vực 4096 byte. Có một số công cụ có sẵn để sắp xếp chúng ngoài việc sao chép vào và ra khỏi ổ đĩa khác? (Tôi không có ổ đĩa dự phòng), hoặc tôi sẽ cần tạo một số công cụ "dịch chuyển" dữ liệu sang một bên một chút? Phân vùng là ext3.

Cảm ơn!

Cập nhật:

Tôi thấy có một cách thông minh để sử dụng dd để dịch chuyển phân vùng tại chỗ trong câu hỏi này: Làm thế nào để di chuyển một phân vùng trong GNU / Linux? Nhưng tôi không biết nếu nó sẽ hoạt động trên một lát của một khu vực, mặc dù. Tôi không thể kiểm tra nó ngay bây giờ nhưng sẽ làm khi tôi có thời gian.

Cập nhật 2:

Vì vậy, tôi đã căn chỉnh thành công phân vùng bằng phương pháp trên và chỉnh sửa MBR bằng tay trên trình soạn thảo hex. Ngay sau khi tôi cắm lại ổ cứng, phân vùng boom tự động được gắn! Mặc dù vậy, tôi không khuyến nghị điều này, có lỗi I / O trong quá trình này và tôi có thể mất tất cả mọi thứ, xem bình luận về câu trả lời của Rod. Đối với phân vùng khác, tôi sẽ không chấp nhận rủi ro và sẽ sử dụng một ổ cứng cũ và căn chỉnh các khối tại một thời điểm bằng cách sao chép dữ liệu và sau đó dán lại vào một vị trí khác.

Các vấn đề quy mô ngành đang trở nên khá phức tạp. Cho đến cuối năm 2009, phần lớn các đĩa cứng đã sử dụng các cung 512 byte và đó là điều đó. Vào cuối năm 2009, các nhà sản xuất đĩa đã bắt đầu giới thiệu cái gọi là đĩa Định dạng Nâng cao (AF), sử dụng các cung 4096 byte. Các đĩa AF đầu tiên này (và, AFAIK, tất cả các đĩa AF hiện nay) trình bày một giao diện cho máy tính hiển thị mỗi khu vực vật lý 4096 byte được chia thành tám khu vực logic 512 byte . Chuyển đổi này cho phép các công cụ cũ hơn, bao gồm nhiều BIOS, được xây dựng với các giả định 512 byte, tiếp tục hoạt động. Tôi không biết đĩa của bạn có sử dụng AF hay không, nhưng trong cả hai trường hợp, nó gần như chắc chắn sử dụng kích thước cung cấp logic 512 byte, nghĩa là giao diện với HĐH nên sử dụng các cung từ 512 byte.

Vấn đề phức tạp là vỏ đĩa USB nhất định. Một số trong các vỏ bọc này làm ngược lại những gì AF thực hiện: Chúng lấy tám cung đĩa và gộp chúng thành một cung 4096 byte mới. Tôi không chắc lý do đằng sau động thái này là gì, nhưng một lợi thế thực tế là các đĩa lớn hơn 2TiB có thể được sử dụng với hệ thống phân vùng MBR cũ. Một nhược điểm lớn là một đĩa được phân vùng trong một trong các vỏ này không thể được sử dụng trực tiếp hoặc trong một vỏ bọc không thực hiện kiểu dịch này. Tương tự, một đĩa được chuẩn bị mà không có bản dịch này không thể được sử dụng khi nó được chuyển vào một bao vây như vậy. Lưu ý rằng vấn đề này vượt xa chính MBR; đĩa của bạn có thể xác định phân vùng đầu tiên là bắt đầu trên (512-byte) sector 2048, nhưng nếu HĐH của bạn muốn tìm kiếm (4096 byte) sector 2048,tìm điểm bắt đầu của phân vùng đó Bạn đã gặp phải vấn đề này. Như vậy, ban đầu bạn nghĩ rằng đó là lỗi của vỏ USB gần với nhãn hiệu hơn so với suy nghĩ gần đây của bạn rằng bo mạch chủ của bạn đã làm hỏng nó. Tôi chưa bao giờ nghe nói về một bo mạch chủ dịch kích thước ngành theo cách này. (Tuy nhiên, một số thiết bị RAID phần cứng làm như vậy.)

Tôi không biết cách buộc Linux điều chỉnh ý tưởng của nó về kích thước cung, nhưng nếu bạn có đủ dung lượng đĩa, thực hiện sao chép đĩa cấp thấp sang đĩa khác có thể giúp ích. Ví dụ:

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

Điều này sẽ sao chép đĩa của bạn từ /dev/sdb(đĩa USB; điều chỉnh khi cần thiết) vào tệp ~/image.img. Sau đó, bạn có thể sử dụng tập lệnh sau để gắn phân vùng của hình ảnh:

#!/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

Lưu tập lệnh như, nói mount_imagevà sử dụng nó như thế này:

./mount_image ~/image.img 2 /mnt

Điều này sẽ mount phân vùng 2 của image.imgđể /mnt. Lưu ý rằng tập lệnh dựa trên GPT fdisk ( gdisk) , mà hầu hết các bản phân phối bao gồm trong một gói được gọi là gptfdiskhoặc gdisk.

Về lâu dài, một giải pháp tốt hơn là tìm cách kết nối đĩa không thực hiện bản dịch kích thước ngành. Một kết nối trực tiếp đến một bo mạch chủ mới sẽ thực hiện thủ thuật; hoặc bạn có thể tìm thấy một bao vây bên ngoài không thực hiện dịch. Trên thực tế, một số vỏ bọc thực hiện dịch trên các cổng USB nhưng không phải trên các cổng eSATA, vì vậy nếu vỏ của bạn có cổng eSATA, bạn có thể thử sử dụng cổng đó. Tôi nhận ra rằng tất cả các giải pháp này đều có khả năng tiêu tốn tiền, mà bạn nói rằng bạn không có, nhưng có lẽ bạn có thể trao đổi bao vây dịch thuật của mình cho một dịch thuật không dịch.

Một tùy chọn khác xảy ra với tôi là thử sử dụng một máy ảo như VirtualBox. Một công cụ như vậy có thể giả định kích thước cung 512 byte khi truy cập thiết bị đĩa, hoàn tác bản dịch một cách hiệu quả; hoặc bạn có thể sao chép nội dung của đĩa thô (như trong dd if=/dev/sdc of=/dev/sdb) trong máy ảo, có thể sao chép nội dung có nén, do đó cho phép hình ảnh vừa với không gian đĩa ít hơn mức tiêu thụ ban đầu.

Kịch bản này đã khái quát hóa đề xuất của Rod Smith, khi bạn có một cuộc đột kích hoặc một loại tiền điện tử. Không bảo hành. Hãy cải thiện nó! (Cập nhật với phát hiện mới nhất về mdadm)

#!/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

Một cách khác, khá thẳng về phía trước để làm điều này là sử dụng chức năng cứu hộ của parted. Điều này đòi hỏi bạn phải tạo nhãn đĩa mới, vì vậy nó liên quan đến rủi ro. Chia tay hoạt động trực tiếp trên đĩa để tạo bản sao lưu khi cần thiết trước khi chạy chia tay. Sau đó bắt đầu:

parted /dev/sdb

parted sẽ cho bạn biết điều gì đó dọc theo các dòng này khi cố đọc một đĩa có kích thước cung khác với bảng phân vùng đã được tạo:

Error: /dev/sdb: unrecognised disk label                                  

Sử dụng mklabel để tạo MBR hoặc GPT mới theo những gì bạn đã sử dụng trước đó

(parted) mklabel
New disk label type? mbr

Sau đó chạy cứu để tìm phân vùng cũ của bạn

(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

Lặp lại quá trình cứu hộ nếu bạn có nhiều phân vùng hơn. Bây giờ bạn đã hoàn thành.

Tôi gặp vấn đề này khi gỡ đĩa 4TB khỏi vỏ ngoài WD My Book. Vấn đề là:

1. bảng phân vùng MBR bị tắt bởi hệ số 8 và
2. bảng phân vùng MBR không thể xử lý> 2TB khi kích thước cung là 512.

Giải pháp: Viết lại bảng phân vùng thành GPT, chuyển đổi các giá trị để sử dụng các cung 512 byte.

Trong trường hợp của tôi, phân vùng bắt đầu với độ lệch 1MB và kết thúc (~ 856kB) trước khi kết thúc đĩa. Điều này là tốt vì sau đó nó đã cho phép MBR + GPT (17408 byte) trước phân vùng và GPT dự phòng (16896 byte) ở cuối đĩa.

Tôi đã tạo ra hình ảnh của cả hai khu vực chỉ trong trường hợp (sử dụng dd).

Tôi ghi nhận đầu ra từ fdisk -l /dev/sde.

Tôi đã sử dụng gdisk để xóa phân vùng đầu tiên. Nếu bạn muốn, bạn có thể làm như tôi đã làm và thay đổi giá trị căn chỉnh thành 8 (4096) để sử dụng càng nhiều không gian càng tốt. Sau đó, tôi đã tạo một phân vùng mới khi bắt đầu vào năm 2048 và kết thúc ở cuối đĩa. Tôi sẽ phát triển hệ thống tập tin sau.

Rất may, sự thay đổi kích thước khu vực không ảnh hưởng đến hệ thống tệp, LVM hoặc LUKS.