Debian Sid startup problems

I've somehow managed to foul up my Debian system such that it won't "go graphical" and then somehow freezes up. Since I can't see any screen output, I can't tell very well what's going on. I'm sort of mystified as to how and why this happened: I recently installed some USB stuff (apt-get install usbitem), and I just can't understand how that would foul up my display. I haven't installed any X related programs lately, nor have I fiddled with any display settings. What happens is that I boot the system as normal (let lilo start the default kernel), the machine goes through its bootup routine, displaying messages and then, at the stage where I expect the XDM login window to appear, my monitor goes blank with a "no signal" message. Any keyboard input I've tried has no effect on the machine: ctrl-alt-Fx won't get me any virtual terminals, ctrl-alt-bkspc does not kill X (is it even starte
d?) and dump me at a command prompt, and ctrl-alt-del won't reboot the system. I looked at /var/log/messages after booting the system from a Knoppix disk (thank God for Klaus and co.!), and the KDE it boots into looks prfectly normal (except not as fine a resolution as I'd like). Some /var/log/messages output that looks significant is as follows:

Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps existing 0xd0000000,0x1000000
Jun 11 13:58:38 debian kernel: [drm] Initialized radeon 1.9.0 20020828 on minor 0
Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps existing 0xd0000000,0x1000000
Jun 11 13:58:38 debian kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
Jun 11 13:58:38 debian kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.

Not sure why this problem suddenly crops up, or what to do about it. I've thought of upgrading the X server as one possible solution, but don't want to just take wild stabs like that. So, I ask for input here. Does this output mean anything to anyone here? Any suggestions on what to do about it? I can provide more output from /var/log/messages if this is not the relevant part. Any help will be appreciated. For now, when I get stuck at this point in the boot process I can only power the machine off with the power switch.

Thanks, James


-
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: Debian Sid startup problems

The first thing you need to pin down is whether this is an X problem or
some sort of USB problem (possibly one involving a kernel module).

To do that, see if you can boot successfully to a command prompt. The
simplest way to do that is to use your emergency procedure to get access to
the hard disk, then rename the file /etc/rc2.d/S99xdm to something that
will not execute (I usually change it to No99xdm). Then see if the system
will boot/init successfully.

If it does, then your problem is with X, and we need to explore that more
closely.

If not, then your problem is probably with the recent changes you made, and
we need to examine them more closely.

(Another option is to see if you can telnet or ssh to the system after it
boots/inits but apparently "hangs". This could work if the problem is just
an unusually nasty console error, but not if it is a kernel problem. Also,
I don't know if your system is on a LAN and runs the needed daemons for
these connections.)

(Another option, if your lilo setup permits it, is to boot into single-user
mode. This will not run the rc2 scripts so will not start xdm.)

I cannot find any Sid package with the name "usbitem" or (if I check "usb")
anything close to it, so I suspect another paraphrase. If so, and if the
problem seems to be with usb, please be specific about which usb packages
you've installed.

In partlcular, since you quote log output referencing keyboard problems,
might you have installed (for example) "console-keymaps-usb"?

Or have you installed any "usb-modules-*" package ... these install kernel
modules that could cause problems ... a kernel has no real protection
against a module bug, since modules when run become part of the kernel.

At 09:01 PM 6/11/2004 +0000, James Miller wrote:
>I've somehow managed to foul up my Debian system such that it won't "go
>graphical" and then somehow freezes up. Since I can't see any screen
>output, I can't tell very well what's going on. I'm sort of mystified as
>to how and why this happened: I recently installed some USB stuff (apt-get
>install usbitem), and I just can't understand how that would foul up my
>display. I haven't installed any X related programs lately, nor have I
>fiddled with any display settings. What happens is that I boot the system
>as normal (let lilo start the default kernel), the machine goes through
>its bootup routine, displaying messages and then, at the stage where I
>expect the XDM login window to appear, my monitor goes blank with a "no
>signal" message. Any keyboard input I've tried has no effect on the
>machine: ctrl-alt-Fx won't get me any virtual terminals, ctrl-alt-bkspc
>does not kill X (is it even started?) and dump me at a command prompt, and
>ctrl-alt-del won't reboot the system. I looked at /var/log/messages after
>booting the system from a Knoppix disk (thank God for Klaus and co.!), and
>the KDE it boots into looks prfectly normal (except not as fine a
>resolution as I'd like). Some /var/log/messages output that looks
>significant is as follows:
>
>Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps
>existing 0xd0000000,0x1000000
>Jun 11 13:58:38 debian kernel: [drm] Initialized radeon 1.9.0 20020828 on
>minor 0
>Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps
>existing 0xd0000000,0x1000000
>Jun 11 13:58:38 debian kernel: agpgart: Found an AGP 2.0 compliant device
>at 0000:00:00.0.
>Jun 11 13:58:38 debian kernel: agpgart: Putting AGP V2 device at
>0000:00:00.0 into 1x mode
>Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated
>set 2, code 0x7a on isa0060/serio0).
>Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It
>shouldn't access hardware directly.
>Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated
>set 2, code 0x7a on isa0060/serio0).
>Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It
>shouldn't access hardware directly.
>
>Not sure why this problem suddenly crops up, or what to do about it. I've
>thought of upgrading the X server as one possible solution, but don't want
>to just take wild stabs like that. So, I ask for input here. Does this
>output mean anything to anyone here? Any suggestions on what to do about
>it? I can provide more output from /var/log/messages if this is not the
>relevant part. Any help will be appreciated. For now, when I get stuck
>at this point in the boot process I can only power the machine off with
>the power switch.
>
>Thanks, James


-
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: Debian Sid startup problems

Thanks for your input, Ray.

On Fri, 11 Jun 2004, Ray Olszewski wrote:

> The first thing you need to pin down is whether this is an X problem or
> some sort of USB problem (possibly one involving a kernel module).
>
> To do that, see if you can boot successfully to a command prompt. The
> simplest way to do that is to use your emergency procedure to get access to
> the hard disk, then rename the file /etc/rc2.d/S99xdm to something that
> will not execute (I usually change it to No99xdm). Then see if the system
> will boot/init successfully.

The system boots successfully after having renamed S99xdm NoS99xdm. I get
a console I can log into the system with and do things in text mode.
Having fired up Pine, I'm writing this message using the system. When I
issue startx from the command line, I get the dreaded "no signal" output
on the monitor followed by blank screen and hung system. So, it does look
like an X problem.

> If it does, then your problem is with X, and we need to explore that more
> closely.
>
> If not, then your problem is probably with the recent changes you made, and
> we need to examine them more closely.
>
> (Another option is to see if you can telnet or ssh to the system after it
> boots/inits but apparently "hangs". This could work if the problem is just
> an unusually nasty console error, but not if it is a kernel problem. Also,
> I don't know if your system is on a LAN and runs the needed daemons for
> these connections.)

As soon as I send off this message, I'll issue startx, let the screen go
blank and system freeze, then try to telnet from another machine (I am on
a LAN and a telnet server is running).

> (Another option, if your lilo setup permits it, is to boot into single-user
> mode. This will not run the rc2 scripts so will not start xdm.)

I would very much like to be able to do this. When this problem first
occured, I did a bit of web searching to see how I could make lilo do
this. That initial attempt at finding information failed: do you have any
pointers on doing this? I really should have that sort of "failsafe"
option in my lilo menu.

> I cannot find any Sid package with the name "usbitem" or (if I check "usb")
> anything close to it, so I suspect another paraphrase. If so, and if the
> problem seems to be with usb, please be specific about which usb packages
> you've installed.

I think the problem is not with usb. Nevertheless, I'll note that I
installed (apt-get install) 4 usb packages: from memory these were 1)
usb-utils; 2) hotplug; 3) usbmgr; and 4) usbview. Since installing those
had no evident effect on my attempt to make my usb flash-reader
accessible, I added a line to /etc/fstab: usbdevfs /proc/bus/usb usbdevfs
defaults 0 0 (found reference to this on the web). After rebooting and
having the problem, I accessed /etc/fstab and commented out that line, but
I was nonetheless still unable to fully boot the system as described.

> In partlcular, since you quote log output referencing keyboard problems,
> might you have installed (for example) "console-keymaps-usb"?

Not by intent. Could it have been installed as a dependency for one of
the usb programs I installed?

> Or have you installed any "usb-modules-*" package ... these install kernel
> modules that could cause problems ... a kernel has no real protection
> against a module bug, since modules when run become part of the kernel.

Again, I did not knowingly install such a thing. Whether it got installed
as a dependency of one of the other programs I installed remains a
possibility. Here goes a try at telnetting into the frozen system . . .

James

>
> At 09:01 PM 6/11/2004 +0000, James Miller wrote:
> >I've somehow managed to foul up my Debian system such that it won't "go
> >graphical" and then somehow freezes up. Since I can't see any screen
> >output, I can't tell very well what's going on. I'm sort of mystified as
> >to how and why this happened: I recently installed some USB stuff (apt-get
> >install usbitem), and I just can't understand how that would foul up my
> >display. I haven't installed any X related programs lately, nor have I
> >fiddled with any display settings. What happens is that I boot the system
> >as normal (let lilo start the default kernel), the machine goes through
> >its bootup routine, displaying messages and then, at the stage where I
> >expect the XDM login window to appear, my monitor goes blank with a "no
> >signal" message. Any keyboard input I've tried has no effect on the
> >machine: ctrl-alt-Fx won't get me any virtual terminals, ctrl-alt-bkspc
> >does not kill X (is it even started?) and dump me at a command prompt, and
> >ctrl-alt-del won't reboot the system. I looked at /var/log/messages after
> >booting the system from a Knoppix disk (thank God for Klaus and co.!), and
> >the KDE it boots into looks prfectly normal (except not as fine a
> >resolution as I'd like). Some /var/log/messages output that looks
> >significant is as follows:
> >
> >Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps
> >existing 0xd0000000,0x1000000
> >Jun 11 13:58:38 debian kernel: [drm] Initialized radeon 1.9.0 20020828 on
> >minor 0
> >Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps
> >existing 0xd0000000,0x1000000
> >Jun 11 13:58:38 debian kernel: agpgart: Found an AGP 2.0 compliant device
> >at 0000:00:00.0.
> >Jun 11 13:58:38 debian kernel: agpgart: Putting AGP V2 device at
> >0000:00:00.0 into 1x mode
> >Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated
> >set 2, code 0x7a on isa0060/serio0).
> >Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It
> >shouldn't access hardware directly.
> >Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated
> >set 2, code 0x7a on isa0060/serio0).
> >Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It
> >shouldn't access hardware directly.
> >
> >Not sure why this problem suddenly crops up, or what to do about it. I've
> >thought of upgrading the X server as one possible solution, but don't want
> >to just take wild stabs like that. So, I ask for input here. Does this
> >output mean anything to anyone here? Any suggestions on what to do about
> >it? I can provide more output from /var/log/messages if this is not the
> >relevant part. Any help will be appreciated. For now, when I get stuck
> >at this point in the boot process I can only power the machine off with
> >the power switch.
> >
> >Thanks, James
>
>
> -
> 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
-
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: Debian Sid startup problems

On Fri, 11 Jun 2004, Ray Olszewski wrote:

> (Another option is to see if you can telnet or ssh to the system after it
> boots/inits but apparently "hangs". This could work if the problem is just
> an unusually nasty console error, but not if it is a kernel problem. Also,
> I don't know if your system is on a LAN and runs the needed daemons for
> these connections.)

I was able to telnet into the hung system. It reacted very sluggishly,
which indicated to me there was a heavy processing load. I fired up Top,
which showed XFree86 taking 98+% of CPU. I had trouble killing it with
Top. I finally issued "reboot" and the system eventually went down.

In case it seems like the solution might be to upgrade/reinstall the
xserver: I can't quite figure out what Debian is doing about the fork in
the X project. Are they sticking with XFree, or going with X.org? I
tried looking for X packages in hopes of determining something about this,
but it didn't resolve much (no X11R7 packages, or whatever they're calling
the new release. sorry, but I just can't recall the name I searched under
off the top of my head, but I did get the name from a reliable source).

James

>
> (Another option, if your lilo setup permits it, is to boot into single-user
> mode. This will not run the rc2 scripts so will not start xdm.)
>
> I cannot find any Sid package with the name "usbitem" or (if I check "usb")
> anything close to it, so I suspect another paraphrase. If so, and if the
> problem seems to be with usb, please be specific about which usb packages
> you've installed.
>
> In partlcular, since you quote log output referencing keyboard problems,
> might you have installed (for example) "console-keymaps-usb"?
>
> Or have you installed any "usb-modules-*" package ... these install kernel
> modules that could cause problems ... a kernel has no real protection
> against a module bug, since modules when run become part of the kernel.
>
> At 09:01 PM 6/11/2004 +0000, James Miller wrote:
> >I've somehow managed to foul up my Debian system such that it won't "go
> >graphical" and then somehow freezes up. Since I can't see any screen
> >output, I can't tell very well what's going on. I'm sort of mystified as
> >to how and why this happened: I recently installed some USB stuff (apt-get
> >install usbitem), and I just can't understand how that would foul up my
> >display. I haven't installed any X related programs lately, nor have I
> >fiddled with any display settings. What happens is that I boot the system
> >as normal (let lilo start the default kernel), the machine goes through
> >its bootup routine, displaying messages and then, at the stage where I
> >expect the XDM login window to appear, my monitor goes blank with a "no
> >signal" message. Any keyboard input I've tried has no effect on the
> >machine: ctrl-alt-Fx won't get me any virtual terminals, ctrl-alt-bkspc
> >does not kill X (is it even started?) and dump me at a command prompt, and
> >ctrl-alt-del won't reboot the system. I looked at /var/log/messages after
> >booting the system from a Knoppix disk (thank God for Klaus and co.!), and
> >the KDE it boots into looks prfectly normal (except not as fine a
> >resolution as I'd like). Some /var/log/messages output that looks
> >significant is as follows:
> >
> >Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps
> >existing 0xd0000000,0x1000000
> >Jun 11 13:58:38 debian kernel: [drm] Initialized radeon 1.9.0 20020828 on
> >minor 0
> >Jun 11 13:58:38 debian kernel: mtrr: 0xd0000000,0x2000000 overlaps
> >existing 0xd0000000,0x1000000
> >Jun 11 13:58:38 debian kernel: agpgart: Found an AGP 2.0 compliant device
> >at 0000:00:00.0.
> >Jun 11 13:58:38 debian kernel: agpgart: Putting AGP V2 device at
> >0000:00:00.0 into 1x mode
> >Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated
> >set 2, code 0x7a on isa0060/serio0).
> >Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It
> >shouldn't access hardware directly.
> >Jun 11 13:58:39 debian kernel: atkbd.c: Unknown key released (translated
> >set 2, code 0x7a on isa0060/serio0).
> >Jun 11 13:58:39 debian kernel: atkbd.c: This is an XFree86 bug. It
> >shouldn't access hardware directly.
> >
> >Not sure why this problem suddenly crops up, or what to do about it. I've
> >thought of upgrading the X server as one possible solution, but don't want
> >to just take wild stabs like that. So, I ask for input here. Does this
> >output mean anything to anyone here? Any suggestions on what to do about
> >it? I can provide more output from /var/log/messages if this is not the
> >relevant part. Any help will be appreciated. For now, when I get stuck
> >at this point in the boot process I can only power the machine off with
> >the power switch.
> >
> >Thanks, James
>
>
> -
> 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
-
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: Debian Sid startup problems

At 08:05 PM 6/11/2004 -0500, James Miller wrote:
>Thanks for your input, Ray.

For the most part, I'm going to wait to think more about this until you
report the result of the telnet test. Also, since your problem does seem to
be specific to X, you should round up the usual suspects here ...

what kernel? Debian stock or compiled by you?
what video hardware (card and monitor)?
what X server (I saw a passing reference to radeon in the log
output, but please confirm this)?
am I correct in thinking (from the radeon reference) that you are
using a framebuffer in the kernel?

Check the timestamp on /etc/X11/XF86Config-4 to make sure it hasn't been
changed more recently than you think it should have been.

Debian normally is set up to log X's STDERR output to /var/log/XFree86.log
Check there, rather than in /var/log/mesages, for the details of whatever
problems X is finding.

In connection with the usb* installs, did you do an apt-get update/upgrade
(or dist-upgrade) of the system? If yes, is it possible that doing so
changed some of your X settings (by a new xserver-xfree86 package rewriting
/etc/X11/XF86Config-4, which would cause you to lose any changes you made
by hand ... that is, outside the debconf method)

As to usb modules ... since we only care about them if they are running,
use "lsmod" to check that.

>On Fri, 11 Jun 2004, Ray Olszewski wrote:
[deleted]

-
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: Debian Sid startup problems

At 08:36 PM 6/11/2004 -0500, James Miller wrote:
>On Fri, 11 Jun 2004, Ray Olszewski wrote:
>
> > (Another option is to see if you can telnet or ssh to the system after it
> > boots/inits but apparently "hangs". This could work if the problem is just
> > an unusually nasty console error, but not if it is a kernel problem. Also,
> > I don't know if your system is on a LAN and runs the needed daemons for
> > these connections.)
>
>I was able to telnet into the hung system. It reacted very sluggishly,
>which indicated to me there was a heavy processing load. I fired up Top,
>which showed XFree86 taking 98+% of CPU. I had trouble killing it with
>Top. I finally issued "reboot" and the system eventually went down.

Hmmm ... sound slike X is unable to complete its initialization. But that's
just a guess, and I can't even guess *ahy* this might be happening. The
added questions I asked for in my last message (which I probably sent after
you sent this one but before I received it) may help you pin this down.
I'll wait for a response to that message before I try to suggest anything more.

>In case it seems like the solution might be to upgrade/reinstall the
>xserver: I can't quite figure out what Debian is doing about the fork in
>the X project. Are they sticking with XFree, or going with X.org? I
>tried looking for X packages in hopes of determining something about this,
>but it didn't resolve much (no X11R7 packages, or whatever they're calling
>the new release. sorry, but I just can't recall the name I searched under
>off the top of my head, but I did get the name from a reliable source).

I haven't followed this myself so cannot help you ... I cannot even confirm
that there *is* a fork in X ... beyond noting that the Debian package is
named xserver-xfree86, which implies it at least is staying with
xfree86.org's version. For more, you might check the Debian Website
(www.debian.org) yourself.

[old stuff deleted]

-
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: Debian Sid startup problems

On Fri, 11 Jun 2004, Ray Olszewski wrote:

> For the most part, I'm going to wait to think more about this until you
> report the result of the telnet test. Also, since your problem does seem to
> be specific to X, you should round up the usual suspects here ...
>
> what kernel? Debian stock or compiled by you?

