Bug #1813

booting kernel.old uses /boot/modules, not modules.old

Added by elekktretterr over 4 years ago. Updated about 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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

History

#1 Updated by alexh over 4 years ago

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, 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
>

#2 Updated by dillon over 4 years ago

:
: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
<>

#3 Updated by qhwt+dfly over 4 years ago

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.

#4 Updated by dillon over 4 years ago

: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
<>

#5 Updated by qhwt+dfly over 4 years ago

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}.

#6 Updated by dillon over 4 years ago

:
: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
<>

#7 Updated by dillon over 4 years ago

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

Also available in: Atom PDF