I pulled the latest changesets just now and found this weird behavior:
'make' and 'make install' worked as expected, but 'make modules_install'
just deleted all the old modules, ran depmod, and then installed no new
modules -- nothing.
I finally found that doing another 'make' fixed whatever the problem
was and allowed modules_install to work properly the second time.
This happened on two different machines, so I'm fairly sure it wasn't
just me having a brainfart.
On Wed, Apr 14, 2004 at 08:40:47AM -0700, walt wrote:
> I pulled the latest changesets just now and found this weird behavior:
>
> 'make' and 'make install' worked as expected, but 'make modules_install'
> just deleted all the old modules, ran depmod, and then installed no new
> modules -- nothing.
>
> I finally found that doing another 'make' fixed whatever the problem
> was and allowed modules_install to work properly the second time.
>
> This happened on two different machines, so I'm fairly sure it wasn't
> just me having a brainfart.
This is my second report about this.
But you gave some new info "work properly the second time".
This was not the case for the other person.
I will look into it tonight.
Sam
On Wednesday 14 April 2004 12:18, Sam Ravnborg wrote:
>On Wed, Apr 14, 2004 at 08:40:47AM -0700, walt wrote:
>> I pulled the latest changesets just now and found this weird
>> behavior:
>>
>> 'make' and 'make install' worked as expected, but 'make
>> modules_install' just deleted all the old modules, ran depmod, and
>> then installed no new modules -- nothing.
>>
>> I finally found that doing another 'make' fixed whatever the
>> problem was and allowed modules_install to work properly the
>> second time.
>>
>> This happened on two different machines, so I'm fairly sure it
>> wasn't just me having a brainfart.
>
>This is my second report about this.
>But you gave some new info "work properly the second time".
>This was not the case for the other person.
>
>I will look into it tonight.
>
> Sam
WRT 2.6.5-bk1: So far everything I've checked seems to be working,
including loading all the modules on the 1st build and reboot to it.
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
On Wed, Apr 14, 2004 at 06:18:27PM +0200, Sam Ravnborg wrote:
> On Wed, Apr 14, 2004 at 08:40:47AM -0700, walt wrote:
> > I pulled the latest changesets just now and found this weird behavior:
> >
> > 'make' and 'make install' worked as expected, but 'make modules_install'
> > just deleted all the old modules, ran depmod, and then installed no new
> > modules -- nothing.
> >
> > I finally found that doing another 'make' fixed whatever the problem
> > was and allowed modules_install to work properly the second time.
> >
> > This happened on two different machines, so I'm fairly sure it wasn't
> > just me having a brainfart.
>
> This is my second report about this.
> But you gave some new info "work properly the second time".
> This was not the case for the other person.
Make this the third. I just saw it happen here too.
'make bzImage ; make modules ; make modules_install' fails in the above way.
Doing a 'make' seems to work.
Dave
On Wednesday 14 April 2004 13:00, Dave Jones wrote:
>On Wed, Apr 14, 2004 at 06:18:27PM +0200, Sam Ravnborg wrote:
> > On Wed, Apr 14, 2004 at 08:40:47AM -0700, walt wrote:
> > > I pulled the latest changesets just now and found this weird
> > > behavior:
> > >
> > > 'make' and 'make install' worked as expected, but 'make
> > > modules_install' just deleted all the old modules, ran depmod,
> > > and then installed no new modules -- nothing.
> > >
> > > I finally found that doing another 'make' fixed whatever the
> > > problem was and allowed modules_install to work properly the
> > > second time.
> > >
> > > This happened on two different machines, so I'm fairly sure it
> > > wasn't just me having a brainfart.
> >
> > This is my second report about this.
> > But you gave some new info "work properly the second time".
> > This was not the case for the other person.
>
>Make this the third. I just saw it happen here too.
>'make bzImage ; make modules ; make modules_install' fails in the
> above way. Doing a 'make' seems to work.
>
> Dave
I'm a great believer in scripting this stuff out, saves me from my own
typu's. My "makeit" script seems to have worked ok, and it does
seperate makes for bzImage, modules, and modules_install. However,
IIRC it does do some other work between making modules, and the make
modules_install. I had to re-arrange things a bit so the final
depmod was clean.
I don't know if this is how you are supposed to do it, but here is how
I do it, please critique:
------------makeit-----------
#!/bin/sh
## this script assumes you have downloaded, unpacked and linked
kernel-whatever.version
## First, set the version string to match the Makefile setting
VER=2.6.5-bk1
# I've re-arranged this to be one contiguous command line, because
# this way if there is an error, it dies right there instead of making
# you scroll back 700k in the shell's history to check for errors.
# And, due to changes in the 2.6 way of doing things, the System.map
# stuff has been moved to a point BEFORE the make modules_install
# because it (apparently) now has a self-contained depmod command.
# Also, one should make sure the DEPMOD declaration in the Makefile
# is NOT hard coded pathwise, so it will find the newer, 2.6 version
# of depmod, that bit me several times.
make clean && \
echo && \
echo && \
echo makeing bzImage && \
make -j4 bzImage && \
echo && \
echo && \
echo Now making modules && \
echo && \
echo && \
make modules && \
echo &&
echo removeing /boot/vmlinuz-$VER-old && \
rm -f /boot/vmlinuz-$VER-old && \
echo touching vmlinuz-$VER && \
touch /boot/vmlinuz-$VER && \
echo mv-ing /boot/vmlinuz-$VER /boot/vmlinuz-$VER-old && \
mv -f /boot/vmlinuz-$VER /boot/vmlinuz-$VER-old && \
echo copying bzImage to /boot/vmlinuz-$VER && \
cp -f arch/i386/boot/bzImage /boot/vmlinuz-$VER && \
echo removeing old lib/modules/$VER.old && \
rm -fR /lib/modules/$VER.old && \
echo touching /lib/modules/$VER && \
touch /lib/modules/$VER && \
echo moving /lib/modules/$VER to /lib/modules/$VER.old && \
mv -f /lib/modules/$VER /lib/modules/$VER.old && \
echo cleaning up in /boot && \
rm -f /boot/System.map /boot/System.map-$VER && \
echo copying in new System.map && \
cp -f System.map /boot/System.map-$VER && \
echo cd-ing to /boot && \
cd /boot && \
echo doing the link of System.map-$VER to System.map && \
ln -s System.map-$VER System.map && \
echo cd-ing back to /usr/src/linux-2.6 to do the modules_install && \
cd /usr/src/linux-2.6 && \
echo && \
echo make modules_install && \
echo && \
make modules_install && \
depmod -ae -F System.map $VER && \
echo All done! reboot after fixing lilo or grub.conf
-----------------------
If the above is incorrect, I'd appreciate some pointers on how to
improve it.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
On Wed, Apr 14, 2004 at 06:00:10PM +0100, Dave Jones wrote:
>
> Make this the third. I just saw it happen here too.
> 'make bzImage ; make modules ; make modules_install' fails in the above way.
> Doing a 'make' seems to work.
I think I tracked it down now.
During 'make bzImage' the directory .tmp_versions was deleted and created.
This is only supposed to happen when building modules.
This does not match your failure report 100%.
I assume what you did was something like:
make bzImage
make modules
make install <= This would trigger the above case
make modules_install
Or maybe you inverted the two:
make modules
make bzImage
Anyway here is the fix.
Please let me know if you still se problems.
Sam
===== Makefile 1.478 vs edited =====
--- 1.478/Makefile Tue Apr 13 17:46:49 2004
+++ edited/Makefile Wed Apr 14 22:19:26 2004
@@ -624,8 +624,10 @@
endif
prepare0: prepare1 include/linux/version.h include/asm include/config/MARKER
+ifneq ($(KBUILD_MODULES),)
$(Q)rm -rf $(MODVERDIR)
- $(if $(CONFIG_MODULES),$(Q)mkdir -p $(MODVERDIR))
+ $(Q)mkdir -p $(MODVERDIR)
+endif
# All the preparing..
prepare-all: prepare0 prepare
On Wed, Apr 14, 2004 at 10:25:54PM +0200, Sam Ravnborg wrote:
> This does not match your failure report 100%.
> I assume what you did was something like:
>
> make bzImage
> make modules
> make install <= This would trigger the above case
> make modules_install
That's quite possible.
> Anyway here is the fix.
> Please let me know if you still se problems.
I'll give it a shot.
Dave
On Wed, Apr 14, 2004 at 06:00:10PM +0100, Dave Jones wrote:
> On Wed, Apr 14, 2004 at 06:18:27PM +0200, Sam Ravnborg wrote:
> > On Wed, Apr 14, 2004 at 08:40:47AM -0700, walt wrote:
> > > I pulled the latest changesets just now and found this weird behavior:
> > >
> > > 'make' and 'make install' worked as expected, but 'make modules_install'
> > > just deleted all the old modules, ran depmod, and then installed no new
> > > modules -- nothing.
> > >
> > > I finally found that doing another 'make' fixed whatever the problem
> > > was and allowed modules_install to work properly the second time.
> > >
> > > This happened on two different machines, so I'm fairly sure it wasn't
> > > just me having a brainfart.
> >
> > This is my second report about this.
> > But you gave some new info "work properly the second time".
> > This was not the case for the other person.
>
> Make this the third. I just saw it happen here too.
> 'make bzImage ; make modules ; make modules_install' fails in the above way.
> Doing a 'make' seems to work.
>
I've seen the same problem doing 'make; make install
modules_install'. I haven't tried doing make again before
modules_install - I'll do that when I have time.
Simon
--
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
On Wed, Apr 14, 2004 at 10:25:54PM +0200, Sam Ravnborg wrote:
> On Wed, Apr 14, 2004 at 06:00:10PM +0100, Dave Jones wrote:
> >
> > Make this the third. I just saw it happen here too.
> > 'make bzImage ; make modules ; make modules_install' fails in the above way.
> > Doing a 'make' seems to work.
>
> I think I tracked it down now.
> During 'make bzImage' the directory .tmp_versions was deleted and created.
> This is only supposed to happen when building modules.
>
> This does not match your failure report 100%.
> I assume what you did was something like:
>
> make bzImage
> make modules
> make install <= This would trigger the above case
> make modules_install
>
> Or maybe you inverted the two:
> make modules
> make bzImage
>
> Anyway here is the fix.
> Please let me know if you still se problems.
>
This patch fixed the problem for me - 'make install modules_install'
now does what it's supposed to do.
Simon
--
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
> This patch fixed the problem for me - 'make install modules_install'
> now does what it's supposed to do.
Thanks for the report.
Sam