Я могу воспроизвести вашу проблему и объяснить ее. И исправить это, я думаю.
Краткое объяснение
По какой-то причине первый сектор вашего диска, если интерпретировать его как MBR, содержит таблицу полудействующих разделов. У любой ОС нет причин полагать, что она суперфлоппи.
Длинное объяснение
MBR против VBR
Большинство дисков, которые мы используем, были разбиты на разделы. В этом случае первые 512 байт диска являются Master Boot Record (MBR). Даже в таблице разделов GUID (GPT) первые 512 байт образуют своего рода MBR по устаревшим причинам. Важно то, что каждая современная ОС ожидает найти MBR в самом начале диска.
Superfloppy - это диск, который при создании файловой системы рассматривался как раздел. В этом случае первые 512 байт содержат загрузочную запись тома (VBR), как обычно бывает в начале раздела.
Некоторые файловые системы используют VBR для хранения своих важных метаданных, NTFS является одной из них. И MBR, и VBR могут содержать код начальной загрузки. На не загружаемых устройствах этот "код" может быть тривиальным, защитным или даже безумным. Нет четкой схемы, поэтому вы не можете точно сказать, является ли ваш 512-байтовый сектор MBR или VBR или чем-то еще.
В общем случае, лучшее, что вы можете сделать, это проверить, выглядит ли соответствующий фрагмент как нормальная таблица разделов MBR. Я думаю, что это то, что делают операционные системы. К сожалению, возможно иметь VBR, который проходит этот тест.
Эта проблема
Давайте сравним базовую раскладку MBR (отсюда) с раскладкой NTFS VBR (отсюда):
MBR │ byte offset │ NTFS VBR
│ hex / dec │
───────────┼─────────────┼─────────────
│ 0x000 / 000 │ mainly NTFS
bootstrap │ … │ metadata
code ├─────────────┼─────────────
│ 0x054 / 084 │
│ … │ bootstrap
───────────┼─────────────┤ code
partition │ 0x1BE / 446 │
table │ … │
───────────┼─────────────┼─────────────
0x55 │ 0x1FE / 510 │ 0x55
0xAA │ 0x1FF / 511 │ 0xAA
───────────┴─────────────┴─────────────
Я взял свою флешку и создал NTFS суперфлоппи с помощью mkntfs -F -f /dev/sdc . Инструмент переписал весь первый сектор, включая область кода начальной загрузки. Windows или другая ОС могут некоторое время считать MBR и проверять область таблицы разделов. Вот что он получит:
#fdisk -l /dev/sdc
Disk /dev/sdc: 31.5 GB, 31466323968 bytes
64 heads, 32 sectors/track, 30008 cylinders, total 61457664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2052474d
This doesn't look like a partition table
Probably you selected the wrong device.
Device Boot Start End Blocks Id System
/dev/sdc1 ? 6579571 1924427647 958924038+ 70 DiskSecure Multi-Boot
/dev/sdc2 ? 1953251627 3771827541 909287957+ 43 Unknown
/dev/sdc3 ? 225735265 225735274 5 72 Unknown
/dev/sdc4 2642411520 2642463409 25945 0 Empty
Partition table entries are not in disk order
Как вы можете видеть, fdisk может сказать, что «это не похоже на таблицу разделов». Windows скажет в основном то же самое, затем предположит, что сектор VBR, найдет в нем сигнатуру NTFS и, наконец, смонтирует. На самом деле у старой Windows XP с этим проблем не было. Также мой Kubuntu сообщил в dmesg:
sdc: неизвестная таблица разделов
но тогда KDE предложил смонтировать его как суперфлоппи.
Обратите внимание, что любой инструмент, который проверяет таблицу разделов, фактически читает фрагмент кода начальной загрузки из VBR. Этот код не нужен для работы NTFS. Я проверил с помощью hexdump что фрагмент вообще не является исполняемым кодом; это выглядит как набор текстовых сообщений, которые будут отображаться, если я попытаюсь загрузиться с этого устройства, например:
Press Ctrl+Alt+Del to restart
Это означает, что я могу создать частично действительную таблицу разделов, и она будет искажать только текстовые сообщения, которые я, вероятно, никогда не увижу.
Ну, я так и сделал, с помощью fdisk я создал таблицу разделов, которая выглядит корректно. Конечно, это указывает на "разделы" без файловых систем, потому что единственная файловая система - все еще NTFS на суперфлоппи.
В Windows XP диск ведет себя почти как ваш диск. Почти, потому что я получил письмо, назначенное на первый раздел. Моя настоящая (суперфлоппиальная) файловая система NTFS свежая и пустая, а ваша нет. Один из его секторов интерпретируется как VBR для первого поддельного раздела. Наши сектора наверняка содержат разные данные, возможно, в этом причина. Тем не менее, я верю, что только что разгадал вашу тайну.
Похоже, что кто-то собирался разбить вашу суперфлоппи-диск и передумал между fdisk и mkfs .
Исправление
В моем случае было достаточно записать нули в таблицу разделов:
dd if=/dev/zero of=/dev/sdc bs=1 seek=446 count=64
Если я хочу восстановить весь фрагмент "загрузочного кода" моей суперфлоппи-диска, я могу скопировать его из другого раздела NTFS, созданного mkntfs:
fallocate -l 2MiB tmp.ntfs
mkntfs -F -f tmp.ntfs
dd if=tmp.ntfs of=/dev/sdc bs=1 skip=84 seek=84 count=426
rm tmp.ntfs
