LINUX.ORG.RU
Ответ на: комментарий от wyldrodney

не думал ниразу. На Си, наверно...

dd if=/dev/sda4 of=/mnt/bk/sda4.iso помог, как никогда.
А вот fdisk все-равно отказывается с ним (хардом) работать. А после попыток fsck достучаться до винта, он вообще пропадает из /dev/

vitroot ★★
() автор топика

у меня то-же накрылся старый винт причем очень странно. все читается (dd созранил образ) но ничего не может записатся (shred ругается навсе сектора) как будто стоит защита от записи...

xtron
()
Ответ на: комментарий от madcore

>Если он без проблем слился, то почему не монтировался?

Возможно потому, что были проблемы в районе таблицы разделов.

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

проблемы-то, может, и были, но если dd if=/dev/sda4 сработал, то проблемы были какие-то странные, не кажется?

vitroot ★★
() автор топика

стоило попробовать mount -o ro, дабы при монтировании небыло попыток записей временных меток, обновления журналов и прочих записей. Винты могут лочится от записи, если имеют достаточно плохие показания смарта.

dd - наше фсио

EmStudio
()
Ответ на: комментарий от vitroot

> вот не поверишь, ro делал - безрезультатно, а вот dd запедалил

Верю. Более того, этот метод более правильный, ибо порой не знаешь, как долго жить винту. Вот только если гюлки в mbr, то скорее надо копировать /dev/sdX, а не /dev/sdXY, ибо можно слить что-то не то...

EmStudio
()
Ответ на: комментарий от vitroot

>проблемы-то, может, и были, но если dd if=/dev/sda4 сработал, то проблемы были какие-то странные, не кажется?

Я лишь могу предположить, что fdisk пытался прочитать больше/глубже, чем читало ядро в таблице разделов, и напарывался на бэды (смотри вывод dmesg лучше). А dd просто сразу читал нужный раздел, без лишних движений.

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

> На Си, наверно...

Файл называется dd.c. Говорят, там есть код древнее юникса :)

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

>проблемы-то, может, и были, но если dd if=/dev/sda4 сработал, то проблемы были какие-то странные, не кажется?

Всё просто. На носителях обычно имеется две MBR: одна основная, другая резервная. fdisk не смог прочитать одну из них и верифицировать другую, вот и обламывался.
dd работает по-тупому: тупо читает и пишет байты блочного устройства по заданному смещению.

iZEN ★★★★★
()

testdisk в помощь.

iZEN ★★★★★
()

поздравляем! :)

а URL с оцифровками сказок не вспомнил? (может кому ещё пригодится)

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

> Всё просто. На носителях обычно имеется две MBR: одна основная, другая резервная

Изен, ты путаешь. Никаких резервов для MBR не предусмотрено, есть только дополнительные MBR в расширенных разделах, которые все уникальны и не имеют дублей. Хотя у вас там во фряхе все через анальный проход...

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

>Изен, ты путаешь. Никаких резервов для MBR не предусмотрено,

А чёрт, точно — MBR всегда одна (зато GPT дублируется, ага).

В DOS и OEM-версиях установщиков есть команда "fdisk /mbr", которая вроде бы ремонтирует повреждённую MBR. Однако она просто записывает загрузочный код (возможно с меню загрузки для OEM), не меняя таблицы разделов.

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

нет, url так и не нашел. Зато оцифровки все на месте. Для желающих могу выложить :)

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