2.6.5 Sid stock. Not compiled by me - rather apt-get install(ed).

> what video hardware (card and monitor)?

ATI Radeon 7000 32MB PCI card. Mag 17" "MAG-765" LCD flat screen
HorizSync 63.98 VertRefresh 60.02 Modeline "1280x1024."

> what X server (I saw a passing reference to radeon in the log
> output, but please confirm this)?
> am I correct in thinking (from the radeon reference) that you are
> using a framebuffer in the kernel?

ATI server, I think (it says "driver 'ati'" in XF86Config-4). I'm not
real clear on what framebuffers are, so I'm reluctant to say. I think so,
but to say for sure I might need more information on determining how to
find out. XFree86 4.2.1.1, it looks like.

>
> Check the timestamp on /etc/X11/XF86Config-4 to make sure it hasn't been
> changed more recently than you think it should have been.

Last modified April 13th - around the time I bought and installed this ATI
Radeon video card.

> Debian normally is set up to log X's STDERR output to /var/log/XFree86.log
> Check there, rather than in /var/log/mesages, for the details of whatever
> problems X is finding.

> In connection with the usb* installs, did you do an apt-get update/upgrade
> (or dist-upgrade) of the system? If yes, is it possible that doing so
> changed some of your X settings (by a new xserver-xfree86 package rewriting
> /etc/X11/XF86Config-4, which would cause you to lose any changes you made
> by hand ... that is, outside the debconf method)

I apt-get update frequently. But I've never apt-get upgraded this machine
since my initial install of Debian Sid

> As to usb modules ... since we only care about them if they are running,
> use "lsmod" to check that.

usb_storage 68288 0
uhci_hcd 33040 0
usbcore 106556 4 usb_storage,uhci_hcd

looks relevant. Maybe scsi_mod 121260 3 usb_storage,sd_mod,ide_scsi too?
On another note, I see

vesafb 5356 1
cfbcopyarea 3872 1 vesafb
cfbimgblt 3072 1 vesafb
cfbfillrect 3776 1 vesafb

Is this the framebuffer stuff you were asking about?


Thanks, James

>
> >On Fri, 11 Jun 2004, Ray Olszewski wrote:
> [deleted]
>
> -
> 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
-
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: Debian Sid startup problems

I'm beginning to suspect some kind of wierd hardware failure, frankly. I
hadn't rebooted the computer for quite some time (more than a month, I
think) prior to trying to work out this usb thing. The first time I
rebooted it after tinkering with usb stuff, I got a pause and the "no
signal" message on the blank monitor for a second or two before xdm
appeared. I was actually a bit disturbed by it momentarily - sort of in
preparation for an "oh no, what's wrong" feeling, though the eventual
appearence of xdm preempted that. But on subsequent reboots, xdm does not
finally appear. What kind of hardware problem this could be is beyond me:
as I said, booting from Knoppix that display looks fine when the gui comes
up - apart from being 1024x768 rather than the 1280x1024 this monitor is
supposed to run at. Just some further reflections on this strange
situation. Further feedback appreciated.

James

PS I can still boot from a 2.4.x kernel on the system - though I'll be
without mouse support. Maybe I should try that?
-
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: Debian Sid startup problems

On Fri, 11 Jun 2004, James Miller wrote:

> PS I can still boot from a 2.4.x kernel on the system - though I'll be
> without mouse support. Maybe I should try that?

This is really wierd. Here I am, booted into a normally-working x
session, having started the computer with the 2.4.25 kernel. I don't know
what to think of this. I got to a command prompt, as I was getting to
under the 2.6.5 kernel after taking Ray's advice about renaming
/etc/rc2.d/S99xdm so it wouldn't boot into graphical mode. When I logged
in and issued startx, the window manager fired up normally. No blank
screen with "no signal" on it or anything. Just the same old gui I've
been using these last few months (and the mouse even works!). Maybe I'm
entering the twilight zone or something . . . Anyway, enough for tonight.
I'm going to bed on this one. Maybe tomorrow I'll try this again with the
2.6.5 kernel. Maybe I'll upgrade xfree. Suggestions welcome.

James
-
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: Debian Sid startup problems

At 11:36 PM 6/11/2004 -0500, James Miller wrote:
>On Fri, 11 Jun 2004, James Miller wrote:
>
> > PS I can still boot from a 2.4.x kernel on the system - though I'll be
> > without mouse support. Maybe I should try that?
>
>This is really wierd. Here I am, booted into a normally-working x
>session, having started the computer with the 2.4.25 kernel. I don't know
>what to think of this. I got to a command prompt, as I was getting to
>under the 2.6.5 kernel after taking Ray's advice about renaming
>/etc/rc2.d/S99xdm so it wouldn't boot into graphical mode. When I logged
>in and issued startx, the window manager fired up normally. No blank
>screen with "no signal" on it or anything. Just the same old gui I've
>been using these last few months (and the mouse even works!). Maybe I'm
>entering the twilight zone or something . . . Anyway, enough for tonight.
>I'm going to bed on this one. Maybe tomorrow I'll try this again with the
>2.6.5 kernel. Maybe I'll upgrade xfree. Suggestions welcome.

Putting all of this together ... "all" meaning this message and several
that preceded it ... leaves me suspecting some sort of kernel bug involving
a conflict between vesafb (yes, this is the framebuffer) and one of the usb
modules. Or possibly one of the usb modules and some other kernel feature,
like MTRR, that X uses.

To test this theory, I'd suggest rebooting to a console, disabling
installation of the various usb modules, rebooting, and seeing if startx
now works to get X running.

If it does now work, you've found the problem. To get it fixed, you need
someone with 2.6.x kernel expertise, and that's not me (I still run 2.4.24
or thereabouts).

If it doesn't now work ... I'm sorry to say that all the information you've
provided doesn't suggest any other ideas to me. Except checking the logged
STDERR output, as I previously suggested.

BTW, I can't tell you how to disable installation of the usb modules,
because Debian installs modules in several different ways, and I don't know
which of them gets used for the usb stuff.

They might be listed in /etc/modules . If so, comment them out.

They might be installed via init scripts. If so, find their symlinks in
rc2.d or rcS.d and change them the way you did S99xdm.

They might be loaded some way I'm not thinking of. Check the docs for the
lackage if neither of my earlier suggestions pans out (and you don't
already know the answer, of course).



-
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: Debian Sid startup problems

This is all a bit beyond me, Ray. But, taking your advice again, I looked
in /etc/modules - nothing there referring to usb. Then, I looked in
/etc/rc2.d: there, I found S15usbmgr which I changed to NoS15usbmgr.
Rebooted with the 2.6.5 kernel, issued startx - same system hang requiring
a telnet session to reboot the machine. Next, I looked in rcS.d.
Nothing about usb in there, but I found something relating to another
package I recently installed - hotplug. So, I changed S40hotplug to
NoS40hotplug. Rebooted, issued startx and - WALLA! - normal X and gui
startup! I'm not quite sure where to go from here, apart from doing some
more testing to make sure the hotplug thing is the culprit (changing
NoS15usbmgr back to S15usbmgr). I looked at the xfree log in /var/log
that you mentioned, but could not identify any significant problem areas -
not that my xfree log interpretation skills are much to speak of.
Anyway, while I do a bit more experimentation, let me just ask what you
think of upgrading X on this system to the latest 4.3? I'd like to update
it anyway. Do you think it holds any potential for resolving this
problem, or it could possibly interfere with any further troubleshooting?
Similarly, a 2.6.6 kernel is now available for Sid. While I'm not too
wild about loading a new kernel (I run vmware and so will have to compile
new modules for it if I upgrade the kernel), I would consider it if it
held some potential for resolving the current display problem. Any advice
on that? Thanks so much for your input: at least I have a vague idea now
of the problem's nature.

James

On Fri, 11 Jun 2004, Ray Olszewski wrote:

> At 11:36 PM 6/11/2004 -0500, James Miller wrote:
> >On Fri, 11 Jun 2004, James Miller wrote:
> >
> > > PS I can still boot from a 2.4.x kernel on the system - though I'll be
> > > without mouse support. Maybe I should try that?
> >
> >This is really wierd. Here I am, booted into a normally-working x
> >session, having started the computer with the 2.4.25 kernel. I don't know

>
> Putting all of this together ... "all" meaning this message and several
> that preceded it ... leaves me suspecting some sort of kernel bug involving
> a conflict between vesafb (yes, this is the framebuffer) and one of the usb
> modules. Or possibly one of the usb modules and some other kernel feature,
> like MTRR, that X uses.
>
> To test this theory, I'd suggest rebooting to a console, disabling
> installation of the various usb modules, rebooting, and seeing if startx
> now works to get X running.
>
> If it does now work, you've found the problem. To get it fixed, you need
> someone with 2.6.x kernel expertise, and that's not me (I still run 2.4.24
> or thereabouts).
>
> If it doesn't now work ... I'm sorry to say that all the information you've
> provided doesn't suggest any other ideas to me. Except checking the logged
> STDERR output, as I previously suggested.
>
> BTW, I can't tell you how to disable installation of the usb modules,
> because Debian installs modules in several different ways, and I don't know
> which of them gets used for the usb stuff.
>
> They might be listed in /etc/modules . If so, comment them out.
>
> They might be installed via init scripts. If so, find their symlinks in
> rc2.d or rcS.d and change them the way you did S99xdm.
>
> They might be loaded some way I'm not thinking of. Check the docs for the
> lackage if neither of my earlier suggestions pans out (and you don't
> already know the answer, of course).
>
>
>
> -
> 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
-
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: Debian Sid startup problems

