LINUX.ORG.RU

файловая система доступна только для чтения

 , , , ,


0

1

Привет ЛОР! Случилась какая-то неведомая ***
включил я сегодня комп, появилось обновление хрома, я запустил обновление, включил музыку в Ябраузере на ютюбе и пошел заниматься своими делами, минут через 10-15 музыка затихла я пошел посмотреть, и увидел, что браузер закрылся, при попытке запустить ничего не произошло, залез в консоль и увидел что на любую команду ответ файловая система доступна только для чтения, pic
Когда-то уже сталкивался с такой проблемой, оказалось, что связано это с браузером Brave, и после его удаления все работало нормально, где-то полгода
теперь же то же самое проявилось с Ябраузером. после перезагрузки(пуск > питание > перезагрузить работало несмотря на нерабочую консоль) включил музыку в хроме, где-то минут 30 все работало нормально, но потом повторилось, а вот после перезагрузки уже появилось вот это
куда копать и как с этим быть?
ОС manjaro, если что, система на ssd
PS после первого раза проводил кучу проверок ssd, ошибок не было

PS после первого раза проводил кучу проверок ssd,

Какие?

Ну подыхает значит твой Kingston... Бэкапь и беги за новым кингстоном.

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

Какие?

какие-то команды со smart вписывал, много читал, о каждом параметре, и судя по результатам диск был впорядке, да и говорю же, что после удаления Brave проблема пропала на полгода

Ну подыхает значит твой Kingston

если быть точнее, то kingdian)

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

Скопируй файлы и папки командой cp -r в следующий раз, когда файловая система переходит в read-only состояние. На другой диск.

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

Ну, грубо говоря...

Обычно контроллер SSD посылает ядру сигнал о неисправности диска/исчерпании ячеек и ядро принимает решение перевести ФС в указанный режим для предотвращения ее дальнейшего разрушения.

Deleted ()

У тебя файловая сдохла. И все твои софтинки были ни при чем. Теперь беги за другим носителем, чтобы с этого данные забекапить. Форматнешь и дальше будет работать. А так - бэкап хоть научишься делать, прежде чем использовать экзотические ФС.

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

У тебя файловая сдохла

это я уже понял, хотелось бы оживить, есть снапшоты, правда они на том же разделе живут, то есть в /.snapshots

прежде чем использовать экзотические ФС

за 1,5 года ни единого разрыва, в чем может быть причина столь специфического поведения?

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

в чем может быть причина столь специфического поведения?

В кривости btrfs - тут на форуме регулярно появляются топики про различные проблемы с ней, причём почти у всех она ломается «внезапно» (с). Я бы не стал связываться с ФС, которая может встать колом в любой момент. Даже при наличии свежих бэкапов это, как минимум, потеря времени.

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

kingdian
Да ты мастер ходить по граблям.

Ну тут как повезёт, на самом деле. Я в 2015 купил из интереса на али Netac N5m 120 ГБ, он пару лет отпахал на моей машине, а теперь стоит в старом ноутбуке жены под Виндой 7-й. Пока не помер :) При этом у отца типа брендовый Kingston SATA 120 Гб сдох через полтора года.

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

В кривости btrfs

ясненько
терерь вопрос, могу ли я свои данные с бтр рсинкнуть на раздел hdd с ntfs? а потом перенести на заблаговременно подготовленный ext4 на ссд? (просто у меня дефицит свободного места на харде)

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

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

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

Лучше в tar-файл сохрани на свой ntfs-раздел. Если бэкапишь много файлов, то даже быстрее будет, чем просто копировать туда-сюда. Да и права на файлы сохраняться.

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

имеется такая структура

sudo btrfs subvolume list /mnt/
ID 258 gen 547472 top level 5 path @home
ID 259 gen 547245 top level 5 path @cache
ID 660 gen 547470 top level 5 path @
ID 828 gen 546506 top level 660 path @/.snapshots/2019-07-14--03-50-43-@daily
ID 829 gen 546775 top level 660 path @/.snapshots/2019-07-15--21-53-38-@daily
ID 830 gen 547467 top level 660 path @/.snapshots/2019-07-16--20-47-24-@daily

[br]
допустим @home я забэкаплю такой командой
tar -cvzpf /mnt/HDD/backup.tar.gz -C /mnt/@home

а как обойти снапшоты, которые лежат в @/.snapshots? фс ведь доступна для чтения, делетнуть их вряд ли удастся, а если и удастся, могу что-то повредить, @cache я так понимаю можно не бэкапить?
И да после бэкапа хотелось бы попробовать пофиксить то что имею, htower, RedEyedMan4, t184256 поможете? хотелось бы для себя разобраться где собака порылась, да и для опыта и общества полезно

