Red Hat Bugzilla – Bug 146820
Pkgs with names longer than 79 chars cause problems for genhdlist
Last modified: 2012-06-20 12:10:10 EDT
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):
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.
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.
No problems whatsoever.
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
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).
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
*** Bug 146821 has been marked as a duplicate of this bug. ***
Thanks for the patch James.
Would you mind rediffing against HEAD, thanks.
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?
cvs -z3 login
cvs -z3 co anaconda
Created attachment 111059 [details]
Patch against anaconda HEAD
You guys had changed it to be a static buffer of 256 bytes (which is much
so that is where the reject occured. Anyway, this patch should apply clean
against anconda cvs HEAD branch.
Sorry for the delay - applied.
User email@example.com's account has been closed
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.