From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-desktop+bounces-1919-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Q5UyD-0007rL-92
for garchives@archives.gentoo.org; Fri, 01 Apr 2011 03:24:21 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 9B3611C020;
Fri, 1 Apr 2011 03:22:31 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 271F41C020
for <gentoo-desktop@lists.gentoo.org>; Fri, 1 Apr 2011 03:22:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 6C1851B407E
for <gentoo-desktop@lists.gentoo.org>; Fri, 1 Apr 2011 03:22:30 +0000 (UTC)
X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org
X-Spam-Score: -2.523
X-Spam-Level:
X-Spam-Status: No, score=-2.523 required=5.5 tests=[AWL=0.076,
BAYES_00=-2.599]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id IEtHTZimcaWg for <gentoo-desktop@lists.gentoo.org>;
Fri, 1 Apr 2011 03:22:22 +0000 (UTC)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
by smtp.gentoo.org (Postfix) with ESMTP id 838CC1B40BE
for <gentoo-desktop@gentoo.org>; Fri, 1 Apr 2011 03:22:20 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
(envelope-from <glgd-gentoo-desktop@m.gmane.org>)
id 1Q5UwE-0000te-MC
for gentoo-desktop@gentoo.org; Fri, 01 Apr 2011 05:22:18 +0200
Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-desktop@gentoo.org>; Fri, 01 Apr 2011 05:22:18 +0200
Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-desktop@gentoo.org>; Fri, 01 Apr 2011 05:22:18 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-desktop@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-desktop] Re: System problems - some progress
Date: Fri, 1 Apr 2011 03:22:07 +0000 (UTC)
Message-ID: <pan.2011.04.01.03.22.06@cox.net>
References: <1300596366.8325.30.camel@vishnu.fmp.com>
<20110321001034.42e087b8.zilka@fi.muni.cz>
<1300672634.8325.179.camel@vishnu.fmp.com>
<20110321095742.758b2278.zilka@fi.muni.cz>
<1300724287.1757.78.camel@ubuntu>
<685081770-1300738047-cardhu_decombobulator_blackberry.rim.net-274633814-@bda261.bisx.prod.on.blackberry>
<1300746267.11877.76.camel@vishnu.fmp.com> <4D87D52F.4060706@gmail.com>
<4D87FD44.1030502@gentoo.org> <1300990587.8052.61.camel@vishnu.fmp.com>
<AANLkTi=0XYSLKEshcs1Lbw=MNG8F=qWsNWq6ee+G4KD7@mail.gmail.com>
<1300999110.8052.287.camel@vishnu.fmp.com>
<AANLkTim_TT2zEajqP0w+qtv9OEViwGebDV5-fKUesJxf@mail.gmail.com>
<1301005988.8052.359.camel@vishnu.fmp.com>
<AANLkTi=--n0fu5DnT6NkYohKbQVkn1sZmcsJW6ir4zyw@mail.gmail.com>
<1301019013.1733.5.camel@ubuntu> <pan.2011.03.25.08.57.14@cox.net>
<1301057292.1780.17.camel@ubuntu> <pan.2011.03.25.22.59.33@cox.net>
<1301107592.1735.102.camel@ubuntu> <pan.2011.03.26.08.40.10@cox.net>
<1301155053.5544.74.camel@ubuntu>
Precedence: bulk
List-Post: <mailto:gentoo-desktop@lists.gentoo.org>
List-Help: <mailto:gentoo-desktop+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-desktop+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-desktop+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-desktop.gentoo.org>
X-BeenThere: gentoo-desktop@lists.gentoo.org
Reply-to: gentoo-desktop@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net
User-Agent: Pan/0.134 (Wait for Me; GIT 9383aac branch-testing)
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt:
X-Archives-Hash: fb0fefaf8f860ceb2d9b9ca72fddc970
Lindsay Haisley posted on Sat, 26 Mar 2011 10:57:33 -0500 as excerpted:
> Yep, I know where you're coming from there. Iptables isn't all that
> hard to understand, and I've become pretty conversant with it in the
> process of using for my own and others' systems. I'd always rather dea=
l
> with the "under the hood" CLI tools than with some GUI tool that does
> little more than obfuscate the real issue. That way lies Windows!
Indeed, the MSWindows way is the GUI way. But I wasn't even thinking=20
about that. I was thinking about the so-called "easier" firewalling CLI/
text-editing tools that have you initially answer a number of questions t=
o=20
setup the basics, then have you edit files to do any "advanced" tweaking=20
the questions didn't have the foresight to cover.
But my (first) problem was that while I could answer the questions easy=20
enough, I lacked sufficient understanding of the real implementation to=20
properly do the advanced editing. And if I were to properly dig into=20
that, I might as well have mastered the IPTables/Netfilter stuff on which=
=20
it was ultimately based in the first place.
The other problem, when building your own kernel, was that the so-called=20
simpler tools apparently expect all the necessary Netfilter/IPTable kerne=
l=20
options to be available as pre-built modules (or built-in) -- IOW, they'r=
e=20
designed for the binary distributions where that's the case. Neither the=
=20
questions nor the underlying config file comments mentioned their kernel=20
module dependencies. One either had to pre-build them all and hope they=20
either got auto-loaded as needed, or delve into the scripts to figure out=
=20
the dependencies and build/load the required modules.
Now keep in mind that I first tried this on Mandrake, where I was buildin=
g=20
my own kernel within 90 days of first undertaking the switch, while I was=
=20
still booting to MS to do mail and news in MSOE, because I hadn't yet had=
=20
time to look at user level apps well enough to make my choices and set=20
them up. So it's certainly NOT just a Gentoo thing. It's a build-your-
own-kernel thing, regardless of the distro.
The problem ultimately boiled down to having to understand IPTables itsel=
f=20
well enough to know what kernel options to enable, either built-in or as=20
modules which would then need to be loaded. But if I were to do that, wh=
y=20
would I need the so-called "easier" tool, that only complicated things. =20
Honestly, the tools made me feel like I was trying to remote-operate some=
=20
NASA probe from half-way-across-the-solar-system, latency and all, instea=
d=20
of using the direct-drive, since what I was operating on was actually=20
right there next to me!
At that time I simply punted. I had (or could have and did have, by=20
(wise) choice on MS) a NAPT based router between me and the net anyway,=20
and already knew how to configure /it/. So I just kept it and ran the=20
computer itself without a firewall for a number of years. Several years=20
later, after switching to Gentoo, when I was quite comfortable on Linux i=
n=20
general, I /did/ actually learn netfilter/iptables, configure my computer=
=20
firewall accordingly, and direct-connect for a year or two -- until my=20
local config changed and I actually had the need for a NAPT device as I=20
had multiple local devices to connect to the net.
Which brings up a nice point about Gentoo. With Mandrake (and most other=
=20
distributions of the era, from what I read), there were enough ports open=
=20
by default that having a firewall of /some/ sort, either on-lan NAPT=20
device or well configured on-computer IPChains/IPTables based, was wise. =
=20
IOW, keeping that NAPT device was a good choice, even if it /was/ an MS-
based view of things, because the Linux distros of the time still ran wit=
h=20
various open ports (whether they still do or not I don't know, I suspect=20
most do, tho they probably do it with an IPTables firewall up now too).
Gentoo's policy by contrast has always (well, since before early 2004,=20
when I switched to it) been:
1) Just because it's installed does NOT mean it should have its initscrip=
t=20
activated so it runs automatically in the default runlevel -- Gentoo ship=
s=20
by default with the initscripts for net-active services in /etc/init.d,=20
but does NOT automatically add them to the default runlevel.
2) Even when a net-active service IS activated, Gentoo's default=20
configuration normally has it active on the loopback localhost address=20
only.
3) Gentoo ships X itself with IP-forwarding disabled, only the local Unix=
=20
domain socket active.
As such, by the time I actually got around to learning IPTables/netfilter=
=20
and setting it up on my Gentoo box, it really wasn't as necessary as it=20
would be on other distributions, anyway, because firewall or no firewall,=
=20
the only open ports were ports I had deliberately opened myself and thus=20
already knew about.
But of course defense in depth is a VERY important security principle,=20
correlating as it does with the parallel "never trust yourself not to fat=
-
finger SOMETHING!" (Now, if the so-called security services HBGary, et.=20
al., only practiced it! ... I think that's what galled most of the world=
=20
most, not that they screwed up a couple things so badly, but that they so=
=20
blatantly violated the basic defense-in-depth, or we'd have never read=20
about the screw-ups in the first place as they'd have not amounted to=20
anything if the proper layers of defense had been there... and for a=20
SECURITY firm, no less, to so utterly and completely miss it!) So=20
regardless of the fact that in theory I didn't actually need the firewall=
=20
by then since the only open ports were the ones I intended to be open, I=20
wasn't going to run direct-connected without /some/ sort of firewall, and=
=20
I learned and activated IPTables/netfilter before I did direct-connect. =20
And now that I have NAPT again, I still keep it running, as that's simply=
=20
another layer of that defense in depth, and I can use the NAPT router for=
=20
multiplexing several devices on a single IP, not its originally accidenta=
l=20
side-effect of inbound firewalling, tho again, I keep that too as it's=20
another layer of that defense in depth, I just don't /count/ on it.
>> Bottom line, yeah I believe ext4 is safe, but ext3 or ext4, unless you
>> really do /not/ care about your data integrity or are going to the
>> extreme and already have data=3Djournal, DEFINITELY specify data=3Dord=
ered,
>> both in your mount options, and by setting the defaults via tune2fs.
>=20
> So does this turn off journaling? What's a good reference on the
> advantages of ext4 over ext3, or can you just summarize them for me?
No, this doesn't turn off journaling.
Briefly...
There's the actual data, the stuff in the files we care about, and=20
metadata, the stuff the filesystem tracks behind the scenes so we don't=20
have to worry about it. Metadata includes stuff like the filename, the=20
dates (create/modify/access, the latter of which isn't used that much any=
=20
more and is often disabled), permissions (both traditional *ix set*/user/
group/world and if active SELinux perms, etc), INODE AND DIRECTORY TABLES=
=20
(most important in this context, thus the CAPS, as without them, your dat=
a=20
is effectively reduced to semi-random binary sequences), etc.
It's the metadata, in particular, the inode and directory tables, that fs=
ck=20
concerns itself with, that's potentially damaged in the event of a chaoti=
c=20
shutdown, that fsck checks and tries to restore on remount after such a=20
shutdown, etc.
Because the original purpose of journaling was to shortcut the long fscks=
=20
after a chaotic shutdown, traditionally it concerns itself only with=20
metadata. In practice, however, due to reordered disk operations at both=
=20
the OS and disk hardware/firmware level, the result of a recovery with=20
strict meta-data-only journaling on a filesystem can be perfectly restore=
d=20
filesystem metadata, but with incorrect real DATA in those files, because=
=20
the metadata was already written to disk but the data itself hadn't been,=
=20
at the time of the chaotic shutdown.
Due to important security implications (it's possible that the previous=20
contents of that inode was an unlinked but not secure-erased file=20
belonging to another user, UNAUTHORIZED DATA LEAK!!!), such restored=20
metadata-only files where the data itself is questionable, are normally=20
truncated to zero-length, thus the post-restore zero-length "empty" file=20
phenomenon common with early journaled filesystems and still occasionally=
=20
seen today.
The data=3D journaling option controls data/metadata handling.
data=3Dwriteback is "bare" metadata journaling. It's the fastest but=20
riskiest in terms of real data integrity for the reasons explained above.=
=20
As such, it's often used where performance matters more than strict data=20
integrity in the event of chaotic shutdown -- where data is backed up and=
=20
changes since the backup tend to be trivial and/or easy to recover, where=
=20
the data's easily redownloaded from the net (think the gentoo packages=20
tree, source tarballs, etc), and/or where the filesystem is wiped at boot=
=20
anyway (as /tmp is in many installations/). Zeroed out files on recovery=
=20
can and do happen in writeback mode.
data=3Dordered is the middle ground, "good enough" for most people, both =
in=20
performance and in data integrity. The system ensures that the commit of=
=20
the real data itself is "ordered" before the metadata that indexes it,=20
telling the filesystem where it's located. This comes at a slight=20
performance cost as some write-order-optimization must be skipped, but it=
=20
GREATLY enhances the integrity of the data in the event of a chaotic=20
shutdown and subsequent recovery. There are corner-cases where it's stil=
l=20
possible at least in theory to get the wrong behavior, but in practice,=20
these don't happen very often, and when they do, the loss tends to be tha=
t=20
of reverting to the pre-update version of the file, losing only the=20
current edit, rather than zeroing out of the file (or worse yet, data=20
leakage) entirely.
data=3Djournal is the paranoid option. With this you'll want a much larg=
er=20
journal, because not only the metadata, but the data itself, is=20
journaled. (And here most people thought that's what journaling did /all=
/=20
the time!) Because ALL data is ultimately written TWICE in this mode,=20
first to the journal and then from there to its ultimate location, by=20
definition it's a factor of two slower, but provided the hardware is=20
working correctly, the worst-case in a chaotic shutdown is loss of the=20
current edit, reverting to the previous edition of the file.
FWIW and rather ironically, my original understanding of all this came=20
from a series of IBM DeveloperWorks articles written in the early kernel=20
2.4 series era, explaining the main filesystem choices, many of them then=
=20
new, available in kernel 2.4. While the performance data and some=20
filesystem implementation detail (plus lack of mention of ext4 and btrfs=20
as this was before their time) is now somewhat dated, the theory and=20
general filesystem descriptions remain solid, and as such, the series=20
remains a reasonably good intro to Linux filesystems to this day. As=20
such, parts of it are still available as linked from the Gentoo=20
Documentation archived copy of those IBM DeveloperWorks articles. In=20
particular, two parts covering ext3 and the data=3D options remain availa=
ble:
http://www.gentoo.org/doc/en/articles/afig-ct-ext3-intro.xml
http://www.gentoo.org/doc/en/articles/l-afig-p8.xml
The ironic bit is who the author was, one Daniel Robbins, the same DRobbi=
ns=20
who founded the then Enoch Linux, now Gentoo. But I read them long befor=
e=20
I ever considered Gentoo, when I was first switching to Linux and using=20
Mandrake. It was thus with quite some amazement a number of years later,=
=20
after I'd been on Gentoo for awhile, that I discovered that the *SAME*=20
DRobbins who founded Gentoo (and was still active tho on his way out in=20
early 2004 when I started on Gentoo), was the guy who wrote the Advanced=20
Filesystem Implementor's Guide in IBM DeveloperWorks, the guide I'd found=
=20
so *INCREDIBLY* helpful years before, when I hadn't a /clue/ who he was o=
r=20
what distribution I'd chose years later, as I just starting with Mandrake=
=20
and trying to figure out what filesystems to choose.
As to the ext3/ext4 differences... AFAIK the (second) biggest one is that=
=20
ext4 uses extents by default, thus fragmenting files somewhat less over=20
time. (Extents are a subject worth their own post, which I won't attempt=
=20
as while I understand the basics I don't understand all the implications=20
thereof myself. But one effect is better efficiency in filesystem layout=
,=20
when the filesystem was created with them anyway... it won't help old=20
files on upgraded-to-ext4-from ext2/3 that much. Google's available for=20
more. =3D:^)
There's a lot of smaller improvements as well. ext4 is native large-
filesystem by default. A number of optimizations discovered since ext3=20
are implemented in ext4 that can't be in ext3 for stability and/or old-
kernel backward compatibility reasons. ext4 has a no-journal option=20
that's far better on flash-based thumb-drives, etc. There are a number o=
f=20
options that can make it better on SSDs and flash in general than ext3.
And the biggest advantage is that ext4 is actively supported in the kerne=
l=20
and supports ext2/3 as well, while ext2/3, as separate buildable kernel=20
options, are definitely considered legacy, with talk, as I believe I=20
mentioned, of removing them as separate implementations entirely, relying=
=20
on ext4's backward compatibility for ext2/3 support. In that regard, ext=
3=20
as a separate option is in worse shape than reiserfs, since it's clearly=20
legacy and targeted for removal. As part of ext4, support will=20
*DEFINITELY* continue for YEARS, more likely DECADES, so is in no danger=20
in that regard (more so than reiserfs support, which will continue to be=20
supported as well for at least years), but the focus is definitely on ext=
4=20
now, and as ext3 becomes more and more legacy, the chances of corner-case=
=20
bugs appearing in ext3-only code in the ext4 driver do logically=20
increase. In that regard, reiserfs could actually be argued to be in=20
better shape, since it's not implemented as a now out-of-focus older-
brother to a current filesystem, so while it has less focus in general, i=
t=20
also has less chances of being accidentally affected by a change to the=20
current-focus code.
Which can be argued to have already happened with the default ext3=20
switching to data=3Dwriteback for a number of kernels, before being switc=
hed=20
back to the data=3Dordered it always had before. A number of kernels ago=
=20
(2.6.29 IIRC), ext4 was either officially just out of or being discussed=20
for bringing out of experimental. I believe it was Ubuntu that first mad=
e=20
it a rootfs system install option, in that same time period. Shortly=20
thereafter, a whole slew of Ubuntu on ext4 users, most of whom it turned=20
out later were using the closed nVidia driver, which was unstable in that=
=20
version against that Ubuntu version and kernel, thus provoking many cases=
=20
of "chaotic shutdown", a classic worst-case trial-by-fire test for the=20
then still coming out of experimental ext4, began experiencing the classi=
c=20
"zeroed out file" problems on reboot after their chaotic shutdowns.
*Greatly* compounding the problem were some seriously ill-advised Gnome=20
config-file behaviors. Apparently, they were opening config-files for=20
read-write simply to READ them and get the config in the process of=20
initializing GNOME. Of course, the unstable nVidia driver was=20
initializing in parallel to all this, with the predictable-in-hindsight=20
results... As gnome was only READING the config values, it SHOULD have=20
opened those files READ-ONLY, if necessary later opening them read-write=20
to write new values to them. As with the security defense-in-depth=20
mentioned in the HBGary parenthetical above, this is pretty basic=20
filesystem principles, but the gnome folks had it wrong. The were openin=
g=20
the files read/write when they only needed read, and the system was=20
crashing with them in that state. As a result, these files were open for=
=20
writing in the crash, and as is standard security practice as explained=20
above, the ext4 journaling system, defaulting to write-back mode, restore=
d=20
them as zeroed out files to prevent any possibility of data leak. =20
Actually, there were a few other technicalities involved as well (file=20
renaming on write, failure to call fsync, due in part to ext3's historic=20
bad behavior on fsync, which it treated as whole-filesystem-sync, etc),=20
but that's the gist of things.
So due to ext4's data=3Dwriteback and the immaturity of the filesystem su=
ch=20
that it didn't take additional precautions, these folks were getting=20
critical parts of their gnome config zeroed out every time they crashed,=20
and due to the unstable nVidia drivers, they were crashing frequently!!
*NOT* a good situation, and that's a classic understatement!!
The resulting investigation discovered not only the obvious gnome problem=
,=20
but several code tweaks that could be done to ext4 to reduce the=20
likelihood of this sort of situation in the future.
All fine and good, so far. But they quickly realized that the same sort=20
of code tweak issues existed with ext3, except that because ext3 defaulte=
d=20
to data=3Dordered, only those specifically setting data=3Dwriteback were=20
having problems, and because those using data=3Dwriteback were expected t=
o=20
have /some/ problems anyway, the issues had been attributed to that and=20
thus hadn't been fully investigated and fixed, all these years.
So they fixed the problems in ext3 as well. Again, all fine and good --=20
the problems NEEDED fixed. *BUT*, and here's where the controversy comes=
=20
in, they decided that data=3Dwriteback was now dependable enough for BOTH=
=20
ext3 and ext4, thus changing the default for ext3.
To say that was hugely controversial is an understatement (multiple=20
threads on LKML, LWN, elsewhere where the issue was covered at the time,=20
often several hundreds of posts long each), and my feelings on=20
data=3Dwriteback should be transparent by now so where I stand on the iss=
ue=20
should be equally transparent, but Linus never-the-less merged the commit=
=20
that switched ext3 to data=3Dwriteback by default, AFAIK in 2.6.31. (AFA=
IK,=20
they discovered the problem in 2.6.29, 2.6.30 contained temporary work-
around-fixes, 2.6.31 contained the permanent fixes and switched ext3 to=20
data=3Dwriteback.)
Here's the critical point. Because reiserfs isn't so closely related to=20
the ext* family, it retained the data=3Dordered default it had gotten yea=
rs=20
early, the same kernel Chris Mason committed the code for reiserfs to do=20
data=3Dordered at all. ext3 got the change due to its relationship with=20
ext4, despite the fact that it's officially an old and stable filesystem=20
where arguably such major policy changes should not occur. If the sepera=
te=20
kernel option for ext3 is removed in ordered to remove the duplicate=20
functionality already included in ext4 for backward compatibility reasons=
,=20
by definition, this sort of change to ext4 *WILL* change the ext3 it also=
=20
supports, unless deliberate action is taken to avoid it. That makes such=
=20
issues far more likely to occur again in ext3, than in the relatively=20
obscure ext4.
Meanwhile, as mentioned, with newer kernels (2.6.36, 37, or 38, IDR which=
,=20
tho it won't matter for those specifying the data=3Doption either via=20
filesystem defaults using tune2fs, or via specific mount option), ext3=20
reverted again to the older and safer default, data=3Dordered.
And as I said, it's my firm opinion that the data=3D option has a stronge=
r=20
effect on filesystem stability than any possibly remaining issues with=20
ext4, which is really quite stable by now. Thus, ext3, ext4, or reiserfs=
,=20
I'd **STRONGLY** recommend data=3Dordered, regardless of whether it's the=
=20
default as it is with old and new (but with a gap) ext3 and reiserfs as i=
t=20
has been for years, or not, as I believe ext4 still defaults to=20
data=3Dwriteback. If you value your data, "just do it!"
Meanwhile, I believe the default on the definitely still experimental=20
btrfs is data=3Dwriteback too. While I plan on switching to it eventuall=
y,=20
you can be quite sure I'll be examining that default and as of this point=
,=20
have no intentions of letting it be data=3Dwriteback, when I do.
....
> The problem with Gentoo was that because EVMS was an orphaned project, =
I
> believe the ebuild wasn't updated. The initrd file was specific for
> EVMS.
That's quite likely, indeed.
> Of course. I like technology that _lasts_! We have a clock in our
> house that's about 190 years old [...] turned me on to the Connecticut
> Clock and Watch museum, run by one George Bruno [who] also makes workin=
g
> replicas [and] was able to send me an exact replacement part! Try
> _THAT_ with your 1990's era computer ;-)
That reminds me... I skipped it as irrelevant to the topic at hand, but=20
due to kernel sensors and ACPI changes, I decided to try the last BIOS=20
upgrade available for this Tyan, after having run an earlier BIOS for som=
e=20
years. Along about 2.6.27, I had to start using a special boot parameter=
=20
to keep the sensors working, as apparently the sensor address regions=20
overlap ACPI address regions (not an uncommon issue in boards of that era=
,=20
the kernel folks say). The comments on the kernel bug I filed suggested=20
that a BIOS update might straighten that out (it didn't, BIOS still too=20
old and board EOLed, even if it is still working), so I decided to try it=
.
The problem was that I had a bad memory stick. Now the kernel has=20
detectors for that and I had them active, but the kernel drivers for that=
=20
were introduced long after I got the hardware, and while it was logging a=
n=20
issue with the memory, since it had been doing that since I activated the=
=20
kernel drivers for it, I misinterpreted that as simply how it worked, so=20
wasn't aware of the bad memory it was trying to tell me about.
So I booted to the FreeDOS floppy I used for BIOS upgrades (I've used=20
FreeDOS for BIOS upgrades for years, without incident before this) and=20
began the process.
It crashed half-way thru the flash-burn, apparently when it hit that bad=20
memory!!
Bad situation, but there's supposed to be a failsafe direct-read-recover=20
mode built-in, that probably would have worked had I known about it. =20
Unfortunately I didn't, and by the time I figured it out, I'd screwed tha=
t=20
up as well.
But luckily I have a netbook, that I had intended to put Gentoo on but ha=
d=20
never gotten around to at that point (tho it's running Gentoo now, 2.6.38=
=20
kernel, kde 4.6.1, fully updated as of mid-March). It was still running=20
the Linpus Linux it shipped with (first full system I've bought since my=20
original 486SX25 w/ 2MB memory and 130 MB hard drive in 1993, or so, and=20
I'd have sooner done without the netbook than pay the MS tax, I DID have=20
to order it from Canada and have it shipped to the US). I was able to ge=
t=20
online with that, grab a yahoo webmail account since my mail logins were=20
stuck on the main system without a BIOS, and use that to order a new BIOS=
=20
chip shipped to me, the target BIOS pre-installed.
That new BIOS chip rescued my system!
I suspect my feelings after that BIOS chip did the trick rather mirror=20
yours after that gear did the trick for your clock. The computer might=20
not be 190 years old, but 2003 is old enough in computer years, and I=20
suspect I have rather more of my life wound up in that computer than you=20
do in that clock, 190 years old or not.
Regardless, tho, you'll surely agree,
WHAT A RELIEF TO SEE IT RUNNING AGAIN! =3D:^)
--=20
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