Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-06 Thread Peter Humphrey
On Tuesday 06 January 2009 02:02:16 Francisco Ares wrote:

> This is a snippet of the end of the boot screen:
>
>  * Setting framebuffer console images ... [ ok ]
>  * Starting gpm ...   [ ok ]
>  * Setting up kdm ... [ ok ]
>  * Loading ALSA modules ...
>  *   Loading: snd-seq-oss ... [ ok ]
>  *   Loading: snd-pcm-oss ... [ ok ]
>  *   Restoring Mixer Levels ...   [ ok ]
>  * Starting
>  *   no interface module has been loaded

That looks suspicious to me. Init seems to be trying to run an (in effect) 
empty file in /etc/init.d/. What else have you got in there that doesn't 
belong? This is mine:

$ ls -w 76 /etc/init.d
acpiddbus  lm_sensors  numlock   spamd
alsasounddepscan.shlocal   pwcheck   sshd
bootmisc dnsextd   localmount  pydoc-2.4 syslog-ng
checkfs  fancontrolmdnsd   pydoc-2.5 udev-postmount
checkrootfunctions.sh  mDNSResponderPosix  reboot.sh urandom
chronyd  gkrellmd  modules rmnologin vixie-cron
clockgpm   net.eth0rsyncdxdm
consolefont  halt.sh   net.lo  runscript.sh
crypto-loop  hostname  netmountsaslauthd
cupsdkeymaps   nscdshutdown.sh

Four of those are soft links: depscan.sh, functions.sh, net.eth0 and 
runscript.sh, thus:

$ (cd /etc/init.d && ls -l depscan.sh functions.sh net.eth0 runscript.sh)
lrwxrwxrwx 1 [...] depscan.sh -> ../../sbin/depscan.sh
lrwxrwxrwx 1 [...] functions.sh -> ../../sbin/functions.sh
lrwxrwxrwx 1 [...] net.eth0 -> net.lo
lrwxrwxrwx 1 [...] runscript.sh -> ../../sbin/runscript.sh

Your script execution order doesn't look right to me. This is what happens 
on my system:

INIT: Entering runlevel: 3
 * Starting eth0
 *   Bringing up eth0
 * 192.168.2.6  [ ok ]
 *   Adding routes
 * default via 192.168.2.1 ...  [ ok ]
 * Mounting network filesystems ... [ ok ]
 * Setting up kdm ...   [ ok ]
 * Loading ALSA modules ...
 *   Loading: snd-pcm-oss ...   [ ok ]
 *   Loading: snd-seq-oss ...   [ ok ]
 * Restoring Mixer Levels ...   [ ok ]
 * Starting chronyd ... [ ok ]
 * Starting D-BUS system messagebus ... [ ok ]
 * Starting cupsd ...   [ ok ]
 * Loading lm_sensors modules...
 *   Loading i2c-nforce2 ...[ ok ]
 *   Loading adm1026 ...[ ok ]
 *   Loading w83627hf ...   [ ok ]
 *   Loading k8temp ... [ ok ]
 * Initializing sensors ... [ ok ]
 * Starting sshd ...[ ok ]
 * Starting vixie-cron ...  [ ok ]
 * Starting local ...   [ ok ]

(I don't run gpm if I'm starting X; I have a separate soft-level for console 
operation, and it does run there.)

Have you sync'd recently? Which profile did you install from? This is mine:

$ ls -l /etc/make.profile
lrwxrwxrwx 1 root root 50 2008-12-10 
11:24 /etc/make.profile -> ../usr/portage/profiles/default/linux/amd64/2008.0

You might like to look at these again, as they also affect the execution 
order:

$ grep PLUG /etc/conf.d/rc | grep -v \#
RC_HOTPLUG="yes"
RC_COLDPLUG="yes"
RC_PLUG_SERVICES="!*"

-- 
Rgds
Peter



Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Dirk Heinrichs
Am Dienstag, 6. Januar 2009 03:52:54 schrieb Francisco Ares:

> Tried to use net.eth2 in boot group: it works,

There's no need to do so, they belong into default.

