Bug 119538 - up2date not downloading/installing kernel
Summary: up2date not downloading/installing kernel
Keywords:
Status: CLOSED DUPLICATE of bug 119208
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date
Version: rawhide
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
URL:
Whiteboard:
Depends On:
Blocks: up2date-fc2
TreeView+ depends on / blocked
 
Reported: 2004-03-31 08:27 UTC by Gene Czarcinski
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 19:02:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Gene Czarcinski 2004-03-31 08:27:17 UTC
Description of problem:

Clean everything install of FC2-T2.  When updated packages appeared in
development, I attempted to update.  For the first update, I only
selected the kernel packages (yes, selected from the "flagged to be
skipped").

All packages were downloaded except the kernel itself the the progress
bar displayed that the download was NOT complete although the message
was displayed to proceed to install.

This may be a dup of
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118566
I cannot tell from the text of that report.

Comment 1 Gene Czarcinski 2004-03-31 15:26:24 UTC
Bad news, bad news.  This problem may be worse than it originally appears.

I attempted to update the four amanda-* packages plus anaconda,
anconda-runtime, and a2ps.  All packages appeared to be downloaded and
then the install ... the install progress bar did not complete
although the "finish" message appeared.  When I went to the next
frame, it indicated that all packages were installed and, by checking
with rpm, anaconda, anaconda-runtime, a2ps, amanda-client,
amanda-devel, and amanda-server were.  However, the amanda packages
was not missing!  I checked the install.log and it had been installed.

Comment 2 Gene Czarcinski 2004-03-31 15:59:29 UTC
Well, looks like this is another selinux permissions thing.  I logged
in as root and tried to manually install amanda and got:

rpm -Uvh /var/spool/up2date/amanda-2.4.4p2-3.x86_64.rpm
Preparing...               
########################################### [100%]
error: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
error: %pre(amanda-2.4.4p2-3) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping amanda-2.4.4p2-3

I then switched to permissive mode using the setenforcing command and
amanda installed fine.

I also tried manually installing the kernel under enforcing mode and got:

rpm -ivh /var/spool/up2date/kernel-2.6.4-1.298.x86_64.rpm
Preparing...               
########################################### [100%]
error: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
error: %pre(kernel-2.6.4-1.298) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping kernel-2.6.4-1.298

Comment 3 Russell Coker 2004-04-01 02:12:49 UTC
Currently we don't support doing this as staff_r. 
 
The idea is that you use the sysadm_r role to upgrade/install 
packages. 

Comment 4 Aleksey Nogin 2004-04-01 02:27:57 UTC
A part of the problem is that /usr/sbin/up2date is not an rpm_exec_t -
see bug 119208.

Comment 5 Gene Czarcinski 2004-04-02 22:26:59 UTC
This is really getting to be a BIG problem.

This time it was gdm.  I tried to update to gdm 2.6.0 and up2dte said
it did (but the progress bar was short so I checked).  Oops, gdm is
NOT installed.

OK, install ... lots of error messages.  Do "setenforce 0" and then
manually install oldpackage .. fine ... install the new package ... fine.

My big problem is that there is NOT record that rpm had a problem!

Comment 6 Aleksey Nogin 2004-04-02 23:55:15 UTC
What does "ls -Z /usr/sbin/up2date" says? If it's not an rpm_exec_t,
then you are using an old policy (or did not relabel files after
installign a new one) and you are seeing bug 119208.

Comment 7 Daniel Walsh 2004-04-03 13:23:37 UTC
Fixing up2date is a multi step process.

One update to latest policy.
restorecon /usr/sbin/up2date

update to latest usermode

Add 
ROLE=sysadm_r
TYPE=rpm_t
to
/etc/security/console.apps/up2date.




Comment 8 Gene Czarcinski 2004-04-03 14:30:52 UTC
I wish this was just SELinux and security policy related but I do not
believe that is the complete problem.  Yes, you can fix the stuff
mentioned above and that will definitely help.  However, does that
still leave the possibility that rpm could fail actually doing an
install but up2date says everything is OK?  I would have thought that
the policy failures would have been caught.

Comment 9 Adrian Likins 2004-04-05 19:06:57 UTC
>I wish this was just SELinux and security policy related but I do not
>believe that is the complete problem.  Yes, you can fix the stuff
>mentioned above and that will definitely help.  However, does that
>still leave the possibility that rpm could fail actually doing an
>install but up2date says everything is OK? 

Yup, that can happen. I wish it couldn't, but it can. Depending
on the failure mode, rpm will not report any errors after failing
to install a package.  

rpm-python is changing at the moment, so hopefully this can be
fixed. 

Comment 10 Gene Czarcinski 2004-04-05 20:03:56 UTC
Well I seem to have the reverse midas touch because it happens to me a
lot.

I have two systems with FC2-T2 in test one ix86 and one x86_64.  I can
see the problem with kernel installs because it is also there for a
manual rpm -ivh unless i do "setenforce 0".  However, some packages
will install OK on one system but not on the other.  The delete
without install problem leaves the files installed but removes
everything from rpmdb  -- had that happen with the recent gdm and
xorg-x11 packages and then it did not install xorg-x11-xdm ... that
all happened on one system (ix86) ... on the x86_64, it skipped
installing xorg-x11-xfs but that is all.

Comment 11 Michael J. Kofler 2004-04-09 02:44:10 UTC
Same problem here as original and comments 1,2 above, with same
output. Not sure why root isn't sysadm or how to make it so, but
turning off SELinux resulted in a proper install as follows:
[root@endor root]# rpm -ivh
/root/Desktop/kernel-smp-2.6.5-1.308.i686.rpm
/root/Desktop/kernel-2.6.5-1.308.i686.rpm
Preparing...               
########################################### [100%]
error: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
error: %pre(kernel-2.6.5-1.308) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping kernel-2.6.5-1.308
error: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
error: %pre(kernel-smp-2.6.5-1.308) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping
kernel-smp-2.6.5-1.308
[root@endor root]# rpm -ivh
/root/Desktop/kernel-smp-2.6.5-1.308.i686.rpm
/root/Desktop/kernel-2.6.5-1.308.i686.rpm
Preparing...               
########################################### [100%]
warning: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
Continuing ...
   1:kernel                
########################################### [ 50%]
warning: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
Continuing ...
WARNING: /lib/modules/2.6.5-1.308/unsupported/fs/reiserfs/reiserfs.ko
needs unknown symbol sleep_on
warning: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
Continuing ...
   2:kernel-smp            
########################################### [100%]
warning: setexeccon(root:staff_r:rpm_script_t) fails from context
"root:staff_r:staff_t": Invalid argument
Continuing ...
WARNING:
/lib/modules/2.6.5-1.308smp/unsupported/fs/reiserfs/reiserfs.ko needs
unknown symbol sleep_on
[root@endor root]# rpm -q kernel-smp
kernel-smp-2.6.4-1.305
kernel-smp-2.6.5-1.308
[root@endor root]#


Comment 12 Aleksey Nogin 2004-04-09 04:23:12 UTC

*** This bug has been marked as a duplicate of 119208 ***

Comment 13 Red Hat Bugzilla 2006-02-21 19:02:17 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


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