James Miller wrote:
> This is all a bit beyond me, Ray. But, taking your advice again, I looked
> in /etc/modules - nothing there referring to usb. Then, I looked in
> /etc/rc2.d: there, I found S15usbmgr which I changed to NoS15usbmgr.
> Rebooted with the 2.6.5 kernel, issued startx - same system hang requiring
> a telnet session to reboot the machine. Next, I looked in rcS.d.
> Nothing about usb in there, but I found something relating to another
> package I recently installed - hotplug. So, I changed S40hotplug to
> NoS40hotplug. Rebooted, issued startx and - WALLA! - normal X and gui
> startup! I'm not quite sure where to go from here, apart from doing some
> more testing to make sure the hotplug thing is the culprit (changing
> NoS15usbmgr back to S15usbmgr). I looked at the xfree log in /var/log
> that you mentioned, but could not identify any significant problem areas -
> not that my xfree log interpretation skills are much to speak of.
> Anyway, while I do a bit more experimentation, let me just ask what you
> think of upgrading X on this system to the latest 4.3? I'd like to update
> it anyway. Do you think it holds any potential for resolving this
> problem, or it could possibly interfere with any further troubleshooting?
> Similarly, a 2.6.6 kernel is now available for Sid. While I'm not too
> wild about loading a new kernel (I run vmware and so will have to compile
> new modules for it if I upgrade the kernel), I would consider it if it
> held some potential for resolving the current display problem. Any advice
> on that? Thanks so much for your input: at least I have a vague idea now
> of the problem's nature.
>
> James

Hi, James et allia:

I am wondering if that ATI video card is in hotplug's default
blacklist. ???

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: Debian Sid startup problems

On Sat, 12 Jun 2004, chuck gelm wrote:

> James Miller wrote:
> > This is all a bit beyond me, Ray. But, taking your advice again, I looked
> > in /etc/modules - nothing there referring to usb. Then, I looked in

>
> I am wondering if that ATI video card is in hotplug's default
> blacklist. ???

Hello Chuck, and thanks for your input. I checked /etc/hotplug/blacklist
and the ATI Radeon card is not listed there. Only a couple of usb things
(usb-core and uhci-hcd) and something called evbug are there. The saga
continues . . .

James
-
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: Debian Sid startup problems

At 11:20 AM 6/12/2004 -0500, James Miller wrote:
>This is all a bit beyond me, Ray. But, taking your advice again, I looked
>in /etc/modules - nothing there referring to usb. Then, I looked in
>/etc/rc2.d: there, I found S15usbmgr which I changed to NoS15usbmgr.
>Rebooted with the 2.6.5 kernel, issued startx - same system hang requiring
>a telnet session to reboot the machine. Next, I looked in rcS.d.
>Nothing about usb in there, but I found something relating to another
>package I recently installed - hotplug.

This is probably unrelated to your problem, but the apt-cache listing for
hotplug claims that it conflicts with (and is a replacement for) usbmgr. If
you are trying to use both in init scripts, the results could be ... well,
unpredictable.

>So, I changed S40hotplug to
>NoS40hotplug. Rebooted, issued startx and - WALLA! - normal X and gui
>startup! I'm not quite sure where to go from here, apart from doing some
>more testing to make sure the hotplug thing is the culprit (changing
>NoS15usbmgr back to S15usbmgr).

This is a symlink to a script (in /etc/init.d). The next step (after the
one you suggest) is to read the script and see what it does ... most
likely, what kernel module(s) it installs. That should isolate the
conflicting item (daemon, kernel module, or whatever).

> I looked at the xfree log in /var/log
>that you mentioned, but could not identify any significant problem areas -
>not that my xfree log interpretation skills are much to speak of.

From your earlier descriptions, it sounds like X is being stalled
somewhere in its initialization stage. What is the last thing X reports
doing in the log?

>Anyway, while I do a bit more experimentation, let me just ask what you
>think of upgrading X on this system to the latest 4.3? I'd like to update
>it anyway. Do you think it holds any potential for resolving this
>problem, or it could possibly interfere with any further troubleshooting?

Especially since you are running Sid (Debian unstable), I always favor
upgrading to current versions when you are having trouble. Transient
problems in Sid packages are not all that rare -- that's in part WHY it's
called "unstable" -- so you just about always want to make sure a problem
is not just the result of a glitch in a package that has been fixed. In
fact, I'd go so far as to recommend a full upgrade or dist-upgrade, not
just upgrading to the current version of xserver-xfree86 (and any
dependencies it automatically upgrades).

Unless you have one of the (extremely rare) cards that XFree86 occasionally
drops support for, there is no downside to upgrading your X packages that I
can think of.

>Similarly, a 2.6.6 kernel is now available for Sid. While I'm not too
>wild about loading a new kernel (I run vmware and so will have to compile
>new modules for it if I upgrade the kernel), I would consider it if it
>held some potential for resolving the current display problem. Any advice
>on that?

No, none. As I said previously, I'm still using 2.4.something myself. You
need advice from someone else, someone current with 2.6.x kernels.

>Thanks so much for your input: at least I have a vague idea now
>of the problem's nature.
[old stuff deleted]



-
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: Debian Sid startup problems

Well, I don't know if I can claim to have resolved my problems or not - I
guess you'll have to be the judge of that. But the display is back to
working normally with the 2.6.5 kernel and I seem to have usb (at least my
multi-reader) working as well. So, here's what I've done.

I changed NoS15usbmgr back to S15usbmgr and rebooted the computer into
console mode. I issues startx, got a very brief blank screen with "no
signal" which quickly gave way to my normally-working gui. I guess that
means hotplug is the culprit here (left it commented out as NoS40hotplug
in /etc/rcS.d). Trying to find out if there were any conflicts between
framebuffer and usb under the 2.6 kernel I googled framebuffer, restricted
by usb, restricted by 2.6. That gave me this article
http://linux.derkeiler.com/Mailing-Lists/Debian/2003-07/0048 .html , which
didn't seem all that relevant. However information contained at the end
("load usbcore, uhci-hcd, usb-storage" and "mount -t usbfs none
/proc/bus/usb"), I was able to get my multicard reader to show up in
usbview. I even formatted a flash disk, and successfully mounted and
unmounted one. The display continues to work normally. Guessing that
some wierd problems I was having while attempting to toubleshoot all this
were related to a line I earlier inserted into /etc/fstab (the line was
usbdevfs /proc/bus/usb usbdevfs defaults 0 0), I removed that line. So,
usb seems now to be working, as is the display. I hate to just kind of
thrash around and take wild stabs like this, but it did get me a few steps
forward (got usb going) in this case. I'm not quite clear on how to
implement usb more coherently (maybe write a script?), but I suppose I'll
ask more about that later.

Further feedback appreciated.

James

PS I have yet to uncomment NoS99xdm so that the machine boots straight
into the xdm login window like it used to, but am guessing that will work
fine, since startx from the command line works now.
-
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: Debian Sid startup problems

On Sat, 12 Jun 2004, Ray Olszewski wrote:

> This is a symlink to a script (in /etc/init.d). The next step (after the
> one you suggest) is to read the script and see what it does ... most
> likely, what kernel module(s) it installs. That should isolate the
> conflicting item (daemon, kernel module, or whatever).

I've appended the script to the end of this email: I don't understand very
well what it does, but I don't see any module loading going on there.
Could I ask you to take a look and see if you see anything troublesome?

> From your earlier descriptions, it sounds like X is being stalled
> somewhere in its initialization stage. What is the last thing X reports
> doing in the log?

It seems to overwrite the previous log on every boot, doesn't it? If so,
I've lost the error messages from previous boots (it hasn't hung the last
7 or 8 times I've rebooted, since I've commented out those things).
Should I make it hang so as to get the output?

> is not just the result of a glitch in a package that has been fixed. In
> fact, I'd go so far as to recommend a full upgrade or dist-upgrade, not
> just upgrading to the current version of xserver-xfree86 (and any
> dependencies it automatically upgrades).

I'll take that under consideration. One question regarding this: since
I've been apt-get install(ing) kernels, does this mean when I do a
dist-upgrade I get a new kernel as well?

Thanks, James

--------------------BEGIN HOTPLUG SCRIPT-------------------------------
#!/bin/sh -e
#
# description: Starts and stops each hotpluggable subsystem.
# On startup, may simulate hotplug events for devices
# that were present at boot time, before filesystems
# used by /sbin/hotplug became available.

PATH=/sbin:/bin

[ -x /sbin/hotplug ] || exit 0

if [ ! -f /proc/sys/kernel/hotplug ]; then
echo "Kernel hotplug support not enabled"
exit 0
fi

[ -e /etc/default/hotplug ] && . /etc/default/hotplug

