Strange problem
t...@unslept.com
upgraded to unstable in the last few days. The machine was rebooted today,
and came up in a very strange state. No users could log in, only root, and
things like ps, w, and top wouldn't work. I was called, got in via ssh,
and finally had enough sense to run 'mount'. It looks like /proc and /
were exactly the same, which is impossible. I unmounted and remounted
/proc by hand, started up the utils that didn't start, checked things out
the best I could, and rebooted again. Same thing. I've gone through
everything I can think of remotely. I can't figure this one out. Has anyone
else ever seen something like this?
Tim
--
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> Tim Sailer (at home) >< Coastal Internet,Inc. <<
>> Network and Systems Operations >< PO Box 671 <<
>> http://www.buoy.com >< Ridge, NY 11961 <<
>> t...@unslept.com/t...@buoy.com >< (631)924-3728 (888) 924-3728 <<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--
To UNSUBSCRIBE, email to debian-is...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jeremy C. Reed
> OK, folks. I have a stumper here. An associate has a machine that was
> upgraded to unstable in the last few days. The machine was rebooted today,
In my experience, unstable is "unstable".
> and came up in a very strange state. No users could log in, only root, and
> things like ps, w, and top wouldn't work. I was called, got in via ssh,
Why happens when you runs these commands? (What does "wouldn't
work" mean?)
What do the logs say?
> and finally had enough sense to run 'mount'. It looks like /proc and /
> were exactly the same, which is impossible. I unmounted and remounted
What do you mean that it is impossible to be the same? (Are you saying
that proc was also mounted at / ?)
> /proc by hand, started up the utils that didn't start, checked things out
> the best I could, and rebooted again. Same thing. I've gone through
What do the kernel messages say?
What do the logs say?
What are these utils that didn't start? (Some network services that need
to be correctly setup in /etc/rc*.d/ ?)
> everything I can think of remotely. I can't figure this one out. Has anyone
> else ever seen something like this?
Sometimes when I upgrade from stable to unstable, I have had some packages
not reinstalled and some software didn't start that should have.
Jeremy C. Reed
echo '9,J8HD,fDGG8B@?:536FC5=8@I;C5?@H5B0D@5GBIELD54DL>@8L?:5GDEJ8LDG1' |\
sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP'
Jason Lim
> On Fri, 2002-02-01 at 01:42, Jason Lim wrote:
> > We have production boxes running unstable with no problem. Needed to
run
> > unstable because only unstable had some new software, unavailable in
> > stable. Its a pity stable gets so outdated all the time as compared to
> > other distros like Redhat and Caldera (stable still on 2.2 kernel),
but
> > thats a topic for a separate discussion.
>
> This is really a shame. It's my biggest complaint with Debian by far.
> The tools work very well, but the release cycle is such that you can't
> use a "stable" revision of the distribution and have modern packages
> available.
I agree. What I would like to know is how other Linux distros like Redhat
(only mentioning Redhat because that is what many of our cusomters
request, and nearly everyone knows it) can have pretty new "stable"
releases? No release is going to be totally bug-free, and I think just
about everyone (business and personal) know and accept this. Perhaps
people are willing to trade in a few more bugs to have a far more
up-to-date system?
I know Debian likes to have "stable" REALLY VERY stable... but perhaps it
is SO stable that is too outdated to be used in a production environment.
I mean, I think Debian is the only Linux distro still shipping with a 2.2
kernel; everyone else has gone ahead with 2.4 for quite a long time now.
I pretty much work with Linux exclusively in a business environment... so
from a business of view (and I hate to say this... but...) I like Redhat
more than Debian, in that a default install of Redhat comes with a 2.4
kernel, ext3, and lots of up-to-date tools, whereas with Debian I have to
recompile a new kernel, download the various new tools to support the new
kernel, etc... and as we all know, jumping from "stable" to "unstable" is
problem-prone and doesn't worth flawlessly every time.
> I can't imagine this issue is being ignored, but is it discussed on a
> policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE,
> -CURRENT scheme works much better than what Debian has. I've never seen
> big political arguments on this mailing list, but I always hear that
> Debian as an organization is often too burdened with internal bickering
> and politics to move forward with big changes. Is that the case here?
>
> Just curious, not trying to start a flame war.
>
I also do not believe in "flame wars", which are not at all constructive.
I'd be very willing to engage in some constructive discussion with anyone,
with ideas that are "doable" rather than "ideals". I think Debian MAY be
too weighed down in ideals, rather than focusing on getting a good
opensource linux distro "out there". Of course, there are probably many
factors affecting Debian and making it slow to move, but surely something
can be done to improve the situation?
I know that as a company, we could donate a bit of money (with the economy
as it is, not much though), but from what I can see, money isn't really
where the problem lies... it is somewhere else.
I don't know what I can personally do to help policy changes or anything
like that, but I'd be willing to give my perspective and ideas on the
matter, if that helps at all. Perhaps other business users out there would
also like to give Debian a bit more input, so Debian becomes a viable
business distro that isn't so out-of-date?
Lang Hurst
*********** REPLY SEPARATOR ***********
On 2/1/02 at 4:25 PM Tim Quinlan wrote:
>> kernel, etc... and as we all know, jumping from "stable" to "unstable"
>is
>> problem-prone and doesn't worth flawlessly every time.
>
>Why jump all the way to unstable, why not use testing? Testing is
>usually stable enough for most applications plus the various software
>packages are pretty up to date.
>
>
In my experience unstable is pretty damn stable as well. I upgraded a couple of boxen from stable to unstable a little over a year ago and haven't been bit by any of the big bugs. I just check the mailing lists and debian planet to see if anything big has popped up before doing an apt-get update && apt-get upgrade. Obviously these aren't servers.
I think the only problem with debian is the naming. Changing nothing but the name from "unstable" to "cutting edge" or something and there wouldn't be close to the outcry about how 'behind' debian is. IMHO.
>--
>To UNSUBSCRIBE, email to debian-is...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
--
Lang
Is uniformity attainable? Millions of innocent men, women, and
children, since the introduction of Christianity, have been burnt,
tortured, fined, imprisoned; yet we have not advanced one inch towards
uniformity. What has been the effect of coercion? To make one half
of the world fools, and the other half hypocrites.
-- Thomas Jefferson
Jason Lim
>
> > kernel, etc... and as we all know, jumping from "stable" to "unstable"
is
> > problem-prone and doesn't worth flawlessly every time.
>
> Why jump all the way to unstable, why not use testing? Testing is
> usually stable enough for most applications plus the various software
> packages are pretty up to date.
>
I remember reading somewhere that security updates go to unstable first,
then into "security", then testing... meaning that testing was the last to
get security updates. Is this wrong?
Jason Lim
>> kernel, etc... and as we all know, jumping from "stable" to "unstable"
>is
>> problem-prone and doesn't worth flawlessly every time.
>
>Why jump all the way to unstable, why not use testing? Testing is
>usually stable enough for most applications plus the various software
>packages are pretty up to date.
>
>
>In my experience unstable is pretty damn stable as well. I upgraded a
couple of boxen from stable to unstable a little over a >year ago and
haven't been bit by any of the big bugs. I just check the mailing lists
and debian planet to see if anything big >has popped up before doing an
apt-get update && apt-get upgrade. Obviously these aren't servers.
In my experience as well. As I said in a previous post, i've heard that
testing is the last to get security updates, which is not acceptable if
you're running servers.
>I think the only problem with debian is the naming. Changing nothing but
the name from "unstable" to "cutting edge" or
> something and there wouldn't be close to the outcry about how 'behind'
debian is. IMHO.
Well, there more or less needs to be more frequent "stable" releases...
something along the lines of Redhat's quick releases. Okay... Redhat
again.. i know i know... but you've got to admit they've got the release
aspect of their distro pretty good. They are business people over there,
and they know how frequent business users like to have updates, and when
critical updates should be released.
I'm just wondering if it is even POSSIBLE to follow the frequent release
schedule that Redhat follows, or if it is not possible because most/all of
the developers for Debian are volunteers and won't "work" to such a tight
schedule. If we can find and identify the problems not allowing up-to-date
releases, perhaps a solution can be found?
Lang Hurst
Options are:
1) "unstable"
pros: Very up to date,
cons: Occasion big bug that can do damage
user: Someone who knows there way around Linux pretty well and likes to say,"I use unstable 'cause I'm so cool!"
2) "testing"
pros: Pretty up to date, very stable
cons: May have the latest-greatest version of an app a week or two after your buddy using "unstable". Last to get security upgrades.
user: Someone who actually uses their computer to get work done and is less worried about being the latest greatest cool guy. Someone who laughs at their co-working trying to figure out why init keeps bombing after his last "unstable" upgrade.
3) "stable"
pros: Rock stable, quicker security updates than testing.
cons: old
user: critical server.
Most of these characterization are user standpoint. If I had a server that was super critical, I'd use stable (or *BSD). The two servers I have don't have a huge load and it's not a big deal if they go down (not to sound like a huge power user, 'cause I'm talking about a home network and a minor server at work). I have testing on them.
In short, if you're a user, it doesn't make sense to use stable. Use testing or unstable and you're system will be as "up to date", if not more, as any distro. If you're running a server, just use testing, unless security is a big issue. Then use stable. Or use testing and keep a watch on the linux security pages, and manually apply the newest patches when they come out.
IMHO, there is a level for any use inside the various debian trees. The biggest problem from a PR standpoint for debian is in the names.
Feel free to disagree with any point I made, 'cause I'm not as good as I sound.
--
Lang
Is uniformity attainable? Millions of innocent men, women, and
children, since the introduction of Christianity, have been burnt,
tortured, fined, imprisoned; yet we have not advanced one inch towards
uniformity. What has been the effect of coercion? To make one half
of the world fools, and the other half hypocrites.
-- Thomas Jefferson
--
Tim Uckun
>
>Feel free to disagree with any point I made, 'cause I'm not as good as I
>sound.
I'll throw my $.02 here.
I think there is a more fundamental problem here. That is somehow
incorporating the latest apache into stable will somehow make stable
break. What needs to get done is to build a distro which isolates
applications to a sufficient degree that they don't break each other. If
you are able to build a distro like that then all you have to worry about
is the application itself. If postgres 7.2 is deemed stable then you add it
to your stable distro. Apple has done very interesting things with their
bundle system if anyone cares to look, encap also looks pretty interesting.
Ideally a distribution should act like this.
Applications should not overly interfere with each other.
It should be possible to install multiple versions of the same application.
The distribution should be able to incorporate manually installed
applications (make install)
It should be possible to reconstruct the package database from the disk drive.
all that and apt goodness too of course.
feel free to add your own to the list.
:wq
Tim Uckun
US Investigations Services/Due Diligence
http://www.diligence.com/
Jeremy C. Reed
> On Fri, 2002-02-01 at 01:42, Jason Lim wrote:
> > We have production boxes running unstable with no problem. Needed to run
> > unstable because only unstable had some new software, unavailable in
> > stable. Its a pity stable gets so outdated all the time as compared to
> > other distros like Redhat and Caldera (stable still on 2.2 kernel), but
> > thats a topic for a separate discussion.
>
> This is really a shame. It's my biggest complaint with Debian by far.
> The tools work very well, but the release cycle is such that you can't
> use a "stable" revision of the distribution and have modern packages
> available.
Some up-to-date packages are located in the "testing" distribution.
This probably has been (and currently) discussed elsewhere. I think the
problems are that there are too many packages and too many dependencies.
Maybe a solution would be to have a fourth collection (beside stable,
testing and unstable): "mini". It would not have thousands of packages.
For example, it would only have about 150 to 300 packages. Only new
packages are added if a vote approves.
The mini collection can be done similar to the testing distribution: The
mini distribution can be automatically-generated from the unstable
distribution by a set of scripts which attempt to move over packages which
lack important bugs and don't have dependency conflicts.
Look here for ideas: http://people.debian.org/~jules/testingfaq.html
What do you think of having a mini distribution that limits the number of
packages allowed?
> I can't imagine this issue is being ignored, but is it discussed on a
> policy list, probably? It seems like FreeBSD's -RELEASE, -STABLE,
> -CURRENT scheme works much better than what Debian has. I've never seen
One difference is that FreeBSD's ports collection is different than their
base collection. The base (or main) collection has the -stable and
-current development branches. But the ports collection is only developed
in one: -current. (FreeBSD builds packages for -current and recent
releases, but they only use one, the current, ports collection. Because of
this, some consider the -current ports collection to be like "unstable".)
Jeremy C. Reed
p.s. I am writing an article about the BSD ports collections, in regards
to *stable* ports collections. If you are interested in reviewing a rough
draft, let me know off-list.
Donovan Baarda
> On 1 Feb 2002, Jeff S Wheeler wrote:
>
> > On Fri, 2002-02-01 at 01:42, Jason Lim wrote:
> > > We have production boxes running unstable with no problem. Needed to run
> > > unstable because only unstable had some new software, unavailable in
> > > stable. Its a pity stable gets so outdated all the time as compared to
> > > other distros like Redhat and Caldera (stable still on 2.2 kernel), but
> > > thats a topic for a separate discussion.
> >
> > This is really a shame. It's my biggest complaint with Debian by far.
> > The tools work very well, but the release cycle is such that you can't
> > use a "stable" revision of the distribution and have modern packages
> > available.
>
> Some up-to-date packages are located in the "testing" distribution.
>
> This probably has been (and currently) discussed elsewhere. I think the
> problems are that there are too many packages and too many dependencies.
Yep, the old exponential dependancy problem...
> Maybe a solution would be to have a fourth collection (beside stable,
> testing and unstable): "mini". It would not have thousands of packages.
> For example, it would only have about 150 to 300 packages. Only new
> packages are added if a vote approves.
This sounds a little bit like what I think is needed; Debian needs to be
partitioned into sub-distro's with their own independant release schedules.
> What do you think of having a mini distribution that limits the number of
> packages allowed?
Why not just call it "debian-core". Then you can have "debian-gnome",
"debian-kde", "debian-xfree" etc. Each of these can be implemented as
seperate distro's with their own releases, using Packages files pointing
into the pool.
This paritions the dependancies, making it all easier to manage, speeding
the release cycle and potentialy allowing people to mix-n-match stable-core
with unstable-gnome if they wish.
--
----------------------------------------------------------------------
ABO: finger a...@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Jeremy C. Reed
> > This probably has been (and currently) discussed elsewhere. I think the
> > problems are that there are too many packages and too many dependencies.
>
> Yep, the old exponential dependancy problem...
I see the "problems with unstable" page is over 500 pages (448KB) long.
> > Maybe a solution would be to have a fourth collection (beside stable,
> > testing and unstable): "mini". It would not have thousands of packages.
> > For example, it would only have about 150 to 300 packages. Only new
> > packages are added if a vote approves.
>
> This sounds a little bit like what I think is needed; Debian needs to be
> partitioned into sub-distro's with their own independant release schedules.
>
> > What do you think of having a mini distribution that limits the number of
> > packages allowed?
>
> Why not just call it "debian-core". Then you can have "debian-gnome",
> "debian-kde", "debian-xfree" etc. Each of these can be implemented as
> seperate distro's with their own releases, using Packages files pointing
> into the pool.
>
> This paritions the dependancies, making it all easier to manage, speeding
> the release cycle and potentialy allowing people to mix-n-match stable-core
> with unstable-gnome if they wish.
So do you mean that these sub-distros don't have any dependencies on any
packages within the other sub-distros?
Jeremy C. Reed
echo '9,J8HD,fDGG8B@?:536FC5=8@I;C5?@H5B0D@5GBIELD54DL>@8L?:5GDEJ8LDG1' |\
sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP'
--
Jason Lim
> >
> > This paritions the dependancies, making it all easier to manage,
speeding
> > the release cycle and potentialy allowing people to mix-n-match
stable-core
> > with unstable-gnome if they wish.
>
> So do you mean that these sub-distros don't have any dependencies on any
> packages within the other sub-distros?
I think that is what he means... that you could throw a hybrid system
together.
For example... most ISPs would probably want the most up to date apache
and proftpd (or whatever your combination is). They don't really care to
have the most up to date compilers or libraries or anything else... only
what is required to get the latest apache and proftpd.
I can see a problem in this idea though, as many packages have cross
depedancies. EG. apache needs library A version 2, while proftpd needs
library A version 3. How would that be handled? Upgrading to libarary A
version 3 might break apache...