agafron ()
Ответ на: комментарий от Deleted
tar --lzma -cvpf /mnt/HDD/home.tar.lzma -C /mnt/ssd/\@home
tar: Робкий отказ от создания пустого архива
Попробуйте «tar --help» или «tar --usage» для
получения более подробного описания.
[manjaro-mate manjaro]# tar -cvzpf /mnt/HDD/backup.tar.gz -C /mnt/ssd/\@home/
tar: Робкий отказ от создания пустого архива
Попробуйте «tar --help» или «tar --usage» для
получения более подробного описания.

ЧЯДНТ?

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

бэкап @ завершился неудачей

/mnt/ssd/@/.snapshots/
tar: /mnt/ssd/@/.snapshots/2019-07-14--03-50-43-@daily: Функция stat завершилась с ошибкой: Ошибка ввода/вывода
tar: /mnt/ssd/@/.snapshots/2019-07-15--21-53-38-@daily: Функция stat завершилась с ошибкой: Ошибка ввода/вывода
tar: /mnt/ssd/@/.snapshots/2019-07-16--20-47-24-@daily: Функция stat завершилась с ошибкой: Ошибка ввода/вывода
/mnt/ssd/@/.__deepin.db
/mnt/ssd/@/.check-aur
/mnt/ssd/@/.__deepin.lft
/mnt/ssd/@/.__deepin.num
/mnt/ssd/@/bin
/mnt/ssd/@/lib
/mnt/ssd/@/lib64
/mnt/ssd/@/sbin
/mnt/ssd/@/.Trash-1000/
/mnt/ssd/@/.Trash-1000/expunged/
/mnt/ssd/@/.Trash-1000/info/
/mnt/ssd/@/.Trash-1000/files/
/mnt/ssd/@/snap
tar: Завершение работы с состоянием неисправности из-за возникших ошибок

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

А я и не заметил про -C :) Пора на боковую...

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

я просто хотел сохранить все и потом без переустановки разметить заново диск и вернуть все на место, а потом тольео граб обновить и вуаля...
Ну а вообще в идеале хотелось бы все починить без этих танцев, бэкап как страховка

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

пробую чекнуть фс, такой выхлоп

btrfs check --repair --check-data-csum /dev/sdb1
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/sdb1
UUID: b79f6a6c-0ce8-4063-b7bb-717507e895a9
[1/7] checking root items
incorrect offsets 12308 12255
incorrect offsets 12308 12255
Fixed 0 roots.
[2/7] checking extents
incorrect offsets 12308 12255
Shifting item nr 78 by 53 bytes in block 56930172928
Shifting item nr 79 by 53 bytes in block 56930172928
Shifting item nr 80 by 53 bytes in block 56930172928
Shifting item nr 81 by 53 bytes in block 56930172928
Shifting item nr 82 by 53 bytes in block 56930172928
Shifting item nr 83 by 53 bytes in block 56930172928
Shifting item nr 84 by 53 bytes in block 56930172928
Shifting item nr 85 by 53 bytes in block 56930172928
Shifting item nr 86 by 53 bytes in block 56930172928
Shifting item nr 87 by 53 bytes in block 56930172928
Shifting item nr 88 by 53 bytes in block 56930172928
Shifting item nr 89 by 53 bytes in block 56930172928
Shifting item nr 90 by 53 bytes in block 56930172928
Shifting item nr 91 by 53 bytes in block 56930172928
Shifting item nr 92 by 53 bytes in block 56930172928
Shifting item nr 93 by 53 bytes in block 56930172928
Shifting item nr 94 by 53 bytes in block 56930172928
Shifting item nr 95 by 53 bytes in block 56930172928
Shifting item nr 96 by 53 bytes in block 56930172928
items overlap, can't fix
check/main.c:4243: fix_item_offset: BUG_ON `ret` triggered, value -5
btrfs(+0x5c2b2)[0x55a82302f2b2]
btrfs(+0x658ff)[0x55a8230388ff]
btrfs(+0x65c80)[0x55a823038c80]
btrfs(+0x668bc)[0x55a8230398bc]
btrfs(cmd_check+0x1384)[0x55a82303deb4]
btrfs(main+0x92)[0x55a822fe60c2]
/usr/lib/libc.so.6(__libc_start_main+0xf3)[0x7f587c3d2ee3]
btrfs(_start+0x2e)[0x55a822fe62ce]
Aborted (core dumped)

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

В тред для помощи призывается intelfx, замеченный в использовании btrfs :)

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

Первое правило btrfs — запускать btrfs check --repair только после посекторного бэкапа сломанного тома. Оно может сделать ещё хуже (например, упав посередине процесса, что у тебя и произошло).

