LINUX.ORG.RU

Ubuntu «не осилила» HDD с GPT


0

1

Есть жёсткий диск, размеченный и отформатированный в ubuntu 10.04. Т.к. диск большой, сделал там GPT. И в 10.04 он нормально работал.

Затем была установлена ubuntu 14.04, и диск внезапно стал «недоступен». 'fdisk -l' его упоминает, но гном монтировать его разделы не предлагает, при запуске gparted получаю 'Invalid argument during seek for read on ...', далее gparted показывает содержимое диска как 'unallocated'.

Но самое интересное, что если опять запустить 10.04 (где диск по-прежнему нормально виден), а потом перезагрузиться в 14.04, то и 14.04 забывает про ошибки и нормально работает с диском.

Возникают вопросы:

Что это за чудеса? Почему загрузка 10.04 «всё чинит»?

Как вообще так вышло, что появились проблемы от обновления OS? Не возникнет ли новых проблем с какой-нибудь 18.04?

Ну и, наконец, как это исправить (чтобы диск сразу был виден в 14.04)?

★★

Что это за чудеса? Почему загрузка 10.04 «всё чинит»?

Это убунту, сынок...

Вот тебе еще пример: I hate Ubuntu!!!.

Не возникнет ли новых проблем с какой-нибудь 18.04?

Возникнут.

Zhbert ★★★★★
()
Ответ на: комментарий от redgremlin

gdisk. fdisk не умеет GPT.

Я им только смотрел, «видит ли система устройство». Пишет, что видит.

Там винды рядом, случаем, не стоит?

Не, винды нет. Только эти две системы, 14.04 и 10.04.

И это не случайное совпадение, я много раз проверял.

fffgh ★★
() автор топика
Ответ на: комментарий от redgremlin

Ну вот gdisk в тот момент, когда 14.04 не видит, в студию.

Выложу, как доберусь.

fffgh ★★
() автор топика
Ответ на: комментарий от redgremlin

fdisk не умеет GPT

/root # fdisk /dev/sda  

Welcome to fdisk (util-linux 2.25).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sda: 55.9 GiB, 60022480896 bytes, 117231408 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
Disklabel type: gpt
Disk identifier: E9201D73-B9C6-4F1E-9996-511F62B88E1D

Device        Start      End  Sectors  Size Type
/dev/sda1      2048   264191   262144  128M EFI System
/dev/sda2    264192 67373055 67108864   32G Linux root (x86-64)
/dev/sda3  67373056 84150271 16777216    8G Linux swap

Command (m for help):
Gotf ★★★
()
Ответ на: комментарий от redgremlin

Перечислить разделы он вроде может :) Вот что-то другое сделать точно не сумеет.

Gotf ★★★
()
Ответ на: комментарий от redgremlin

Ну вот gdisk в тот момент, когда 14.04 не видит, в студию.

$ sudo gdisk устройство?

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
fffgh ★★
() автор топика
Ответ на: комментарий от redgremlin
Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 5860531055 sectors, needs to be 5860533168 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 5860533134, but backup header is at
5860533167 and disk size is 5860531055 sectors.
The 'e' option on the experts' menu will probably fix this problem

Caution: Partition 1 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

Identified 4 problems!
fffgh ★★
() автор топика
Ответ на: комментарий от fffgh

5860533134, but backup header is at
5860533167 and disk size is 5860531055 sectors.

что с размером драйва?

parrto
()
Ответ на: комментарий от redgremlin

Вот тут чинят точно такую же (вплоть до цифр) проблему

Спасибо, но мне не столько починить, сколько понять, что вообще происходит (см «чудеса»). Системе с такими выкрутасами я диск чинить не доверю — без данных же останусь.

fffgh ★★
() автор топика
Ответ на: комментарий от fffgh

что вообще происходит

Покажи данные данные по диску из dmesg ( dmesg | grep '/dev/sd_буква_твоего_диска_') в Ubuntu 10.04, раз там работает, ну и выхлоп gdisk v и p там же.

redgremlin ★★★★★
()

А вот что 10.04 животворящий делает:

(загрузил 10.04, нажал в нём «перезагрузить» и загрузил 14.04)

(т.е. этот тот же диск, в той же 14.04, что и выше)

$ sudo gdisk 

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): v

Caution: Partition 1 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

No problems found. 5070 free sectors (2.5 MiB) available in 1
segments, the largest of which is 5070 (2.5 MiB) in size.

Если кто-то действительно портит разметку, то, получается, это 14.04?

fffgh ★★
() автор топика
Ответ на: комментарий от fffgh

dmesg | grep, gdisk p в студию

Если кто-то действительно портит разметку

Никто её тебе не портит

загрузил 10.04, нажал в нём «перезагрузить» и загрузил 14.04

Ну и нахера?

redgremlin ★★★★★
()
Ответ на: комментарий от fffgh

Далее в том же, «рабочем» режиме 14.04:

Command (? for help): p
Disk: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 8-sector boundaries
Total free space is 5070 sectors (2.5 MiB)

