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.
