On Friday, April 08, 2011 12:21:07 PM Duncan did opine:
> gene heskett posted on Fri, 08 Apr 2011 06:50:36 -0400 as excerpted:
> > On Friday, April 08, 2011 06:23:40 AM Duncan did opine:
> >
> > I will do that, and reboot in a few minutes. Because I have /var on
> > its own partition, this always involves a tap of the reset button as
> > the shutdown gets to:
> > turning off swaps -f and hangs due to /var already having been
> > unmounted & it can't get a lockfile opened.
> >
> > I know, that is not preferred, but having had a couple of instances
> > where an error made / into read-only, that prevented the logs from
> > recording any trace of the error, and was pure hell to troubleshoot,
> > the first time I just re-installed. So I am adament about /var being
> > on its own partition just to prevent the loss of logging when the
> > main / goes tits up. IMO, the shutdown scripts that cannot work
> > under those conditions are hopelessly broken.
>
> FWIW, here /var is on /, but /var/log is on its own partition.
>
> I believe I mentioned the disk overheat I had. Well, at the time I
> didn't have another drive at hand and one the drive cooled down, the
> problem didn't seem to be getting seriously worse. And I had
> partitioned the thing up with duplicate/backup partitions for much of
> the system, so that's what I ended up booting, some of the backups.
>
> But I ended up with a / of one age, /usr of another, and the current
> /var, each on its own partition separate from the other two. That was
> terrible to try to sort out, as what the package manager installation
> database (in /var/db) had to say didn't match the reality of what was
> installed on /, which didn't match /usr. I started by reinstalling all
> the packages (on Gentoo, but from binpkgs, which I always made it a
> point to build, as they come in handy for all sorts of reasons, the
> binpkgs partition was thankfully current) the package database said
> were installed anyway. That got me back to in sync there, but because
> the old versions were different, where the actual filenames differed as
> where libraries had been updated, I now had "orphan" old versions that
> weren't removed as they would have been in a proper upgrade. It took
> me months to cleanup that mess, a bit at a time as I realized there
> were yet more orphans lurking around!
>
> So when I did the partition plan for the new system, I decided that
> everything the package manager installed to along with its database in
> /var/db, should be on the the same partition, so if it happened again,
> the database and all package installations would at least be in sync
> with each other, no matter which partitions I ended up mix and
> matching, and how old the backup partition was that I ended up using.
>
> By contrast, /var/log really does need its own, relatively small,
> partition. Several times I've had various bugs runaway with the
> logging, and end up filling up the log partition, normally only about a
> third of capacity even right before the weekly logrotates. The
> relatively small (1 gig... I still find it a bit ironic to call that
> "small" but anyway) log partition has kept the issue from filling up /,
> while the small spare capacity, always under a gig, means I find out
> about it far sooner than I would if it were on a partition with
> double-digit gigs or more of spare capacity.
>
> But the "everything the pm installs to and the pm database" policy for
> /, has meant a bit of a strange setup, with several bits of /usr either
> as their own filesystems (/usr/local, since it contains a lot of local
> scripts and the like I'd hate to have to reauthor) or symlinks onto
> filesystems mounted elsewhere (/usr/src, for instance, is a symlink to
> a subdir of my only raid-0 backed filesystem, since it's locally cached
> net data, with the distro package tree as another subdir on the raid-0,
> with the same local-cached net data reasoning).
>
> >> Anyway, assuming those unreadable-by-root files are indeed filesystem
> >> damage as I expect, there's a fair chance it's due to data=writeback
> >> on that filesystem, be it ext3 or ext4. For both of them, if it
> >> were my data on the filesystem and unless it was something I was
> >> comfortable sticking on a RAID-0 without redundancy or backup, I'd
> >> take tune2fs and ensure the filesystem was marked data=ordered in
> >> the filesystem itself, Additionally, make sure your mount options
> >> (or remount, for root) include the data=writeback option.
> >
> > What is the syntax to extract that info?, the -l output as shown below
> > doesn't say.
>
> I don't see it either, which means that if it's not set at mount time by
> either the mount command or fstab, the kernel defaults apply. And we
> know that data=writeback was the kernel default for part of the 2.6.3x
> series.
>
> > I'm off to do a full powerdown reboot, and at least 1 full cycle of
> > memtest86. /.autofsck touched. With 4Tb of fscking to do, I won't
> > say brb. :-)
>
> You got /that/ right!
Well, apparently the fsck worked, but the invocation is silent, all one
sees at boot time is a stalled boot, with the drive activity led stuck on.
No invocation line, no progress indication on screen. So, not feeling that
well, I went back to bed, and when I woke up again I had a login screen.
So I did. I had made sure the widgits were locked before the reboot. I am
back to a totally fscked up kde. My background of choice is on workspace
1, as is a cachew in the upper right corner. All the apps, like a couple
of konsoles with multiple tabs, a copy of firefox, were all opened on
workspace one on top of each other. And no task manager bar. So I moved
them to the worklspaces they normally lived on.
Rolling the mouse wheel got me to workspace 2, where I find I have no
cashew, but perhaps 9 or so task manager panels all stacked up on each
other, and at slightly different size scales. So I unlock the widgets,
start scaling then up so I can select the top one easily, and delete them
one by one till I am down to just one. So I come to the conclusion that a
casahew and the task manager bar are mutually exclusive, so on workspace 1
I have added the icons to the screen at random locations, so I can launch
an app, or click on the pager and have those function available. On the
other 9 workspaces, I have a task manager bar, but no cashew, so I cannot
select a screen background.
Back in my salad years, we used to have an insecticide called "Cook's Real
Kill" that came in quart bottle with a finger press spray pump. The point
I'm leading up is that methinks kde needs a liberal application of this,
say about a gallon... Obviously there is a contaminated file, maybe more,
that is creating all this havoc-hate & discontent, but no one close enough
to the kde camp to know what needs to be fixed is actually reading this
list.
BUT, I haven't located a bootable cd with memtest86 on it either, thats
next, as there is no use my becoming terminally frustrated every time I
reboot trying to make it like I want it when the tools are only available
if one has a cashew to do it with. The one, really maddening item missing
is the ability to restart a missing cashew on a given workspace.
Off to run memtest.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://tinyurl.com/ddg5bz>
<http://www.cantrip.org/gatto.html>
You don't have to explain something you never said.
-- Calvin Coolidge
___________________________________________________
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.