Том хотя бы в R/O продолжает монтироваться? Забэкапь данные, если ещё этого не сделал, и сноси ФС к чертям.

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

Вернись на ext4, а про снапшоты забудь. Btrfs сырая.

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

фс монтируется, бэкап смог сделать только @home, на бэкапе @ происходит это, RedEyedMan4 советует @ бэкапить по отдельности

после посекторного бэкапа сломанного тома

это какими средствами делается?

и сноси ФС к чертям

в общем возвращение фс в статус кво невозможен?

agafron ()

и еще, в качестве совета, раз уж мне с вероятностью в 99% придется переустанавливать ось, хотел бы задать такой вопрос. У меня комп умеет в ефи и в легаси, когда ставил систему еще где-то в 2015 то с ефи заморачиваться не стал, что скажете, есть ли смысл или не заморачиваться?

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

на бэкапе @ происходит это

И что, это весь @? В бэкап ничего не попадает в итоге?

RedEyedMan4 советует @ бэкапить по отдельности

Нет никакого смысла это делать — вообще-то tar пропускает файлы с ошибками и продолжает архивировать всё что может. Если у тебя получается пустой архив — то твоей ФС хана, поздравляю.

это какими средствами делается?

Любыми. Например, dd.

в общем возвращение фс в статус кво невозможен?

Тебе бы сначала данные спасти. Про восстановление самой ФС забудь.

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

И что, это весь @? В бэкап ничего не попадает в итоге?

бэкап создается, сегодня перепроверил, в сжатом виде(lzma) 11.3 Гб, вот вроде как все основное есть
переживаю, что он некорректно распакуется

Про восстановление самой ФС забудь.

ok

Тебе бы сначала данные спасти.

@home создал, @ то что есть создал, @cache - не обязательно, насколько я понимаю?
Если все верно завтра приступлю к восстановлению
есть ли еще какие-то поводные камни?
ЗЫ. хотел бы на счет бтрфс уточнить, на какой период о ней стоит забывать?

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

и еще, архив сохранился с жесткими путями типа /mnt/ssd/@/, как его правильно распаковывать, например в / ?

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

На ближайшие лет 5 забудь про неё. Используй ext4 поверх LVM, если хочется больше гибкости, стабильнее ничего нет пока. А вот ошибки ввода-вывода наталкивают на мысль, что у тебя не с ФС проблема, а с диском. Ты бы его SMART показал.

Deleted ()
Ответ на: комментарий от agafron
  1. бэкапить образ раздела при помощи dd в два разных места и лепишь на них chattr -i для надежности

  2. делаешь с последующими их копиями что душе угодно, я бы начал с mount -o ro,subvolid=??? и последующий tar, а параллельно поигрался бы со средствами восстановления btrfs

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

btrfs

Выбрось это поделие. Лучше уж NTFS, чем это.

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

бэкап создается, сегодня перепроверил, в сжатом виде(lzma) 11.3 Гб, вот вроде как все основное есть

Тогда всё отлично.

переживаю, что он некорректно распакуется

Если создался — распакуется.

@home создал, @ то что есть создал, @cache - не обязательно, насколько я понимаю?

Просто смонтируй свою ФС с -o ro,subvol=/ и забэкапь всю точку монтирования. На твоём месте я бы разбирался уже потом, после распаковки на новую ФС.

ЗЫ. хотел бы на счет бтрфс уточнить, на какой период о ней стоит забывать?

Я не говорил «забудь про btrfs». Это всякие истерички говорят, я к ним отношения не имею. Я говорил, что не стоит пытаться восстановить данный конкретный экземпляр btrfs: если ФС продолжает читаться, то гораздо проще забэкапить всё что читается и пересоздать ФС с нуля.

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

Просто смонтируй свою ФС с -o ro,subvol=/ и забэкапь всю точку монтирования. На твоём месте я бы разбирался уже потом, после распаковки на новую ФС.

монтировал так mount -o subvolid=0 /dev/sdb1 /mnt, щас еще делаю сжатый образ жд с помощью dd dd if=/dev/sdb bs=8M conv=sync,noerror status=progress | gzip -c > /mnt/HDD/backup.img
на сколько я понимаю, его можно будет потом смонтировать и из него вытащить все необходимое, если можно объясни один момент, dd ведь сохраняет образ жд полностью с учетом структуры поломанной фс и неразмеченного пространства, предполагаю, что я его смонтирую, а потом с помощью rsync всё это дело раскидаю по вновь созданным разделам, интересует вероятность поймать что-то невразумительное.
ну и еще у меня есть все в tar, какой способ корректней?

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