> but I still have the init
> scripts frozen as X starts, up until I hit Ctrl-Alt-F1 and watch them go
> on.

What is the next service started after xdm? Maybe it's that one that has the 
problem.

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Dirk Heinrichs
Am Dienstag, 6. Januar 2009 03:55:30 schrieb Nick Cunningham:

> If thats xdm then ive no idea why its starting so early,

Because it's perfectly fine to do so. On my system, there are about 10 
services which are started _after_ xdm (kdm).

Bye...

Dirk


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Francisco Ares
On Tue, Jan 6, 2009 at 12:55 AM, Nick Cunningham wrote:

>
>> ...
>>
>
> Ok, that net.* error may mean you have some config in the wrong place (or a
> really old config file). Network configs for all interfaces should go in
> /etc/conf.d/net and then to ensure they get started you create a symlink
> from /etc/init.d/net.lo to /etc/init.d/net.eth2 (in your case). Unless your
> creating init files for whatever reason, you should never need to edit
> anything in /etc/init.d/.
>
> Im interested to see what "Setting up kdm ... " is, do you use KDE or
> GNOME? If thats xdm then ive no idea why its starting so early, and if it is
> xdm then thats your problem im guessing.
>
> BTW, if your thinking of moving to openrc, make sure you read the migration
> guide and follow it to the letter otherwise you risk being left with an
> unbootable system: http://www.gentoo.org/doc/en/openrc-migration.xml
>
> - Nick
>