Т.е. «last usable sector» такой же, как и ранее, когда «не работало».

Размер диска = 5860533168. А раньше было: «Disk size is 5860531055 sectors, needs to be 5860533168 sectors.»

fffgh ★★
() автор топика
Ответ на: комментарий от redgremlin

dmesg | grep, gdisk p в студию

Сейчас попробую.

Никто её тебе не портит

А что ж тогда ругается?

загрузил 10.04, нажал в нём

Ну и нахера?

Надо же главную фишку топика проиллюстрировать.

fffgh ★★
() автор топика
Ответ на: комментарий от fffgh

Видимо, у тебя там разметка в каком-то подвешенном состоянии, Убунта 10.04 ее при запуске как-то исправляет, но не до конца, и она остаётся сбитой. Что говорит

sudo parted -l

  • В 10.04?
  • В 14.04?
  • В 14.04 после второй подряд загрузки?
proud_anon ★★★★★
()
Ответ на: комментарий от redgremlin

В 10.04:

$ dmesg | grep sdc
[    2.249279] sd 6:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[    2.249280] sd 6:0:0:0: [sdc] 4096-byte physical blocks
[    2.249309] sd 6:0:0:0: [sdc] Write Protect is off
[    2.249310] sd 6:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    2.249325] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.249438]  sdc: sdc1
[    2.964032] sd 6:0:0:0: [sdc] Attached SCSI disk

$ sudo gdisk /dev/sdc
GPT fdisk (gdisk) version 0.5.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): v
No problems found. 5070 free sectors (2.5 MiB) available in 1
segments, the largest of which is 5070 sectors (2.5 MiB) in size

Command (? for help): p
Disk /dev/sdc: 5860533168 sectors, 2.7 TiB
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1565565838
Total free space is 5070 sectors (2.5 MiB)
fffgh ★★
() автор топика
Ответ на: комментарий от redgremlin

Я и без тебя уже нагуглил подобное.

Круто. И кто у них там виноват?

Материнка Gigabyte?

ASRock на ней написано.

fffgh ★★
() автор топика
Ответ на: комментарий от proud_anon

В 10.04:

$ sudo parted -l
..
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sdc: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  3001GB  3001GB  xfs
fffgh ★★
() автор топика
Ответ на: комментарий от proud_anon

В 14.04 после 10.04:

Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sdd: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17,4kB  3001GB  3001GB  xfs                msftdata
fffgh ★★
() автор топика
Ответ на: комментарий от proud_anon

Далее, чтобы 14.04 перестала нормально видеть диск, выключаю компьютер и, включив, гружусь в 14.04. Если просто перезагрузиться — ошибок нет.

$ sudo parted -l

Error: Invalid argument during seek for read on /dev/sdc                  
Retry/Ignore/Cancel? I                                                    
Error: The backup GPT table is corrupt, but the primary appears OK, so that will
be used.
OK/Cancel?
fffgh ★★
() автор топика
Ответ на: комментарий от fffgh

И кто у них там виноват?

Некоторые BIOS могут создавать свою копию на диске, для чего часть диска откусывают в http://en.wikipedia.org/wiki/Host_protected_area. Некоторые из них бажные и откусывают всегда, даже когда настройка не включена. Откусывают с конца, где как раз находится копия GPT. Видимо, 10.04 по какой-то причине сбрасывает настройки HPA и получает доступ ко всему диску, тогда как 14.04 не видит конец, не может считать копию GPT (GPT хранится в двух экземплярах, в самом начале и самом конце диска) и поэтому считает её повреждённой. Мягкая перезагрузка не запускает в биосе процесс начальной инициализации, поэтому после 10.04 14.04 получает таки доступ ко всему диску (чтобы это подтвердить или опровергнуть после загрузки в 10.04 выбери не перезагрузку, а выключение с последующим запуском 14.04, тогда разметка снова должна посчитаться сбойной).

redgremlin ★★★★★
()
Последнее исправление: redgremlin (всего исправлений: 1)

Вот ещё загадка: какая разница между выключением компьютера и перезагрузкой?

Если, включив 10.04, перезагрузить компьютер в 14.04 — 14.04 диск «увидит».

А если после 10.04 компьютер выключить, затем включить и загрузить 14.04 — то «не увидит».

Ранее интересовались материнской платой. Похоже, не зря.

fffgh ★★
() автор топика
Ответ на: комментарий от fffgh

Интересное явление. Во-первых, я вижу, что у тебя в 10.04 диск определяется как /dev/sdc, а в 14.04 — как /dev/sdd. Кроме того у тебя откуда-то сам собой ставится флаг msftdata. Может, и правда проблемы с BIOS.

Во-вторых, разделы у тебя вправду не очень хорошо выровнены.

Можешь показать ещё вывод

sudo parted /dev/sdc 'unit s print'
из 10.04 или то же для /dev/sdd из 14.04, когда она нормально работает? А то, может, у тебя там вообще нету копии GPT?

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)
Ответ на: комментарий от redgremlin

Некоторые BIOS могут создавать свою копию на диске

