On Monday June 30 2003 09:10 am, Guillaume Rousse wrote:
> > I don't believe they're related either, ie, kernel and
> > devfsd. When I did manage to recover cooker (9.1 install +
> > resync with urpmi to current cooker), the new devfs failed to
> > provide scd0, loop, rtc, .. The only alternative was to rebuild
> > 9.1's devfsd src.rpm and --force it in. Then I had a working
> > system again (scd0, loop, rtc, ...)
>
> Check in your logs for messages as
> "/sbin/devfsd-try-modload"^INo such file or directory
Nope, none of that. Perhaps the log has rotated since I
re-installed and went back to an older devfsd
> If it is the case, just edit your /etc/devfsd.conf file and
> switch the comment between the following lines:
> #LOOKUP .* EXECUTE /sbin/devfsd-try-modload
> LOOKUP .* MODLOAD
LOOKUP .* MODLOAD is all that's there
(devfsd-1.3.25-19mdk, rebuilt on cooker from src.rpm)
Suppose I could take devfsd out of my skip.list, update and then
try the edit. Seems like a better idea to fix the current devfsd in
cooker tho, no?. The only reason I don't think the current kernel
problem and devfsd problem are related, is we've had /dev/loop
missing in past kernels (IIRC, about 2.4.20-11), yet the kernel
didn't panic, and no harddrake message on boot that it wanted to
remove /dev/scd0, my burner. I got that mesg after the
re-install+cooker, replaced devfsd with the older version, an then
later went to reboot to a newly installed multimedia kernel
(mm-18dk). Same I was usin before all this fsck-up. Fortunately I
chose cancel to both questions, and subsequent re-boots haven't
tried to remove scd0. Another possibly related issue is that mdkkdm
now refuses my valid user passwd, even after resetting it with
'passwd tom' (as root).
--
Tom Brinkman Corpus Christi, Texas
