Bug 26317

Summary: /modules not created by make installkernel
Product: Base System Reporter: bill <bill>
Component: kernAssignee: Peter Pentchev <roam>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
patch none

Description bill 2001-04-03 16:30:00 UTC
	I blew away my /modules (and /modules.old) directory and
	then did a make installkernel. The result was a file where
	/modules should have been.

Fix: 

For a workaround, just don't blow away /modules (delete
	its contents instead) or, having done so, mkdir /modules
	before doing the make installkernel.
How-To-Repeat: 
	rm -fr /modules*
	cd /usr/src
	make installkernel KERNCONF=yourkernel
Comment 1 Peter Pentchev 2001-04-03 16:37:37 UTC
On Tue, Apr 03, 2001 at 11:23:08AM -0400, T. William Wells wrote:
> 
> >Number:         26317
> >Category:       kern
> >Synopsis:       /modules not created by make installkernel
> >Originator:     T. William Wells
> >Release:        FreeBSD 4.3-BETA i386
> >Organization:
> >Environment:
> System: FreeBSD twwells.com 4.3-BETA FreeBSD 4.3-BETA #2: Mon Mar 19 12:24:00 EST 2001 root@twwells.com:/usr/obj/usr/src/sys/TWWELLS i386
> 
> 
> >Description:
> 
> 	I blew away my /modules (and /modules.old) directory and
> 	then did a make installkernel. The result was a file where
> 	/modules should have been.
> 
> >How-To-Repeat:
> 
> 	rm -fr /modules*
> 	cd /usr/src
> 	make installkernel KERNCONF=yourkernel
> 
> >Fix:
> 
> 	For a workaround, just don't blow away /modules (delete
> 	its contents instead) or, having done so, mkdir /modules
> 	before doing the make installkernel.

The /modules directory is created in the first stage of the 'make installworld'
process.  As world and kernel should generally always be rebuild/reinstalled
in sync, this does not usually arise as a problem :)

As you correctly point out, a workaround is to always have a /modules dir.
I wonder, though, whether the 'installkernel' target in Makefile.inc1 should
not, too, invoke a 'make hierarchy', or at least some subset of that, to do
an mtree from BSD.root.dist; that should ensure that the /modules directory
is there.

G'luck,
Peter

-- 
I am the thought you are now thinking.
Comment 2 k 2001-04-03 17:10:48 UTC
On Tue, Apr 03, 2001 at 08:40 (-0700) +0000, Peter Pentchev wrote:
>  The /modules directory is created in the first stage of the 'make installworld'
>  process.  As world and kernel should generally always be rebuild/reinstalled
>  in sync, this does not usually arise as a problem :)
>  
>  As you correctly point out, a workaround is to always have a /modules dir.
>  I wonder, though, whether the 'installkernel' target in Makefile.inc1 should
>  not, too, invoke a 'make hierarchy', or at least some subset of that, to do
>  an mtree from BSD.root.dist; that should ensure that the /modules directory
>  is there.

From /usr/src/UPDATING
        make buildworld
        make buildkernel KERNCONF=YOUR_KERNEL_HERE
        make installkernel KERNCONF=YOUR_KERNEL_HERE
        reboot  (in single user) [1]
        make installworld
        mergemaster
        reboot


Hence you are recommended to run installkernel before installworld.

See PR 20326 where the problem is similar.


>  
>  G'luck,
>  Peter
>  
>  -- 
>  I am the thought you are now thinking.
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-bugs" in the body of the message

-- 
Johan Karlsson		mailto:k@numeri.campus.luth.se
Comment 3 Peter Pentchev 2001-04-03 17:24:39 UTC
On Tue, Apr 03, 2001 at 06:10:48PM +0200, Johan Karlsson wrote:
> On Tue, Apr 03, 2001 at 08:40 (-0700) +0000, Peter Pentchev wrote:
> >  The /modules directory is created in the first stage of the 'make installworld'
> >  process.  As world and kernel should generally always be rebuild/reinstalled
> >  in sync, this does not usually arise as a problem :)
> >  
> >  As you correctly point out, a workaround is to always have a /modules dir.
> >  I wonder, though, whether the 'installkernel' target in Makefile.inc1 should
> >  not, too, invoke a 'make hierarchy', or at least some subset of that, to do
> >  an mtree from BSD.root.dist; that should ensure that the /modules directory
> >  is there.
> 
> From /usr/src/UPDATING
>         make buildworld
>         make buildkernel KERNCONF=YOUR_KERNEL_HERE
>         make installkernel KERNCONF=YOUR_KERNEL_HERE
>         reboot  (in single user) [1]
>         make installworld
>         mergemaster
>         reboot
> 
> 
> Hence you are recommended to run installkernel before installworld.
> 
> See PR 20326 where the problem is similar.

