Hello module wizards,
If one makes changes to the kernel configuration,
compiles, then attempts to install the new kernel,
there are two possible things that happen.
(1) One does `make modules_install` before `make install`
or...
(2) One does `make install` before `make modules_install'.
In the first case, `make install` may fail because the
loop device module fails to load with:
Script started on Mon 08 Nov 2004 09:07:41 AM EST
# insmod loop.ko
insmod: error inserting 'loop.ko': -1 Invalid module format
# insmod -f loop.ko
insmod: error inserting 'loop.ko': -1 Invalid module format
# dmesg | tail --lines 2
loop: version magic '2.6.9 SMP preempt PENTIUM4 gcc-3.3' should be '2.6.9 SMP PENTIUM4 gcc-3.3'
loop: version magic '2.6.9 SMP preempt PENTIUM4 gcc-3.3' should be '2.6.9 SMP PENTIUM4 gcc-3.3'
# exit
Script done on Mon 08 Nov 2004 09:08:35 AM EST
..OR..
The installation seems to work, but the system won't complete
a boot because modules from the previous configuration were used
in the `initrd` procedure.
This all comes about because the new module loading procedure
won't allow (ignores) the "-f" (force) parameter. So, one
is screwed trying to do something simple like substituting
a preemptive kernel for another if there isn't already an
alternate bootable system on the disk.
Please restore the "-f" parameter passed to insmod. It
was there for a very good reason. This allows one
who encounters the module-loading error while installing
the kernel to force the module loading. In this way, the
correct modules are used to generate the new `initrd` image.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On 08 Nov 2004 at 10h11, linux-os wrote:
Hi,
> Please restore the "-f" parameter passed to insmod. It
> was there for a very good reason. This allows one
> who encounters the module-loading error while installing
> the kernel to force the module loading. In this way, the
> correct modules are used to generate the new `initrd` image.
Wouldn't using the EXTRAVERSION field save you from such hassles?
--
Colin
On Mon, 8 Nov 2004, Colin Leroy wrote:
> On 08 Nov 2004 at 10h11, linux-os wrote:
>
> Hi,
>
>> Please restore the "-f" parameter passed to insmod. It
>> was there for a very good reason. This allows one
>> who encounters the module-loading error while installing
>> the kernel to force the module loading. In this way, the
>> correct modules are used to generate the new `initrd` image.
>
> Wouldn't using the EXTRAVERSION field save you from such hassles?
>
> --
> Colin
>
There are certainly work-arounds for problems that shouldn't
exist at all. So, every time I do something to a kernel, I
have to change whatever the EXTRAVERSION field is? Then, when
a customer demands that the kernel version be exactly the
same that was shipped with Fedora or whatever, I'm screwed.
They simply should not have removed the "-f" option of
insmod. It's just that simple. This option allowed transient
(possible) incompatibilities so that one could be productive
and not spend a whole day reinstalling from a distribution
CD because the new modules wouldn't work because somebody
decided that their special VERMAGIC_STRING was so ")@*&#$%)"
important that they preempted my work. Don't get me started....
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
On Mon, 08 Nov 2004 12:52:18 EST, linux-os said:
> There are certainly work-arounds for problems that shouldn't
> exist at all. So, every time I do something to a kernel, I
> have to change whatever the EXTRAVERSION field is? Then, when
> a customer demands that the kernel version be exactly the
> same that was shipped with Fedora or whatever, I'm screwed.
If you didn't have the foresight to keep that kernel version around,
there isn't much we can do to help you. Yes, this may mean you have
a big bunch of /usr/src/linux-2.6.* directories.
Note that you can *still* get screwed unless you keep the same
compiler toolchain around...
> They simply should not have removed the "-f" option of
> insmod. It's just that simple. This option allowed transient
> (possible) incompatibilities so that one could be productive
> and not spend a whole day reinstalling from a distribution
> CD because the new modules wouldn't work because somebody
> decided that their special VERMAGIC_STRING was so ")@*&#$%)"
> important that they preempted my work. Don't get me started....
Yes, instead you can spend a whole day reinstalling from a
distribution CD, and then restoring user files from backup,
because the new module you just 'insmod -f' had a different
number of parameters to some kernel call, and as a result your
stack got smashed and took the root filesystem with it....
On Mon, 8 Nov 2004 [email protected] wrote:
> On Mon, 08 Nov 2004 12:52:18 EST, linux-os said:
>
>> There are certainly work-arounds for problems that shouldn't
>> exist at all. So, every time I do something to a kernel, I
>> have to change whatever the EXTRAVERSION field is? Then, when
>> a customer demands that the kernel version be exactly the
>> same that was shipped with Fedora or whatever, I'm screwed.
>
> If you didn't have the foresight to keep that kernel version around,
> there isn't much we can do to help you. Yes, this may mean you have
> a big bunch of /usr/src/linux-2.6.* directories.
>
Wrong. Whoever put the module-loading code INSIDE the kernel,
for POLITICAL reasons, created a new POLICY.
[SNIPPED...]
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
linux-os wrote:
> On Mon, 8 Nov 2004 [email protected] wrote:
>
>> On Mon, 08 Nov 2004 12:52:18 EST, linux-os said:
>>
>>> There are certainly work-arounds for problems that shouldn't
>>> exist at all. So, every time I do something to a kernel, I
>>> have to change whatever the EXTRAVERSION field is? Then, when
>>> a customer demands that the kernel version be exactly the
>>> same that was shipped with Fedora or whatever, I'm screwed.
>>
>>
>> If you didn't have the foresight to keep that kernel version around,
>> there isn't much we can do to help you. Yes, this may mean you have
>> a big bunch of /usr/src/linux-2.6.* directories.
>>
>
> Wrong. Whoever put the module-loading code INSIDE the kernel,
> for POLITICAL reasons, created a new POLICY.
>
No. Version information is still stripped in module-init-tools in
_userspace_ for modprobe --force. The fact that insmod doesn't support
'-f' is probably an oversight and Rusty would likely accept a patch.
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBkQbBdQs4kOxk3/MRArfFAJ9So6d7pRXqAgkuGj9XhsELsrymdgCfZs+x
Yz1bhTMbZkD35dbd8CEk+vk=
=kAgK
-----END PGP SIGNATURE-----
On Tue, 2004-11-09 at 13:04 -0500, Mike Waychison wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> linux-os wrote:
> > On Mon, 8 Nov 2004 [email protected] wrote:
> >
> >> On Mon, 08 Nov 2004 12:52:18 EST, linux-os said:
> >>
> >>> There are certainly work-arounds for problems that shouldn't
> >>> exist at all. So, every time I do something to a kernel, I
> >>> have to change whatever the EXTRAVERSION field is? Then, when
> >>> a customer demands that the kernel version be exactly the
> >>> same that was shipped with Fedora or whatever, I'm screwed.
> >>
> >>
> >> If you didn't have the foresight to keep that kernel version around,
> >> there isn't much we can do to help you. Yes, this may mean you have
> >> a big bunch of /usr/src/linux-2.6.* directories.
> >>
> >
> > Wrong. Whoever put the module-loading code INSIDE the kernel,
> > for POLITICAL reasons, created a new POLICY.
> >
>
> No. Version information is still stripped in module-init-tools in
> _userspace_ for modprobe --force. The fact that insmod doesn't support
> '-f' is probably an oversight and Rusty would likely accept a patch.
Hmm, insmod is actually designed to be a minimal system call wrapper
(ie. most people probably shouldn't be using it). However, it accepts
standard input and objcopy will happily strip sections out of a module.
Cheers,
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
[email protected] wrote:
> On Mon, 08 Nov 2004 12:52:18 EST, linux-os said:
>>They simply should not have removed the "-f" option of
>>insmod. It's just that simple. This option allowed transient
>>(possible) incompatibilities so that one could be productive
>>and not spend a whole day reinstalling from a distribution
>>CD because the new modules wouldn't work because somebody
>>decided that their special VERMAGIC_STRING was so ")@*&#$%)"
>>important that they preempted my work. Don't get me started....
>
>
> Yes, instead you can spend a whole day reinstalling from a
> distribution CD, and then restoring user files from backup,
> because the new module you just 'insmod -f' had a different
> number of parameters to some kernel call, and as a result your
> stack got smashed and took the root filesystem with it....
This is Linux, not MS-DOS, where the system works for the user and you
shouldn't have to do nonsense like "do you really want to load the
module?" I agree with Dick, you shouldn't have to recompile the whole
kernel to fix a trivial change. If you shoot yourself in the foot it's
your fault, taking away the the gun is the policy of another o/s I won't
name.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me