Re: [release+kernel] upgrade headache
Hi! Sorry, not got 24/7 net access, so I've not got any
mail since this one. Either way, I eventually fixed it
myself in the meantime.
[snip]
> If you are using a debian stock kernel, try adding the module for your
> scsi card, scsi_mod, sg, etc. to /etc/modules. Check /boot/config-2.2.x
> to see which modules were compiled into your previous kernel.
I had already added the modules for them to /etc/mkinitrd/modules, but
it hadn't occurred to me to use /etc/modules too. I wasn't sure if
you meant it would tell mkinitrd what modules were needed, or if
it would be used at boot time... I did so anyway, and included the
file in the initrd image. It didn't seem to help (and there wasn't
anything in cofig-2.2.x that I didn't already know, but good idea
anyway).
> Alternative: install the 2.4 kernel source deb and compile in support
> for your scsi card. If you compile your own kernel, you don't need to
> use initrd.
Sure, but it would seem to be missing the point of initrd if it *didnt*
let you boot on nearly anything by default...
[snip]
> 2.4 stock kernels are highly modularized. Modules that were compiled
> into the 2.2 kernels now have to be loaded--hence the initrd.
I can appreciate that, but my point had been that if the kernel package
wasn't supported on all configurations, a warning should have been
given (I did later find that the kernel setup and image weren't quite at
fault- but an important detail hadn't been mentioned).
[snip]
> > -(2) The mkinitrd docs seem hard to follow;
> > -(3) Having used mkinitrd several times, trying various things with
> > its config files, I *still* cannot get an initrd image that will
> > get the kernel to boot. It does appear that the advansys.o,
> > scsi_mod.o, sd_mod.o, ext2.o files *are* already in the image- but
> > the kernel doesn't seem interested in loading them.
> The kernel installation scripts should create the initrd image you
> need, However, you will need to tell the kernel what modules need to be
> loaded.
Again, unfortunately the mkinitrd docs weren't entirely clear on how
things were actually done. It sounded like /etc/mkinitrd/modules
specified what modules would be loaded before trying to mount root,
but *didn't* automatically put them in the image. Mkinitrd gives
no messages except for errors and you can't mount the image on a
2.2 kernel (because the fstype is newer) so it's very hard to know
what is being put in the image.
Well, after much hunting through various docs, I found a mention
that lilo should be passing the kernel parameter "init=/linuxrc".
I had read about how linuxrc was run when the ramdisk image was loaded,
but nothing else had suggested that you needed to tell the kernel to
do so explicitly- the warning when installing the kernel image just
said something like "add initrd=/initrd.img to the image=/vmlinuz
stanza", and thats all. Well it now works, but I'd be surprised
if no-one else ever gets this wrong.
For anyone who wants to know, my lilo.conf is now:
boot=/dev/sda1
root=/dev/sda1
install=/boot/boot.b
map=/boot/map
delay=20
image=/vmlinuz
initrd=/boot/initrd.img-custom
append="mem=240M init=/linuxrc"
label=Linux
read-only
image=/vmlinuz.old
append="mem=240M"
label=Old
read-only
(the mem=240M is a nasty hack for utah-glx that will be coming out
as soon as I install XFree 4.x, the vmlinuz.old bit was added after
I found the 2.4 kernel failing, so I could boot something).
So in summary, someone (prolly the kernel packager) needs to indicate
better all those initrd issues, give more complete instructions, and
perhaps suggest which docs should be read, eg /usr/doc/kernel-doc-2.4.18/
Documentation/initrd.txt.gz, although bits of this also seem out of
date.
Thanks v.much for the help, anyway. I'm prolly going to go and
pester the bttv guys for a bit now (as the new drivers still lock up :P).
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: