Bug 57233 - up2date hung during kernel upgrade 2.4.2-2 to 2.4.9-12
Summary: up2date hung during kernel upgrade 2.4.2-2 to 2.4.9-12
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date
Version: 7.1
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: 2001-12-07 16:22 UTC by bil kleb
Modified: 2015-01-07 23:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-05-21 18:38:06 UTC
Embargoed:


Attachments (Terms of Use)


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 bil kleb 2001-12-07 16:22:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
I read http://www.redhat.com/support/resources/howto/kernel-upgrade/ and
updated my up2date before starting, viz,

  # rpm -q up2date
  up2date-2.7.11-7.x.1

Then I ran up2date to go from the 2.4.2-2 kernel to the 2.4.9-12 kernel,
and up2date hung during the installation phase.

Note: I selected "all" the packages normally marked to skipped, i.e., the
kernel rpms; the dependency checking added many more packages to update.  I
did not select any packages
to update in the "normal" menu.

I have stuck the standard error from the up2date run in the Actual Results
section.

It did not update lilo.conf (included in the additional information
section).

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


How reproducible:
Didn't try


Actual Results:  # up2date
error: cannot remove /usr/src/linux-2.4.2 - directory not empty
error: cannot remove /var/lib/rpm - directory not empty
error: cannot remove /usr/local/man/man4 - directory not empty
error: cannot remove /usr/local/man/man3 - directory not empty
error: cannot remove /usr/local/man/man1 - directory not empty
error: cannot remove /usr/local/man - directory not empty
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 61, in
whichBootLoader
    fd = os.open(bootDev, os.O_RDONLY)
OSError: [Errno 2] No such file or directory: '"/dev/hda"'

Expected Results:  The kernel should have been upgraded without hanging.

Additional info:

# cat /etc/lilo.conf 
boot="/dev/hda"
map=/boot/map
install=/boot/boot.b
prompt
timeout="50"
message=/boot/message
linear
default=GNUlinux

image="/boot/vmlinuz-2.4.2-2"
	label="GNUlinux"
	read-only
	root="/dev/hda6"

other=/dev/hda1
	label="winME"

Comment 1 bil kleb 2001-12-07 18:12:52 UTC
I changed /etc/lilo.conf by hand (see below), issued lilo -v -v, and rebooted
the machine successfully with the new kernel.

# cat /etc/lilo.conf
boot="/dev/hda"
map=/boot/map
install=/boot/boot.b
prompt
timeout="50"
message=/boot/message
linear
default=GNUlinux
 
image="/boot/vmlinuz-2.4.9-12"
        label="GNUlinux"
        read-only
        root="/dev/hda6"
 
image="/boot/vmlinuz-2.4.2-2"
        label="linux2.4.2-2"
        read-only
        root="/dev/hda6"
 
other=/dev/hda1
        label="winME"

Comment 2 Adrian Likins 2001-12-10 19:43:39 UTC
it's the line:
boot="/dev/hda"

up2date doesnt no how to handle the quotes. It's breaking on that.

Interesting. I didnt realize that lilo supported quoting that 
argumen. Doesnt look like any of my lilo.confs in the test suite
quote that argument either. Looks like your lilo.conf gets added
to the test suite.

I'll fix it so that up2date understands that argument properly
for the next release.

Just out of curiosity, what generated this lilo.conf? was it
a standard tool or edited by hand? Just curious because it's
the first one I've seen that way.




Comment 3 bil kleb 2001-12-11 04:12:55 UTC
AFAICR, it was generated during a 7.1 upgrade with dma turned off; but I could
easily be wrong about that since the install did not go well.

Comment 4 Adrian Likins 2002-03-07 00:00:25 UTC
This should be fixed in the next release of the client.

Comment 5 Matt Jamison 2003-05-21 18:38:06 UTC
resolving bug.  
reopen if needed.


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