Hi Michael,
Well, I was the on who originally reported the problem. On my
system, the problem seemed to be that the 'initscripts' configuration
had been messed up.
I compared mine with a friends whose system was working and noticed the
anomalies. I used 'sysv-rc-conf'. 'udev' is supposed to run at 'init'
mode 'S' and that entry was unset. Setting that solved the problem. I do
not know how and why it happened so can't help you there. Just check and
see if this is the problem. Couple of other services configuration was
also messed up.
What you would need to check I think is that 'makedev' runs at 'init'
mode '2-5', and 'udev', 'udev-mtab' are set to run at 'init' mode 'S'.
Hope this helps :). And thanks to Kevin who pointed out that it was
an initscript error :).
-Vibhav
Michael Armida wrote:
Hello All,
I picked up on a recent conversation from this list here:
http://permalink.gmane.org/gmane.linux.debian.user/256763
I'm having exactly the same problem. Does Kevin Mark or anybody else
know where I can find more information about the "initscript upgrade
error", or how to fix this problem? I checked around in
bugs.debian.org/initscripts, bugs.debian.org/sysvinit, and google, and
can't find anything useful about the situation.
A friend and much wiser Debian user than I took a look at my problem
and determined that by commenting out the "return" in the
mount_tmpfs() below from the udev startup script, /dev gets populated
as normal, and things go back to usual, minus the hacked script
(around line 23):
mount_tmpfs() {
if grep -E -q "^[^[:space:]]+ /dev tmpfs" /proc/mounts; then
echo "Looks like /dev is already mounted. Let's keep going anyway."
# return
fi
We weren't, however, able to determine why /dev was being mounted with
the tmpfs ahead of the udev script.
I am but a newbie Debian user, so please feel free to point me at the
right documentation or bug report.
TIA,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
