Проблемы с dvd-rw

Версия ядра какая? Может, стоит обновиться?

Linux comp 2.6.26-ARCH #1

у меня подобная проблема с SATA писалкой. Она почему-то записывает в начало каждого диска 32 байта туфты. И приходится записанные диски монтировать с опцией offset=20.

в любом случае - проблема скорее всего кроется в драйверах SATA-чипа мамки. Какой чипсет у тебя?

вырежи сто метров с записанной болванки.

dd if=/dev/dvd of=test.img bs=1M count=100

и посмотри что будет говорит. Если отработает без проблем - посотри в hexview где начинается собственно образ. И глянь в оригинальный iso. И проанализируй разницу.

никакого различия...

чипсет VIA V8273R

>никакого различия... чипсет VIA V8273R

во-во и у меня 8237 только не R.

PS то есть dd отработал полностью без ошибок на том же самом приводе??? попробуй тогда срипать образ на том же приводе и смонтировать его с помощью mount -o loop. Если смонтируется - будет очень странно... 2. попробуй записанный диск на другом приводе.

//Dikiy

да, dd отработал без проблем и рипнул образ, но образ не монтируется по той же причине:

Sep 22 17:16:25 comp isofs_fill_super: root inode is not a directory. Corrupted media?

md5sum оригинального образа и рипнутого не сошлись, на другом приводе тоже не пашет 8(

>md5sum оригинального образа и рипнутого не сошлись, на другом приводе тоже не пашет 8(

вот и выявилась проблема. теперь попробуй найти где начинаются различия и насколько ни велики. попробуй заюзать для этой цели cmp.

PS Если есть возможность подключи этот привод к другой мамке. И попробуй провести операцию записи.

PPS serial ata писалки довольно проблематичны пока :(

различия нашёл, похоже что привод действительно добавил чего-то лишнее, ибо байты в рипнутом образе сдвинуты ровно на 20 (вроде как) от орининального, т.е.:

оригинал:

0000F940 23 00 00 00 00 00 00 23 00 08 00 00 00 00 08 00 6C 02 18 14 1C 13 00 02 00 00 01 00 00 01 08 43 #......#........l..............C

0000F960 41 54 50 41 47 45 53 00 52 52 05 01 89 4E 4D 0D 01 00 63 61 74 70 61 67 65 73 50 58 24 01 6D 41 ATPAGES.RR...NM...catpagesPX$.mA

рипнутый образ:

0000F940 00 00 00 00 54 46 1A 01 0E 6C 02 18 14 1C 13 00 6C 02 18 14 13 3A 00 6C 02 18 14 1C 13 00 7A 00 ....TF...l......l....:.l......z.

0000F960 23 00 00 00 00 00 00 23 00 08 00 00 00 00 08 00 6C 02 18 14 1C 13 00 02 00 00 01 00 00 01 08 43 #......#........l..............C

0000F980 41 54 50 41 47 45 53 00 52 52 05 01 89 4E 4D 0D 01 00 63 61 74 70 61 67 65 73 50 58 24 01 6D 41 ATPAGES.RR...NM...catpagesPX$.mA

и что в данном случае предпринимать?

> И приходится записанные диски монтировать с опцией offset=20.

насчет этого ясно, но задача-то была записать на диск образ и загрузиться с него на другой машине... 8(

нерешаемо что ли?

>и что в данном случае предпринимать?

mount -o offset=32 (0x20 == 32)

>насчет этого ясно, но задача-то была записать на диск образ и загрузиться с него на другой машине... 8( нерешаемо что ли?

теоретически - очень трудно. практически - не решаемо. судя по всему это баг в чипсете от VIA. Я уже писал багрепорт не эту тему.

http://bugzilla.kernel.org/show_bug.cgi?id=10137

молчание.... да и один из разрабов сказал в http://bugzilla.kernel.org/show_bug.cgi?id=10175, что не имеет доступа к докам от vt6420 (контроллер SATA в чипсете vt8237).

PS в общем - лекарством может быть только покупка новой мамки или покупка SATA контроллера на PCI. Или покупка IDE резака.

спасибо... все-таки придется сходить записать фрю у друга :)

>спасибо... все-таки придется сходить записать фрю у друга :)

у меня есть к тебе просьба. Не поленись, зарегистрируйся и напиши, пожалуйста, багрепорт на bugzilla.kernel.org. И дай ссылку на мой баг №10137 как на "похожий". А то про мой они забыли :( А так как у тебя мамка по-новее будет, то они и зачешутся.

>спасибо... все-таки придется сходить записать фрю у друга :)

ну и прикрепи туда соответственно то, что ты тут уже написал (дамп насчет 32-х левых байт в начале записанной болванки).

ок, щас сделаю

сделал, http://bugzilla.kernel.org/show_bug.cgi?id=11622

по английски нормально только читаю :) поэтому половину текста у тебя скопировал, тут уж не обессудь... проблема-то одна и та же

надо надеяться скоро решат.

>надо надеяться скоро решат.

я тоже. Бо 9 месяцев назад купил себе резак. А он, собака, и не пашет толком :-( А еще один брать - жаба душит :)

Backward compatibility between SATA 1.5 Gbit/s controllers and SATA 3.0 Gbit/s devices was important, so SATA/300's autonegotiation sequence is designed to fall back to SATA/150 speed (1.5 Gbit/s rate) when in communication with such devices. In practice, some older SATA controllers do not properly implement SATA speed negotiation. Affected systems require the user to set the SATA 3.0 Gbit/s peripherals to 1.5 Gbit/s mode, generally through the use of a jumper[5], however some drives lack this jumper. Chipsets known to have this fault include the VIA VT8237 and VT8237R south bridges, and the VIA VT6420 and VT6421L standalone SATA controllers.