At the end of make bzImage I get:
> make[2]: Entering directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
> tmppiggy=_tmp_$$piggy; \
> rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk; \
> objcopy -O binary -R .note -R .comment -S /opt/kernel/linux-2.5.24/vmlinux $tmppiggy; \
> gzip -f -9 < $tmppiggy > $tmppiggy.gz; \
> echo "SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }}" > $tmppiggy.lnk; \
> ld -m elf_i386 -r -o piggy.o -b binary $tmppiggy.gz -b elf32-i386 -T $tmppiggy.lnk; \
> rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk
> /bin/sh: _tmp_18313piggy: No such file or directory
> ld: cannot open _tmp_18313piggy.gz: No such file or directory
> gcc -D__ASSEMBLY__ -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -traditional -c head.S
> gcc -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DKBUILD_BASENAME=misc -c misc.c
> ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o
> ld: cannot open piggy.o: No such file or directory
> make[2]: *** [bvmlinux] Error 1
> make[2]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
> make[1]: *** [compressed/bvmlinux] Error 2
> make[1]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot'
> make: *** [bzImage] Error 2
I tried zImage, with the same result.
Can I boot with just vmlinux?
jay
On Sat, Jun 22, 2002 at 01:41:46PM -0400, sean darcy wrote:
> At the end of make bzImage I get:
[output snipped]
Hi Sean.
I've tried to reproduce this without luck. Could you please mail me your .config.
What shell are you using?
Sam
On Sat, 22 Jun 2002, sean darcy wrote:
> At the end of make bzImage I get:
>
> > make[2]: Entering directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
> > tmppiggy=_tmp_$$piggy; \
> > rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk; \
> > objcopy -O binary -R .note -R .comment -S /opt/kernel/linux-2.5.24/vmlinux $tmppiggy; \
> > gzip -f -9 < $tmppiggy > $tmppiggy.gz; \
> > echo "SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }}" > $tmppiggy.lnk; \
> > ld -m elf_i386 -r -o piggy.o -b binary $tmppiggy.gz -b elf32-i386 -T $tmppiggy.lnk; \
> > rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk
> > /bin/sh: _tmp_18313piggy: No such file or directory
> > ld: cannot open _tmp_18313piggy.gz: No such file or directory
> > gcc -D__ASSEMBLY__ -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -traditional -c head.S
> > gcc -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DKBUILD_BASENAME=misc -c misc.c
> > ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o
> > ld: cannot open piggy.o: No such file or directory
> > make[2]: *** [bvmlinux] Error 1
> > make[2]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
> > make[1]: *** [compressed/bvmlinux] Error 2
> > make[1]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot'
> > make: *** [bzImage] Error 2
At least I didn't break it, for a change. For all I can tell, the link of
piggy.o fails, since the _tmp_xx.gz doesn't exist. That again doesn't
exist since the _tmp_xx does not exist when gzipping it.
So the question is why does the objcopy ... line not generate the tmp_xx
file. I don't see it spitting out any error either, but could you check
the obvious, like remaining free space on that filesystem and /tmp?
BTW: I just rewrote that part so that it would at least properly stop at
the place where the error occurs, but that still leaves the question as to
what the actual error in your case is.
> Can I boot with just vmlinux?
Not unless you have a bootloader which supports that (i.e.: No.)
--Kai
Just a question about kbuild behaviour:
I compiled 2.5.24, with make dep, make bzImage, make modules....
After that, as usually, make dep; make bzImage ...doesn't change nor
recompile anything After that, I changed an option with menuconfig,
"VGA 16-color graphics console support",and "3DFX Banshee/Voodoo 3
display support" (because i can't see somethnig when i boot with it)
from built-in to module. Then I run make dep; and it did make some small
changes, as expected.
Then make bzImage compiled the entier kernel again, or at less a big big
part of it, not only the changes made in menuconfig. make modules
recompiled things again, wich are not affected with the changes (ie:
iptables modules).
My questions is:
It's not expected to do the same as 2.4 kernels, i mean, recompile only
the changes made, not the entire thing?
PD: What are you doing with kbuild 2.5? What parts are you integrating?
Wich parts you aren't going to integrate?
On Sat, 22 Jun 2002, Diego Calleja wrote:
> I compiled 2.5.24, with make dep, make bzImage, make modules....
> After that, as usually, make dep; make bzImage ...doesn't change nor
> recompile anything After that, I changed an option with menuconfig,
> "VGA 16-color graphics console support",and "3DFX Banshee/Voodoo 3
> display support" (because i can't see somethnig when i boot with it)
> from built-in to module. Then I run make dep; and it did make some small
> changes, as expected.
>
>
> Then make bzImage compiled the entier kernel again, or at less a big big
> part of it, not only the changes made in menuconfig. make modules
> recompiled things again, wich are not affected with the changes (ie:
> iptables modules).
>
> My questions is:
>
> It's not expected to do the same as 2.4 kernels, i mean, recompile only
> the changes made, not the entire thing?
If you toggled VGA 16-color support, that adds or removes the symbols
from fbcon-vga-planes.c to the list of export symbols.
After the toggle, make dep detects that and adapts
include/linux/modversions.h accordingly.
Now, if you "make" again, all files which include/linux/modversions.h need
to be rebuilt, since it changed. And that's a lot of files, as you've
noticed. The problem is that in reality, only a file which also *uses* one
of these exported symbols really changes. But make cannot know that, so it
recompiles everything which is possibly affected.
There's no easy way out from that, what you can of course do is turning
off CONFIG_MODVERSIONS - in that case you'll see that only very little
will be affected and rebuilt.
The fact that 2.4 recompiles little even in that case is since kbuild
there has bugs in it which lead to it forgetting to recompile files
(sometimes eventually resulting in "unresolved symbols in ...", which can
only be cured with make mrproper).
For the current kbuild, you should never need to do make mrproper, it
should always recognize changes and rebuild what's necessary.
> PD: What are you doing with kbuild 2.5? What parts are you integrating?
> Wich parts you aren't going to integrate?
I'm currently still doing small bits, shipped files, asm-offsets
generation and the like. I'm also preparing for separate build / src tree,
which makes the current Makefiles and kbuild-2.5's Makefile.in's basically
equivalent information-wise (though not syntactically).
If switching to kbuild-2.5's preprocessing phase will be necessary or make
sense I do not even know myself yet. So some more patience is needed
there.
--Kai
On Sat, 22 Jun 2002 16:08:45 -0500 (CDT)
Kai Germaschewski <[email protected]> escribi?:
> Now, if you "make" again, all files which include/linux/modversions.h
> need to be rebuilt, since it changed. And that's a lot of files, as
> you've noticed. The problem is that in reality, only a file which also
> *uses* one of these exported symbols really changes. But make cannot
> know that, so it recompiles everything which is possibly affected.
This has a lot of sense ;), thanks
Sam Ravnborg wrote:
> On Sat, Jun 22, 2002 at 01:41:46PM -0400, sean darcy wrote:
>
>>At the end of make bzImage I get:
>
> [output snipped]
>
> Hi Sean.
> I've tried to reproduce this without luck. Could you please mail me your .config.
> What shell are you using?
>
> Sam
> -
> 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/
I'm using bash. It's a pretty standard rh7.3 installation.
.config is attached.
What the hell is piggy???
Thanks for any help
jay
Kai Germaschewski wrote:
> On Sat, 22 Jun 2002, sean darcy wrote:
>
>
>>At the end of make bzImage I get:
>>
...................
> So the question is why does the objcopy ... line not generate the tmp_xx
> file. I don't see it spitting out any error either, but could you check
> the obvious, like remaining free space on that filesystem and /tmp?
>
........................
> --Kai
>
20 gigs free. Aren't these big new disks great?
Glad it's not a build problem. Just wish I could figure out what kind of
problem it is.
jay
On Sat, Jun 22, 2002 at 09:32:03PM -0400, sean darcy wrote:
> Kai Germaschewski wrote:
> > On Sat, 22 Jun 2002, sean darcy wrote:
> >
> >
> >>At the end of make bzImage I get:
> >>
> ...................
> > So the question is why does the objcopy ... line not generate the tmp_xx
> > file. I don't see it spitting out any error either, but could you check
> > the obvious, like remaining free space on that filesystem and /tmp?
> >
> ........................
> > --Kai
> >
> 20 gigs free. Aren't these big new disks great?
>
> Glad it's not a build problem. Just wish I could figure out what kind of
> problem it is.
I just checked in some changes that changed all the find commands to
disregard the BK directories. Is there any chance that that could
screw it up?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 22 Jun 2002, sean darcy wrote:
> 20 gigs free. Aren't these big new disks great?
I somehow manage to fill them up just fine no matter how big they are ;)
> Glad it's not a build problem. Just wish I could figure out what kind of
> problem it is.
Well, could you try to
cd /opt/kernel/linux-2.5.24/arch/i386/boot/compressed
objcopy -O binary -R .note -R .comment -S /opt/kernel/linux-2.5.24/vmlinux
_tmp_piggy
and see if that generates _tmp_piggy in that directory?
--Kai
On Sat, Jun 22, 2002 at 09:22:32PM -0400, sean darcy wrote:
>
> I'm using bash. It's a pretty standard rh7.3 installation.
>
> .config is attached.
With your .config everything is still fine. Seems you have a problem
on your machine. In another mail you said you had a rather large
disk. Try to do a "df -h" to see how much space is actually available
for the /tmp partition.
> What the hell is piggy???
A simple temporary name.
Sam
Sam Ravnborg wrote:
>
> With your .config everything is still fine. Seems you have a problem
> on your machine. In another mail you said you had a rather large
> disk. Try to do a "df -h" to see how much space is actually available
> for the /tmp partition.
>
> -
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hde5 38G 8.9G 27G 25% /
/dev/hde2 121M 9.1M 106M 8% /boot
/dev/hde7 68G 124M 64G 1% /opt/photo/hde7
none 219M 0 219M 0% /dev/shm
/dev/hdg1 1019M 616M 403M 61% /win/cdrive
/dev/hdg5 2.0G 1.8G 229M 89% /win/ddrive
As you can see /tmp is on the / partition. Lots of room.
jay
Kai Germaschewski wrote:
> On Sat, 22 Jun 2002, sean darcy wrote:
>
> Well, could you try to
>
> cd /opt/kernel/linux-2.5.24/arch/i386/boot/compressed
> objcopy -O binary -R .note -R .comment -S /opt/kernel/linux-2.5.24/vmlinux
> _tmp_piggy
>
> and see if that generates _tmp_piggy in that directory?
>
> --Kai
Nope .It generates a segmentation fault!. I'm running 2.4.18, binutils
2.12.90. I'm going to try a different binutils.
Here's strace:
[root@daddy compressed]# strace objcopy -O binary -R .note -R .comment
-S /opt/kernel/linux-2.5.24/vmlinux _tmp_piggy
execve("/usr/bin/objcopy", ["objcopy", "-O", "binary", "-R", ".note",
"-R", ".comment", "-S", "/opt/kernel/linux-2.5.24/vmlinux",
"_tmp_piggy"], [/* 28 vars */]) = 0
uname({sys="Linux", node="daddy", ...}) = 0
brk(0) = 0x807c66c
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libNoVersion.so.1", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=6135, ...}) = 0
close(3) = 0
open("/lib/libNoVersion.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\10\0\000"...,
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=6135, ...}) = 0
old_mmap(NULL, 7248, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40014000
mprotect(0x40015000, 3152, PROT_NONE) = 0
old_mmap(0x40015000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0) = 0x40015000
close(3) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=76711, ...}) = 0
old_mmap(NULL, 76711, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000
close(3) = 0
open("/lib/i686/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`u\1B4\0"...,
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1401027, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40029000
old_mmap(0x42000000, 1264928, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x42000000
mprotect(0x4212c000, 36128, PROT_NONE) = 0
old_mmap(0x4212c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x12c000) = 0x4212c000
old_mmap(0x42131000, 15648, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x42131000
close(3) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++