On Sun, 23 Sep 2012 01:24:44 +0000 (UTC)
Duncan <1i5t5.duncan@xxxxxxx> wrote:
> 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.)
That is basically what i do now boot to CLI log in then kdm& after
several attempts i can get a usable system that way
>
> 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.
>
Well i have run so many tests on the hard drive all come up rosey , I
have a feeling this is going to turn out to be a problem with ext4 for
some reason and /or the latest util-linux
>
> 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.
Yes that is something not around "startx" in Arch linux i will have to
look into that
>
> 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.
I often think it would be nice to go back to OLVWM i used to like that
but along came kde and well the rest is history.
>
> 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.
>
I may well leave it boot to CLI now .
One thing i think i will do is back the entire /home up again and
re-install using XFS as i have an almost identical setup on the laptop
just using XFS updated the same times same updates and that dont miss
a beat
Cheers Pete
--
Linux 7-of-9 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012
x86_64 GNU/Linux
___________________________________________________
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.
