cvs commit: src/sys/boot/common help.common src/sys/boot/forth loader.conf

[John-Mark Gurney]

Pawel Jakub Dawidek wrote this message on Tue, Aug 10, 2004 at 12:30 +0200:
> +> Please include complete information of the breakage that this change
> +> is suppose to cause.
> 
> I've just checked on the next machine (this is 3rd machine) and it doesn't
> put '/boot/kernel' into 'kern.module_path' sysctl. That's why kldload(8)
> cannot work properly.
> 
> The only difference that I'm seeing between our environments is that I use
> new loader (with beastie picture) everywhere and you don't use it, right?

Nope, on the system that I upgraded on Sunday, Aug 8th, I'm seeing zero
problems, and the machine is using the beastie loader.  As you saw in an
email last night, it also has my changes...

If I boot kernel.old after breaking out into the loader prompt, I see a
module path of: /boot/kernel.old;/boot/kernel;/boot/modules.. This is
because of a bug in loader that doesn't reset the module_path when loading
a different kernel after it's already loaded one, but I haven't
investigated it yet...

If I use nextboot to boot kernel.old, I end up with a module path of:
/boot/kernel.old;/boot/modules, which is as it should be.

If I let the machine boot normally, my module path is:
/boot/kernel;/boot/modules...

Have you tried booting another kernel?  I can't see how your machine
could of booted /boot/kernel.old ever with kernel modules, if your
machine is currently having troubles with loading kernel modules.
(Since kernel.old would not have been added to module path, since it
isn't being now, and the correct modules would never load.)

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."