This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 5138 - when usiThe newest boot images broke bootloader part of the installation
when usiThe newest boot images broke bootloader part of the installation
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
6.0
i386 Linux
high Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-09-14 17:48 EDT by kresa
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-09-20 14:27:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kresa 1999-09-14 17:48:30 EDT
When using the newest (09-Sept-1999) boot.img and
bootnet.img, the lilo (bootloader) part of installation
fails. In the log virtual console it says that insmod loop.o
failed, although i'm not sure how is that connected.

Might be that the loop.o doesn't fit the installation kernel
version. insmod in the installation doesn't have the -f
option so i couldn't check that.

When using older boot images everything works fine.
Comment 1 reimer 1999-09-20 08:30:59 EDT
I experienced the same bug when using the latest (09/09/99)
bootnet.img with NFS install. But from my experience the bug already
shows up when the boot disk is created (one step before lilo setup).

Virtual console 3 shows:

> running: /bin/insmod /bin/insmod /modules/loop.o
> insmod failed!

On virtual console 2 I tried manually:

  /bin/insmod /modules/loop.o

and I got the following error message:

> /modules/loop.o: kernel-module version mismatch
> /modules/loop.o was compiled for kernel version 2.2.5-14BOOT
> while this kernel is version 2.2.12-2.6.0BOOT

Resolution: So IMHO the problem could be easily solved by supplying
appropriate upgrade modules for kernel 2.2.12-2.6.0BOOT and replacing
the modules in redhat-6.0/i386/RedHat/instimage/modules/ which is
mounted as /modules/ in the install2 stage.

Regards, Wolfgang.
PS: I already replaced
redhat-6.0/i386/RedHat/instimage/usr/bin/install2 by the new
(09/13/99) executable updates/6.0/images/i386/install2 (BTW, this new
install2 executable is not mentioned anywhere on
http://www.redhat.com/corp/support/errata/RHEA1999036_01.html)
Comment 2 Bill Nottingham 1999-09-20 14:27:59 EDT
This is not a bug - you must force a supplementary disk. From
the annoucement:

8. Solution:
   Three disks are needed for Intel based computers: "boot.img" or
"bootnet.img", "supp.img", and "modules.img". Choose "boot.img" for
local
   installs (CD-Rom, hard drive) or "bootnet.img" for network installs
(NFS, FTP, HTTP). Copy the three images to 1.44 MB floopy disks using:
dd
   if=file.img of=/dev/fd0 bs=72k under Linux or "rawrite.exe" under
DOS or Windows.

   After preparing the disk images, insert the appropriate boot disk
and boot the computer. At the boot prompt type "linux supp" and press
Enter.
   This tells the installer to load changes from the supplemental and
modules disks. The installer will prompt the user to insert the
supplemental
   disk and modules disk during the installation process.
Comment 3 pq 1999-09-21 12:31:59 EDT
Marking this as resolved would seem most unfortunate for us
and maybe other people using kickstart. Once we have Linux
installed we do automatic reinstalls by booting the bootnet
image from /boot - i.e. we never use any floppies. If we then
have to go round each machine and insert a floppy we lose a lot
of the convenience of the RedHat kickstart install when
(re)installing a teaching laboratory full of machines.
(Precis - the old bootnet images still work for our hardware
but we would be upset if the general mechanism changed).
Paul Quare
Dept Computer Science, Manchester University, U.K.
Comment 4 pq 1999-09-22 04:55:59 EDT
Marking this as resolved would seem most unfortunate for us
and maybe other people using kickstart. Once we have Linux
installed we do automatic reinstalls by booting the bootnet
image from /boot - i.e. we never use any floppies. If we then
have to go round each machine and insert a floppy we lose a lot
of the convenience of the RedHat kickstart install when
(re)installing a teaching laboratory full of machines.
(Precis - the old bootnet images still work for our hardware
but we would be upset if the general mechanism changed).
Paul Quare
Dept Computer Science, Manchester University, U.K.
Comment 5 reimer 1999-09-22 08:53:59 EDT
Although not mentioned by RedHat (may be they want to keep it a secret
;-), there is also a resolution other than telling the installer to
load changes from the supplemental and modules disks. Some parts of
the RedHat/instimage and RedHat/base directories must be updated. This
can be done by extracting the necessary stuff from the new (09/09/99)
supp.img and modules.img files and using the new (09/13/99) install2
executable. The following procedure works for me (and should work for
others as well):


For CD-ROM and NFS installs:
----------------------------

1) Replace RedHat/instimage/usr/bin/install2 by the new (09/13/99)
executable
ftp://ftp.redhat.com/pub/redhat/updates/6.0/images/i386/install2.

2) Replace the modules in RedHat/instimage/modules/ by the one
supplied in the new (09/09/99) modules.img.

2a) You can extract the modules from modules.img as follows:

    mkdir /mnt/modules_disk
    mount -o loop modules.img /mnt/modules_disk
    gzip -cd /mnt/modules_disk/modules.img >/var/tmp/modules_img
    mkdir /mnt/modules
    mount -o loop /var/tmp/modules_img /mnt/modules

2b) Copy the modules from /mnt/modules/ to RedHat/instimage/modules/.


For FTP and HTTP installs:
--------------------------

The file RedHat/base/stage2.img must be replaced by an updated one. A
new version of stage2.img can be created as follows:

3) Perform step 2a) to extract the modules directory (if not done
yet).

4) Extract the stuff supplied in the new (09/09/99) supp.img. This can
be done as follows:

   mkdir /mnt/supp_disk
   mount -o loop supp.img /mnt/supp_disk
   gzip -cd /mnt/supp_disk/stage2.img >/var/tmp/supp_img
   mkdir /mnt/supp
   mount -o loop /var/tmp/supp_img /mnt/supp


5) Create a new stage2.img:

5a) Create and mount an empty ext2 fs image for stage2.img:

   dd if=/dev/zero of=/var/tmp/stage2_img bs=1k count=3500
   mke2fs -N 224 -m 0 -F /var/tmp/stage2_img
   mkdir /mnt/stage2
   mount -o loop /var/tmp/stage2_img /mnt/stage2

5b) Copy the required directories from supp.img and modules.img to
file system for stage2:

   cp -a /mnt/supp/{lib,usr,var} /mnt/stage2
   cp -a /mnt/modules /mnt/stage2

5c) Umount and compress the image to get the new stage2.img file:

   umount /mnt/stage2
   gzip -9c /var/tmp/stage2_img >/var/tmp/stage2.img

5d) Copy /var/tmp/stage2.img to RedHat/base/stage2.img

Hope this helps.

Regards, Wolfgang.

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