boot problem

boot problem

[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

[chuck gelm]

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?
> 
> TIA,
> 
> Andrew

Hi, Andrew:

  I try to install a kernel from the v10.1 install disk #1.

HTH, Chuck


-
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

[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

[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

[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

[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

Re: boot problem

[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