Bug 59867
Summary: | mkbootdisk errors not captured | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Jean Berthomieu <berthoms> |
Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-05-25 14:53:38 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jean Berthomieu
2002-02-14 00:29:45 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? 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. |