depscan failing on system init - SOLVED!

tweakt · Last edited by tweakt on Fri Jun 04, 2004 6:32 pm; edited 1 time in total

OK. I'm still not sure what started this, and I expected to see it reported but not yet, so I'm guessing it's caused by something special I've configured. I had to hand copy this cause it happens before root is mounted writeable. The errors cause rc to think the checkfs script fails (no actual errors) and this causes rc to drop to sulogin. From there I can get the system started by repeatedly Ctrl-D'ing my way through. Basically rc doesn't remember what's been started so a bunch of stuff is executed 2 or 3 times.

The first chance I get to drop into sulogin, I found /var/lib/init.d to be empty, so obviously depcache is not doing it's job. I've tried to track down the source of the 'java-config' error to no avail...

I thought, after reading comments in /sbin/rc maybe that since /var is a seperate filesystem from root, that I might need svcmount="yes" in /etc/conf.d/rc but that doesn't seem to be the problem.

Here is my filesystem layout:

tweakt · Posted: Tue May 18, 2004 2:10 am Post subject:

*Ugh*

Just what I was afraid of... nobody else run into this? I'll keep poking at it and see what I can find out.

aethyr · Veteran Joined: 06 Apr 2003 Posts: 1085 Location: NYC

tweakt · Posted: Fri Jun 04, 2004 1:31 am Post subject: Bumpety bump...

OK. I ignored it for a while but I got so sick of it the other day, I delved into the problem some more. I've made some progress!

re-merging baselayout did not change anything.

I came up with a way to step through the init scripts to find out what was happening. I inserted 'sulogin' into a couple key places so I could drop into a shell and poke around.

Here is what I found.

The very first thing that runs is "/sbin/rc sysinit" (started directly from init). Somewhere around line 417 or so, depscan.sh is run. This is responsible for creating various items under /var/lib/init.d that are necessary for init scripts to function correctly. After sysinit is done, the scripts assigned to the boot runlevel start to run in the order determined by their dependencies. The order is something like:

checkroot
modules
checkfs
localmount
clock
...etc

Ok, here is my filesystem layout, this will help explain the issue I'm having (I've omitted non-physical filesystems):

/dev/hda5 on / type ext3 (rw)
/dev/hda6 on /opt type ext3 (rw,nodev)
/dev/hda7 on /usr type ext3 (rw,nodev)
/dev/hda8 on /home type reiserfs (rw,nodev,noatime,notail)
/dev/hda9 on /var type ext3 (rw)
/dev/hda10 on /tmp type ext3 (rw,nosuid,nodev)

Ok, so the boot level scripts start to run, checkroot, modules, checkfs all execute fine. Then localmount mounts the remaining partions (above) including /var. The files created as a result of depscan.sh earlier are now inaccessible because the real /var filesystem has been mounted OVER them. The next script to run, clock, spews the errors I posted earlier about non existant symlink targets, etc. What happens is there is no dependency cache, so clock starts checkroot, modules, etc ALL OVER AGAIN, and this continues for all of the boot scripts until at some point later depscan is run again from somewhere else and /var/lib/init.d is recreated and all is well.

So... what wierd thing did I do to my system to cause this? I know I can't be the only person with a seperate /var filesystem. And I know /var can't be mounted any earlier (and shouldn't be). Did I do something to cause a second depscan.sh call not to be run after localmount?

Any clues?

I could probably hack it to work now at this point but I'd prefer to have it functioning as intended to avoid and future wierdness. Thanks for any help...

yooda · Posted: Fri Jun 04, 2004 10:49 am Post subject:

I used to have similar error-messages from /sbin/rc with the development sources 2.6.5 (vanilla sources). I had no idea of what was happening, too, but after an upgrade to 2.6.7-rc2, everything works fine now. And in case you are using an udev-only system, make sure your /etc/udev/udev.conf is correct and readable.

tweakt

I just figured out the problem!

There is a section in /sbin/rc that starts 'critical services'.

These are boot level scripts that must be started successfully for system startup to continue. These scripts are started JUST PRIOR to updating the service dependecies (stuff in /var/lib/init.d). Here is what mine looked like:

yooda · Posted: Fri Jun 04, 2004 8:46 pm Post subject:

cool

I don't have the file /etc/runlevels/boot/.critical, but localmount is in that directory...

anyway, good to know for the next time!!