From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) Description of problem: When upgrading a system 7.1 to 7.2, since kernel is already 2.4.9-21, the installer does not rewrite boot block, if you upgrade from lilo to grub, grub will not function, and system will not be bootable. Furthermore, at end, when making boot floppy, it will fail, and you won't have any easy way to boot this system. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Update a RH-7.1 system to last kernel released. 2.Upgrade this system to RH-7.2 choosing grub as boot loader 3.Keep default boot floppy creation. Actual Results: System wont boot with just a plain "LI" (part of lilo). Expected Results: Bootblock should be writen anywhere, anytime, when making a major upgrade... Additional info: There is a tricky way to make this system bootable again: -booting from an installation floppy or CDROM (but not from PXE network, why ?) and typing at prompt: vmlinuz single root=/dev/hda3 (change to right partition) -then grubinstall -then force a kernel upgrade: rpm -Uvh --force kernel-...rpm otherway: uninstall current kernel before making RH-7.2 upgade (Humph! Humph!)
For the first part -- did you select to install GRUB to the same location that you had previously installed LILO (ie installed to MBR in both cases)? That's the only case I know of this causing what you describe. As to the boot floppy creation failing, how did it fail?
It did happen once more, when I was upgrading another server from 7.1 to 7.2. Our 4 Linux servers share the same hardware configuration : Dual Pentium ASUS card with Mylex DAC960 Raid-5 controller (3 x 17 Go Disk + 1 spare). All of them had the latest (at that time) RPMs provided by RH for 7.1 i.e. kernel 2.4.9-31. Using the graphic display dialog when upgrading, I choose to convert all the partitions in this logical set to ext3: /boot (32Mo), / (about 17Go, /home:disk2 (17 Go), and to use GRUB instead of LILO on MBR. I did no customization to the selected RPMs, and all the upgrade seemed to go right until I had to create the boot floppy. Then I got the message : No kernel packages were installed on your system. Your boot loader configuration will not be changed. - Obviously since my present kernel was more recent than the one on the RH 7.2 distrib. Then I got the dialog to insert a new formatted floppy and things get worse : An error occurred while making the boot disk. Please make sure that there is a formatted floppy in the first floppy drive. Yes, there it was! Both the floppy, the drive and anything else was OK. Just something soft prevented it to write this floppy. So I had to skip this floppy creation to bypass this dialog (I tried several times). When I rebooted again this system I came on a failed LILO prompt : LI (despite it said that your boot loader configuration will not be changed). I could not use the usual trick to boot the start floppy with vmlinuz single root=/dev/rd/c0d0p3, since the DAC960 driver is not available at this point and I had to use rescue mode, chroot to /mnt/sysimage, then edit lilo.conf.anaconda since it had already tried to install GRUB, and write again the boot block. So, it can boot again (using LILO, not GRUB, because of another bug #56271, I cant install GRUB with a DAC960 system). Also, I cant even make a boot floppy (mkbootdisk), I get this sibylline message fs type MSDOS/vfat not supported by kernel (!) though I use a plain, standard, kernel-enterprise 2.4.9-31 now, and it just can read/write Windows floppies, as usual
Ugh, this is because we aren't installing a kernel so can't write out our own bootloader config (because we don't know enough about what you had installed before) and by updating lilo, you move the bootblocks without updating LILO's bootblock map. I'm wondering if the problem with mkbootdisk is somehow related to the size being larger than the disk can hold. What do you get if you run `/sbin/mkbootdisk --verbose`
Yes! there is a problem with floppy size: >Insert a disk in /dev/fd0. Any information on the disk will be lost. >Press <Enter> to continue or ^C to abort: >Formatting /dev/fd0... done. >Copying /boot/vmlinuz-2.4.9-31... done. >Creating initrd image... >gzip: stdout: No space left on device >done. >Setting up syslinux... cat: write error: No space left on device >done. This can't be solved while upgrading, because there's no way to choose another device, maybe I can try to make a boot disk on a ZIP floppy later, when system is running OK?
Well, we've implemented two things which will help for the next release -- better handling of bootloader configuration on upgrades to make it a lot less likely that you'll get shot in the foot and linking things that get put on the initrd against dietlibc (which makes them smaller so that you can fit more large modules on the floppy). I will look at making the boot floppy creation failure case more explicit as to the "why" it failed, though
Fixing mkbootdisk to pass these errors back properly is a lot of code changes. Will revisit for a future release as this isn't a regression from older releases
Added code to just try to verify that the boot disk was written out sanely by looking at sizes of files written out and comparing to "known good"
I'm going through Bugzilla closing some bugs that have been marked as Modified for some period of time. I believe that most of these issues have been fixed, so I'm resolving these bugs as Rawhide. If the bug you are seeing still exists, please reopen this report and mark it as Reopened.