drive mount problems only in kde

[Duncan]

P .NIKOLIC posted on Sat, 22 Sep 2012 09:39:53 +0100 as excerpted:

> Hi list
> 
> 
> Well this is going to be a corker  i am running as in the sig block arch
> Linux  x86_64   KDE 4.9.1  .
> 
> When i boot the system and leave KDM to stat kde x ect  and log into KDE
>  i get both  / and /home mounted ro....  BUT

I'm going to assume that was supposed to be "leave KDM to _start_ kde, X, 
_etc_".  Because there is a (kernel) "stat" function related to files, 
but the context in which you used the term doesn't seem to make sense, so 
I'm left to guess what you really meant.  And "ect"... makes no sense 
either, "etc" is my best guess and fits the (reconstructed) context.

So I'm assuming the sentence should read:

When I boot the system and leave kdm to _start_ kde, X, etc., and log 
into kde, I get both / and /home mounted ro... BUT

> If i do not log into KDE but come out to a tty log in as root and check
> then both are mounted correctly mounted rw my question is What in KDE
> 4.9.1 is faffing around and changing the mount status and how do i stop
> it

Interesting question.  As Harry says, it's likely an Arch-specific 
problem, which suggests taking it to the arch forums/lists/whatever.  
However, as a gentooer who runs pre-release git kernels enough to be a 
bit more familiar with Linux kernel internals and discussions (thus the 
observations about "stat" above, tho that's filesystem level, so pretty 
much any userspace program that deals with files deals with stat too) 
than many, I can make some general observations that might explain some 
of it, tho you'll likely still have to go to the arch forums/lists to get 
help with a fix, since a fix would be in Arch-specific configuration.

1) The rootfs (/) is traditionally originally mounted ro/read-only, until 
a fsck can be done to ensure the filesystem is in order, before 
remounting it rw/read-write.

If the system crashed or the filesystem otherwise didn't complete a clean 
shutdown, the fsck fixes the problem before writes have a chance to make 
it worse.  But unlike other filesystems, fsck and the filesystem-specific 
fsck that it in turn launches, normally reside on rootfs, so it must be 
mounted read-only in ordered to access them, while other filesystems can 
remain entirely unmounted until after their fscks.

2) That rootfs remains ro, then, could imply that the initscripts running 
the fsck and subsequent remount rw are never invoked.  That would imply 
that the initscripts that fsck and mount other filesystems aren't run 
either, altho in a traditional config that would mean they aren't mounted 
at all, while you said /home is mounted, but ro.  But for all I know arch 
handles things a bit differently and mounts /home ro as well.  <shrug>


If that's the problem, then the solution is a "simple" one.  However kdm 
is being invoked, ensure that it depends on (or simply comes after, 
depending on your init system, gentoo's openrc handles depends and 
parallel initscript launching, as does systemd, but the traditional 
sysvinit didn't, and IDR whether upstart does or not, those that don't, 
simply depend on serialized and specified-order launching) the standard 
initscripts, which should then fsck and (re)mount all mount-at-boot 
filesystems normally (rw in your case).


3) An alternative and much more serious problem would be that something's 
triggering the kernel into switching the mounts to ro.  If the kernel 
detects a hardware problem (that in itself isn't serious enough to 
trigger a full system crash), rather than risk writing to the wrong place 
on-disk and (further) corrupting existing on-disk data, it automatically 
switches affected filesystems to ro mode.

I recently went thru this with an old (purchased in 2003, tho it was a 
dual socket Opteron that I had dual-core Opteron 290s in, so quad-core 
@2.8GHz, not /too/ bad, but the six-core "Bulldozer" fx6100, rated 3.3 GHz 
but OCed slightly to 3.6 GHz, that I replaced it with, is of course 
nicer, the best bit was getting off of AGP onto PCIE!) motherboard that 
popped a capacitor.  When the system was cold enough (< ~68F/20C, room-
temp), the capacitor would still function well enough to keep the system 
running.  But if it got too warm (it's Phoenix, AZ, with outside summer 
temps 45C/113F+ and comfortable ACed room temps for me are near 28C/82F), 
the system would stall disk access (both read and write) and sometimes 
the kernel would trigger ro on one or more partitions.

