boot problem

am 02.05.2005 14:07:17 von Andrew

I have just used the Slackware 'swaret' tool to upgrade from Slackware
10.0 to 10.1. The result is my system no longer boots properly. Most
attempts to reboot get as far as 'Freeing unused kernel memory: 120k
freed', followed by a 'sh-3.00#' prompt, though on one attempt I got
something like 'kernel panic. attempted to kill init' (I haven't been
able to reproduce this). Where do I begin to sort this mess out?

TIA,

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: boot problem

am 02.05.2005 15:41:51 von chuck gelm net

Re: boot problem

am 02.05.2005 17:16:11 von Ray Olszewski

Andrew wrote:
> I have just used the Slackware 'swaret' tool to upgrade from Slackware
> 10.0 to 10.1. The result is my system no longer boots properly. Most
> attempts to reboot get as far as 'Freeing unused kernel memory: 120k
> freed', followed by a 'sh-3.00#' prompt, though on one attempt I got
> something like 'kernel panic. attempted to kill init' (I haven't been
> able to reproduce this). Where do I begin to sort this mess out?

It's difficult to say what your problem is from this sketchy a
description, but the likely place to start tracking it down is by
looking at your logs. The 'sh-3.00#' prompt at least means the system is
throwing you into a shell as root ... probably in single-user mode ...
so you should be able to read the logs.

But first take a look at whether /etc/inittab was changed by the
upgrade. Dropping into single-user mode usually means a problem with
init, not the kernel itself ... especially if the kernel makes it to the
"freeing memory" step ... and this is the file the controls the
operation of the init program.

Then see what init scripts were modified by the upgrade. (I forget where
Slackware puts them, but look for a line in /etc/inittab similar to
this: "si::sysinit:/etc/init.d/rcS". Unless it has changed recently,
Slackware uses an old style of init-script organization that can easily
get errors incorporated into it through an automated upgrade, and that
*may* be all you are seeing. Make sure that whatever top-level init
scripts inittab points to ... in the line like the one above and in a
series of (probably) six that resemble "l2:2:wait:/etc/init.d/rc 2" ...
are present on the system and executable.

Next thing is to look at your logs ... and at the output of "dmesg", if
Slackware down't dump that to a logfile during boot/init (some distros
do, but I don't know about Slack). It is likely, though not certain,
that either the kernel itself, or init by way of syslogd, will be
logging a better description of the problem than what is going to the
screen.

Check your filesystems to make sure that they are a trpe that your
kernel can mount. This is unlikely to be a problem, but just might be,
for example if you're using ext3 but the kernel supports only ext2. See
what "df" reports, and see if the entries in /etc/fstab are reasonable
when compared with df's output.

The suggestion Chuck made, to install a different kernel, is likely his
response to the kernel panic message you say you got on one occasion,
and it may do the job for you, or it may be like using a cannonball to
sway a fly. Definitely give it a try; there are a lot of things this
"mess" *might* be that a kernel change will fix.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: boot problem

am 02.05.2005 17:21:28 von Andrew

joy merwin monteiro wrote:

>Hi,
>
>Somewhere, your kernel parameters have been messed up.....
>it is using bash as init. at the lilo prmpt,
>
>init=/sbin/init
>
> as a parameter
>should do the trick, though it should have been the other way round,
>when you want to bypass the passwd, you do
>
>init=/bin/bash
>
>see if anything is added to lilo.conf..... can't think of any other place
>unless init has been replaced by bash :-(
>
>Joy
>
>
It didn't work, but it seems to be on the right track as in fact
/sbin/init doesn't exist.
Any idea how it can be created? Or why it wasn't?

TIA,

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: boot problem

am 02.05.2005 17:26:17 von Andrew

Ray Olszewski wrote:

> It's difficult to say what your problem is from this sketchy a
> description, but the likely place to start tracking it down is by
> looking at your logs. The 'sh-3.00#' prompt at least means the system
> is throwing you into a shell as root ... probably in single-user mode
> ... so you should be able to read the logs.
>
> But first take a look at whether /etc/inittab was changed by the
> upgrade. Dropping into single-user mode usually means a problem with
> init, not the kernel itself ... especially if the kernel makes it to
> the "freeing memory" step ... and this is the file the controls the
> operation of the init program.
>
> Then see what init scripts were modified by the upgrade. (I forget
> where Slackware puts them, but look for a line in /etc/inittab similar
> to this: "si::sysinit:/etc/init.d/rcS". Unless it has changed
> recently, Slackware uses an old style of init-script organization that
> can easily get errors incorporated into it through an automated
> upgrade, and that *may* be all you are seeing. Make sure that whatever
> top-level init scripts inittab points to ... in the line like the one
> above and in a series of (probably) six that resemble
> "l2:2:wait:/etc/init.d/rc 2" ... are present on the system and
> executable.
>
> Next thing is to look at your logs ... and at the output of "dmesg",
> if Slackware down't dump that to a logfile during boot/init (some
> distros do, but I don't know about Slack). It is likely, though not
> certain, that either the kernel itself, or init by way of syslogd,
> will be logging a better description of the problem than what is going
> to the screen.
>
> Check your filesystems to make sure that they are a trpe that your
> kernel can mount. This is unlikely to be a problem, but just might be,
> for example if you're using ext3 but the kernel supports only ext2.
> See what "df" reports, and see if the entries in /etc/fstab are
> reasonable when compared with df's output.
>
> The suggestion Chuck made, to install a different kernel, is likely
> his response to the kernel panic message you say you got on one
> occasion, and it may do the job for you, or it may be like using a
> cannonball to sway a fly. Definitely give it a try; there are a lot of
> things this "mess" *might* be that a kernel change will fix.
>
I shall do as you describe. Meanwhile, please note my reply tp Joy's
suggestion: /sbin/init does not exist. Also, the kernel change made no
difference.

Thanks,

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: boot problem

am 02.05.2005 18:08:42 von Ray Olszewski

Andrew wrote:
> Ray Olszewski wrote:
>
>> It's difficult to say what your problem is from this sketchy a
>> description, but the likely place to start tracking it down is by
>> looking at your logs.
[...]
> I shall do as you describe. Meanwhile, please note my reply tp Joy's
> suggestion: /sbin/init does not exist. Also, the kernel change made no
> difference.

Don't bother with any of what I suggested until you deal with "the case
of the missing init". That is your proximate problem .. though a problem
that basic is a warning that something really major may have gone wrong
in your upgrade.

init is the basic, core application that keeps everything running in
userspace; after the kernel itself, it's the most essential thing a
system runs. It's a program, and you can't "create" it the way you would
a script; you need to (re-)install it from your Slackware install CD or
floppy. (In Debian, init is in the package "sysvinit"; some Slacker will
need to tell you the name of the corresponding Slackware package.)

First, though, please double-check the "does not exist" part. How did
you check this? There are several ways, but any other then "ls -l
/sbin/init*", done as root, might provide a false negative. And as part
of the check, make sure the root filesystem that's being mounted is the
drive and partition you expect it to be ("df" will check this for you)
and that no other partition is being mounted on /sbin ("df" will tell
you that too).

ALso ... this is a real long shot ... take a moment to make sure init
isn't just in the wrong place. "find / -name init" (run as root) is the
most reliable way to turn up a copy of init that was installed in an
unusual location.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: boot problem

am 02.05.2005 18:10:08 von Andrew

OK. This is practically solved. Thank-you all. The sysvinit package had
not been installed. I've done that now and the system is booting
alright, but a few other things have been messed up as well (the X
config, for one).

So beware, users of swaret. Nothing is perfect.

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs