Как раздуплить флешку не перегружая Linux?

0

2

Как зафакапить Linux.

1. Копируем что-то жирное на флешку (съемный носитель)

2. Набираем команду sync

3. Не дожидаясь окончания работы sync отмонтировать флешку. Почему-то получилось.

4. Невозможно после вынимания прекратить sync по Ctrl+C. Невозможно снять даже kill -9

5. Невозможно вставить смонтировать ранее вынутую флешку. mount виснет. Ни Ctrl+C, ни kill -9 не снимают mount (sync тоже так и висит в задачах)

6. На другом компе (тоже Linux) флешка нормально открывается и работается с ней. Только жирный файл побит, недокаченный.

КАК теперь поработать с флешкой на первом компе?!

Система Debian 11, ядро 5.16

Что-то мне подсказывает, что такого поведения не должно быть.

P.S. С другими флешками все работает. Скорее всего, после втыкания первой она опознается по guid или чему там и кому-то в ядре слегка крышу сносит.

Ссылка

←	Завтра будет 10 дней без происшествий у манжары

Посоветуйте сервис e-mail рассылки

→

Нет, просто ты повесил ядро (в пункте 4 это видно). Повисшее ядро уже никак не починить, только ребут, причём он будёт жёсткий.

Монтирования скорее всего ждут пока снимется какая-то блокировка, а она уже не снимется. Сами они при этом могли ещё какие-то блокировки за собой утянуть в вечное ожидание.

Что-то мне подсказывает, что такого поведения не должно быть.

Ну да, это баг (первоначальное поведение sync+umount, а остальное уже закономерный итог).

Система Debian 11, ядро 5.16

И какое-то левое ядро, хотя может с этим и не связано.

firkax ★★★★★
(15.11.22 00:27:15 MSK)
Последнее исправление: firkax 15.11.22 00:32:28 MSK (всего исправлений: 5)

Старый анекдот про виндовс: «Пап, а что такое многозадачная система? – Ща, сына, дискетку доформатирую и покажу.»

pr849 ★
(15.11.22 00:41:29 MSK)

Ссылка

Попробуй выгрузить загрузить драйвер юсб.

voltmod ★★★
(15.11.22 01:47:00 MSK)

Ответ на: комментарий от voltmod 15.11.22 01:47:00 MSK

Дело явно не в нем.

praseodim ★★★★★
(15.11.22 01:56:22 MSK) автор топика

Ссылка

Ответ на: комментарий от firkax 15.11.22 00:27:15 MSK

Нет, просто ты повесил ядро (в пункте 4 это видно). Повисшее ядро уже никак не починить, только ребут, причём он будёт жёсткий.

Угу. ребуталось с отвалами дисковой подсистемы и потом с запуском журнала восстановления. То есть, вообще так даже правильно сделал, что перезагрузку запустил. Система явно была в покореженном состоянии.

И какое-то левое ядро, хотя может с этим и не связано.

Просто из testing ядро. Нужно для видеокарты, 5.10 в stable недостаточно

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

praseodim ★★★★★
(15.11.22 01:58:48 MSK) автор топика

Ответ на: комментарий от voltmod 15.11.22 01:47:00 MSK

Там ядрёный тред-зомбак, лечится только перезагрузкой. Причём не факт что «мягкой».

Jameson ★★★★★
(15.11.22 01:59:23 MSK)

Ссылка

Ответ на: комментарий от firkax 15.11.22 00:27:15 MSK

Ну да, это баг (первоначальное поведение sync+umount, а остальное уже закономерный итог).

Похоже вообще на какой-то общий баг наткнулся.

Если запустить

dd if=/dev/zero of=/dev/sdb1 bs=1M status=progress

где sdb1 - флешка оно работает пока не исчерпается емкость, выводится сообщение об ошибке и также виснет намертво, ничем не снимешь dd.

praseodim ★★★★★
(15.11.22 02:29:09 MSK) автор топика
Последнее исправление: praseodim 15.11.22 02:29:34 MSK (всего исправлений: 1)

