Bug 1302072 - kickstarting RHEL5 from Proxy server on RHEL6 fails
kickstarting RHEL5 from Proxy server on RHEL6 fails
Product: Red Hat Satellite Proxy 5
Classification: Red Hat
Component: Server (Show other bugs)
All Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Gennadii Altukhov
Red Hat Satellite QA List
Depends On:
Blocks: sat570-triage
  Show dependency treegraph
Reported: 2016-01-26 12:21 EST by Fotios Tsiadimos
Modified: 2016-06-22 07:43 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-06-22 07:43:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2195961 None None None 2016-03-10 13:48 EST

  None (edit)
Description Fotios Tsiadimos 2016-01-26 12:21:58 EST
Description of problem:
While kickstarting from proxy server we get this error in the install.log on the client:
Installing kernel-2.6.18-398.el5.x86_64
error: unpacking of archive failed on file /boot/vmlinuz-2.6.18-398.el5;56495c6d: cpio: read
 and the server fails to boot because it can not find the kernel to boot off of

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

How reproducible:
Satellite Proxy 5.5, 5.6 and 5.7 installed RHEL6. Trying to kickstart a RHEL5 system it fails. Works when kickstarting a RHEL6 or RHEL7

RHN Satellite Proxy 5.6 on a RHEL5 and we were able to provision the system without any issues.
Comment 1 Tomas Lestach 2016-01-27 03:57:55 EST
Just got an confirmation from QA, they're able to kickstart RHEL5 over RHN Proxy on RHEL6 without any issues. This does not look to be a RHN Proxy bug.

Make sure, the kernel-2.6.18-398.el5.x86_64.rpm has the right size/checksum.
Comment 4 Gennadii Altukhov 2016-02-17 04:34:03 EST
Comment 10 Gennadii Altukhov 2016-03-14 12:52:47 EDT
Yes, I can reproduce the bug and after some investigation I have:

1) There are, actually, 2 bugs:
- On the side of Proxy (squid)
- On the side of Anaconda (for RHEL 5).

2) Why it happens for RHEL 5 and doesn't for RHEL 6?
Installation of packages by Anaconda can be divided on 3 steps:

Downloading of metadata for a repository: repodata/repomd.xml, primary.xml.gz, comps-rhel5-vt.xml, filelists.xml.gz

Extract from metadata (primary.xml) information about range of RPM-header for every package, something like this:
<rpm:header-range start="440" end="19045"/>

and download RPM-header with range GET request, e.g.:

GET /ty/5cuO9OQ6/Server/kernel-2.6.18-398.el5.x86_64.rpm HTTP/1.1^M
Accept-Encoding: identity^M
Range: bytes=440-996355^M
Connection: close^M
Host: dhcp131-19.brq.redhat.com^M
User-agent: urlgrabber/3.1.0 yum/3.2.22^M

In /var/log/squid/access.log:
363:1457694721.703    417 TCP_MISS/206 996393 GET http://dhcp131-19.brq.redhat.com/ty-cksm/fc669e3a67c667843a2105e66a8c7ab7/Server/kernel-2.6.18-398.el5.x86_64.rpm - DIRECT/ application/octet-stream

TCP_MISS/206 looks OK, we have no the package in the cache and this is Range-request (code 206).


Download all packages to install them.

In config of squid we have parameter:
range_offset_limit -1 KB
It means that squid download whole file, even range request.

Actually during downloading packages Squid do not return the whole package to Anaconda after range request.
It is possible to reproduce the bug with curl
curl -v --get \
     -H 'Host: dhcp131-19.brq.redhat.com' \
     -H 'Connection: close' \
     -H 'Accept-Encoding: identity' \
     -H 'Range: bytes=440-996355' \
     -A 'urlgrabber/3.1.0 yum/3.2.22' \
     'http://dhcp131-19.brq.redhat.com/ty/5cuO9OQ6/Server/kernel-2.6.18-398.el5.x86_64.rpm' -o kernel-2.6.18-398.el5.x86_64.rpm-head

curl -v --get \
     -H 'Host: dhcp131-19.brq.redhat.com' \
     -H 'Connection: close' \
     -H 'Accept-Encoding: identity' \
     -A 'urlgrabber/3.1.0 yum/3.2.22' \
     'http://dhcp131-19.brq.redhat.com/ty/5cuO9OQ6/Server/kernel-2.6.18-398.el5.x86_64.rpm' -o kernel-2.6.18-398.el5.x86_64.rpm

You will see an error 
curl: (18) transfer closed with 20755079 bytes remaining to read

The same error in anaconda.log, but on RHEL 6 Anaconda tries to download package again, e.g.:

15:26:33,326 WARNING : Try 1/10 for http://dhcp131-19.brq.redhat.com/ty/6BGjRC8Z/Packages/kernel-firmware-2.6.32-573.el6.noarch.rpm failed: [Errno 14] PYCURL ERROR 18 - "transfer closed with 9163780 bytes remaining to read"
15:26:33,579 WARNING : Failed to get http://dhcp131-19.brq.redhat.com/ty/6BGjRC8Z/Packages/kernel-firmware-2.6.32-573.el6.noarch.rpm from mirror 1/1, or downloaded file is corrupt
15:26:33,581 WARNING : package download failure, retrying automatically
Comment 11 Gennadii Altukhov 2016-03-14 12:55:45 EDT
As a workaround you can do:
- Downgrade squid to version squid-3.1.10-29.el6.x86_64
yum downgrade squid-3.1.10-29.el6.x86_64


- change squid config

remove: range_offset_limit -1 KB
add: request_header_access Range deny all
Comment 12 Gennadii Altukhov 2016-03-15 07:50:47 EDT
Anaconda Bug 1317864
Comment 13 Gennadii Altukhov 2016-03-21 07:13:43 EDT
Squid Bug 1319705
Comment 14 Tomas Lestach 2016-05-13 10:03:11 EDT
The blocking squid issue has been fixed in RHEL 6.8 (Bug 1319705) and the plan is to backport the fix to RHEL 6.7.z (Bug 1322709).

Based on that I'm switching this BZ to ON_QA.
Comment 15 Radovan Drazny 2016-05-19 09:17:06 EDT
Tested with squid-3.1.23-16.el6 containing the fix for BZ 1319705. Performed reprovisioning of RHEL 5 client via RHN Proxy on RHEL 6 server 30 times, never failed, always went through without any problem.


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