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
Version-Release number of selected component (if applicable):
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
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 force a kernel upgrade: rpm -Uvh --force kernel-...rpm
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.
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
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
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
>Setting up syslinux... cat: write error: No space left on device
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.