Bug 146820 - Pkgs with names longer than 79 chars cause problems for genhdlist
Summary: Pkgs with names longer than 79 chars cause problems for genhdlist
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords: Patch
: 146821 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-02-01 21:29 UTC by James Olin Oden
Modified: 2012-06-20 16:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 16:10:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Makes genhdlist dynamically allocate the buffer for each line. (2.52 KB, patch)
2005-02-01 21:32 UTC, James Olin Oden
no flags Details | Diff
Patch against anaconda HEAD (2.52 KB, patch)
2005-02-14 16:35 UTC, James Olin Oden
no flags Details | Diff

Description James Olin Oden 2005-02-01 21:29:05 UTC
Description of problem:
If you try to use the --fileorder option of genhdlist and some of 
the rpms you had pkgorder scan hand file names longer than 79 
characters, then the behavior of genhdlist is non-deterministic.
Depending on the length of the package names it may fail outright, 
generate a "halfway" sorted package list, or something that is just
wrong.  If your lucky it will actually fail the sanity check on the
filename, if not it will not "fail" and you won't find out anythings
wrong until you install the generated media on a system and things 
get installed in a very wrong order (or worse, almost right order).

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

How reproducible:
Always (though the extent of the damage is variable)

Steps to Reproduce:
1. In a valid rpm repository preped for building anaconda media
   add a couple rpms whose names are longer than 79 characters.
2. Now run genhdlist, pkgorder, and genhdlist with the proper options
   as you would when building the media.

  
Actual results:
Depends on your package names (things with lots of -'s in the name
will pass the sanity test).  Either it fails the filename sanity, or
you end up with packages sorted wrong.

Expected results:
No problems whatsoever.

Additional info:
The problem is trivial.  Though pkgorder does not care about the size 
of the lines it prints genhdlist creates a static buffer of 80 chars,
and one must be used for \0.  Just need to change it to dynamically
allocate its buffer as needed.  I have a patch for this and will 
attach it.

BTW, if you follow the earlier Fedora notes on building kernel 
modules in seperate rpms, you end up with some really long filenames 
for the kernel module rpms (kernel-module-somemod-%(uname -r)-1-
1.rpm, increase the length of the original kernel release and the 
kernel modules release, and, hypothetically speaking of course, you 
will exceed 79 chars).

Comment 1 James Olin Oden 2005-02-01 21:32:10 UTC
Created attachment 110528 [details]
Makes genhdlist dynamically allocate the buffer for each line.

Inline I implement a _fgets() that does a read ahead to figure out the size of
the malloc needed, then mallocs the buffer, and fills it returning the pointer.

I tried to still give it similar semantics to fgets(), so you still can't tell
if you reached EOF or you had an error.  Might consider changing some of the
return NULL's to abort().   Also, I did not deallocate the memory...I can send
a patch with being done if desired.  genhdlist only runs for about a second and
its gone, so the memory gets "freed" anyway, so I did not worry about it too
much.

Comment 2 James Olin Oden 2005-02-01 21:34:05 UTC
*** Bug 146821 has been marked as a duplicate of this bug. ***

Comment 3 Paul Nasrat 2005-02-01 22:01:02 UTC
Thanks for the patch James.



Comment 4 Paul Nasrat 2005-02-14 04:41:16 UTC
Would you mind rediffing against HEAD, thanks.

Comment 5 James Olin Oden 2005-02-14 14:02:52 UTC
Sure, where do I go to get anaconda CVS?  Any special magic to download it?
You can point to a web page with info if you like?

Thanks...juames

Comment 6 Paul Nasrat 2005-02-14 15:46:33 UTC
Cheers:

http://fedora.redhat.com/projects/anaconda-installer/

export CVSROOT=:pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS
cvs -z3 login
cvs -z3 co anaconda

Comment 7 James Olin Oden 2005-02-14 16:35:52 UTC
Created attachment 111059 [details]
Patch against anaconda HEAD

You guys had changed it to be a static buffer of 256 bytes (which is much
longer),
so that is where the reject occured.  Anyway, this patch should apply clean
against anconda cvs HEAD branch.

Cheers...james

Comment 8 Paul Nasrat 2005-03-14 07:03:47 UTC
Sorry for the delay - applied.

Comment 9 Red Hat Bugzilla 2007-08-21 05:19:41 UTC
User pnasrat@redhat.com's account has been closed

Comment 10 Jiri Pallich 2012-06-20 16:10:10 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.


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