Переустановка будет и проще полноценного разбирательства и надёжнее по полученным результатам.
Кстати, если у вас на этом разделе ничего важного, то не факт, что БТРФС там вам вообще нужна (хотя я не уверен, что эта ФС нужна тем более для важной информации).
Это старенькая машина 15-летней давности, которая была до сих пор задействована только для банковских платежей по 2 часа в месяц. Но недавно я на нее залил торренты и загрузил по полной программе. И сразу read-only в btrfs. Это внушает мне оптимизм, потому что ext4 при этом не отметилась ничем, кроме запуска fsck при загрузке (это я задним числом узнал), а потом работала как ни в чем не бывало. И сколько бы я еще проработал с битой памятью и битыми данными на диске в таком случае? А btrfs сразу вычислила кривое железо!
btrfs check --repair обычно считается самым последним вариантом, "пан или пропал", когда всё остальное опробовано и не дало результата.
Запустил btrfs check --repair с флешки (grml 2024.02, версия btrfs 6+)
Куча ошибок исправлена, судя по выводу. Но ошибки остались, естественно, так как не было избыточности данных. Загружаюсь в Mint, система работает, и btrfs больше не переходит в read-only.
Вот результат (btrfs check --force):
(...) Много записей типа
incorrect local backref count on 318316544 parent 11601936384 owner 0 offset 0 found 0 wanted 1 back 0x5591dbf43cf0
backref disk bytenr does not match extent record, bytenr=318316544, ref bytenr=0
backpointer mismatch on [318316544 8192]
(...) Потом много записей типа
backpointer mismatch on [17160978432 4096]
ref mismatch on [17160982528 4096] extent item 4, found 3
incorrect local backref count on 17160982528 parent 11427397632 owner 0 offset 0 found 0 wanted 1 back 0x5591ddd48880
backref disk bytenr does not match extent record, bytenr=17160982528, ref bytenr=0
(...) Потом много записей типа
unresolved ref dir 409 index 992 namelen 18 name subscriptions.conf filetype 1 errors 2, no dir index
(...) Результат:
ERROR: errors found in fs roots
found 13489639424 bytes used, error(s) found
total csum bytes: 11854028
total tree bytes: 726679552
total fs tree bytes: 687980544
total extent tree bytes: 23232512
btree space waste bytes: 133227555
file data blocks allocated: 35830775808
referenced 27065204736
Как подчистить остатки? Потерянные файлы не проблема. Я просто переустановлю все имеющиеся пакеты. И система как новенькая.
Есть еще команда btrfs rescue. Там интересные опции имеются...
Оперативка на всех одна. Означает ли это, что на разделе с данными (ext4) тоже проблемы, просто ext4 менее требовательна и не кричит об этом?
Тут уж как повезёт.
Может действительно, что-то и повредилось. А может и пронесло. Начните с проверки тех файлов, которые можно удобно проверить на целостность.
Как я понимаю, в etx4 нет способа проверить данные внутри файлов. Явно обнулившиеся, например, видно. А остальные не проверишь средствами ФС, поскольку контрольных сумм нет.
ERROR: errors found in fs roots
found 13619191808 bytes used, error(s) found
total csum bytes: 12101448
total tree bytes: 600260608
total fs tree bytes: 562675712
total extent tree bytes: 21659648
btree space waste bytes: 106538600
file data blocks allocated: 22918488064
referenced 17799499776
Перед этим энное количество записей типа:
root 349 inode 1346888 errors 2001, no inode item, link count wrong
unresolved ref dir 55472 index 9 namelen 9 name copyright filetype 1 errors 4, no inode ref
В принципе, на этом разделе важных данных нет, только система.
Система грузится, внешне не заметно, что она битая. Но через несколько минут после запуска btrfs переходит в read-only и это видно в dmesg.
Версия btrfs-progs 5.16.2
Дальше repair с флешки или лучше какие-то другие варианты?
У меня еще 2 дополнительных вопроса.
1) Оперативка на всех одна. Означает ли это, что на разделе с данными (ext4) тоже проблемы, просто ext4 менее требовательна и не кричит об этом?
2) Перед заменой RAM я сгоряча удалил все снапшоты btrfs (показалось, что мало места на разделе осталось). Можно было бы откатиться на один из снапшотов в данном случае или даже btrfs сама бы его подцепила?
То есть BIOS компьютера может управлять поведением внешней видеокарты? Сюрприз.
Комп действительно не новый, socket 775.
Может помочь перепрошивка видеокарты?
Извлечь возможно. Но не хочется, так как придется прошивать несколько раз и тестировать.
Могут токи при прошивке БИОСа повредить процессор? Вообще на материнке много разных важных микросхем. Они же остаются. По идее с ними ничего не случится. Как с процессором?
Valentin Barbolin дал правильный ответ. У меня почему-то resolv.conf был пустой. После обновления по DHCP в нем появились DNS-сервера. Я закомментировал строки server= в dnsmasq.conf, и заработало.
Valentin Barbolin,
Я создал папку, как в ответе на superuser.com:
/etc/resolver
В нее положил файл dev
-----------------------------------
nameserver 127.0.0.1
-----------------------------------
В Debian не работает.
В ответе на superuser.com речь об OS X.
Также не очень понятна связь между папкой /etc/resolver и dnsmasq
Сделал доступ на другие порты компьютера (3). Все ОК. Более того, компьютер (3) - это не только клиент OpenVPN, он еще и шлюз из VPN в локалку. Часть перенаправлений портов с компьютера (2) на (3) требует перенаправлений с (3) на компьютеры локалки. С помощью POSTROUTING -o tun0 на (2) и (3) все заработало!
Теперь iptables на компьютере (2) в моем примере в начале топика выглядят так:
==========================================
*filter
:INPUT ACCEPT [480:23477]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1527:542132]
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 63254 -j DNAT --to-destination 172.28.2.254:22
-A POSTROUTING -d 172.28.2.254 -p tcp -m tcp --dport 22 -o tun0 -j MASQUERADE
COMMIT
===============================
Это старенькая машина 15-летней давности, которая была до сих пор задействована только для банковских платежей по 2 часа в месяц. Но недавно я на нее залил торренты и загрузил по полной программе. И сразу read-only в btrfs. Это внушает мне оптимизм, потому что ext4 при этом не отметилась ничем, кроме запуска fsck при загрузке (это я задним числом узнал), а потом работала как ни в чем не бывало. И сколько бы я еще проработал с битой памятью и битыми данными на диске в таком случае? А btrfs сразу вычислила кривое железо!
Запустил btrfs check --repair с флешки (grml 2024.02, версия btrfs 6+)
Куча ошибок исправлена, судя по выводу. Но ошибки остались, естественно, так как не было избыточности данных. Загружаюсь в Mint, система работает, и btrfs больше не переходит в read-only.
Вот результат (btrfs check --force):
(...) Много записей типа
incorrect local backref count on 318316544 parent 11601936384 owner 0 offset 0 found 0 wanted 1 back 0x5591dbf43cf0
backref disk bytenr does not match extent record, bytenr=318316544, ref bytenr=0
backpointer mismatch on [318316544 8192]
(...) Потом много записей типа
backpointer mismatch on [17160978432 4096]
ref mismatch on [17160982528 4096] extent item 4, found 3
incorrect local backref count on 17160982528 parent 11427397632 owner 0 offset 0 found 0 wanted 1 back 0x5591ddd48880
backref disk bytenr does not match extent record, bytenr=17160982528, ref bytenr=0
(...) Потом много записей типа
unresolved ref dir 409 index 992 namelen 18 name subscriptions.conf filetype 1 errors 2, no dir index
(...) Результат:
ERROR: errors found in fs roots
found 13489639424 bytes used, error(s) found
total csum bytes: 11854028
total tree bytes: 726679552
total fs tree bytes: 687980544
total extent tree bytes: 23232512
btree space waste bytes: 133227555
file data blocks allocated: 35830775808
referenced 27065204736
Как подчистить остатки? Потерянные файлы не проблема. Я просто переустановлю все имеющиеся пакеты. И система как новенькая.
Есть еще команда btrfs rescue. Там интересные опции имеются...
Как я понимаю, в etx4 нет способа проверить данные внутри файлов. Явно обнулившиеся, например, видно. А остальные не проверишь средствами ФС, поскольку контрольных сумм нет.