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).
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.
*** 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? Thanks...juames
Cheers: http://fedora.redhat.com/projects/anaconda-installer/ export CVSROOT=:pserver:anonymous.com:/usr/local/CVS 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 longer), so that is where the reject occured. Anyway, this patch should apply clean against anconda cvs HEAD branch. Cheers...james
Sorry for the delay - applied.
User pnasrat'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.