Ответ на: комментарий от praseodim 15.11.22 02:29:09 MSK

Вряд ли такое могло бы быть в стабильном ядре, скорее всего это именно в твоём, ребутнись в другое какое-нить и посмотри.

firkax ★★★★★
(15.11.22 02:36:48 MSK)

Ссылка

Ответ на: комментарий от praseodim 15.11.22 01:58:48 MSK

Просто из testing ядро. Нужно для видеокарты, 5.10 в stable недостаточно

А в backports то же самое, что и в testing?

greenman ★★★★★
(15.11.22 03:29:20 MSK)

Ответ на: комментарий от greenman 15.11.22 03:29:20 MSK

Упс, сейчас глянул, это и есть backports

praseodim ★★★★★
(15.11.22 03:46:20 MSK) автор топика

Ссылка

Невозможно после вынимания прекратить sync по Ctrl+C. Невозможно снять даже kill -9

В man 2 sync в ERRORS нет EINTR, т.е. вызов, очевидно, невозможно прервать. А вот если флешку выдернуть, то могло бы и EIO вернуть.

gag ★★★★★
(15.11.22 05:45:53 MSK)

Ссылка

Ответ на: комментарий от praseodim 15.11.22 01:58:48 MSK

Просто из testing ядро. Нужно для видеокарты, 5.10 в stable недостаточно

Используешь проприетарные драйвера и удивляешься проблемам в ядре?

Думаешь, просто так разработчики не принимают баг-репорты если ядро осквернено кривыми дровами? Они вполне могут влиять и на части ядра никак не связанные с видео.

Xenius ★★★★★
(15.11.22 06:45:40 MSK)
Последнее исправление: Xenius 15.11.22 06:47:48 MSK (всего исправлений: 1)

О, мне тут буквально вчера говорили, что в кривой винде пользователь может убить не все процессы, а вот в Линуксе…

alex1101 ☆
(15.11.22 07:27:29 MSK)

Ответ на: комментарий от praseodim 15.11.22 01:58:48 MSK

В бэкпортах есть 5.19. А ты сломал свой Debian.

~~anonymous-angler~~ ★☆
(15.11.22 07:30:55 MSK)

Ответ на: комментарий от anonymous-angler 15.11.22 07:30:55 MSK

В бэкпортах есть уже аж 6.0.3.

alegz ★★★★
(15.11.22 07:59:07 MSK)

Ответ на: комментарий от Xenius 15.11.22 06:45:40 MSK

Используешь проприетарные драйвера и удивляешься проблемам в ядре?

Наоборот. Открытым AMD-ным драйверам (модулям ядра) для видеокарт RX 6000-й серии нужно больше 5.10 Начиная с какого ядра нормально поддерживается AMD RX 6600 XT? (комментарий)

Не скажу точно, начиная с какого ядра работает. С 5.10 не работает, с 5.14 уже работает, но в 5.14 у меня глючил suspend.

praseodim ★★★★★
(15.11.22 08:18:22 MSK) автор топика

Ссылка

Ответ на: комментарий от anonymous-angler 15.11.22 07:30:55 MSK

В бэкпортах есть 5.19. А ты сломал свой Debian.

В бэкпортах был 5.16, тогда и ставился.

praseodim ★★★★★
(15.11.22 08:18:54 MSK) автор топика

Ответ на: комментарий от praseodim 15.11.22 08:18:54 MSK

И похоже, что ядро из бэкпортов само (при apt-get update && apt-get upgrade) не обновляется на более новое. Только ставить более свежую версию вручную (а старую сносить).

greenman ★★★★★
(15.11.22 08:49:36 MSK)
Последнее исправление: greenman 15.11.22 08:54:52 MSK (всего исправлений: 1)

Ответ на: комментарий от alex1101 15.11.22 07:27:29 MSK

О, мне тут буквально вчера говорили, что в кривой винде пользователь может убить не все процессы, а вот в Линуксе…

Ну так ребята стараются :-)

А если серьезно, то это далеко не первый случай кривых ядер в Дебиане. Причем кривое ядро может и в стабильной ветке висеть.

