Bug 59867 - mkbootdisk errors not captured
Summary: mkbootdisk errors not captured
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-14 00:29 UTC by Jean Berthomieu
Modified: 2007-04-18 16:40 UTC (History)
0 users

Clone Of:
Last Closed: 2003-05-25 14:53:38 UTC

Attachments (Terms of Use)

Description Jean Berthomieu 2002-02-14 00:29:45 UTC
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):

How reproducible:

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

uninstall current kernel before making RH-7.2 upgade (Humph! Humph!)

Comment 1 Jeremy Katz 2002-02-14 20:14:06 UTC
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?

Comment 2 Jean Berthomieu 2002-03-11 16:57:03 UTC
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

Comment 3 Jeremy Katz 2002-03-11 20:27:59 UTC
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`

Comment 4 Jean Berthomieu 2002-03-16 15:49:25 UTC
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?

Comment 5 Jeremy Katz 2002-03-16 18:31:32 UTC
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

Comment 6 Jeremy Katz 2002-04-10 21:50:03 UTC
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

Comment 7 Jeremy Katz 2003-01-03 05:58:13 UTC
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"

Comment 8 Brent Fox 2003-05-25 14:53:38 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.