Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, 8 Nov 2005 15:34:48 +0100, Sven Luther wrote [typo corrected]: You can now, just need to add Recommends: blah to the arch/arch/defines entry. Now the capability has been added, any chance you could pop this extra line in? I'd be happy to do it myself, but of course I can't. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modules
Package: linux-2.6 Version: 2.6.15 When using make module_install with the makefile that comes with the kernel (/lib/modules/2.6.15-1-686/build/Makefile) modules are not installed into the correct location in /lib/modules. They build fine but are then installed to /lib/modules/2.6.15 instead of /lib/modules/2.6.15-1-686. I have seen this with tp_smapi module (http://tpctl.sourceforge.net/), and the zaptel module (available in unstable) built using m-a. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
Congratulations, you are the first to file a bug report against linux
2.6.15 :)
Yay ;-)
Could you tell us exactly what you do to build the module, and check if
this
is not a bug in m-a or your module ?
The official recomended way of building modules is to build inside the
module
tree with KSRC=/lib/modules/2.6.15-1-686/build, is this the way you do it ?
Here are a couple of extracts from the tp_smapi makefile which should show
how it's done (I use 'make install' to drive this):
KVER := $(shell uname -r)
KDIR := /lib/modules/$(KVER)/build
PWD := $(shell pwd)
MDIR := drivers/firmware
...
modules: $(patsubst %.o,%.c,$(TP_MODULES))
$(MAKE) -C $(KDIR) M=$(PWD) modules
...
install: modules
rm -f /lib/modules/$(KVER)/kernel/$(MDIR)/{tp_base,tp_smapi}.ko
$(MAKE) -C $(KDIR) M=$(PWD) modules_install
depmod -a
Did it work for the official 2.6.14-[12] debian kernels ? Did it work for
another kernel ?
No, it was the same at 2.6.14, don't know about earlier than that.
Also worth noting is that it looks from the makefile (the rm before the
make, using MDIR) as though the modules should get installed in
/lib/modules/2.6.15-1-686/kernel/drivers/firmware, but they actually end up
in /lib/modules/2.6.15-1/extras, not sure if that's another build system
problem, or if it is an issue with the makefile though???
Richard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
KDIR := /lib/modules/$(KVER)/build
modules: $(patsubst %.o,%.c,$(TP_MODULES))
$(MAKE) -C $(KDIR) M=$(PWD) modules
...
install: modules
rm -f /lib/modules/$(KVER)/kernel/$(MDIR)/{tp_base,tp_smapi}.ko
$(MAKE) -C $(KDIR) M=$(PWD) modules_install
We use $(MAKE) KSRC=/lib/modules/$(KVER)/build to build and install, i
believe. have you seen other modules and can you confirm they don't break
or
something such ?
I'm sorry but I'm not quite sure what you mean.
I've tried changing the above make calls to these:
$(MAKE) KSRC=$(KDIR) modules
$(MAKE) KSRC=$(KDIR) M=$(PWD) modules
$(MAKE) KSRC=$(KDIR) -C $(KDIR) M=$(PWD) modules
only the last of the 3 will build, and that still installs to the wrong
place again.
The original method does build fine, so I think for the most part make is
finding it's way into the right places, it's just the install step that uses
the wrong kernel name string for it's installation directory in
/lib/modules, so I'd think that however KSRC works we'd end up with the same
problem?
As I say I'm not sure that I've understood the KSRC variable, or quite where
to use it, so you may well be right about it.
Doing a bit of digging, I see that it comes down to the value of MODLIB in
/usr/src/linux-headers-2.6.15-1-686/scripts/Makefile.modinst, this appears
to come from $KERNELRELEASE, which appears to be made up of
$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION)
Calling 'make -C /lib/modules/2.6.15-1-686/build kernelrelease' shows the
kernel release as 2.6.15, but shouldn't this show 2.6.15-1-686, (which is
defined for UTS_RELEASE in version.h)?
Richard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345918: linux-2.6: modules do not install to correct folder in /lib/modu
Calling 'make -C /lib/modules/2.6.15-1-686/build kernelrelease' shows the kernel release as 2.6.15, but shouldn't this show 2.6.15-1-686, (which is defined for UTS_RELEASE in version.h)? can you give the output of : dpkg -l | grep linux-header [EMAIL PROTECTED]:~$ dpkg -l | grep linux-header ii linux-headers-2.6-686 2.6.15-1 Architecture-specific header files for Linux ii linux-headers-2.6.14-2 2.6.14-7 Common header files for Linux kernel 2.6.14 ii linux-headers-2.6.14-2-686 2.6.14-7 Header files for Linux kernel 2.6.14 on PPro ii linux-headers-2.6.15-1 2.6.15-1 Common header files for Linux kernel 2.6.15 ii linux-headers-2.6.15-1-686 2.6.15-1 Header files for Linux kernel 2.6.15 on PPro [EMAIL PROTECTED]:~$ Please, the issue may be related to you not having the right header package installed, or the header package being buggy, but i believe the first to be the case. You need the per flavour linux-header package, which should include a configured .config file, settign the $KERNELRELEASE variable to the right thing, somwhere in this chain something may be wrong, either on your part or ours. Seems to be no mention of the version number (except a comment) in the .config files: [EMAIL PROTECTED]:~# locate .config | grep 2.6.15 | xargs grep 2.6.15 /usr/src/linux-headers-2.6.15-1-686/.config:# Linux kernel version: 2.6.15-1-686 /usr/src/linux-headers-2.6.15-1/.config:# Linux kernel version: 2.6.15-1 /var/lib/dpkg/info/linux-image-2.6.15-1-686.config:my $version = 2.6.15-1-686; Another try is : apt-get source -b pwc I had to install kernel-package and linux-headers-2.6.14 (which pulled in headers for all kinds of x86 cpus i don't have) to get this to pass the dependancy check, but it still failed to build. And it appears it was trying to build using the headers for k7, not 686 too. That package seems messed up, probably not the best one to test with. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345918: Possible solution
It appears that this has now been fixed in 2.6.15-3, the localversion file is now installed with the headers. I have tested it with the zaptel module and it now installs to the correct location. Can this bug be closed, or has it been left open for a reason? Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345918: Duplicate bug (Was: modules do not install to correct folder)
This appears to be a duplicate of #330081, but since this one is marked 'confirmed' and has a different urgency, I'll leave it to the maintainers to combine as they see fit. Yes, it does seem to be the same problem. As it looks to have been fixed now they should ideally be merged and closed - unless it was left open for a reason. As neither bug has been acknowledged as being fixed, it doesn't seem wise to close them manually incase the fix we see at the moment hasn't been deemed as final. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358580: linux-2.6: cannot build modules against 2.6.16
Richard, you said you were able to build fglrx. Did you make something special ? I also tried without module-assistant, but cannot figure out why it is looking for Makefile.lib.c file. That module builds fine for me, in fact so far it's the only one that does against 2.6.16. bcm5700 doesn't, thinkpad smapi doesn't, nvidia doesn't (though that's because of something in the nvidia driver itself, not the kernel headers package). While in 2.6.15 I did: m-a clean all m-a -l 2.6.16-1-686 - update - prepare - select - - get - - build - - install sudo module-assistant -t build fglrx Warning, /usr/src/linux-headers-2.6.16-1 seems to contain unconfigured kernel source! I do still get this warning, and it is probably part of the problem, but it seems the flgrx module builds differently (i.e. doesn't use the kernels own module build makefile) so it does work. To avoid this bug getting distracted if you still can't get it to build I'd raise it against that component, and if it does relate to this bug then the maintainer can hopefully draw some attention to this one. So far there has been no response from any of the kernel team to this bug. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394974: linux-image-2.6.18-1-686: 2.6.18-3 breaks module compatability
tags 394974 - moreinfo thanks Please show the breakage. Oops, forgot to paste some in. Here are examples from 2 boxes: boot.0:Tue Oct 24 08:16:57 2006: nvidia boot.0:Tue Oct 24 08:16:57 2006: FATAL: Error inserting nvidia (/lib/modules/2.6.18-1-686/nvidia/nvidia.ko): Invalid module format dmesg:nvidia: module license 'NVIDIA' taints kernel. dmesg.0:nvidia: disagrees about version of symbol struct_module [EMAIL PROTECTED]:~$ sudo modprobe tp_smapi WARNING: Error inserting thinkpad_ec (/lib/modules/2.6.18-1-686/extra/thinkpad_ec.ko): Invalid module format FATAL: Error inserting tp_smapi (/lib/modules/2.6.18-1-686/extra/tp_smapi.ko): Invalid module format [EMAIL PROTECTED]:~$ dmesg thinkpad_ec: disagrees about version of symbol struct_module tp_smapi: disagrees about version of symbol struct_module thinkpad_ec: disagrees about version of symbol struct_module tp_smapi: disagrees about version of symbol struct_module Richard. _ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
This could be changes to video drivers in the kernel. Please describe your graphics card used. Oops, I did intened to mention that. It's an Nvidia GeForce 6600GT 128MB (generic unbranded reference board). Please try the following: 1) add ramdisk = /usr/sbin/mkinitrd.yaird to /etc/kernel-img.conf 2) make a backup of the initrd for your older working kernel 3) Run dpkg-reconfigure old kernel package 4) Reboot with older kernel Now older kernel hits same problem. So I guess this is yaird problem then? You can also try installing initramfs-tools, uninstalling yaird, run dpkg-reconfigure new kernel package and reboot with new kernel. Also has no video on boot. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
Nvidia. Ok (or ok is perhaps an exageration: problems with this specific hardware vendor is not really a surprise to me...) Yeah, but it plays native Linux Quake 4 very nicely! You did remember to uninstall yaird before regenerating the ramdisk? Yep, and to confirm it I checked the size of the generated image, all three initrd tools produced clearly different sized images (yaird the smallest by a little, then mkinitrd, then initramfs several times the size). Richard: Are you ready for some more geeky tests? Always ;-) So if you could boot an old kernel with initrd ramdisk and kernel options init=/bin/sh rw, and run the following command: /sbin/lsmod /mkinitrd-modules.dump Then do the same with same kernel but yaird ramdisk It also needed a mount /proc for lsmod to work. It looks as though yaird loads a whole lot less modules. If I had to guess I'd say it might be all those frame buffer modules that mkinitrd version loads but yaird doesn't. Richard. Here is the lsmod from the mkinitrd: Module Size Used by ext3 141736 1 jbd56760 1 ext3 mbcache 9252 1 ext3 reiserfs 254416 0 ide_disk 18688 2 ide_generic 1152 0 [permanent] via82cxxx 13820 0 [permanent] trm290 4196 0 [permanent] triflex 3680 0 [permanent] slc90e665664 0 [permanent] sis551316488 0 [permanent] siimage12448 0 [permanent] serverworks 9032 0 [permanent] sc1200 7296 0 [permanent] rz1000 2400 0 [permanent] piix 10340 0 [permanent] pdc202xx_old 11168 0 [permanent] opti621 4324 0 [permanent] ns87415 4264 0 [permanent] hpt366 20384 0 [permanent] hpt34x 5152 0 [permanent] generic 3808 0 [permanent] cy82c6934676 0 [permanent] cs5530 5312 0 [permanent] cs5520 4544 0 [permanent] cmd64x 12028 0 [permanent] atiixp 5904 0 [permanent] amd74xx14396 0 [permanent] alim15x3 12268 0 [permanent] aec62xx 7360 0 [permanent] pdc202xx_new9248 0 [permanent] ide_core 130388 27 ide_disk,ide_generic,via82cxxx,trm290,triflex,slc90e66,sis5513,siimage,serverworks,sc1200,rz1000,piix,pdc202xx_old,opti621,ns87415,hpt366,hpt34x,generic,cy82c693,cs5530,cs5520,cmd64x,atiixp,amd74xx,alim15x3,aec62xx,pdc202xx_new unix 27888 0 fbcon 39936 65 tileblit2240 1 fbcon font8096 1 fbcon bitblit 5920 1 fbcon vesafb 7992 1 cfbcopyarea 3872 1 vesafb cfbimgblt 2816 1 vesafb cfbfillrect 4128 1 vesafb softcursor 2176 1 vesafb capability 4584 0 commoncap 6912 1 capability And here is the the lsmod from the yaird image: Module Size Used by unix 27888 0 ext3 141736 1 jbd56760 1 ext3 mbcache 9252 1 ext3 ide_disk 18688 2 ide_generic 1152 0 [permanent] hpt366 20384 0 [permanent] ide_core 130388 3 ide_disk,ide_generic,hpt366 shpchp 99428 0 pci_hotplug28468 1 shpchp evdev 9728 0 mousedev 11776 0 usbhid 36480 0 usbkbd 7008 0 ehci_hcd 35336 0 uhci_hcd 32176 0 usbcore 122300 5 usbhid,usbkbd,ehci_hcd,uhci_hcd psmouse31236 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
Try editing /etc/yaird/Default.cfg and add the following: MODULE vesafb Ok, that got the vesafb loaded, but that didn't give me video. Added MODULE fbcon as well and that did the job. This testing was all on the 2.6.12. As Sven said vesafb isn't a module at 2.6.14. So for =2.6.14 you need both, for 2.6.14 you only need to add fbcon to the conf file. Tested, so I can now confirm this working at both 2.6.12 2.6.14. So, I have a workaround. Not sure how this should be fixed permanently though? Easiest way would seem to be to change the yaird Default.conf, but I don't know if that's the right way. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
As Sven said vesafb isn't a module at 2.6.14. So for =2.6.14 you need both, for 2.6.14 you only need to add fbcon to the conf file. I'm sure you all spotted it - there is a slight error in the above statement, so for the record it should read: As Sven said vesafb isn't a module at 2.6.14. So for 2.6.14 you need both, for =2.6.14 you only need to add fbcon to the conf file. It was about midnigth when I wrote that. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
Kernel-images 2.6.x-686 and 2.6.x-k7 shoud recommend libc6-i686, because libc6-686 improves system performance when running with 2.6.x-686 and 2.6.x-k7 kernel-images. Thanks for the clarification. I now agree with your suggestion. I will get it into the tree, but my TODO list is rather long today. Did this bug get forgotten about? I suspect like most of us your todo list hasn't got any shorter over the last year, but I would imagine it'd only be a little change to get this in??? And it'd be be nice to get a clean output from deborphan again. Thanks, Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: acknowledged by developer (Bug#336450: fixed in yaird 0.0.11-11)
Confirmed fix working. Thanks guys. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
2.6.8 is frozen solid for sarge. IF there is interest in having this added for the etch kernels, can you please reasign it to linux-2.6 I think it should become a permanent addition to all 686 class kernels going forward, but I don't mind what point that starts at - unstable would be fine for me, but etch would be useful more widely. I wouldn't expect anything to change in sarge at this stage in it's release. I'm afraid I don't know how to reassign a bug in BTS though, so I can't do that. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
