Bug 712313

(In reply to comment #0)
> Description of problem:
> The primary.xml files generated by satellite for custom channels are missing
> the value for 'installed' attribute:
> <size package="6666666" archive="3333333" installed=""/>
> This causes anaconda installer to fail during the installation with a kickstart
> when using this files as part of a custom kickstartable tree.

What anaconda version on what operating system is this?

Isn't this an anaconda bug, rather than Satellite bug?

What is the output of

# rpm -q spacewalk-taskomatic

on that Satellite?

jan(In reply to comment #1)
> (In reply to comment #0)
> > Description of problem:
> > The primary.xml files generated by satellite for custom channels are missing
> > the value for 'installed' attribute:
> > <size package="6666666" archive="3333333" installed=""/>
> > This causes anaconda installer to fail during the installation with a kickstart
> > when using this files as part of a custom kickstartable tree.
> 
> What anaconda version on what operating system is this?
> 
> Isn't this an anaconda bug, rather than Satellite bug?

It's a satellite bug becuase the file is generated by satellite, if you check the same file in the ISO for a RHEL5 you will see the field contains the right value, AFAIR it is used to calculate how much space you need to install all the packages.


spacewalk-taskomatic 1.2.29-45.el5sat

(In reply to comment #4)
> 
> It's a satellite bug becuase the file is generated by satellite, if you check
> the same file in the ISO for a RHEL5 you will see the field contains the right
> value,

The primary.xml.gz generated from RHN hosted have the installed attribute set to empty string as well.

IIRC, the "installed" size is not stored anywhere in the Satellite database when rpms are synced or imported, that's why it's not generated on output either. I assume it's the same in RHN hosted database schema, which means that hosted cannot include the value in the channel dumps used during satellite-sync either.

While I agree that we should look at adding the attribute value, it will not happen anytime soon.

If having that attribute set to an empty string causes anaconda to fail, please file bug against anaconda because 1) the attribute has been empty string since day one and we did not have reports about anaconda failing for this reason 2) anaconda authors will be able to address the failures much faster than the Satellite team, due to this being a database schema issue.

The installation fails only because i am using that files to create kickstartable trees for custom channels. One of the causes is that the field is empty and anaconda expects it, i guess it wouldn't do any harm if total size was shown as 'unknonw' or 'mayor than the compressed size' if the field is empty..., will redirect this to anaconda team.

What's the error message?

11:06:06 INFO    : All kickstart %%traceback script(s) have been run
11:06:06 CRITICAL: Traceback (most recent call first):
  File "/usr/lib/anaconda/yuminstall.py", line 555, in getDownloadPkgs
    totalSize += int(po.returnSimple("installedsize")) / 1024
  File "/usr/lib/anaconda/yuminstall.py", line 1143, in doPostSelection
    (self.dlpkgs, self.totalSize, self.totalFiles)  = self.ayum.getDownloadPkgs()
  File "/usr/lib/anaconda/backend.py", line 163, in doPostSelection
    return anaconda.backend.doPostSelection(anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/dispatch.py", line 223, in currentStep
    self.gotoNext()
  File "/usr/lib/anaconda/text.py", line 539, in run
    (step, instance) = anaconda.dispatch.currentStep()
  File "/usr/bin/anaconda", line 970, in ?
    anaconda.intf.run(anaconda)
ValueError: invalid literal for int(): 

11:06:06 INFO    : in run, screen = <snack.SnackScreen instance at 0x2aaaae735050>

Whatever you are using to generate primary.xml needs to fill in the proper value for the installed size.  You're providing anaconda with invalid information.

(In reply to comment #10)
> Whatever you are using to generate primary.xml needs to fill in the proper
> value for the installed size.  You're providing anaconda with invalid
> information.

While this might be true, RHN hosted and RHN Satellite have been doing this since day one. And only now anaconda started to choke on that.

Since anaconda never complained about it in the past, the installed size is not stored in the database at all, so RHN hosted and RHN Satellite will have hard time generating the value if they don't have it stored for existing content (since they never needed it).

That is why the proposal is to revert to the old behaviour of anaconda when the value was not needed.

(In reply to comment #11)
> 
> That is why the proposal is to revert to the old behaviour of anaconda when the
> value was not needed.

Hmm. Now I'm thinking of it, maybe noone has ever tried to do what the reporter does, so there was no change in behaviour of anaconda?

Jan, the primary.xml is from the custom channels, not the RH ones.

This code has not changed since 2009.  anaconda needs the installed size to do things like warn whether you have enough free disk space to install the package set you've chosen.  So yeah, whatever's creating these primary.xml files needs to get fixed.

Created attachment 585056 [details]
add installed size to repodata

Hello,

Here is a patch for your review.  This patch allows kickstarts using spacewalk-generated repodata to succeed.  The part I'm quite unsure about is how to update existing repodata; see below.

New packages, after this patch/schema update, will have an installed_size attribute.  Old packages will use the payload size.  NOTE: spacewalk is sneaky (okay, smart) and caches repodata in the database.  Even with this new code, spacewalk will continue to use the repodata in the db with an empty installed size.  You can either delete the repodata ("delete from rhnPackageRepodata" ?), delete your packages and re-import, or set this attribute in /etc/rhn/rhn.conf: user_db_repodata = false .  Except that, due to a bug(?), the last option fails miserably (commit b8dccc0a added checks for null repodata in the db to some task queries) and causes repodata to be generated with no requires/provides/etc (when using user_db_repodata=false; removing the checks generates correct repodata).

Thoughts?

(In reply to comment #17)
> Created attachment 585056 [details]
> add installed size to repodata
> 
> Hello,
> 
> Here is a patch for your review.  This patch allows kickstarts using

Joshua, great work, thank you, I have now pushed your patch to Spacewalk master, fd1e71ef69b1c5a7d8b99a836e1b291ab5654f15, and we will flesh out the rest from here.

We are currently struggling with error

Error: Package with same name already exists on server but contents differ (package recompiled).  Use --force or remove old package before uploading the newer version.
	Diff: [['installed_size', '', '']]

when rhnpushing packages.

(In reply to comment #19)
> We are currently struggling with error
> 
> Error: Package with same name already exists on server but contents differ
> (package recompiled).  Use --force or remove old package before uploading
> the newer version.
> 	Diff: [['installed_size', '', '']]
> 
> when rhnpushing packages.

Fix for this issue in Spacewalk master now, bb834f3d10f5970f3b9411c0c25ea7ceffd50ba6.

checkstyle issue ...

spacewalk.git: c5b79eba8b169bfa709885230a2c8474486fd7ee

Hi,

I've just stuck into this bug. My setup is Satellite 5.5 running over RH6.3.

The kickstart I was trying was 5.1 KS tree. I was using 4 child channels: Supplementary and Tools Child channels from RH and two extra custom channels: EPEL & VMware Tools. I tried to disable the custom ones with no luck. 

I have two questions:
1) Is there any workaround?
2) When will the commits from comments 20 and 24 reach downstream?

Thanks in advance
César

Satellite 5.6 has been released. This bug was tracked under the release.  

This bug was either VERIFIED or RELEASE_PENDING (re-verified prior shortly
before release). 

Moving to CLOSED CURRENT_RELEASE. 

Text from Upgrade Erratum follows:

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1395.html