I know; this is why I think that a subset of the 'make hierarchy'
functionality should be added first thing in the 'installkernel' target.

G'luck,
Peter

-- 
Thit sentence is not self-referential because "thit" is not a word.
Comment 4 bill 2001-04-03 19:01:38 UTC
> The /modules directory is created in the first stage of the 'make installworld'
> process.  As world and kernel should generally always be rebuild/reinstalled
> in sync, this does not usually arise as a problem :)

Ideally, yes. Actually, what happened is that I was under the
misapprehension that specifying NO_MODULES meant that one didn't
get -- or need -- kernel modules. So I blew away that directory
after I had built and installed my kernel, only to discover that
I really did need some kernel modules. (For Linux compatibility
and for a screensaver; evidently, those can't be compiled into
the kernel nowadays.)

So, I did another make buildkernel (the easy to fix my blunder, I
thought), and found that it didn't work as expected.

> As you correctly point out, a workaround is to always have a /modules dir.
> I wonder, though, whether the 'installkernel' target in Makefile.inc1 should
> not, too, invoke a 'make hierarchy', or at least some subset of that, to do
> an mtree from BSD.root.dist; that should ensure that the /modules directory
> is there.

It would. OTOH, installation of the kernel really doesn't need
anything other than / and /modules, right? So maybe it should just
do a mkdir /modules and not worry about the rest.
Comment 5 Gregory Bond 2001-04-09 01:03:24 UTC
> It should at least bomb out with an error message, instead of pretending it
> succesfully installed your kernel and modules, even though what it
> _actually_ did was install one module as '/modules'...

A simple patch to achieve this is attached. (I.e. install into /modules/ 
rather than /modules to force the error to be trapped.)

Comment 6 Peter Pentchev freebsd_committer freebsd_triage 2001-07-06 09:56:28 UTC
State Changed
From-To: open->analyzed

Let's see if the FreeBSD community likes the proposed trailing-slash 
patch. 


Comment 7 Peter Pentchev freebsd_committer freebsd_triage 2001-07-06 09:56:28 UTC
Responsible Changed
From-To: freebsd-bugs->roam

I'll take care of the responses in -arch and -audit.
Comment 8 Peter Pentchev 2001-07-18 11:05:47 UTC
On Sun, Apr 08, 2001 at 05:10:02PM -0700, Gregory Bond wrote:
> The following reply was made to PR kern/26317; it has been noted by GNATS.
> 
> From: Gregory Bond <gnb@itga.com.au>
> To: David Taylor <davidt@yadt.co.uk>
> Cc: freebsd-gnats-submit@FreeBSD.ORG
> Subject: Re: kern/26317: /modules not created by make installkernel 
> Date: Mon, 09 Apr 2001 10:03:24 +1000
> 
>  This is a multipart MIME message.
>  
>  --==_Exmh_8133331360
>  Content-Type: text/plain; charset=us-ascii
>  
>  > It should at least bomb out with an error message, instead of pretending it
>  > succesfully installed your kernel and modules, even though what it
>  > _actually_ did was install one module as '/modules'...
>  
>  A simple patch to achieve this is attached. (I.e. install into /modules/ 
>  rather than /modules to force the error to be trapped.)

This patch was committed into -current, and if no serious beatings occur,
it shall be MFC'd in two weeks.

Thanks!

G'luck,
Peter

-- 
When you are not looking at it, this sentence is in Spanish.
Comment 9 Peter Pentchev freebsd_committer freebsd_triage 2001-09-24 17:37:12 UTC
State Changed
From-To: analyzed->closed

Eep; I actually MFC'd this patch about two months ago.. 
Thanks for the problem report!