Hi all,

When I start up Slackware (runlevel 3), I receive this error while booting the kernel: After some searching on this forum, about the only matching article says me something about uncommenting ttys0 in /etc/inittab...which is simply not there at all...

Background info:
I run Slackware 10.2 and boot the sata.i kernel file. I just installed it, and was able to boot the system twice, or maybe three times (before this error turned up) without any problems.
I've set up a dual boot in my boot.ini file, using the 512 bytes bootsector for Linux booting. I already updated the bootsect.lnx boot file in my C:\ after the problem occured, but it does not seem to help.The last thing I did before rebooting (to lookup my hostname etc in Windows) was running netconfig.

Please help,
Pazkaw.

By the way, I'm running a 2.4.x kernel on an AMD 64 PC... is this kernel not compatible yet and do I have to do some magic kernel-update immediately after booting for the first time after installation, before it crashes? :-P ...Dunno, just an idea...at least it'd be a nice trick, but will it help?

Though, I think it's got something to do with either alsaconfig or netconfig: I just reinstalled Slackware etc., and rebooted each time after having made a modification. It crashed after running the alsaconfig and netconfig.

I might also be able to recover some log files, using Knoppix. Just ask for the ones you might need...

Thanks for the amazing amount of replies! You guys are great!

...Fortunately, I managed to fix it myself. Minor error, though. Since nobody was interested in this threath anyway, I don't really have any idea why I should post the solution either.
Though, for those interested and might ever pass by having the same problem, just chmod the /dev/console file to rw for all users; for some strange kind of reason one or another config tool f*cked it up and made it rw only for root, causing it not to start properly at boot time.

Cheers,
Pazkaw

I'm glad it's working for you - Googling for me only produced more people with the same problem you were having. I'd be interested to hear if the problem happens again as my /dev/console is

crw------- 1 root tty 5, 1 2005-12-24 18:56 /dev/console

and I don't get any errors...

Hmmm very weird it only worked for me after chmod'ing indeed... but I'm glad it's working now though. My previous PC and my other PC, which both had/have Slackware installed, don't show any no similar problems either.

When I googled for the problem it only spitted out useless solutions (at least, they didn't work for me), and - just like you said - people with the same problem. Weird, there are not many threads and solutions to this problem. I think it probably all remains a mystery!

Could you please post the solution. I've suddently run into this error too. I'm running Slackware 10.2 as well.

Thanks,
Patrick

My console entry looks like this:

crw------- 1 root tty 5, 1 2006-01-17 08:51 /dev/console

pazkaw wrote
he typed something like "chmod 777 /dev/console" and it fixed his problem

I have run into this as well. Seemingly after the recent upgrade to -current.

steve@peggyo:/dev$ ls -la console
crwx------ 1 root tty 5, 1 2006-01-23 16:26 console
steve@peggyo:/dev$

Mine hung at boot then went on to continue loading. Perhaps thats why mine is executable? I'm not certain I like the chmod 777 option. Might be a security risk, though I don't know this for certain.

Edit: Now I can't reproduce the error. Oh well.

My linux system hung for about 5 seconds as well when opening the console. But suddently it just stopped happening one day and now appears to boot correctly. I hope it doesn't come back!

I understand you came here looking for help and were disappointed by the response, but comments like this aren't helpful. If no one volunteered a solution, it's probably because they don't have one. It isn't personal. Having encountered this issue myself tonight and havin read this thread (and Google) it's obvious to me that this is an unusual error which doesn't seem to have a clear solution.


You should post the solution because this is a forum where people come to help each other. There are plenty of bad forums out there which offer a lot in the way of flaming and whining, but very few left which are actual communities of people wanting to help each other. Information wants to be free..yes, I'm sure I've heard that somewhere.

By posting your solution you've started a thread (a conversation, if you will) which people have added to and will probably continue to add to. Hopefully the people participating will eventually nail down the cause of this error and the proper solution and then, six months from now when some newb stumbles in completely lost, he'll have our collected experience to learn from instead of having to wade through a voluminous, but not quite relevant stack of Google search results.

Sorry if it sounds like I am chastising you..I'm not. It's just that we all need to be reminded every once in a while that for a forum like this to be useful, we need to contribute when we can. Based on your number of posts, I'm assuming you've been helped by this forum a couple of times, at least. As have I. But for as many times as I've been helped, there has been just as many times when I find a post describing the same problem I've got and with it a response offering a solution, and no reply post saying if it worked or not. That is very frustrating, as I am sure you would agree. Now just imagine if everyone who came here came looking for help, but none of them were willing to give it. This forum wouldn't be worth a damn.

<steps down off of soapbox>

I found that running chmod 700 on /dev/console took care of the issue for me. Like another poster, chmod 777 makes me nervous for anything that is system related.

Hi all.

Sorry about taking this one up again. I'm having exactly the same problem, and this is not the first time I've tried it. I tried chmod'ing /dev/console to 700 and when that didn't work, I even tried to chmod it to 777. This did not help either. Any other suggestions please? I'm awfully tired of reinstalling my system when this error occurs (which is quite often actually).

BTW, I'm running Slackware 11 on top of an VMware ESX 3.0.1 as well as directly the hardware on several different machines.

Kind regards

Use 755 for the most permissive quasi-safe permissions. That should be ok, but I'm not sure what an abuser could be able to do with a console that is +rx, but not +w.

The real mode for /dev/console is:

Character device with permissions: 600

mknod -m 600 /tmp/contest c 5 1

# ls -alsF /dev/console
0 crw------- 1 root root 5, 1 Mar 25 14:27 /dev/console

# ls -alsF /dev/contest
0 crw------- 1 root root 5, 1 Mar 25 14:42 /tmp/contest

About not giving answers to people who ask them, or saying RTFM or being a general ass, I agree, there is no reason to be this way, its better to just keep quiet than to bother writing stupid non-helpful stuff. I find the lack of documentation, from Solaris, to FreeBSD, to the Linuxes, to be the main reason people ask questions. The man and info pages are generally devoid of useful examples, and a lot of useful text and X config tools are underpowered for the task.

Just the other day I was on Solaris 10 switching from DHCP mode to static ip and it took a long, long long time for me to find that /etc/nodename needed to be set, but nowhere on Google or otherwise could I find a document to clearly make a checklist for doing this.

Its not RTFM, etc, it was brutal trial and error and combing through bigadmin and man pages to simply come up with:


Solaris networking checklists:

Solaris 11 - take off autoconfig on physical instance.
(svcadm)

/etc/nodename (must be set to set hostname)
/etc/ethers (specify main mac address here to bind to name)
/etc/nsswitch.conf
/etc/resolv.conf

/etc/hostname.e1000g0 (hostname.ifconfigname)
(to disable DHCP, make sure /etc/nodename is set, and hostname.ifname exists, and remove all dhcp.ifnames)

/etc/defaultrouter

/etc/dhcp/ should only have inittab and inittab6, nothing else.

/etc/inet/hosts -> /etc/hosts

sample:
#
# Internet host table
#
::1 localhost localhost.localdomain
127.0.0.1 localhost localhost.localdomain
10.7.1.15 solstage solstage.localdomain loghost loghost.localdomain

/etc/inet/netmasks -> /etc/netmasks
(sample /etc/netmasks)
10.5.0.0 255.255.0.0

/etc/inet/ipnodes should point to /etc/inet/hosts



So again, I agree people should be less hostile in both directions, but I know where the snarky attitudes come from those who ask questions, its an expectation that non-helpful replies will be given and then on top of the RTFM-like troll, it becomes apparent that most people who try to make someone else look and feel stupid couldn't even solve the problem if they tried themselves.

I feel all RTFM and snide snarky comments should contain the answer below. If you can't answer it, then shut your trap. You get no glory from calling someone an idiot if you can't show them how they are being an idiot.

Things to try:
1)

Try to chroot into the system with a live cd, or pre-create the device node on the /dev/ directory of the system that is having issues.

Live CD and create /dev/console:

mknod /dev/console c 5 1
or
mknod -m 600 /dev/console c 5 1

(the most explicit)

2) Realize that it is possible to make these in an initial ramdisk (initrd), try making sure you have an initrd for the kernel and make sure it works with that initrd and that the initrd can be mounted (create the mountpoint for initrd).

Note: non-udev /dev/console and /dev/null must exist before udev starts.

3) Make sure your init process is 'real', I've encountered one rooted box where the init process itself was re-written due to a rootkit, but was faulty. I generally would use Knoppix LIVECD and scan for stuff with clam and a detect rootkit utility.

4) Explore your initrd, and example is as follows:

"file" your current initrd, eg:

file initrd-2.6.18-53.1.14.el5.img
initrd-2.6.18-53.1.14.el5.img: gzip compressed data, from Unix, last modified: Sat Mar 22 22:10:30 2008, max compression

If its compressed, move a copy of that initrd off somewhere, and rename it initrd-2.6.18-53.1.14.el5.img to initrd-2.6.18-53.1.14.el5.img.gz

Decompress it:

gzip -d initrd-2.6.18-53.1.14.el5.img.gz

Then file it again, its often a cpio or other type of simple archive:
file initrd-2.6.18-53.1.14.el5.img
initrd-2.6.18-53.1.14.el5.img: ASCII cpio archive (SVR4 with no CRC)

Then decompress it:
mkdir initrd_out
cd initrd_out
cpio -cid -I ../initrd-2.6.18-53.1.14.el5.img

Now you get a simple set of files:
bin
dev
etc
init
lib
proc
sbin
sys
sysroot

In the init file youll see:

echo Creating initial device nodes
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/systty c 4 0
mknod /dev/tty c 5 0
mknod /dev/console c 5 1

These 5 are the minimum to get things going for things like udev or other /dev/ creation stuff.

This stuff is probably specific to things that use an nash script in the initrd, but you clearly see that very early on these devices must be created .

A lot of time you can simply mount initrds using loop , so check if they are compressed and mount them via:

mount -o loop /boot/initrd-not-compressed.img /mnt

This is nice because you can modify it on the fly without having to repack it.

5) udev and all these new fancy dynamic dev managers are not an excuse to delete all of /dev/ without the proper diaper that comes before udev.