Created attachment 435521 [details] Backtrace from Catalina.out Description of problem: I start a (reasonably long) kickstart, it runs most of the way through and then I get a File Not Found message on the machine beeing kickstarted. Version-Release number of selected component (if applicable): Will attach full list How reproducible: Consistently, but with different failing packages.
Created attachment 435522 [details] List of RPMs installed on SW server
I mentioned the bug to Justin Sherrill via IRC on Thursday. Possibly relevant information being that : * It worked 24 hours ago. * The resultant VM was unbootable (it failed to find the boot image properly) * Then I changed the partitioning setup in the kickstart to remove the use of LVM * I also commented out a couple of entries from the package install list (They take a long time to install) * Tried rebuilding the VM again, and it now fails. Yesterday with xulrunner, today with rpm-devel
Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2.
Mass-moving to space13.
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Created attachment 509585 [details] Catalina log on repo access Whenever http://spacewalk/ks/dist/child/f14updates/Fedora-14-Desktop-x86_64 or similar is accessed via the kickstart, this error happens.
(In reply to comment #0) > Created attachment 435521 [details] > Backtrace from Catalina.out > > Description of problem: > I start a (reasonably long) kickstart, it runs most of the way through and then > I get a File Not Found message on the machine beeing kickstarted. > > Version-Release number of selected component (if applicable): > Will attach full list > > How reproducible: > Consistently, but with different failing packages. The first backtrace comes from the code // Ported from perl - needed for yum's requests for byte ranges private StreamInfo manualServeByteRange(HttpServletRequest request, HttpServletResponse response, String diskPath, String range) { // bytes=440-25183 String[] bytesheader = StringUtils.split(range, "="); String[] ranges = StringUtils.split(bytesheader[1], "-"); long start = Long.valueOf(ranges[0]).longValue(); long end = Long.valueOf(ranges[1]).longValue(); if (log.isDebugEnabled()) { log.debug("manualServeByteRange Start : " + start); log.debug("manualServeByteRange End : " + end); } where we process the Range requests. And the range either did not contain the dash (minus) sign, or it was a suffix range request, something like bytes=-500 or bytes=9500- as specified in the 14.35.1 of RFC 2616. In that case, the ranges array would only have single element. We probably want something like splitPreserveAllTokens there, and correctly account for situations when we will not know the start or end and compute it from the totalSize.
(In reply to comment #7) > Created attachment 509585 [details] > Catalina log on repo access > > Whenever http://spacewalk/ks/dist/child/f14updates/Fedora-14-Desktop-x86_64 or > similar is accessed via the kickstart, this error happens. Hello, do kickstart work as expected and does the problem only happen when you try to "browse" the kickstart tree manually? Spacewalk does not provide the full directory listing -- in will only return the repodata *files* that are needed during kickstart. You might want to append repodata/primary.xml.gz or something similar.
Aligning under space16.
(In reply to comment #8) > > We probably want something like splitPreserveAllTokens there, and correctly > account for situations when we will not know the start or end and compute it > from the totalSize. Fixed in Spacewalk master, 365fb6234d3bbb67919ce058f16b427548421e18, implemented via regexp to also check for the bytes= prefix.
Spacewalk 1.6 has been released.