I recently compiled a number of my own kernels. I used the method from the sticky note on this forum, and ended up with deb files for the completed kernel and headers. I had some trouble with the first one I compiled, so I went on to build several more. When installing kernels after the initial one I would get this error from the 'dpkg -i' command. (See below.) Then I'd have to boot up to an earlier kernel, remove the kernel I was trying to replace, and then install the one I had just finished building. Does everyone have this problem?

Thanks a lot. Any help would be appreciated.

Yeah, if you're going to use a module that has firmware from the kernel, then you'll run into this. (I think I said that right.) If you don't actually use this xircom device, then turn it off in the .config fine and you should be OK.

BTW, are you aware of the issue of replacing the /lib/modules directory for the running kernel? Normally you're going to want to rename /lib/modules/`uname -r` to perhaps /lib/modules/`uname -r`-old or something like that before you run dpkg -i. This will protect you from the chance that you haven't loaded a module until after you do the dpkg -i and then the module isn't actually for the kernel that is still running. OTOH, you can take advantage of this fact if you're working on a module by doing rmmod, then replacing the .ko file in /lib/modules/`uname -r` and then modprobing it. Hope this isn't too much information for you at this point.

I just had another, possibly dangerous, thought. If you actually need this firmware, you might try renaming it before doing dpkg -i. It'll either work or it wont.

I booted into a 2.6.26-1-686 stock kernel. From there I removed the old 2.6.27 kernel from the system. Then I installed the new one and then I rebooted. Will this always work? Do debian stock kernels have a mechanism for dealing with this problem? Wouldn't anything you rename immediately become absent and unusable to the computer? I guess you mean 'rename it back if you need it again later'... right? btw, I get you when you say to remove the module from the kernel config if you don't use it. Thanks.

One last thing, what do you mean when you say 'if you're working on a module' ??

I don't understand this question. What do you mean "will this always work?"? Will what always work? There's nothing special about the debian stock kernel, other than the configuration.

Not if it's in use. If a module is in use by the kernel, even if you remove it, the kernel still has access to it. It's a feature of the unix filesystems that a file isn't actually removed until no-one has it open. It will disappear from you display, yes. But, the inode won't be reused by the system until the final party closes it.

That's possible. But it's really just to avoid the issue of having funny things happen with loadable modules, as I understand it.

Exactly that. I was trying to help solve a bug in a new module earlier in the year. My steps were essentially the following:
If I had been able to find the bug, I could have just moved the new .ko file into /lib/modules, rather than recompile the whole kernel and reinstall it.

I probably don't understand enough, but why don't I get a message about xircom_pgs.fw when I update a stock kernel during a 'safe-upgrade' or 'full-upgrade' with aptitude?

Do you actually update the stock kernel to the same version, or is it updating to a later version?

well, 2.6.26-1-686 was constantly being updated. The kernel names were always 2.6.26-1-686, while the package names were something like linux-image-2.6.26-1-686_2.6.26-8_i386.deb. I would think that the computer would treat them as the same name in that the grub menu.lst line always looked the same... I would think that vmlinuz-2.6.26-1-686 is vmlinuz-2.6.26-1-686 regardless what the deb package name is. (in that case it's updating to the same version without the error)

On the other hand, I would think that 2.6.27.2 and 2.6.27.4 would be teated as different, but I think the firmware error came up that time... iow I think when I had successfully installed 2.6.27.2 and I tried to compile and install 2.6.27.4 I got the error about the firmware. (in this case a later version with the error)

Are you actually using the xircom device?

Nope, and on top of that the kernel is installed. I have no issue with that. I'm just curious. Forget about it if it seems like a hassle.

I just don't know the answer. I ran into this myself in the early days of compiling kernels. Once I realised that they were for devices I don't have I just changed my config and moved on. The only thing I can suggest is to verify that the stock kernel actually has this device enabled. Then, if it does, run an upgrade, capture the steps, and see what they do to avoid the problem.

Thanks. I'll look at the stock kernel. If I do this:
and I get this:
that would lead you to believe it's built as a module, yes? How do I go about 'capturing' the steps from the next upgrade?

Sometimes google is your friend. Checkout this post on the kernel mailing list and probably others in the same thread.

http://linux.derkeiler.com/Mailing-L.../msg03953.html

I didn't read it carefully, but he says that the problem doesn't exist for Debian kernel upgrades. Here's a long snippet