Bug 58886 - kernel install failed using software raid
Summary: kernel install failed using software raid
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-01-26 18:57 UTC by Jim Wright
Modified: 2015-01-07 23:54 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-05-22 12:43:38 UTC
Embargoed:


Attachments (Terms of Use)
/boot/grub/grub.conf (1.12 KB, text/plain)
2002-01-26 18:58 UTC, Jim Wright
no flags Details
/etc/lilo.conf (386 bytes, text/plain)
2002-01-26 18:59 UTC, Jim Wright
no flags Details
/etc/raidtab (663 bytes, text/plain)
2002-01-26 18:59 UTC, Jim Wright
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2002:044 0 normal SHIPPED_LIVE Updated up2date and rhn_register clients available 2002-03-06 05:00:00 UTC
Red Hat Product Errata RHBA-2002:050 0 normal SHIPPED_LIVE Updated up2date and rhn_register clients available 2002-03-22 05:00:00 UTC

Description Jim Wright 2002-01-26 18:57:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13 i686)

Description of problem:
ran graphical up2date to install kernel-2.4.9-21 and friends.  I have software
raid to mirror all my partitions.  the drives are on a pci ide card (since the
via ide on the motherboard sucks).  the installer bombed trying to find
/dev/hda.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. well, i'll only try it once so it is kind of every time.


Actual Results:  % up2date
Traceback (innermost last):
  File "/usr/share/rhn/up2date_client/gui.py", line 786, in doInstallation
    up2date.installBootLoader(kernelsToInstall)
  File "/usr/share/rhn/up2date_client/up2date.py", line 2148, in
installBootLoader
    bootloader = checkbootloader.whichBootLoader()
  File "/usr/share/rhn/up2date_client/checkbootloader.py", line 45, in
whichBootLoader
    fd = os.open(bootDev, os.O_RDONLY)
OSError: [Errno 6] No such device or address: '/dev/hda'


Expected Results:  blissful silence, and everything works.

Additional info:

the progress bars for both the package and the total transfer both show 100%. 
The package I believe it was trying to install when it bombed was 
/var/spool/up2date/kernel-source-2.4.9-21.i386.rpm.  the only active button on
the user interface is "cancel".  and of course I don't know at this point if the
install was successful or not.  (but I suspect it was.)

I see a fundamental flaw in the logic. 
/usr/share/rhn/up2date_client/checkbootloader.py looks to see if
/boot/grub/grub.conf exists, and if it does then the code assumes I am using
grub.  I do not use grub, when I installed I asked for lilo to be used, and
apparently the installer dropped the grub stuff in anyway.  (since I asked for
"everything" to be installed.)

Comment 1 Jim Wright 2002-01-26 18:58:25 UTC
Created attachment 43617 [details]
/boot/grub/grub.conf

Comment 2 Jim Wright 2002-01-26 18:59:13 UTC
Created attachment 43618 [details]
/etc/lilo.conf

Comment 3 Jim Wright 2002-01-26 18:59:39 UTC
Created attachment 43619 [details]
/etc/raidtab

Comment 4 Jim Wright 2002-01-26 19:01:33 UTC
I keep telling you guys that grub is evil.  :)

Comment 5 Jim Wright 2002-01-26 19:05:37 UTC
and I just noticed that up2date updated the grub.conf file and not the lilo.conf
file.  is that worth a separate bugzilla?

Comment 6 Adrian Likins 2002-03-06 23:51:53 UTC
This should be fixed in the next version of the client. (checkbootloader.py
updates).

Comment 7 David M. Cook 2002-03-11 18:04:04 UTC
Verified by creating an /etc/lilo.conf, running /sbin/lilo, and doing an

up2date kernel

Comment 8 Jim Wright 2002-10-26 05:19:19 UTC
last week I ran up2date in graphical mode to install the 2.4.18-17.7.x kernel. 
several good things.  /etc/lilo.conf was updated correctly.  and the system
handled the software raid mirroring correctly.  looks like this one can be closed.

Comment 9 Matt Jamison 2003-05-22 12:43:38 UTC
closing bug.


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