4.6.2 early report

[gene heskett]

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.