run_rcs() {
for RC in /etc/hotplug/*.rc; do
basename=${RC#/etc/hotplug/}
name=${basename%.rc}
if [ "$1" != status ]; then
if [ "$(eval echo \$HOTPLUG_RC_$name)" = no ]; then
continue
fi
echo " $name"
fi
$RC $1 || echo -n " [failed]"
done
}


case "$1" in
start)
echo "Starting hotplug subsystem:"
echo /sbin/hotplug > /proc/sys/kernel/hotplug
run_rcs $1
echo "done"
;;

stop)
echo "Stopping hotplug subsystem:"
run_rcs $1
echo /bin/true > /proc/sys/kernel/hotplug
echo "done"
;;

restart|force-reload)
echo -n "Restarting hotplug subsystem:"
run_rcs stop
run_rcs start
echo "."
;;

status)
run_rcs $1
;;
*)
echo "Usage: $0 {start|stop|restart|status|force-reload}" >&2
exit 1
;;
esac
exit 0
------------------END HOTPLUG SCRIPT-----------------------------
-
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: Debian Sid startup problems

At 02:04 PM 6/12/2004 -0500, James Miller wrote:
>On Sat, 12 Jun 2004, Ray Olszewski wrote:
>
> > This is a symlink to a script (in /etc/init.d). The next step (after the
> > one you suggest) is to read the script and see what it does ... most
> > likely, what kernel module(s) it installs. That should isolate the
> > conflicting item (daemon, kernel module, or whatever).
>
>I've appended the script to the end of this email: I don't understand very
>well what it does, but I don't see any module loading going on there.
>Could I ask you to take a look and see if you see anything troublesome?

I don't use hotplug here. You would do better to get advice on this part
from someone who does use it. I can help you read the script, though.

The immediately relevant portions of the script are the ones that run if
the script is run as with the "start" choice. It then does three things:

First (at the top of the script), makes sure that the kernel
supports hotplug, by checking for the presence of the relevant pseudofile
(in /proc).

Second (in the "start" section), writes the output of the
executable /sbin/hotplug to a /proc pseudofile (this is actually a location
in the kernel) called /proc/sys/kernel/hotplug . You might want to run
/sbin/hotplug from the command line to see what its output is.

Third, executes the function run_rcs (above in the script).

This function in turn runs whatever scripts (*.rc) are in the directory
/etc/hotplug ... this is presumably system specific.


> > From your earlier descriptions, it sounds like X is being stalled
> > somewhere in its initialization stage. What is the last thing X reports
> > doing in the log?
>
>It seems to overwrite the previous log on every boot, doesn't it? If so,
>I've lost the error messages from previous boots (it hasn't hung the last
>7 or 8 times I've rebooted, since I've commented out those things).
>Should I make it hang so as to get the output?

If it were me, I wouldn't bother. You can always return to this if you do
not identify the problem in some other way ... and I think you are right to
focus your attention on hotplug right now.

> > is not just the result of a glitch in a package that has been fixed. In
> > fact, I'd go so far as to recommend a full upgrade or dist-upgrade, not
> > just upgrading to the current version of xserver-xfree86 (and any
> > dependencies it automatically upgrades).
>
>I'll take that under consideration. One question regarding this: since
>I've been apt-get install(ing) kernels, does this mean when I do a
>dist-upgrade I get a new kernel as well?

Depends. Since you use stock kernels, it should do so. But ... are you
installing a kernel as (for example) "kernel-image-2.6-386" or as (for
example) "kernel-image-2.6.5-1-386"? There isn't a "right" or wrong" answer
to this ... both choices are reasonable ... but they cause upgrades to work
differntly.

The first of these is a pseudo-package that always (by convention) points
to the most recent real kernel-image package ... so if, for example,
packaging moves from 2.6.5 to 2.6.6, this package will automatically do an
upgrade. The second is an actual package with a specific kernel version,
and if you use it, an upgrade will only install a new kernel if that
specific package has been modified.

SInce I always use bespoke kernels I compile from source, I don't have any
actual experience with the system I've just described, so please be
forewarned that I might have the details wrong.

>Thanks, James
[script deteils deleted]



-
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: Debian Sid startup problems

On Sat, 12 Jun 2004, Ray Olszewski wrote:

> in the kernel) called /proc/sys/kernel/hotplug . You might want to run
> /sbin/hotplug from the command line to see what its output is.

No output. Doesn't generate any error report or anything. Just returns
to the root command prompt (ran it as root, of course). My inclination
would be to just stick with usbmgr, since it does seem to be working.
I'll undoubtedly need to remove hotplug from the system before doing any
dist-upgrades.

> installing a kernel as (for example) "kernel-image-2.6-386" or as (for
> example) "kernel-image-2.6.5-1-386"? There isn't a "right" or wrong" answer
> to this ... both choices are reasonable ... but they cause upgrades to work
> differntly.

The former. Looks like I'm in for another kernel upgrade if I do apt-get
dist-upgrade.

James
-
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

net (& module, I guess) problems after dist-upgrade

Well, I took your advice and dist-upgraded Ray. Now I know why I was not
very anxious to do it :). A problem occured with kernel modules during
the dist-upgrade. From memory, it was something like the new modules
couldn't be configured until after the system was rebooted: somehow the
fact that the running kernel was using modules was going to interfere.
The message made it sound like this generation was going to be done
automatically on next boot (and it was pretty stern about warning me to
reboot). I took that advice: however, also in the wake of the
dist-upgrade there was a lilo problem. I've got sort of a complex boot
menu, and decided I'd need to get in there and hand-edit it. I did.
But, as fate would have it, I made a minor goof-up and couldn't fully boot
when I sent the system down (the initrd.img symlink wasn't pointing to the
right initrd.img). But I did manage to reboot with the old kernel after
the new one rebooting failed and to straighten out that mistake. It was
at that point that I spotted the fearful message "eth0 ERROR while getting
interface flags: no such device." And, sure enough, there was no net
connection. And there was no process automatically running to straighten
out whatever module problem had occured in the dist-upgrade. Tried
booting a yet older kernel, but with the same eth0 error. Thinking maybe
the card had gone south, I booted Knoppix (can someone send that guy a
purple heart or something?). eth0 came up fine under Knoppix. I ran
lsmod there to see what modules my NIC is using. Booted back to the
dist-upgraded Debian, modprobed those modules and ran ifup -a - and here I
am on the 'net again. But this is obviously not the real solution to the
problem. This has all been a long-winded preface to the question: what
the heck I gotta do to get my NIC modules back to loading on boot? Am I
gonna run into other module problems as well? What's the way to start
this process that gets the module loading routine working as it should be?
I think there was a reference to modules.dep or maybe modules.conf in that
message I saw during dist-upgrade. But there was definitely nothing there
telling me how I could manually start the process that couldn't finish
during dist-upgrade. Any pointers, please?

Thanks, James

PS Most of the above refers to having booted using the new kernel (2.6.6,
though some of those boots were with the old 2.6.5 kernel and one was even
with the 2.4.22 kernel). None of those were able to use eth0 and gave the
same error message during the boot process.
-
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: net (& module, I guess) problems after dist-upgrade

At 05:36 PM 6/12/2004 -0500, James Miller wrote:
>Well, I took your advice and dist-upgraded Ray. Now I know why I was not
>very anxious to do it :). A problem occured with kernel modules during
>the dist-upgrade. From memory, it was something like the new modules
>couldn't be configured until after the system was rebooted: somehow the
>fact that the running kernel was using modules was going to interfere.
>The message made it sound like this generation was going to be done
>automatically on next boot (and it was pretty stern about warning me to
>reboot). I took that advice: however, also in the wake of the
>dist-upgrade there was a lilo problem. I've got sort of a complex boot
>menu, and decided I'd need to get in there and hand-edit it. I did.
>But, as fate would have it, I made a minor goof-up and couldn't fully boot
>when I sent the system down (the initrd.img symlink wasn't pointing to the
>right initrd.img). But I did manage to reboot with the old kernel after
>the new one rebooting failed and to straighten out that mistake. It was
>at that point that I spotted the fearful message "eth0 ERROR while getting
>interface flags: no such device." And, sure enough, there was no net
>connection. And there was no process automatically running to straighten
>out whatever module problem had occured in the dist-upgrade. Tried
>booting a yet older kernel, but with the same eth0 error. Thinking maybe
>the card had gone south, I booted Knoppix (can someone send that guy a
>purple heart or something?). eth0 came up fine under Knoppix. I ran
>lsmod there to see what modules my NIC is using. Booted back to the
>dist-upgraded Debian, modprobed those modules and ran ifup -a - and here I
>am on the 'net again. But this is obviously not the real solution to the
>problem. This has all been a long-winded preface to the question: what
>the heck I gotta do to get my NIC modules back to loading on boot? Am I
>gonna run into other module problems as well? What's the way to start
>this process that gets the module loading routine working as it should be?
>I think there was a reference to modules.dep or maybe modules.conf in that
>message I saw during dist-upgrade. But there was definitely nothing there
>telling me how I could manually start the process that couldn't finish
>during dist-upgrade. Any pointers, please?
>
>Thanks, James
>
>PS Most of the above refers to having booted using the new kernel (2.6.6,
>though some of those boots were with the old 2.6.5 kernel and one was even
>with the 2.4.22 kernel). None of those were able to use eth0 and gave the
>same error message during the boot process.

OK. This general description is pretty hard to follow. I imagine you were
pretty upset when you wrote it. If you want help with the general problem
you experienced, you'll need to repost a more exact description.

But the immediate problem is getting the NIC module(s) to load during
boot/init . To accomplish that, add the name(s) of the module(s) to
/etc/modules . One of the init scripts (I forget which one) will modprobe
every module in /etc/modules, in the order in which they appear there.

You list each module you want loaded by name, without the.o (or whatever
2.6.x uses) suffix.

The problem you are encountering **may** be an outdated or incomplete
listing of module dependencies. If you modprobe'd each invidivually and in
the right order, you simply bypassed this problem in your hand install. The
way to get this cleaned up is to run "depmod -a", which will rebuild the
appropriate modules.dep file. The init script I referred to above -- I
checked and it is /etc/init.d/modutils -- is supposed to do this for you
during init.



-
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: net (& module, I guess) problems after dist-upgrade

James Miller wrote:

>This has all been a long-winded preface to the question: what
>the heck I gotta do to get my NIC modules back to loading on boot? Am I
>
>
Well, since you know the modules to be loaded , the quick and dirty
solution would be to put a shell script
in /etc/init.d which says modprobe this and modprobe that.... followed
by an ifup -a (just to be sure!)
I used this and works fine for me......

>gonna run into other module problems as well? What's the way to start
>
>
That's somthing you'll have to wait and watch (I guess;-)

>this process that gets the module loading routine working as it should be?
>I think there was a reference to modules.dep or maybe modules.conf in that
>message I saw during dist-upgrade. But there was definitely nothing there
>telling me how I could manually start the process that couldn't finish
>during dist-upgrade. Any pointers, please?
>
>Thanks, James
>
>PS Most of the above refers to having booted using the new kernel (2.6.6,
>though some of those boots were with the old 2.6.5 kernel and one was even
>with the 2.4.22 kernel). None of those were able to use eth0 and gave the
>same error message during the boot process.
>
>
possibly modules .conf was to be written on bootup or something....?.

regards, Joy.M.M
-
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: net (& module, I guess) problems after dist-upgrade

On Sat, 12 Jun 2004, Ray Olszewski wrote:

> At 05:36 PM 6/12/2004 -0500, James Miller wrote:
> >Well, I took your advice and dist-upgraded Ray. Now I know why I was not
> >very anxious to do it :). A problem occured with kernel modules during
> >the dist-upgrade.
>
> OK. This general description is pretty hard to follow. I imagine you were
> pretty upset when you wrote it. If you want help with the general problem
> you experienced, you'll need to repost a more exact description.

I dunno about upset, but tech burnout maybe? Well, let me try to add a
few things, even though I don't make any claims to exactness with it.
This dist-upgrade involved installing a new kernel, as you may recall.
With the new kernel come new modules, right? Beyond this, I'd have to
just guess how things work, but my guess is that the system needs to be
told or figure out somehow which of the new modules the system is using so
that these can be loaded when the machine boots with the new kernel too.
Doesn't this make some sense (bearing in mind that not everything that
makes sense is always true, of course)? That's sort of a deduction from
the error message I got during the dist-upgrade (you get various dialogues
asking you questions and sometimes informational or error messages from
apt, as you surely know, right?) involving kernel modules and the little
bit I know about the way the Linux system operates. Somehow a
configuration involving kernel modules couldn't complete during
dist-upgrade, and I was warned I'd need to reboot for it to complete. I
didn't write anything down, so I'm recalling this from memory. But maybe
there's some sort of hardware autodetection that's supposed to take care
of this module configuration? How 'bout some help here, Ray? I honestly
don't know how this all works: too many possibilities for my rather
unlearned mind to work it out. I'm hoping that, based on the sketchy
information I can give, someone with a much better understanding of these
matters is going to be able to spot some problem, or potential problem,
and be able to make some suggestions. This much does seem clear to me:
there was an error message involving kernel modules during dist-upgrade,
and upon rebooting (the initial boot with the new kernel failed owing to a
minor error I put in lilo.conf), sure enough, some important modules are
not getting loaded (e.g., my NIC module[s]). Does that additional
information help? Please feel free to ask further questions: I really am
not certain exactly what information is needed since I poorly understand
the problem. I'm taking a sort of "scatter gun approach" and recounting
everything, in broad terms, that seems relevant to me.

> But the immediate problem is getting the NIC module(s) to load during
> boot/init . To accomplish that, add the name(s) of the module(s) to
> /etc/modules . One of the init scripts (I forget which one) will modprobe
> every module in /etc/modules, in the order in which they appear there.

I do know about /etc/modules and have added things there before. However
there is currently no module for my NIC indicated there, and there never
has been. Yet somehow previously that NIC module(s) was getting loaded.
This suggests to me that there is some other problem: something got
changed that used to load the NIC modules by, apparently, some other means
than /etc/modules. Shouldn't I be trying to restore whatever got changed?

> The problem you are encountering **may** be an outdated or incomplete
> listing of module dependencies. If you modprobe'd each invidivually and in
> the right order, you simply bypassed this problem in your hand install. The
> way to get this cleaned up is to run "depmod -a", which will rebuild the
> appropriate modules.dep file. The init script I referred to above -- I
> checked and it is /etc/init.d/modutils -- is supposed to do this for you
> during init.

The only modprobing I did was for NIC modules - this because I had no 'net
connection when the machine booted up (that holds for all 3 kernels I
tried booting with: 2.4.22; 2.6.5 and 2.6.6). Once I modprobed the
modules I had identified (with the help of Knoppix) as being associated
with my NIC and issued ifup -a, I got an IP offer from my DHCP server and
was online. There were some entries in the resulting text that I had
never seen before (reference to "sit0") so I'll append that below.
Anyway, I've just tried tried depmod -a and then rebooted the machine but
the NIC modules still seem not to get auto-loaded on boot: I have no 'net
connection when the system finishes booting. Previously (previous to the
dist-upgrade I did a couple of days ago) when I would boot the machine the
NIC was brought up during boot, despite the fact that no entries in
/etc/modules were specifying NIC modules at that time. So, I understand
that I can probably get those modules to load by adding them to
/etc/modules, but it seems to me better to try and determine why they were
"autoloading" before, but are not now. Think I should add those modules
to /etc/modules anyway?

I apologize if this is not as coherent as you'd like. I do not fully
understand how the system works and thus what the problem could be - which
is why I'm asking for help here. Any incoherency has probably much to do
with my poor understanding of the matters with which I'm dealing. I'm
sorry, but I just can't change that overnight.

James

----------BEGIN IFUP -A OUTPUT----------------------------------------
[09:20:59]root@computer$ modprobe 8139too
[09:21:10]root@computer$ modprobe mii
[09:21:17]root@computer$ modprobe crc32
[09:21:27]root@computer$ ifup -a
ifup: interface lo already configured
Internet Software Consortium DHCP Client 2.0pl5
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.

Please contribute if you find this software useful.
For info, please visit http://www.isc.org/dhcp-contrib.html

sit0: unknown hardware address type 776
sit0: unknown hardware address type 776
Listening on LPF/eth0/00:e0:4c:82:a1:53
Sending on LPF/eth0/00:e0:4c:82:a1:53
Sending on Socket/fallback/fallback-net
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 192.168.1.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound to 192.168.1.13 -- renewal in 302400 seconds.
----------------END IFUP -A OUTPUT--------------------------------
-
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: net (& module, I guess) problems after dist-upgrade

Replies interspersed.

If there are any other Debian users on this list, especially ones who use
pre-compiled kernels (kernel-image-* packages), their help at this point
would be ... well, helpful.

At 10:01 AM 6/14/2004 -0500, James Miller wrote:
>On Sat, 12 Jun 2004, Ray Olszewski wrote:
>
> > At 05:36 PM 6/12/2004 -0500, James Miller wrote:
> > >Well, I took your advice and dist-upgraded Ray. Now I know why I was not
> > >very anxious to do it :). A problem occured with kernel modules during
> > >the dist-upgrade.
> >
> > OK. This general description is pretty hard to follow. I imagine you were
> > pretty upset when you wrote it. If you want help with the general problem
> > you experienced, you'll need to repost a more exact description.
>
>I dunno about upset, but tech burnout maybe? Well, let me try to add a
>few things, even though I don't make any claims to exactness with it.

My reading your prior report as written while you were upset stemmed from
two things.

First, it was a single long, hard-to-parse paragraph. Not your usual style
(or I thought not so). Since the following paragraph is also long and hard
(for me, at least) to read, I may just have misremembered your writing style.

Second, it included a lot of "something like" references to things. You've
posted here often enough to know that descriptions that imprecise are
unlikely to elicit good advice.

So I inferred that you were largely expressing frustration ...
understandable given the difficulties you are encountering, but nonetheless
needing a followup with better reporting.

>This dist-upgrade involved installing a new kernel, as you may recall.
>With the new kernel come new modules, right? Beyond this, I'd have to
>just guess how things work, but my guess is that the system needs to be
>told or figure out somehow which of the new modules the system is using so
>that these can be loaded when the machine boots with the new kernel too.
>Doesn't this make some sense (bearing in mind that not everything that
>makes sense is always true, of course)?

Yes.

>That's sort of a deduction from
>the error message I got during the dist-upgrade (you get various dialogues
>asking you questions and sometimes informational or error messages from
>apt, as you surely know, right?) involving kernel modules and the little
>bit I know about the way the Linux system operates.

You saw this message. I did not, and you didn't describe it in enough
detail to let be guess what it said.

>Somehow a
>configuration involving kernel modules couldn't complete during
>dist-upgrade, and I was warned I'd need to reboot for it to complete. I
>didn't write anything down, so I'm recalling this from memory.

But you're not recalling enough. Perhaps if you did a "dpkg-reconfigure"
for the relevant package, it would either fix the problem or at least
display the error again, so you could write it down.

>But maybe
>there's some sort of hardware autodetection that's supposed to take care
>of this module configuration?

Dream on. Among the big-name Linux distros, Debian is absolutely the worst
about autodetect. It has no real autodetect capability. all I can be in
that regard is the bearer of bad news.

>How 'bout some help here, Ray? I honestly
>don't know how this all works: too many possibilities for my rather
>unlearned mind to work it out. I'm hoping that, based on the sketchy
>information I can give, someone with a much better understanding of these
>matters is going to be able to spot some problem, or potential problem,
>and be able to make some suggestions.

I hope so too. But that someone isn't me ... I can help you interpret the
error messages youget, but only if I get to see them, not "something like"
them. Possibly someone who has more experience with pre-compile Debian
kernels can spot your problem at a glance, and I hope such a person jumps
into this thread.

In the meantime, I'm trying to give the more limited help I can offer.
Remember that the only situations in which I actually use stock kernels is
right after an install. At that point, if I'm using a NIC that requires one
or more modules (I usually avoid this), I see that the installer *has* put
the names of any needed modules in /etc/modules .

So ...

Is it possible that your kernel upgrade overwrote an /etc/modules file?
(Are there other entries in the file, ones that you added by hand?)

Is it possible that 2.6.x kernels do module loading in some different way
(you won't know this, but someone else on the list might)?

Is it possible that stock kernels use initrd in some way that hides NIC
module loading in the initrd image? (What does /etc/lilo.conf say about
initrd?)

>This much does seem clear to me:
>there was an error message involving kernel modules during dist-upgrade,
>and upon rebooting (the initial boot with the new kernel failed owing to a
>minor error I put in lilo.conf), sure enough, some important modules are
>not getting loaded (e.g., my NIC module[s]). Does that additional
>information help? Please feel free to ask further questions: I really am
>not certain exactly what information is needed since I poorly understand
>the problem. I'm taking a sort of "scatter gun approach" and recounting
>everything, in broad terms, that seems relevant to me.
>
> > But the immediate problem is getting the NIC module(s) to load during
> > boot/init . To accomplish that, add the name(s) of the module(s) to
> > /etc/modules . One of the init scripts (I forget which one) will modprobe
> > every module in /etc/modules, in the order in which they appear there.
>
>I do know about /etc/modules and have added things there before. However
>there is currently no module for my NIC indicated there, and there never
>has been. Yet somehow previously that NIC module(s) was getting loaded.
>This suggests to me that there is some other problem: something got
>changed that used to load the NIC modules by, apparently, some other means
>than /etc/modules. Shouldn't I be trying to restore whatever got changed?

Of course you should. But wouldn't you prefer to have a working system in
the meantime? This suggestion is a quick fix, intended to keep things
working until you solve the underlying problem.

The problem I have here, trying to give you advice, is that I have no
experience doing what you do ... that is, using stock kernels. After the
initial install of the kernel from the install disks, I *always* compile my
own kernel. So I've spent no time figuring out how Debian stock kernels
handle modules.

The solution, for **example**, may be buried in how stock kernels use the
initrd mechanism (something my custom kernels don't do at all). On this
score, your passing reference to making, then fixing a lilo error gets my
attention ... might you have bypassed the initrd mechanism when you "fixed"
lilo.conf? Just a wild guess, though.

On top of that, you've never even mentioned what NIC and what (until you
provided the output below) what modules are involved. So I didn't know if
multiple dependencies might be an issue (they don't appear to be ... though
the relevant -- NIC-related -- output of "ifconfig -a" and "lspci" would
make me more confident of that call).

Until someone come along who has relevant experience, the solution I've
suggested will serve as a temporary workaround.

BTW, I don't recognize "sit0" either, but from the output you posted, it
does not appear relevant to your immediate problem. If you are curious
about it, see what "ifconfig -a" tells you about it.


> > The problem you are encountering **may** be an outdated or incomplete
> > listing of module dependencies. If you modprobe'd each invidivually and in
> > the right order, you simply bypassed this problem in your hand install. The
> > way to get this cleaned up is to run "depmod -a", which will rebuild the
> > appropriate modules.dep file. The init script I referred to above -- I
> > checked and it is /etc/init.d/modutils -- is supposed to do this for you
> > during init.
>
>The only modprobing I did was for NIC modules - this because I had no 'net
>connection when the machine booted up (that holds for all 3 kernels I
>tried booting with: 2.4.22; 2.6.5 and 2.6.6).

Oh. I thought you'd said before that 2.4.22 still worked properly. I
misunderstood, I guess. If you are completely certain that /etc/modules
never included the names of the NIC modules, then I'd definitely suggest
reviewing /etc/lilo.conf to see if you introduced an initrd problem.

>Once I modprobed the
>modules I had identified (with the help of Knoppix) as being associated
>with my NIC and issued ifup -a, I got an IP offer from my DHCP server and
>was online. There were some entries in the resulting text that I had
>never seen before (reference to "sit0") so I'll append that below.
>Anyway, I've just tried tried depmod -a and then rebooted the machine but
>the NIC modules still seem not to get auto-loaded on boot: I have no 'net
>connection when the system finishes booting. Previously (previous to the
>dist-upgrade I did a couple of days ago) when I would boot the machine the
>NIC was brought up during boot, despite the fact that no entries in
>/etc/modules were specifying NIC modules at that time. So, I understand
>that I can probably get those modules to load by adding them to
>/etc/modules, but it seems to me better to try and determine why they were
>"autoloading" before, but are not now. Think I should add those modules
>to /etc/modules anyway?

Yes. See above.


>I apologize if this is not as coherent as you'd like. I do not fully
>understand how the system works and thus what the problem could be - which
>is why I'm asking for help here. Any incoherency has probably much to do
>with my poor understanding of the matters with which I'm dealing. I'm
>sorry, but I just can't change that overnight.

Bottom line: I think you need help from someone who routinely uses
pre-compiled Debian kernels. I hope there is someone like that on this
list, someone who will jump in now and fill the gaps I've left in my advice.


>James
>
>----------BEGIN IFUP -A OUTPUT----------------------------------------
>[09:20:59]root@computer$ modprobe 8139too
>[09:21:10]root@computer$ modprobe mii
>[09:21:17]root@computer$ modprobe crc32
>[09:21:27]root@computer$ ifup -a
>ifup: interface lo already configured
>Internet Software Consortium DHCP Client 2.0pl5
>Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
>All rights reserved.
>
>Please contribute if you find this software useful.
>For info, please visit http://www.isc.org/dhcp-contrib.html
>
>sit0: unknown hardware address type 776
>sit0: unknown hardware address type 776
>Listening on LPF/eth0/00:e0:4c:82:a1:53
>Sending on LPF/eth0/00:e0:4c:82:a1:53
>Sending on Socket/fallback/fallback-net
>DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
>DHCPOFFER from 192.168.1.1
>DHCPREQUEST on eth0 to 255.255.255.255 port 67
>DHCPACK from 192.168.1.1
>bound to 192.168.1.13 -- renewal in 302400 seconds.
>----------------END IFUP -A OUTPUT--------------------------------





-
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: net (& module, I guess) problems after dist-upgrade

Thanks for the input, Ray. Unfortunately, I don't have any very clear
recollection of specifics of that error message, other than it telling me
there was some sort of problem setting up modules since modules were in
use by the current kernel, and giving a very stern warning about the need
to reboot to finish this process once the dist-upgrade was finished.
Maybe I should note that the dist-upgrade seemed to be reinstalling the
version of the kernel I was running at the time (2.6.5) - I'm at a loss as
to why that would be. In any case, I've got a way to at least get
networking going, which is the most important thing I do involving modules
at the moment. So, I'll just sort of limp along with that and try to
figure out what to do next. More, undoubtedly, later.

James

-
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: net (& module, I guess) problems after dist-upgrade

On Mon, 14 Jun 2004, James Miller wrote:

> Thanks for the input, Ray. Unfortunately, I don't have any very clear
> recollection of specifics of that error message, other than it telling me
> there was some sort of problem setting up modules since modules were in
> use by the current kernel, and giving a very stern warning about the need
> to reboot to finish this process once the dist-upgrade was finished.

Ok. By running dpkg-reconfigure -all (my usual brute-force approach), I
was able to recreate the message. Here it is:

You are attempting to install a kernel version that is the same as
the version you are currently running (version 2.6.6-1-686). The modules
list is quite likely to have been changed, and the modules dependency
file /lib/modules/2.6.6-1-686/modules.dep needs to be re-built. It can
not be built correctly right now, since the module list for the
running kernel are likely to be different from the kernel installed.
I am creating a new modules.dep file, but that may not be
correct. It shall be regenerated correctly at next reboot.

I repeat: you have to reboot in order for the modules file to be
created correctly. Until you reboot, it may be impossible to load
some modules. Reboot as soon as this install is finished (Do not
reboot right now, since you may not be able to boot back up until
installation is over, but boot immediately after). I can not stress
that too much. You need to reboot soon.

Please Hit return to continue.

Not touching initrd symlinks since we are being reinstalled (2.6.6-1)
Not updating image symbolic links since we are being updated (2.6.6-1)
A new kernel image has been installed, and usually that means
that some action has to be taken to make sure that the new
kernel image is used next time the machine boots. Usually,
this entails running a ``bootloader'' like SILO, loadlin, LILO,
ELILO, QUIK, VMELILO, ZIPL, or booting from a floppy. (Some
boot loader, like grub, for example, do not need to be run on
each new image install, so please ignore this if you are using
such a boot loader).

A new kernel image has been installed at /boot/vmlinuz-2.6.6-1-686
(Size: 1103kB)

Does that help figuring out where the problem could be? Btw, I have yet
to reboot the system after running dpkg-reconfigure --all to see if I've
resolved anything by that process.

James
-
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: net (& module, I guess) problems after dist-upgrade

At 01:06 PM 6/14/2004 -0500, James Miller wrote:
>On Mon, 14 Jun 2004, James Miller wrote:
>
> > Thanks for the input, Ray. Unfortunately, I don't have any very clear
> > recollection of specifics of that error message, other than it telling me
> > there was some sort of problem setting up modules since modules were in
> > use by the current kernel, and giving a very stern warning about the need
> > to reboot to finish this process once the dist-upgrade was finished.
>
>Ok. By running dpkg-reconfigure -all (my usual brute-force approach), I
>was able to recreate the message. Here it is:
>
> You are attempting to install a kernel version that is the same as
> the version you are currently running (version 2.6.6-1-686). The modules
> list is quite likely to have been changed, and the modules dependency
> file /lib/modules/2.6.6-1-686/modules.dep needs to be re-built. It can
> not be built correctly right now, since the module list for the
> running kernel are likely to be different from the kernel installed.
> I am creating a new modules.dep file, but that may not be
> correct. It shall be regenerated correctly at next reboot.
>
> I repeat: you have to reboot in order for the modules file to be
> created correctly. Until you reboot, it may be impossible to load
> some modules. Reboot as soon as this install is finished (Do not
> reboot right now, since you may not be able to boot back up until
> installation is over, but boot immediately after). I can not stress
> that too much. You need to reboot soon.
>
>Please Hit return to continue.

This is a wordy way of telling you that you should run depmod. The modutils
init script is supposed to do this for you, but it may interact with initrd
in funny ways. So to be safe, do this (following the dpkg-reconfigure):

1. Reboot the system.
2. Log in as root and run "depmod -a".
3. Reboot the system.

This may not fix your modules problem. But it will fix the problem that
this message is warning you about.

>Not touching initrd symlinks since we are being reinstalled (2.6.6-1)
>Not updating image symbolic links since we are being updated (2.6.6-1)

Since I don't use initrd here, I can't tell you what (if anything) to do
about this. But it does reinforce my concern that your problem has
something to do with the initrd step in kernel loading.

If you post again, please provide next time to lilo.conf stanzas for the
current kernel and for 2.4.24.

BTW, I read through the man page for initrd, and from what is there, I
would expect linuxrc to use /etc/modules as its information source about
what modules to load. I could easily be wrong here, though ... the man page
*really* is unclear about where linuxrc (part of initrd) gets module
information from.

>A new kernel image has been installed, and usually that means
>that some action has to be taken to make sure that the new
>kernel image is used next time the machine boots. Usually,
>this entails running a ``bootloader'' like SILO, loadlin, LILO,
>ELILO, QUIK, VMELILO, ZIPL, or booting from a floppy. (Some
>boot loader, like grub, for example, do not need to be run on
>each new image install, so please ignore this if you are using
>such a boot loader).
>
>A new kernel image has been installed at /boot/vmlinuz-2.6.6-1-686
> (Size: 1103kB)
>
>Does that help figuring out where the problem could be? Btw, I have yet
>to reboot the system after running dpkg-reconfigure --all to see if I've
>resolved anything by that process.
>
>James




-
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: net (& module, I guess) problems after dist-upgrade

On Mon, 14 Jun 2004, Ray Olszewski wrote:

> This is a wordy way of telling you that you should run depmod. The modutils
> init script is supposed to do this for you, but it may interact with initrd
> in funny ways. So to be safe, do this (following the dpkg-reconfigure):
>
> 1. Reboot the system.
> 2. Log in as root and run "depmod -a".
> 3. Reboot the system.
>
> This may not fix your modules problem. But it will fix the problem that
> this message is warning you about.

Ok. I did that once before but I'll do it again right after I send off
this email (I've just done depmod -a - no error output - so all that
remains is to reboot).

> >Not touching initrd symlinks since we are being reinstalled (2.6.6-1)
> >Not updating image symbolic links since we are being updated (2.6.6-1)
>
> Since I don't use initrd here, I can't tell you what (if anything) to do
> about this. But it does reinforce my concern that your problem has
> something to do with the initrd step in kernel loading.
>
> If you post again, please provide next time to lilo.conf stanzas for the
> current kernel and for 2.4.24.

Sorry that I didn't note that I was not giving all output for all kernels
installed on this system. I don't even have an item in my boot menu for
the 2.4.24 kernel, and plan on removing it soon (have been planning on it,
but have procrastinated).

cat /etc/lilo.conf
vga=791
boot=/dev/hda
root=/dev/hda1
install=/boot/boot.b
map=/boot/map
delay=20
default=Linux2-6

image=/vmlinuz.2-6
label=Linux2-6
initrd=/initrd.img.2-6

image=/vmlinuz.2-4
label=Linux2-4
initrd=/initrd.img.2-4

image=/vmlinuz.2-4-22
label=Linux2-4-22
initrd=/initrd.img.2-4-22

image=/vmlinuz.2-6-5
label=Linux2-6-5
initrd=/initrd.img.2-6-5

That's the entire file, btw. initrd.img.2-6 is a symlink to
/boot/initrd.img-2.6.6-1-686;
initrd.img.2-4 is a symlink to /boot/initrd.img-2.4.26-1-686;
initrd.img.2-4-22 is a symlink to /boot/initrd.img-2.4.22-1-686;
initrd.img.2-6-5 is a symlink to /boot/initrd.img-2.6.5-1-686. The
various vmlinuz'es are similarly symlinked. It's horribly complex and
error-inviting, I know. I do plan on deleting some of those kernels once
I get things (should I say *if* I get things?) working as they should.

My initial lilo.conf error - in case it's relevant - was pointing the new
kernel (2.6.6) at the 2.6.5 initrd.img. I got a blank screen and system
freeze on trying to boot under that setup. I booted the 2.6.5 kernel
using its own lilo menu item after that and straightened out the error.
Running lilo from the command prompt now does not generate any errors.

Here I go for another reboot . . .

James
-
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: net (& module, I guess) problems after dist-upgrade

On Monday 14 June 2004 20:50, Ray Olszewski wrote:
> BTW, I read through the man page for initrd, and from what is there, I
> would expect linuxrc to use /etc/modules as its information source about
> what modules to load. I could easily be wrong here, though ... the man page
> *really* is unclear about where linuxrc (part of initrd) gets module
> information from.

I dont want to sound like a wet rag but, why would one even try to install the
same kernel version?, why use initrd, simply compile ones own kernel using
the default config file supplied by your distro, (normally found in /boot) on
most systems thesedays.
The trick here is to edit the top dir Makefile and define another
"EXTRAVERSION" then all modules go into another directory under /lib/modules/
leaving the old kernel and its modules intacht and allowing you to use it to
boot if the new kernel fails.

I am not bashing at distro's other than slackware (of which i swear by), i
also have redhat and suse running here, slackware is very basic and IMHO
never gets one into such a state that i have read about here.

Rpm's, aptgets are all well and dandy, they are there for ones easyness,
however reading thro' most debian and suse mailing lists the truth is far
from it.

Slackware and simple tar files IMHO the easiest.

Once again i mean no offence with what i say, its just 12+ years of slackware
experiance and 6 years of using other systems like Redhat and suse give me
that impression.

--
If the Linux community is a bunch of thieves because they
try to imitate windows programs, then the Windows community
is built on organized crime.

Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/


-
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: net (& module, I guess) problems after dist-upgrade

On Mon, 14 Jun 2004, James Miller wrote:

> On Mon, 14 Jun 2004, Ray Olszewski wrote:
>
> > This is a wordy way of telling you that you should run depmod. The modutils
> > init script is supposed to do this for you, but it may interact with initrd
> > in funny ways. So to be safe, do this (following the dpkg-reconfigure):
> >
> > 1. Reboot the system.
> > 2. Log in as root and run "depmod -a".
> > 3. Reboot the system.
> >
> > This may not fix your modules problem. But it will fix the problem that
> > this message is warning you about.
>
> Ok. I did that once before but I'll do it again right after I send off
> this email (I've just done depmod -a - no error output - so all that
> remains is to reboot).

Well, I'm sorry to say that running depmod -a after dpkg-reconfigure --all
didn't get those NIC modules auto-loading like they used to (still loading
them by hand using modprobe, though I do realize adding them to
/etc/modules is another solution).

There are some missing parts to this puzzle, and I can't conjecture what
they would be. My assumption is that the kernel modules error message I
got is somehow related - which seems logical. But I suppose the
possibility exists that something else has gone awry with the dist-upgrade
(as, they say, is wont to happen with Sid). I suppose I may have to pose
some queries on a Debian list and find out if others have had such
problems with this kernel, or with recent Sid dist-upgrades. Perhaps
another option would be to apt-get remove the new kernel and apt-get
install it again.

Meantime, the one other thing that differs between the 2.6.5 and 2.6.6
kernels that I've noted is this sit0 thing. I definitely did not see that
before. I don't know how or if it could be related in any way. But, here
is some ifconfig output related to it, in case this may ring any bels for
anyone:

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Puzzled, James
-
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