Спасибо. А как он выбирает, на какой диск писать? Их там куча же. Неужто на каждый?

Полезу в настройки, вдруг отключу.

fffgh ★★
() автор топика
Ответ на: комментарий от redgremlin

Ну вот, пока я писал, ты уже успел проверить. Так что да, проблема именно в этом.

Однако основную запись MBR никто не трогает. Так что читаться-то в принципе должно хоть как-то.

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)
Ответ на: комментарий от fffgh

Ещё можно поискать обновлённую прошивку, может, уже есть.

proud_anon ★★★★★
()
Ответ на: комментарий от fffgh

А как он выбирает, на какой диск писать?

Хз. Проверь остальные диски, вдруг и их размеры в 10.04 и 14.04 отличаются.

Полезу в настройки, вдруг отключу

hdparm -N 5860533168 вроде должно помогать, можно попробовать в загрузку при старте добавить пораньше (тут уж я не помощник, с убунтушным upstart близких дел не имел :) )

redgremlin ★★★★★
()
Ответ на: комментарий от proud_anon

10.04:

$ sudo parted /dev/sdc 'unit s print'
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sdc: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End          Size         File system  Name  Flags
 1      34s    5860528064s  5860528031s  xfs

в 10.04 диск определяется как /dev/sdc, а в 14.04 — как /dev/sdd

Разве это не нормально? Дисков много, порядок может меняться. Особенно в разных системах.

fffgh ★★
() автор топика
Ответ на: комментарий от proud_anon

Однако основную запись MBR никто не трогает

Какое MBR, когда тут GPT.

Так что читаться-то в принципе должно хоть как-то.

Так оно и читается, но систему смущают 2 вещи — отсутствие рабочей копии GPT и раздел, выходящий за границу диска.

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

Какое MBR, когда тут GPT.

Перепутал, GPT.

отсутствие рабочей копии GPT

Разве Secondary GPT используется не для бэкапа? Основная-то копия, которая в начале диска, у него не повреждена. С ней можно работать, а у него система вообще отказывается читать диск.

и раздел, выходящий за границу диска

Вот я не совсем понимаю, откуда он появляется. Secondary GPT должна располагаться в последних 33 секторах диска, а Secondary GPT Header, соответственно, в последнем секторе диска, но его расположение всё же записывается в Primary GPT. И вот, система видит, что вместо него там чёрт-те что, и ругается на отсутствие Secondary GPT. Но откуда там появляются разделы, которые больше диска, почему Last Usable Block куда-то перемещается? Ведь всё это должно оставаться таким, как есть, в неповреждённой основной копии GPT.

proud_anon ★★★★★
()

Кстати, обратил внимание:

10.04:
5860533168 sectors, 2.7 TiB
First usable sector is 34, last usable sector is 1565565838

«работающая» 14.04:
5860533168 sectors, 2.7 TiB
First usable sector is 34, last usable sector is 5860533134

Почему в 10.04 last usable такой маленький?

fffgh ★★
() автор топика
Ответ на: комментарий от erzent

я нормальный, это убунта болезненная

Ну-ну.

UNiTE ★★★★★
()
Ответ на: комментарий от redgremlin

hdparm -N 5860533168 вроде должно помогать

Не опасная команда?

можно попробовать в загрузку при старте добавить пораньше

Да могу просто в консоль вбить, тот диск мне во время загрузки не нужен.

fffgh ★★
() автор топика
Ответ на: комментарий от proud_anon

Но откуда там появляются разделы, которые больше диска, почему Last Usable Block куда-то перемещается?

Потому что меняется размер диска. Я же расписал всё — Ubuntu «не осилила» HDD с GPT (комментарий)

redgremlin ★★★★★
()
Ответ на: комментарий от fffgh

Не опасная команда?

Она принудительно изменит количество секторов, видимых операционной системой. Если биос не просто резервирует место, но и пишет туда что-то, то возможны всякие неприятности. Но, судя по тому, что с 10.04 всё работает с полным объёмом диска, то ничего туда не пишется.

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

Потому что меняется размер диска.

Да, но почему номер последнего usable сектора меняется? Он у него в одном случае один, а в другом случае — другой. Конечно, если откусить конец диска, то last usable sector будет слишком близко к концу, но у него он вообще другой.

Да, и ещё, собственно, никто ведь не спросил у ТС:

ТС, покажи вывод

sudo hdparm -N <проблемный диск>

В «работающем» и «неработающем» случае. Так мы, собственно, узнаем, включена ли HPA.

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)
Ответ на: комментарий от proud_anon

Да, но почему номер последнего usable сектора меняется?

Перечитал копипасту — в 14.04 он не меняется.

В «работающей» 14.04: «last usable sector is 5860533134». В «не работающей» 14.04: «Claimed last usable sector is 5860533134». И это значение похоже на заявленный размер диска.

А вот в 10.04 last usable sector какой-то не такой, 1565565838. См. Ubuntu «не осилила» HDD с GPT (комментарий)

fffgh ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.