[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 2.6.8.1-kernel on Powerbook G4?



On Wed, Aug 25, 2004 at 02:05:22AM +0200, Timo Reimerdes wrote:
| On Di, 2004-08-24 at 16:12 -0400, Derrick 'dman' Hudson wrote:
| > 
| > | Problems I have:
| > | * no working console on local login: "respawning too fast issue"
| 
| > I saw this issue on a couple machines (x86) while I was tinkering with
| > them.  It was a little bit frustrating for me because the problem ws
| > "intermittent".  I eventually figured it out.  Sometimes on that
| > little 486 I would disable devfsd (this was before udev was available)
| > because cups would take forever to start because devfsd would fork an
| > excessive number of modprobe processes.  Then I couldn't get a local
| > login because /dev/tty1 (etc.) didn't exist.  When devfsd was running,
| > however, /dev/tty1 was a symlink to /dev/vc/1 and getty would open the
| > console.  Could this be the cause of your problem?  Make sure the
| > device specified in /etc/inittab exists.
| > For example, this line tells getty to use /dev/tty1
| >     1:2345:respawn:/sbin/getty 38400 tty1 -f /etc/issue.linuxlogo
| > Likewise, this line says to use /dev/vc/1
| >     1:2345:respawn:/sbin/getty 38400 vc/1 -f /etc/issue.linuxlogo
| > (you probably won't have the '-f /etc/issue.linuxlogo' in your
| > inittab)
| 
| Thx a lot for this answer.

You're welcome, and I'm glad it solved the problem.

| It got me thinking - could it help to add
| lines like:
| L tty1  /dev/vc/1
| L tty2  /dev/vc/2
| L tty3  /dev/vc/3
| L tty4  /dev/vc/4
| L tty5  /dev/vc/5
| L tty6  /dev/vc/6
| to the /etc/udev/links.conf?

I would say that is not the best solution.  I am under the impression
that the debian maintainer added links.conf to udev as an interim
workaround for certain limitations in certain versions of udev and the
kernel.  (for example, earlier 2.6 kernels didn't have any sysfs info
for the framebuffer and some other devices like that needed this
"hard-coded" information)

The better approach, IMO, is to create the apropriate udev rules so
the files/links are created automatically (instead of statically
through links.conf) or to adjust the inittab to look for the
devfs-style name.

What version of udev are you using?  At some point the directory
/etc/udev/rules.d was introduced as a way to specify which rules you
want udev to apply.  By default it contains a symlink to
/etc/udev/udev.rules which is a set of rules creating traditional
names.  On my systems, since I had used devfs for quite some time, I
remove that link and instead put symlinks to /etc/udev/devfs.rules and
/etc/udev/compat-full.rules.  The former gives devfs-style names, and
the latter creates the "comaptibility" symlinks like devfsd used to
do.

I also changed my inittab to have the following section:
    1:2345:respawn:/sbin/getty 38400 tty1 -f /etc/issue.linuxlogo
    2:23:respawn:/sbin/getty 38400 tty2 -f /etc/issue.linuxlogo
    3:23:respawn:/sbin/getty 38400 tty3 -f /etc/issue.linuxlogo
    4:23:respawn:/sbin/getty 38400 vc/4
    5:23:respawn:/sbin/getty 38400 vc/5
    6:23:respawn:/sbin/getty 38400 tty6

With some gettys using the traditional name and some using the
devfs-style name I will have at least one console functioning
regardless of what sort of /dev configuration I boot with.  (basically
this is just a safety net in case somehow I boot and the symlinks
aren't there or something)

| Or would I break my system that way?

No, I don't think there is any potential harm in adding those lines.

| Not having that wonderfull feature of a non-x-login is getting me a
| little nervous everytime I update anything. ;)

:-)


HTH,
-D

-- 
The heart is deceitful above all things
    and beyond cure.
    Who can understand it?
 
I the Lord search the heart
    and examine the mind,
to reward a man according to his conduct,
    according to what his deeds deserve.
 
        Jeremiah 17:9-10
 
www: http://dman13.dyndns.org/~dman/            jabber: dman@dman13.dyndns.org

Attachment: signature.asc
Description: Digital signature


Reply to: