Re: ext3 corruption
From: Helge Hafting
Date: Thu Aug 10 2006 - 08:19:53 EST
Molle Bestefich wrote:
Have you considered debian then? That package system certainly
As far as I remember, I configured it to automatically update everything.
Apparently that function just broke itself very early on :-).
I guess the problem is that I don't know a single Linux packaging system
that actually works well enough to keep a system up to date at all times,
and I don't have any free time to spend on reinstalling systems all the
have been able to keep many a system running for years and years.
You never reinstall, just upgrade.
Sure, you have to trust someone. If you can't trust any distro and its
I think most of the package managers break because their dependency
sucks. Some of them doesn't suck, but they break because there's no
integrity checks, and package maintainers can dump any kind of bizarre
corrupt dependencies they like into them. That's how Gentoo works, for
maintainers, your only choice is to roll your own.
example. Others have even more bizarre ways of breaking, again Gentoo asWell, if you expect to keep a computer running for three years
an example requires the user to run a "switch to newer GCC" command from
time to time, otherwise random packages just start breaking.
AFAIK, every single Linux package manager on the planet is half-ass,
like above or in some other way. If you know of one that's actually well
thought through on all planes and well implemented and thus works good
to keep a system up to date for three years in a row without human
Please speak up!!!
without human intervention - good luck to you! Not only will there be
new vulnerabilities and attacks via the internet in that time, there is also
a substantial risk of hardware breakdown. Disks in particular seems not
to live much more than three years, and if you have several, the chance
is bigger that one goes. Raid protects the data, but surely you will
to replace the failed drive? Or do you install six hot spares so the
system really can keep running alone?
It is certainly possible to run debian and spend 5min per week
on running "apt-get dist-upgrade" which installs anything that
was upgraded since the last time. And if you have many identical
servers, then you know that when one upgrade went without
problems the others will too.
Such coordination can certainly be done - there is just no
> (Maybe the kernel SHOULD coordinate it somehow,
> seems like some of the distros are doing a pretty bad job as is.)
That's pretty much impossible, the best the kernel can do is send
signals to all of the running processes.
Impossible? Few things in the software world are impossible.
Surely it's possible to create a kernel interface where processes
can tell the kernel about which other processes they'd like to
outlive and which ones they'd like to get killed before.
The kernel could then coordinate the killing of processes in a
"shutdown" function, which the various distro's 'reboot' and
'shutdown' scripts could call.
reason at all to do it in the _kernel_. This is the job of the
program called "init". (The kernel is a very important piece of
a linux system, but don't make the mistake of believing
it therefore should be the "general manager" for all things less
Init is the first program that runs,
it is started up by the kernel. Init will then start all other
software you need, such as samba, any other server software,
and of course the login services. When you shut the pc down,
init is the program responsible for stopping everything in
a sane order.
Init is customizable, by editing and/or renaming the so-called
initscripts. That way, you can alter the order of startup and
shutdown of software, if your distribution didn't get this right.
This isn't all that hard, and a linux system administrator is
supposed to be able to make simple adjustments in this area.
Many linux/unix books documents how initscripts work, and there
is usually plenty of online documentation as well.
And voila, that difficult task of assessing in which order to doNot so easy. You do not want to shut down md devices because
things is out of the hands of distros like Red Hat, and into the
hands of those people who actually make the binaries.
samba is using them. Someone else may run samba on a single
harddisk and also have some md-devices that they take down
and bring up a lot. So having samba generally depend on md doesn't
work. Your setup need it, others may have different needs.
That's why the initscripts are _scripts_, simple textfiles that
administrators can manipulate without having to know C programming.
Learn to manipulate the initscripts then. Changing the
Which is probably a good thing, because
a) Red Hat's init scripts probably fails for me because there's
something in my setup that Red Hat didn't expect. A greatly
simplified system as outlined above would help to fix things
shutdown order really is as simple as renaming samba's
script file so it occur earlier in the shutdown order than
the script responsible for taking down the md devices.
You don't even need to understand shellscript programming to
It is open source, they can copy each others's scripts to save
b) Less duplicated effort in the form of init script coding for
the distro maintainers.
effort. They often do - and sometimes the initscript for a
particular piece of sw is written by the maker of that sw too.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/