GNU parted가 MBR의 처음 440바이트에 데이터를 쓰는 이유는 무엇입니까?

GNU parted가 MBR의 처음 440바이트에 데이터를 쓰는 이유는 무엇입니까?

내 이해는 MBR이 512바이트라는 것입니다. 그만큼처음 440바이트(주다또는가져가다약간의 바이트, 구현에 따라 다름)에는 부트 로더/부트스트랩 코드 영역이 포함됩니다. 나머지 바이트에는 파티션 테이블에 대한 정보가 포함됩니다.

디스크의 MBR을 0으로 만드는 경우...

# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512

그런 다음 fdisk파티션 테이블을 작성하는 데 사용합니다 /dev/sdX.

# Create a 2GiB partition starting at 2048 (default).
fdisk /dev/sdX

...
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier ...
...

(fdisk) n
(fdisk) p
(fdisk) 1
(fdisk) 2048
(fdisk) +2G
(fdisk) w

그런 다음 처음 440바이트를 다시 읽습니다.

dd if=/dev/sdX bs=1 count=440

첫 번째 440바이트는 여전히 모두 0입니다. fdisk위에 게시한 링크에 따르면 이는 의미가 있습니다. fdisk파티션 정보를 쓰고 있으므로 첫 번째 440.

다음 6바이트는 0이 아닙니다. 나는 이 바이트가최신 표준 MBR의 디스크 서명.

$ dd if=/dev/sdX bs=1 count=6 skip=440 | hexdump -e '4/1 "%02x " "\n"'
9a 29 97 e7

지금까지 MBR의 배치 방식을 이해하면 이해가 됩니다. 첫 번째 바이트는 부트로더의 도메인이고 파티션 테이블에만 관련되므로 440무시됩니다 .fdiskfdisk

그러나 parted루프에 나를 던지고 있습니다.

동일한 디스크의 MBR을 다시 0으로 설정하면...

# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512

그런 다음 parted를 사용하여 디스크 레이블을 만듭니다( fdisk위에서 자동으로 수행되는 것처럼 보임)...

parted /dev/sdX mklabel msdos

그런 다음 첫 번째 440바이트를 다시 읽으십시오.

$ dd if=/dev/sdX bs=1 count=440 | hexdump -e '16/1 "%02x " "\n"'
fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00
00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75
f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b
4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0이 아닌 바이트가 있습니다!MBR이 어떻게 배치되어야 하는지와 GNU parted가 무엇인지에 대한 나의 현재 이해로는 그것은 말이 되지 않는 것 같습니다.달성해야 할 것.

GNU Parted는 파티션 테이블을 생성하고 조작하는 프로그램입니다.

parted첫 번째 바이트에 데이터를 쓰는 이유는 무엇입니까 440? 해당 바이트는 부트로더용이 아닌가요? 그랬던 것처럼 그 바이트를 내버려두어서는 안 될까요 fdisk?

답변1

내가 나타날 것입니다~ 아니다그만큼오직하나에서알아채다이 행동. arm디스크에 부트로더가 있으면 문제가 발생할 수 있는 일부 환경에서는 특히 문제가 되는 것 같습니다 .

문제는 parted 자체가 (그리고 자동으로) 코드를 거기에 넣기 때문에 임베디드 시스템이 유효한 부트로더 코드가 있다고 생각하고 중단된다는 것입니다.

...그리고...

이 코드를 추가하지 않고 fdisk처럼 동작하기 위해 parted할 수 있는 옵션이 있습니까?

parted이 행동은 다음과 같습니다 .의도적인. 메일링 리스트 의 사용자가 다음과 같이 parted질문합니다.

문제는 parted가 MBR 시작 부분부터 다음 코드를 생성한다는 것입니다.

...

이 코드의 목적은 무엇입니까? 왜 거기에 넣어졌나요?

그리고 대답은 다음과 같습니다.

이는 일반적으로 BIOS 시스템을 부팅하는 데 사용되는 MBR 부팅 코드입니다. x86이 아닌 시스템에서 문제가 발생하는 경우 이를 0으로 설정해야 합니다(또는 파티셔닝 후 시스템 부트로더를 작성해야 합니다).

mklabel일반 부트로더를 디스크에 기록하도록 설계된 것 같습니다 . 적어도 라벨을 msdos사용하는 경우에는 그렇습니다. 나가정하다말이 되지만 fdisk및 에서 보면 syslinux파티션 관리자가 부트로더 섹터를 수정하는 것이 약간 특이한 것 같습니다.

그것것 같다좋아 parted해야 한다~ 아니다0이 아닌 데이터가 있는 경우 해당 섹터를 덮어쓰십시오.

아니요, 기록되지 않는 유일한 경우는 이미 뭔가가 있는 경우입니다(예: 0x00이 아님). 따라서 SDK가 부트로더를 먼저 작성하도록 한 다음 분할하고 parted하면 그대로 유지됩니다.

그러나 그것은~ 아니다내가 보고 있는 행동. 에서 쓰레기를 작성한 /dev/urandom다음 실행하면 parted mklabel0이 아닌 데이터가 확실히 손상됩니다.

내가 mbr.s파일을 조립 libparted하면헤어진 레포, 해당 바이트가 어디에서 오는지 알 수 있습니다.

$ as86 -b /dev/stdout mbr.s | hexdump -e '16/1 "%02x " "\n"'
fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00
00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75
f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b
4c 02 cd 13 ea 00 7c 00 00 eb fe

그건정확히parted내 디스크에서 생성되는 것으로 보이는 바이트 시퀀스입니다 .

관련 정보