On Thu, 11 Mar 2004 07:24:58 -0800, Jesse Keating wrote: > On Thursday 11 March 2004 04:33, Ivan Teliatnikov wrote: > > The initrd is typically used for temporarily booting the hardware into a > > state, that the real kernel vmlinuz can than take over and continue the > > booting. For example - you can't read the kernel off the scsi hard disk > > until you have a scsi driver loaded in the kernel. > > > > My /etc/grub.conf points to non-existing image. Is this correct? > > > > title Red Hat Linux (2.4.20-30.7.legacy) > > root (hd0,0) > > kernel /vmlinuz-2.4.20-30.7.legacy ro root=/dev/hda9 > > initrd /initrd-2.4.20-30.7.legacy.img > > > > I can manually create this image running command > > mkinitrd /initrd-2.4.20-30.7.legacy.img 2.4.20-30.7.legacy First of all, that command would be incorrect, because it would create the initrd image in the root directory as opposed to the /boot directory, which is on a different partition. Your grub.conf file says that you have /dev/hda1 = /boot and /dev/hda9 = /. Creation of the initrd can fail if /boot is out of space. It should be reproducible, too, i.e. * install previous kernel (-28.7) * reboot to previous kernel * erase -30.7 kernel * apt-get -30.7 kernel Is it? > Making of the initrd is part of the kernel %post script. If, for some > reason, you're using a 3rd party module in your current kernel, that > initrd thinks is required, then you should have gotten a message about the > %post script failing. In all the tests I did, I use rpm manually or with > yum, and the initrd.img was created. > > Can anybody else duplicate this failure using apt? I doubt that. There is no reason to assume that the kernel update from 28.7 to 30.7 has changed anything that would break initrd creation. --