Thanks a lot, Nick, I'll re-emerge xdm just to make sure.  But I'm also
having problems compiling kdebase, where kdm sits :-(

The net.eth2 (don't remember why) was made an exact copy of net.lo, so a
symlink just did the same job.  Config files are ok (I guess) and the init
scripts are untouched.

Tomorrow I'm going to check the config files, though.

Thanks again
Francisco


Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Nick Cunningham
>
>
> rc_parallel="NO" (I have tried once, but gave up) and it is really X, I use
> "verbose" framebuffer images
>
> Gonna check that openrc, though.
>
> But, while re-emerging sysvinit:
>
> "
>  * WARNING: You have older net.* files in /etc/init.d/
>  * They need to be converted to symlinks to net.lo.  If you haven't
>  * made personal changes to those files, you can update with the
>  * following command:
> ...
> "
>
> Do the net.* also belong to the boot group of init scripts?  This is a
> snippet of the end of the boot screen:
>
> "
>  * Setting framebuffer console images ... [ ok ]
>  * Starting gpm ...   [ ok ]
>  * Setting up kdm ... [ ok ]
>  * Loading ALSA modules ...
>  *   Loading: snd-seq-oss ... [ ok ]
>  *   Loading: snd-pcm-oss ... [ ok ]
>  *   Restoring Mixer Levels ...   [ ok ]
>  * Starting
>  *   no interface module has been loaded
>  * Starting eth2
>  *   Bringing up eth2
>  * adsl
>  *   Starting ADSL for eth2   [ ok ]
>  * Starting APC UPS daemon ...[ ok ]
>  * Starting cupsd ... [ ok ]
>  * Starting ddclient ...  [ ok ]
> Clearing iptables (created by KMyFirewall)...   Done.
> Starting iptables (created by KMyFirewall)...   Done. [ ok ]
>  * Loading lm_sensors modules...
>  *   Loading coretemp ... [ ok ]
>  * Initializing sensors ...   [ ok ]
>  * Enabling numlock on ttys ...   [ ok ]
>  * Setting clock via rdate ...[ ok ]
>  * Starting S.M.A.R.T. monitoring daemon ...  [ ok ]
>  * Starting vixie-cron ...[ ok ]
>  * Starting local ... [ ok ]
>
> This is ...
> "
>
> Thanks a lot!
> Francisco
>

Ok, that net.* error may mean you have some config in the wrong place (or a
really old config file). Network configs for all interfaces should go in
/etc/conf.d/net and then to ensure they get started you create a symlink
from /etc/init.d/net.lo to /etc/init.d/net.eth2 (in your case). Unless your
creating init files for whatever reason, you should never need to edit
anything in /etc/init.d/.

Im interested to see what "Setting up kdm ... " is, do you use KDE or GNOME?
If thats xdm then ive no idea why its starting so early, and if it is xdm
then thats your problem im guessing.

BTW, if your thinking of moving to openrc, make sure you read the migration
guide and follow it to the letter otherwise you risk being left with an
unbootable system: http://www.gentoo.org/doc/en/openrc-migration.xml

- Nick


Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Francisco Ares
On Tue, Jan 6, 2009 at 12:02 AM, Francisco Ares  wrote:

>
> On Mon, Jan 5, 2009 at 11:21 PM, Nick Cunningham wrote:
>
>>
>> Sorry to answer a question with another one, but how do I know to which
>>> group the services should be added?
>>>
>>> That really might be the solution of my problem. And, yes, it is really X
>>> .
>>>
>>> This is the output from rc-uptate -s  :
>>>acpid |  default
>>>alsasound |  default
>>>  apcupsd |  default
>>> bootmisc | boot
>>>   bootsplash |  default
>>>  checkfs | boot
>>>checkroot | boot
>>>clock | boot
>>>  consolefont | boot
>>>   consolekit |  default
>>>cupsd |  default
>>> dbus |  default
>>> ddclient |  default
>>>   fbcondecor |  default
>>>  gpm |  default
>>> hald |  default
>>>   hdparm |  default
>>> hostname | boot
>>>  keymaps | boot
>>>  kmyfirewall |  default
>>>   lm_sensors |  default
>>>local |  default nonetwork
>>>   localmount | boot
>>>  modules | boot
>>> net.eth2 |  default
>>>   net.lo | boot
>>>  numlock |  default
>>>rdate |  default
>>>rmnologin | boot
>>>   serial | boot
>>>   smartd |  default
>>> sysklogd |  default
>>>  urandom | boot
>>>   vixie-cron |  default
>>>  xdm |  default
>>>
>>> Thanks again
>>> Francisco
>>>
>>
>> Looking over those everything seems fine, i was hoping an obvious problem
>> like xdm being in the boot group could have been a cause.
>>
>> Again, just to rule out the obvious, your sure your seeing xdm start up
>> early and not the framebuffer splash?
>>
>> One other thing to check is whether you have parallel startup enabled,
>> depending on whether your using openrc or not, this may be in /etc/rc.conf
>> or /etc/conf.d/rc (or a similar location, i dont quite remember it exactly).
>> Look for the following (or similar incase its changed):
>> # Set to "YES" if you want the rc system to try and start services
>> # in parallel for a slight speed improvement. When running in parallel we
>> # prefix the service output with it's name as the output will get
>> # jumbled up.
>> # WARNING: whilst we have improved parallel, it can still potentially lock
>> # the boot process. Don't file bugs about this unless you can supply
>> # patches that fix it without breaking other things!
>> rc_parallel="NO"
>>
>> Ideally you want it set to NO to ensure everything starts when it is meant
>> to.
>>
>> Hopefully one of these suggestions will help, if not the next idea is to
>> move to openrc if your not already as that may help, although there is some
>> risk involved in the upgrade.
>>
>> - Nick
>>
>
>
> rc_parallel="NO" (I have tried once, but gave up) and it is really X, I use
> "verbose" framebuffer images
>
> Gonna check that openrc, though.
>
> But, while re-emerging sysvinit:
>
> "
>  * WARNING: You have older net.* files in /etc/init.d/
>  * They need to be converted to symlinks to net.lo.  If you haven't
>  * made personal changes to those files, you can update with the
>  * following command:
> ...
> "
>
> Do the net.* also belong to the boot group of init scripts?  This is a
> snippet of the end of the boot screen:
>
> "
>  * Setting framebuffer console images ... [ ok ]
>  * Starting gpm ...   [ ok ]
>  * Setting up kdm ... [ ok ]
>  * Loading ALSA modules ...
>  *   Loading: snd-seq-oss ... [ ok ]
>  *   Loading: snd-pcm-oss ... [ ok ]
>  *   Restoring Mixer Levels ...   [ ok ]
>  * Starting
>  *   no interface module has been loaded
>  * Starting eth2
>  *   Bringing up eth2
>  * adsl
>  *   Starting ADSL for eth2   [ ok ]
>  * Starting APC UPS daemon ...[ ok ]
>  * Starting cupsd ... [ ok ]
>  * Starting ddclient ...  [ ok ]
> Clearing iptables (created by KMyFirewall)...   Done.
> Starting iptables (created by KMyFirewall)...   Done. [ ok ]
>  * Loading lm_sensors modules...
>  *   Loading coretemp ... [ ok ]
>  * Initializing sensors ...   [ ok ]
>  * Enabling numlock on ttys ...   [ ok ]
>  * Setting clock via rdate ...[ ok ]
>  * Starting S.M.A.R.T. monitoring daemon ...  [ ok ]
>  * Starting vixie-cron ...   

Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Francisco Ares
On Mon, Jan 5, 2009 at 11:21 PM, Nick Cunningham wrote:

>
> Sorry to answer a question with another one, but how do I know to which
>> group the services should be added?
>>
>> That really might be the solution of my problem. And, yes, it is really X
>> .
>>
>> This is the output from rc-uptate -s  :
>>acpid |  default
>>alsasound |  default
>>  apcupsd |  default
>> bootmisc | boot
>>   bootsplash |  default
>>  checkfs | boot
>>checkroot | boot
>>clock | boot
>>  consolefont | boot
>>   consolekit |  default
>>cupsd |  default
>> dbus |  default
>> ddclient |  default
>>   fbcondecor |  default
>>  gpm |  default
>> hald |  default
>>   hdparm |  default
>> hostname | boot
>>  keymaps | boot
>>  kmyfirewall |  default
>>   lm_sensors |  default
>>local |  default nonetwork
>>   localmount | boot
>>  modules | boot
>> net.eth2 |  default
>>   net.lo | boot
>>  numlock |  default
>>rdate |  default
>>rmnologin | boot
>>   serial | boot
>>   smartd |  default
>> sysklogd |  default
>>  urandom | boot
>>   vixie-cron |  default
>>  xdm |  default
>>
>> Thanks again
>> Francisco
>>
>
> Looking over those everything seems fine, i was hoping an obvious problem
> like xdm being in the boot group could have been a cause.
>
> Again, just to rule out the obvious, your sure your seeing xdm start up
> early and not the framebuffer splash?
>
> One other thing to check is whether you have parallel startup enabled,
> depending on whether your using openrc or not, this may be in /etc/rc.conf
> or /etc/conf.d/rc (or a similar location, i dont quite remember it exactly).
> Look for the following (or similar incase its changed):
> # Set to "YES" if you want the rc system to try and start services
> # in parallel for a slight speed improvement. When running in parallel we
> # prefix the service output with it's name as the output will get
> # jumbled up.
> # WARNING: whilst we have improved parallel, it can still potentially lock
> # the boot process. Don't file bugs about this unless you can supply
> # patches that fix it without breaking other things!
> rc_parallel="NO"
>
> Ideally you want it set to NO to ensure everything starts when it is meant
> to.
>
> Hopefully one of these suggestions will help, if not the next idea is to
> move to openrc if your not already as that may help, although there is some
> risk involved in the upgrade.
>
> - Nick
>


rc_parallel="NO" (I have tried once, but gave up) and it is really X, I use
"verbose" framebuffer images

Gonna check that openrc, though.

But, while re-emerging sysvinit:

"
 * WARNING: You have older net.* files in /etc/init.d/
 * They need to be converted to symlinks to net.lo.  If you haven't
 * made personal changes to those files, you can update with the
 * following command:
...
"

Do the net.* also belong to the boot group of init scripts?  This is a
snippet of the end of the boot screen:

"
 * Setting framebuffer console images ... [ ok ]
 * Starting gpm ...   [ ok ]
 * Setting up kdm ... [ ok ]
 * Loading ALSA modules ...
 *   Loading: snd-seq-oss ... [ ok ]
 *   Loading: snd-pcm-oss ... [ ok ]
 *   Restoring Mixer Levels ...   [ ok ]
 * Starting
 *   no interface module has been loaded
 * Starting eth2
 *   Bringing up eth2
 * adsl
 *   Starting ADSL for eth2   [ ok ]
 * Starting APC UPS daemon ...[ ok ]
 * Starting cupsd ... [ ok ]
 * Starting ddclient ...  [ ok ]
Clearing iptables (created by KMyFirewall)...   Done.
Starting iptables (created by KMyFirewall)...   Done. [ ok ]
 * Loading lm_sensors modules...
 *   Loading coretemp ... [ ok ]
 * Initializing sensors ...   [ ok ]
 * Enabling numlock on ttys ...   [ ok ]
 * Setting clock via rdate ...[ ok ]
 * Starting S.M.A.R.T. monitoring daemon ...  [ ok ]
 * Starting vixie-cron ...[ ok ]
 * Starting local ... [ ok ]

This is ...
"

Thanks a lot!
Francisco


Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Nick Cunningham
> Sorry to answer a question with another one, but how do I know to which
> group the services should be added?
>
> That really might be the solution of my problem. And, yes, it is really X .
>
> This is the output from rc-uptate -s  :
>acpid |  default
>alsasound |  default
>  apcupsd |  default
> bootmisc | boot
>   bootsplash |  default
>  checkfs | boot
>checkroot | boot
>clock | boot
>  consolefont | boot
>   consolekit |  default
>cupsd |  default
> dbus |  default
> ddclient |  default
>   fbcondecor |  default
>  gpm |  default
> hald |  default
>   hdparm |  default
> hostname | boot
>  keymaps | boot
>  kmyfirewall |  default
>   lm_sensors |  default
>local |  default nonetwork
>   localmount | boot
>  modules | boot
> net.eth2 |  default
>   net.lo | boot
>  numlock |  default
>rdate |  default
>rmnologin | boot
>   serial | boot
>   smartd |  default
> sysklogd |  default
>  urandom | boot
>   vixie-cron |  default
>  xdm |  default
>
> Thanks again
> Francisco
>

Looking over those everything seems fine, i was hoping an obvious problem
like xdm being in the boot group could have been a cause.

Again, just to rule out the obvious, your sure your seeing xdm start up
early and not the framebuffer splash?

One other thing to check is whether you have parallel startup enabled,
depending on whether your using openrc or not, this may be in /etc/rc.conf
or /etc/conf.d/rc (or a similar location, i dont quite remember it exactly).
Look for the following (or similar incase its changed):
# Set to "YES" if you want the rc system to try and start services
# in parallel for a slight speed improvement. When running in parallel we
# prefix the service output with it's name as the output will get
# jumbled up.
# WARNING: whilst we have improved parallel, it can still potentially lock
# the boot process. Don't file bugs about this unless you can supply
# patches that fix it without breaking other things!
rc_parallel="NO"

Ideally you want it set to NO to ensure everything starts when it is meant
to.

Hopefully one of these suggestions will help, if not the next idea is to
move to openrc if your not already as that may help, although there is some
risk involved in the upgrade.

- Nick


Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Francisco Ares
On Mon, Jan 5, 2009 at 10:22 PM, Nick Cunningham 
wrote:
>
>
> 2009/1/6 Francisco Ares 
>>
>> Hi, guys
>>
>> I've been seeing this for several months now, and I couldn't fix it.  It
is easy to workaround, so I didn't want to bother the list before.
>>
>> But when it's enough, it's enough.
>>
>> While booting, I can see the init scripts progress up to the time xdm
(kdm) starts.  Then I lo gin and start to work.  Suddenly I remember that I
have to issue a Ctrl-Alt-F1 to return to the boot console and only then the
scripts go on, looking like they froze when X started (or some other related
app).
>>
>> That was for several months and has come back now.  During a few months
interval (I suppose that those time periods were coincident to kernel
updates) I got the opposite: the scripts kept going, X appeared for very few
seconds and then the boot console reappeared without intervention.  I always
had to hit Ctrl-Alt-F7 to return to kdm.
>>
>> Any suggestions?
>>
>> Thanks a lot
>> Francisco
>>
>
> Have checked to make sure your init scripts are in the right place, run
rc-update and it will show all your init scripts and in what order group
they are in (boot, default etc). It may be that one got added to the wrong
group which causes X to start too soon. Also check your running the latest
versions of baselayout (and openrc if you run ~arch).
>
> For reference xdm should be the 2nd to last (or thereabouts) script to
run, normally just before local.
>
> (also, are you sure this is X starting and not just a framebuffer splash?)
>
> - Nick

Sorry to answer a question with another one, but how do I know to which
group the services should be added?

That really might be the solution of my problem. And, yes, it is really X .

This is the output from rc-uptate -s  :
   acpid |  default
   alsasound |  default
 apcupsd |  default
bootmisc | boot
  bootsplash |  default
 checkfs | boot
   checkroot | boot
   clock | boot
 consolefont | boot
  consolekit |  default
   cupsd |  default
dbus |  default
ddclient |  default
  fbcondecor |  default
 gpm |  default
hald |  default
  hdparm |  default
hostname | boot
 keymaps | boot
 kmyfirewall |  default
  lm_sensors |  default
   local |  default nonetwork
  localmount | boot
 modules | boot
net.eth2 |  default
  net.lo | boot
 numlock |  default
   rdate |  default
   rmnologin | boot
  serial | boot
  smartd |  default
sysklogd |  default
 urandom | boot
  vixie-cron |  default
 xdm |  default

Thanks again
Francisco


Re: [gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Nick Cunningham
2009/1/6 Francisco Ares 

> Hi, guys
>
> I've been seeing this for several months now, and I couldn't fix it.  It is
> easy to workaround, so I didn't want to bother the list before.
>
> But when it's enough, it's enough.
>
> While booting, I can see the init scripts progress up to the time xdm (kdm)
> starts.  Then I lo gin and start to work.  Suddenly I remember that I have
> to issue a Ctrl-Alt-F1 to return to the boot console and only then the
> scripts go on, looking like they froze when X started (or some other related
> app).
>
> That was for several months and has come back now.  During a few months
> interval (I suppose that those time periods were coincident to kernel
> updates) I got the opposite: the scripts kept going, X appeared for very few
> seconds and then the boot console reappeared without intervention.  I always
> had to hit Ctrl-Alt-F7 to return to kdm.
>
> Any suggestions?
>
> Thanks a lot
> Francisco
>
> --
> "If you have an apple and I have an apple and we exchange apples then you
> and I will still each have one apple. But if you have an idea and I have one
> idea and we exchange these ideas, then each of us will have two ideas." -
> George Bernard Shaw
>

Have checked to make sure your init scripts are in the right place, run
rc-update and it will show all your init scripts and in what order group
they are in (boot, default etc). It may be that one got added to the wrong
group which causes X to start too soon. Also check your running the latest
versions of baselayout (and openrc if you run ~arch).

For reference xdm should be the 2nd to last (or thereabouts) script to run,
normally just before local.

(also, are you sure this is X starting and not just a framebuffer splash?)

- Nick


[gentoo-user] init script freezes when xdm (kdm) starts

2009-01-05 Thread Francisco Ares
Hi, guys

I've been seeing this for several months now, and I couldn't fix it.  It is
easy to workaround, so I didn't want to bother the list before.

But when it's enough, it's enough.

While booting, I can see the init scripts progress up to the time xdm (kdm)
starts.  Then I lo gin and start to work.  Suddenly I remember that I have
to issue a Ctrl-Alt-F1 to return to the boot console and only then the
scripts go on, looking like they froze when X started (or some other related
app).

That was for several months and has come back now.  During a few months
interval (I suppose that those time periods were coincident to kernel
updates) I got the opposite: the scripts kept going, X appeared for very few
seconds and then the boot console reappeared without intervention.  I always
had to hit Ctrl-Alt-F7 to return to kdm.

Any suggestions?

Thanks a lot
Francisco

-- 
"If you have an apple and I have an apple and we exchange apples then you
and I will still each have one apple. But if you have an idea and I have one
idea and we exchange these ideas, then each of us will have two ideas." -
George Bernard Shaw