Bug 57233 - up2date hung during kernel upgrade 2.4.2-2 to 2.4.9-12
up2date hung during kernel upgrade 2.4.2-2 to 2.4.9-12
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-07 11:22 EST by bil kleb
Modified: 2015-01-07 18:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-21 14:38:06 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 bil kleb 2001-12-07 11:22:48 EST
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 13:12:52 EST
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 14:43:39 EST
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-10 23:12:55 EST
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-06 19:00:25 EST
This should be fixed in the next release of the client.
Comment 5 Matt Jamison 2003-05-21 14:38:06 EDT
resolving bug.  
reopen if needed.

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