[Решено] Разделы монтируются в ro

Всем привет. После вчерашнего экстренного отключения питания электроэнергии все разделы на трех дисках начали монтироваться в ro
Из другого дистрибутива все нормально работает
Содержимое mtab:
Файловая система ntfs
/dev/sdb3 /run/media/mic/30660A0C6609D40E fuseblk ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
Файловая система btrfs
/dev/sda3 /run/media/mic/Debian btrfs rw,nosuid,nodev,relatime,ssd,discard=async,space_cache,subvolid=5,subvol=/ 0 0
Файловая система xfs
/dev/sdc2 /run/media/mic/backup xfs rw,nosuid,nodev,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
В fstab записей о них не было, т.к. разделы монтировал в случае надобности.
ls -hl /run/media/mic/
drwxrwxrwx 1 mic users 8,0K мар 17 10:20 30660A0C6609D40E
drwxr-xr-x 3 root root    23 мая  8  2021 backup
drwxr-xr-x 1 root root   250 мар  9 09:52 Debian
И даже не смотря на то что один из разделов в правах пользователя, он не доступен для записи
touch /run/media/mic/30660A0C6609D40E/bla.txt
touch: невозможно выполнить touch для '/run/media/mic/30660A0C6609D40E/bla.txt': Файловая система доступна только для чтения
Я не специалист по линукс, но я бы проверил на ошибки в GParted.
Очень странно что диски разного формата имеют проблему. У меня если падает Windows, то в Linux ntfs-диск переключается в po, пока я не перезагружу в Windows и не выключу её нормально, то есть её падение не влияет на другие диски, да и это невозможно так как диски Linux не монтируются в Win10 с поддержкой записи. В последнее время только LinuxReader позволяет просматривать диск не монтируя его.
И ещё предположение, например у меня часто проблема со шлейфом, раз в 2 месяца зачищаю контакты, думаю свой вклад и БП вкладывает. Как раз таки если проблема со шлейфом, то проблема будет с любыми разделами жёсткого диска. Но опять же это не связано с экстренным выключением питания. Но если всё же питание выключилось потому что комп завис, то можно посмотреть шлейф.
мои программы
Не понятна фраза
ForumLiker
все разделы на трех дисках начали монтироваться в ro
Из другого дистрибутива все нормально работает
Где находится этот "другой дистрибутив" - на одном из трех дисков? ... или подключал внешний?
И еще:
- что за диски: HDD или SDD?
- какие диски были смонтированы в момент экстренного отключения питания?
- archlinux и "другой дистрибутив" на разных дисках? ... и если на разных, то был ли смонтирован диск с этим "другим дистрибутивом"

PS - первым делом не плохо бы выполнить проверку дисков (fsck ...), которые были смонтированы.
Как по мне, так ext4 вполне надежна при отключении питания - попадал много раз, но проблем не было.
Ошибки не исчезают с опытом - они просто умнеют
AZJIO, Ошибок нет, ком не зависал - отключили электроэнергию в доме.

vasek,
sda (SSD)     8:0    0 465,8G  0 disk
├─sda1   8:1    0   512M  0 part *Раздел boot
├─sda2   8:2    0    52G  0 part * Arch f2fs
└─sda3   8:3    0    50G  0 part  *Debian btrfs
sdb   (SSD)   8:16   0 223,6G  0 disk
├─sdb1   8:17   0   100M  0 part
├─sdb2   8:18   0    16M  0 part
├─sdb3   8:19   0 222,9G  0 part  *Windows ntfs
└─sdb4   8:20   0   520M  0 part
sdc    (HDD)  8:32   0 931,5G  0 disk
├─sdc1   8:33   0 831,5G  0 part *ntfs
└─sdc2   8:34   0   100G  0 part  *ntfs
Был смонтирован sda1, sda2, sdb3, sdc1
Что самое интересное, sdc1 доступен для записи, но он у меня монтируется через fstab
BTRFS только одна пережила нормально, внезапное пропадание питания.
А про F2FS я тебе уже в телеге несколько раз говорил:
F2FS имеет слабый fsck, что может привести к потере данных при внезапном отключении питания [3] [4] .

Если потери питания происходят часто, рассмотрите альтернативную файловую систему .
ForumLiker, начни все-таки с проверки дисков/разделов ... и начни с sda (линуксового): загрузись с параметром break=premount и поочередно проверь, без исправления, оба раздела sda2 и sda3, используя fsck, работающие для f2fs и btrfs.
В принципе можно проверить и прямо из системы. Если покажет ошибки, то можно попробовать запустить и с исправлением.
Желательно еще посмотреть у sda S.M.A.R.T. в части испорченых блоков, а лучше запустить еще и проверку.

Правильно понимаю, что диск sdb чисто виндовый и загрузка в винду идет нормально? - то есть он просто монтируется из linux в read only - и с ним делать ничего не нужно?

Это все, что пока пришло в голову … может кто то посоветуют и еще что то ...
Ошибки не исчезают с опытом - они просто умнеют
vasek
ext4 вполне надежна при отключении питания -
Вот-вот.
ForumLiker
Arch f2fs
ForumLiker
*Debian btrfs
ну винда понятно кроме корявой ntfs никуда не станет,для чего линукс ставить непонятно на что если есть самая быстрая и безотказная ext4.Подтомы верхнего уровня снапшоты всякие в btrfs,с самой задумки ненадежная f2fs...
Linux Forever!
Поддержу RusWolf в части использования f2fs ...
С большой вероятностью, что повреждена скорее всего f2fs и логичнее будет не искать/исправлять ошибки, а перенести все файлы на другой раздел/диск, отформатировать в другую файловую систему, например ext4, и вернуть все файлы обратно и подправить fstab.
Можно это провернуть и из debian или загрузочной флэшки. Я обычно использую для копирования MC (копирую все, кроме /mnt, в которую монтирую) - это проще, чем использовать cp.
Ошибки не исчезают с опытом - они просто умнеют
Привет! Судя по выводу команды `ls -hl /run/media/mic/`, у вас все директории в `/run/media/mic/` имеют права на запись для пользователя, что означает, что проблема скорее всего не в правах доступа. Возможно, после экстренного отключения питания произошла ошибка в файловой системе, и она была автоматически смонтирована в режиме "только для чтения", чтобы предотвратить дальнейшие повреждения.

Попробуйте выполнить следующие действия:

1. Проверьте файловую систему на этих дисках на наличие ошибок. Для NTFS можно воспользоваться утилитой `ntfsfix`, для Btrfs - `btrfs check`, а для XFS - `xfs_repair`.
2. Попробуйте выполнить монтирование разделов в режиме чтения-записи вручную, используя опцию `-o rw` или `mount -o remount,rw`. Например: `sudo mount -o remount,rw /dev/sdb3 /run/media/mic/30660A0C6609D40E`.
3. Если проблема не решится, попробуйте создать новый файловый раздел на диске, скопировать туда данные с текущего раздела и попробовать смонтировать его в режиме чтения-записи.

Надеюсь, это поможет вам решить проблему. Если не получится, обратитесь за дополнительной поддержкой. Удачи!
Ошибки в тексте-неповторимый стиль автора©
Все файловые системы проверил. Ошибок нет. Из советов осталось только смена файловой системы системного раздела, только не понимаю как это решит проблему.
 
Зарегистрироваться или войдите чтобы оставить сообщение.