utanho ★★★★★
(15.11.22 09:24:32 MSK)

Ссылка

Ответ на: комментарий от greenman 15.11.22 08:49:36 MSK

И похоже, что ядро из бэкпортов само (при apt-get update && apt-get upgrade) не обновляется на более новое

Обновляется, если всё правильно делать.

надо ставить метапакет вида

linux-image-amd64

а не пакет ядра вида

linux-image-%version%-amd64

utanho ★★★★★
(15.11.22 09:28:23 MSK)

Ответ на: комментарий от alex1101 15.11.22 07:27:29 MSK

Процессы в состоянии D (а sync явно попал в него) убить нельзя.

pandrey ★★
(15.11.22 09:31:22 MSK)

Ссылка

Ответ на: комментарий от utanho 15.11.22 09:28:23 MSK

надо ставить метапакет вида

linux-image-amd64

Я может чего путаю, но на ядра из бекпортов нет метапакета. Метапакет, кстати, стоит, ядро 5.10 (из stable) обновляется, я его не удалял.

praseodim ★★★★★
(15.11.22 14:49:26 MSK) автор топика

Ответ на: комментарий от praseodim 15.11.22 02:29:09 MSK

Похоже вообще на какой-то общий баг наткнулся.

Это не баг, это математика.

dd if=/dev/zero of=/dev/sdb1 bs=1M status=progress

Эта команда пишет В КЭШ а не на флэшку. А потом вызывает fsync

и также виснет намертво, ничем не снимешь dd.

И вот тут оно делает тот самый sync.

А поскольку флэшка твоя гуано и скорость у неё полное днище - например пишет 5MB/с (что совсем не редкость для старых флэшек и для всякого китайского говна, даже если на нем написано гордо USB3) - то при размере флэшки в 64GB синк этот делается очень долго (порядка 4 часов).

В общем учи матчасть, это полезно.

no-dashi-v2 ★★★
(15.11.22 15:25:56 MSK)

Ссылка

Ответ на: комментарий от praseodim 15.11.22 14:49:26 MSK

https://packages.debian.org/bullseye-backports/linux-image-amd64

utanho ★★★★★
(15.11.22 15:26:46 MSK)

И эти люди смеялись что FreeBSD падает при вытаскивании смонтированной флешки…

slovazap ★★★★★
(15.11.22 15:30:08 MSK)

Ответ на: комментарий от utanho 15.11.22 15:26:46 MSK

А упомянутое выше 6.0.3 — для него нет метапакета?

greenman ★★★★★
(15.11.22 17:25:03 MSK)

Ответ на: комментарий от firkax 15.11.22 00:27:15 MSK

Нет, просто ты повесил ядро (в пункте 4 это видно).

Рекомендую ознакомиться с https://stackoverflow.com/questions/223644/what-is-an-uninterruptible-process

Вообще в таких случаях очень полезно смотреть dmesg.

kawaii_neko ★★★★
(15.11.22 17:38:31 MSK)

Ссылка

Ответ на: комментарий от slovazap 15.11.22 15:30:08 MSK

И эти люди смеялись что FreeBSD падает при вытаскивании смонтированной флешки…

Да, FreeBSD эволюционировала, и теперь всего лишь зависает вся USB-подсистема при отключении USB-звуковушки, пока открыто устройство микшера. В моём случае это были наушники, подключённые в режиме DAC через USB.

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

По умолчанию флешки монтируются с опцией flush, поэтому процесс cp не завершается, пока файл физически не скопируется на носитель.

Хорошо — перемонтировал без этой опции, запустил копирование (которое в этот раз выполнилось очень быстро), затем сразу sync и попытался размонтировать. Результат: umount ждёт сброса буферов и до этого не завершается, даже с опцией -f.

Тогда я физически выдернул флешку во время выполнения sync и umount — оба процесса немедленно завершились, и повторное подключение флешки никаких проблем не вызвало.

Всё проверялось на стандартном ядре 5.10.

Rootlexx ★★★★★
(15.11.22 18:00:20 MSK)