Obviously if this is your problem, MUCH more serious, as I said.  You'll 
probably end up buying new hardware, and I'd suggest doing it before you 
lose what you have entirely, but as my experience illustrates, it could 
be the disk, the mobo, maybe just overheating or the cabling to the disk 
needing reseating, the drive interface expansion card if it's not 
directly on-mobo, the powersupply, memory, CPU... tho probably either the 
cables, disk, mobo, or drive interface card.

And it's reasonably possible that the process of starting X and kdm, then 
kde, accesses parts of the disk that simply booting to a CLI (command-
line interface) doesn't access, thus tickling the hardware bug only via 
kdm, etc, too.

4) One thing you can try is logging in at the CLI and running startx from 
there.  That's actually what I do.  I don't even have a *dm (kdm/xdm/gdm/
etc) installed.  Before you do so, however, you'll likely need to 
configure the X session to start kde, rather than whatever other X 
desktop environments you may have installed.  That'd be arch-specific 
again, tho there's a general method for doing it via a user's ~/.xinit 
instead, if desired.  (Here on gentoo, the default if nothing else is 
configured is a minimalistic twm with an xterm to type commands in and 
xclock running.  But of course I don't have them installed either, so if 
I didn't configure kde as my session, it'd either just give me a bare X 
desktop with nothing running, or abort and I'd end up back at the CLI, I 
honestly don't know which as I've never actually tried it, since I 
uninstalled twm/xterm/xclock.)

If when starting X/KDE from the CLI, you still end up in ro mode, then 
it's likely either a hardware issue, or something strange in arch's 
configuration, triggering it.  If OTOH launching X/KDE via startx yields 
rw mode, then it's very likely an initscript configuration issue; simply 
failing to start the proper initscripts when booting to kdm.


5) FWIW, as I said, I don't even have a *dm installed, choosing instead 
to login at the CLI and launch X/kde via startx from there, if I want to 
run it.  I've been doing that for probably a decade now, since my 
mandrake (which became mandriva, and would now be mageia, I guess) days 
before I switched to gentoo in early 2004.  As it happened, I started 
using the CLI login and startx method due to a *dm issue as well, while 
the startx method "just worked".  I was running mandrake cooker, the test 
version, at the time, and I'm sure whatever the problem was, was fixed 
relatively quickly.  But I just switched to a CLI login and running startx 
if I wanted X/kde, and never looked back.

It seems like the graphical *dm login method isn't as robust and is thus 
prone to various bugs, while the startx method, once setup to start your 
preferred DE, "just works".

Plus, as a user gets more advanced and comfortable with the CLI, very 
often they don't want to automatically boot into X anyway, and /prefer/ 
the CLI login, then starting x as they would any other app, if they want 
to run it.  To an advanced user, loading up a full X just to stop it 
again because they're doing some system reconfiguration or backups or 
something, and don't need X running anyway, seems such a waste.  When a 
user gets to that point, it's just easier and less hassle to login at the 
CLI, and run X and the graphical desktop as the would any other app, if 
and when they need it.

At that point the *dm becomes a toy that's nice for the newbie to have, 
but not very practical for an experienced user.  Like all such outgrown 
toys, it sits in the corner for awhile, mostly unused/forgotten, until at 
some point the user decides they don't /need/ it any more, and it's 
dumped/donated to the neighbor kid... uninstalled.  (Remember the Toy 
Story movies?)

Of course if your computer has other users, your kids... family... 
friends... that aren't as experienced with the CLI, the nice graphical *dm 
login can still be better for them.  And there's nothing wrong with 
keeping it for yourself, either, if that's what you prefer.  But after it 
breaks a time or two, while the startx method continues to work, 
especially if there's no less experienced users sharing the system to 
worry about too, like me, many experienced users just decide it's not 
worth the hassle, and quit using it.  YMMV.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.