> Hi everybody, > > I am trying to install Debian on my noname laptop. > > Everything works fine until I reach the "reboot section" of > the installation process. > > I reboot the system from disk and from lilo to uncompresssing the kernel > everything works fine. the filesystems are mounted, a few demons > are started... and so on... > > After run level 2 is reached, the boot process gets > trapped at the moment where the inetd should be started. > nothing works from then on. even ctrl-alt-del gets no response.
Is xfm, gdm, kdm or anything else ending in "dm" somewhere in your init sequence? That would cause an automatic attempt to launch X (which steals the console) and if X isn't setup right at that point, you'd be screwed :( Luckily you can boot singleuser (type 'linux single' with no quotes at the LILO: prompt) and the rc scripts won't run the normal runlevel stuff. Then you can see what it had in mind, or even just run the parts one at a time until you crash it. > I have an internal modem, but I haven't configured a driver module for it. > The network is not configured. All I did was specifying a hostname. > I assume, that thus the internal modem should not pose any problem to the > kernel. The kernel just simply doesn't "know" it, right? devices which are *not* configured rarely cause anything... an attempt to modprobe for a particular thing, might cause it to probe I/O addresses it thinks that thing would use. though. Such probing sometimes causes the offended thing to fail or freak out. But it's rare - kernel hackers don't like to be told their module crashes things. X is often allergic to hostname mismatches, at least, to the order of making things a little slow to get started. Make sure your new hostname is mentioned in /etc/hosts (I like to tell it that it matches 127.0.0.2 just so it doesn't confuse with localhost - and so I can easily change it when I link up to a real network). > Is anybody of you familiar with this problem? > > One workaround could be to open a second shell from the rescue system > and to remove the starting of the inetd-demon from the rc scripts, > but I consider this to be the last resort. I want the demon to be running, > because I want to reach localhost:80, for example. The problem you describe is extremely unlikely to be inetd itself. It isn't terribly likely to be the web daemon either. Note, most web daemons (port 80 traffic) don't run out of inetd. ftp often does. ssh might or might not. > Any kind of help or advice is deeply appreciated! :-) > Bye, > Stefan Best of luck, hope the above is useful. * Heather Stern * star@ many places...
