DragonFlyBSD

This is not a bug, this is the normal behaviour. You can set
module_path=/boot;/boot/modules.old;/;/modules.old to work around that :)

Cheers,
Alex Hornung

On 30/08/10 23:30, elekktretterr@exemail.com.au wrote:

Hi,
When I enter into the boot prompt and run "boot kernel.old", i can see
modules being loaded from /boot/modules, instead of /boot/modules.old. Its
not very intuitive. Is this a bug?

Petr

:
:Hi,
:When I enter into the boot prompt and run "boot kernel.old", i can see
:modules being loaded from /boot/modules, instead of /boot/modules.old. Its
:not very intuitive. Is this a bug?
:
:Petr

It isn't really a bug, its just a lack of implementation in the
    loader.

Hmm.  I've been wanting to go to a /boot/<directory>/{kernel + modules}
    setup for a while, I'm glad you brought this up.  I will mess around a
    bit today and see if I can implement the model I want.  It will be a
    nice break from the kernel work.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Tue, Aug 31, 2010 at 09:23:04AM -0700, Matthew Dillon wrote:

Hmm. I've been wanting to go to a /boot/<directory>/{kernel + modules}
setup for a while, I'm glad you brought this up. I will mess around a
bit today and see if I can implement the model I want. It will be a
nice break from the kernel work.

We have DESTLABEL variable (see build(7)); with which, If specified, things
go to
${DESTDIR}/boot/kernel.${DESTLABEL} and
${DESTDIR}/boot/modules.${DESTLABEL},
respectively. I believe that the idea was to be able to specify this
${DESTLABEL} in the boot loader, for example,

OK boot ${DESTLABEL}        # or maybe .${DESTLABEL}

and $kernel and $module_path are set up to point to those locations.
I'm not sure how to do this in Forth, though.

/boot/<directory> is fine as well, but it could be useful if we have
some make variables for installkernel target to point to where old
kernel/modules should go or where new kernel/modules should be installed.

:go to
: ${DESTDIR}/boot/kernel.${DESTLABEL} and
: ${DESTDIR}/boot/modules.${DESTLABEL},
:respectively. I believe that the idea was to be able to specify this
:${DESTLABEL} in the boot loader, for example,
:
: OK boot ${DESTLABEL} # or maybe .${DESTLABEL}
:
:and $kernel and $module_path are set up to point to those locations.
:I'm not sure how to do this in Forth, though.
:
:/boot/<directory> is fine as well, but it could be useful if we have
:some make variables for installkernel target to point to where old
:kernel/modules should go or where new kernel/modules should be installed.

I managed to the whole thing in one day, including ripping out the
    4th loader and putting in a saner C-based menu system.

Not only can we now boot from directories/{kernel+modules}, but
    I got directories/loader.conf localization working so it is possible
    to have different root mounts, and thus possible to boot 32 or 64 bits
    (though of course root, bins, usr bins, etc have to be different),
    as well as keeping around backup kernels+modules and such.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Wed, Sep 01, 2010 at 01:03:04AM -0700, Matthew Dillon wrote:

:go to
: ${DESTDIR}/boot/kernel.${DESTLABEL} and
: ${DESTDIR}/boot/modules.${DESTLABEL},
:respectively. I believe that the idea was to be able to specify this
:${DESTLABEL} in the boot loader, for example,
:
: OK boot ${DESTLABEL} # or maybe .${DESTLABEL}
:
:and $kernel and $module_path are set up to point to those locations.
:I'm not sure how to do this in Forth, though.
:
:/boot/<directory> is fine as well, but it could be useful if we have
:some make variables for installkernel target to point to where old
:kernel/modules should go or where new kernel/modules should be installed.

I managed to the whole thing in one day, including ripping out the
4th loader and putting in a saner C-based menu system.

That's cool!

Not only can we now boot from directories/{kernel+modules}, but
I got directories/loader.conf localization working so it is possible
to have different root mounts, and thus possible to boot 32 or 64 bits
(though of course root, bins, usr bins, etc have to be different),
as well as keeping around backup kernels+modules and such.

If you try to install a module from e.g. /sys/dev/acpica5, the KLD goes
to right under /boot, is this intended? $modules_path contains /boot,
so KLDs installed that way should just work, but it also affects the
traditional method:

$ cd /sys/config
  $ config -d /path/to/writable MYKERNEL
  $ make depend && make
  $ sudo make install

This will install the kernel to /boot/kernel/kernel but all KLDs under /boot.
This is because KLDs are now installed to ${DESTKERNDIR}, which defaults to
/boot/${KERNEL}, but no .mk files included from within a module directory
supplies the default value for ${KERNEL}.

:
:If you try to install a module from e.g. /sys/dev/acpica5, the KLD goes
:to right under /boot, is this intended? $modules_path contains /boot,
:so KLDs installed that way should just work, but it also affects the
:traditional method:
:..
: $ cd /sys/config
: $ config -d /path/to/writable MYKERNEL
: $ make depend && make
: $ sudo make install
:
:This will install the kernel to /boot/kernel/kernel but all KLDs under /boot.
:This is because KLDs are now installed to ${DESTKERNDIR}, which defaults to
:/boot/${KERNEL}, but no .mk files included from within a module directory
:supplies the default value for ${KERNEL}.

No, that's a bug.  It's supposed to install to a directory. Without
    knowledge of which kernel the module is related to it winds up stuffing
    it in /boot.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Ok, I've committed a change to kmod.mk to set the KERNEL default
when it isn't provided by installkernel. Lets see if that has closed
this install hole.

-Matt