I have upgraded every piece of hardware, except HD. I’ve been getting error messages:
“Configuration file ~/.config/[configfilename] not writeable.”
[configfilename] in {kscreenlocker-greetrc, konsolerc, ksmserver-logout-greetrc} (amongst others).
On investigation, the file doesn’t exist, although “konsolerc” does, and I have "chmod a+rw"d it.
Usually the only solution to get the system working is a reboot.
Driving me to distraction. Any help / advice appreciated.
Two possibilities:
(1) you did something as root, against usual advice. And now you don’t own those file because the owner is root.
(2) you are having disk device errors on that partition, causing the system to remount it as read-only.
It might help if you could post the output of:
ls -l ~/.config/konsolerc
and perhaps similar for some other files giving you problems. Maybe also the output fro
cd ~/.config
ls -ld .
I definitely own the file (when it exists). Can’t give you “code” because I’m on a different computer.
~/.config permissions were drwx------. When I tried to r-x for group / others, I was getting an error the the directory was readonly. After reboot, I was able to change the permissions.
I have been thinking the problem is disk related, although it is only a few months old. (Seagate 2Tb). Any way to tell SUSE where the bad pieces of disk are?
SMARTmontools…
https://software.opensuse.org/package/smartmontoolshttps://www.smartmontools.org/wiki/BadBlockHowto
https://wiki.archlinux.org/index.php/S.M.A.R.T.
man smartctl
I’m now getting errors with vi:
-rw-r--r-- 1 greg users 12288 Aug 2 10:31 .powerball1.cpp.swp
greg@linux-rbnt:~/cpp> rm ./.powerball1.cpp.swp
rm: cannot remove './.powerball1.cpp.swp': Read-only file system
Trying to save file:
E138: Cannot write viminfo file /home/greg/.viminfo.tmp!
greg@linux-rbnt:~> ls -l ~/.viminfo.tmp
ls: cannot access '/home/greg/.viminfo.tmp': No such file or directory
greg@linux-rbnt:~> ls -ld
drwxr-xr-x 1 greg users 728 Aug 2 10:23 .
Looks like time for (another) new HD!
linux-rbnt:~ # smartctl -a /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.12.14-lp151.28.52-default] (SUSE RPM)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 3.5
Device Model: ST2000DM006-2DM164
Serial Number: Z4Z9BJ0H
LU WWN Device Id: 5 000c50 0a5052317
Firmware Version: CC26
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Mon Aug 3 09:35:48 2020 AEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
linux-rbnt:~ # smartctl -H /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.12.14-lp151.28.52-default] (SUSE RPM)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Appears nothing wrong with the disk (or am I missing something?). What is causing OS to suddenly switch to RO mode?
You show only information purporting that everything is fine. Thus I guess your problem could be related to bad karma. You may show all information: using “smartctl -x /dev/sda”. Check the log for errors using journalctl and post your findings.
I give up. I have 2 older HDs, both WD 1TB. In both, smartctl reports bad blocks (in the Windows partition).
1 is running the same kernel :
uname -r
4.12.14-lp151.28.52-default
as this Seagate 2TB, 1 runs a slightly older kernel.
Neither has the problems this Seagate drive is presenting.
All 3 setups get updates from the same repositories.
I think it’s time to go back to WD.
There is probably nothing wrong with your system.
The files you’re trying to remove are temporary files created by the app to allow recovery in case something happens to the main working file.
I’m not sure about your powerball app, but this can easily be seen running vim…When you shutdown vim while working on a file, you can immediately re-open vim and you’ll see not just the file but your cursor will be in the same location where you were last.
If the file is actively in use, the system won’t allow you to remove the file.
If the file is essential, the program may not allow you to remove the file.
If the file is missing, try manually creating a file with that name, the failure may be because the function has permission to modify the file, but not to create it.
smartctl has nothing to do with this situation, but if you do use smartctl, I advise you to learn how to use it correctly…
When smartctl reports bad blocks, that by itself is not bad and is actually fairly common.
What matters is that you should archive that number somewhere, and run the test again in the future.
If the number of bad blocks stays the same, it’s not a problem.
If the number of bad blocks grows, then that’s cause for concern… Either determine if another part is causing the problem (eg bad disk controller, bad power supply) or if the problem could be a drive going bad (yes, it must progressively go bad).
All hard drives are manufactured with the assumption some blocks will go bad, and the internal electronics will detect problems and mark bad blocks permanently if necessary and write to a different location to preserve integrity. Different manufacturers have different strategies how they do this and it’s all done invisibly to the User.
So, don’t toss those drives yet, just keep an eye on them for awhile.
And, don’t forget to create an issue at https://bugzilla.opensuse.org.
There’s no way to know at this point is this problem happened only on your system but if can be replicated (That’s an idea, are you running Virtualbox or other virtualization? Try to see if the problem shows up in a new installation exactly how you set up).
If your problem can be replicated, reporting can fix the problems so others won’t see it.
HTH,
TSU
Thanks your comments Hsu. But I think you missed one important point in relation to my “powerball” app - the error is because it is on a “Read only file system”. Yet when the session started, everything was fine, everything was writeable. Then something happened that turned the system to “R/O”.
When the session started, the configuration files (eg konsolerc) were present, with full rw_ permissions. Even when the system reported the file not writeable, the file was there, with full rw_ permissions.
Long story short - it would seem that when I upgraded the hardware, I happened to get what is probably the only RAM that wasn’t compatible with the CPU. After researching and obtaining RAM that works with the CPU, the system is working fine.
Oops, took you ~3 month to find out?
In any case, fine it works now and thanks for reporting back.