Re: CD-reader on SONY VAIO SR27K [+ kernel compile]
blair.kelly@att.net:
> I am afraid of recompiling my kernel because all my previous
> attempts to do so have been disasterous - requiring a complete
> reinstall. I find the various HOWTOs and hints for kernel
> compilation inconsistent and lacking in details.
Did you have a look into /usr/share/doc/kernel-package ?
It's about the powerful kernel-build and kernel-patch tool 'make-kpkg' from
Manoi Srivastasa. It provides many optional useful features; but in short, it
goes like (e.g.)
cd <kernel source tree>
make menuconfig # or make xconfig
make-kpkg clean
make-kpkg --revision=custom.1.0 kernel_image
(
srivstasa:
>> NOTE: if you have instructed your boot loader to expect initrd kernels
>> ( which is the norm for recent official kernel image packages) you need to
>> addd --initrd to the line above:
>> make-kpkg --initrd --revision=custom.1.0 kernel_image
)
dpkg -i ../kernel-image-X.XXX_1.0_<arch>.deb
# make sure lilo or the like got it right !
shutdown -r now # cause now you've got a new modules set.
This includes the usual module stuff.
You'll get information and requestings about modules and lilo.
Anyway, until the dpkg install, your running setup is untouched.
Before first try, please read up the document source i mentioned above;
because i might have misunderstood something here !
> For example, my understanding of the kernel recompile
> process is
> 1. unpack the source
> 2. make clean
> 3. make mrproper
> 4. copy old config file, make changes, then 'make oldconfig'
> 5. make dep
> 6. edit Makefile, set EXTRAVERSION=[some extension]
> 7. make
> 8. make bzImage
> 9. cp arch/i386/boot/bzImage /boot/vmlinuz-[version/extension]
> 10. cp System.map /boot/System.map-[version/extension]
> 11. mv System.map System.map.old
> 12. mv vmlinuz vmlinuz.old
> 13. ln -s System.map-[version/extension] System.map
> 14. ln -s vmlinuz-[version/extension] vmlinuz
> 15. /sbin/lilo
make-kpkg also does the versioning and the symlinking for you :)
You can configure it's behavior therefore.
> Another question is that in my /boot directory there
> is a boot.b link to /boot/boot-menu.b and
> also a initrd.img-2.4.18-686. Yet I find no discussion
> about them in any HOWTO. When and with what should
> they be updated?
initrd is managed by kpkg as well.
You can customize yout boot-menu (the chooser shown up to boot different
kernels), so i gues it won't get updated by default.
> I now can reboot into my new kernel (which seems to have
> less functionality that my old kernel; specifically,
> I no longer seem to be able to cd to the Windows partition
> from the Linux side)
Perhaps you should take the original source config as a template ?
> and my old kernel now gives me
> a kernel panic and fails to boot.
...which may be a consequence of changed modules in /lib/modules/2.4.18
(if of the same version). The old unchanged modules dir still has to exist
under the path the old kernel would expect it ....
however, first check for typos in /boot and lilo.config ;-)
System.map also has to be the appropriate one; but afaicr it's of minor
importance for booting up.
hth
--
micha.
P.S. Since the document is not really short, i'd like to point you to this
interesting section:
""""""
Now, there is a caveat: If you already have kernel 2.0.29 installed,
and you have a freshly created custom 2.0.29 kernel [having remembered
to do a make-kpkg clean in between ;-], just installing the new 2.0.29
kernel shall install modules (as it should) in /lib/modules/2.0.29,
which is where the old modules were! If you have added or removed
modules relative to the old 2.0.29 kernel (very likely if your old
kernel was the default gigantic generic kernel), then you shall have a
mish-mash of modules in /lib/modules/2.0.29 ;-(
Unfortunately, there is no reasonable solution; I suggest moving the
old modules directory before installation, like so (need to be root):
# mv /lib/modules/2.0.29 /lib/modules/2.0.29.save
# dpkg -i kernel-image-2.0.29_custom.1.0_i386.deb
and later get rid of the .save directory.
People who want to have multiple flavours of the same kernel version
around should look at the append_to_version flag of make-kpkg. This
appends to the EXTRAVERSION variable of the kernel Makefile, and does
not require one to edit that makefile manually. This can also be done
by setting the environment variable APPEND_TO_VERSION. The command
line invocation overrides the env variable.
The method described in the /usr/share/doc/kernel-package/Flavours.gz
file is obsolete (Note: This involves modifying the kernel sources top
level Makefile). Also, if recompiling and using a different flavour,
one needs to do a make-kpkg clean in between compiles.
Please see kernel-pkg.conf (5).
""""""
Reply to: