Bugzilla – Bug 4586
DC pause and resume functionality won't resume at any resumable step
Last modified: 2008-12-01 10:48:38 UTC
You need to log in before you can comment on or make changes to this bug.
I'm building an lzma image using the pause/resume functionality on the build server. Server is based on build 99 but has SUNWdistroconst, SUNWinstall, and SUNWipkg updated as of 11/3. I'm seeing problems resuming at steps that output indicates should be resumable. The initial command was: -bash-3.2$ pfexec distro_const build -p br-arch slim_cd.xml.lzma -bash-3.2$ pfexec distro_const build -l slim_cd.xml.lzma /usr/share/distro_const/DC-manifest.defval.xml validates /tmp/slim_cd.lzma_temp_9778.xml validates Step Resumable Description -------------- --------- ------------- im-pop X Populate the image with packages im-mod X Image area modifications slim-im-mod X Slim CD Image area Modifications br-init X Boot root initialization slim-br-config X Slim CD boot root configuration br-config X Boot root configuration br-arch X Boot root archiving slim-post-mod Slim CD post bootroot image area modification grub-setup Grub menu setup post-mod Post bootroot image area modification iso ISO image creation usb USB image creation The command completes successfully, but when I try to resume, I get the following. I attempted to use each resumable step, but none of them were successful. -bash-3.2$ pfexec distro_const build -r br-arch -p slim-post-mod slim_cd.xml.lzma /usr/share/distro_const/DC-manifest.defval.xml validates /tmp/slim_cd.lzma_temp_9786.xml validates You must specify an earlier step to resume at. Valid steps to resume from are: im-pop Populate the image with packages im-mod Image area modifications slim-im-mod Slim CD Image area Modifications br-init Boot root initialization slim-br-config Slim CD boot root configuration br-config Boot root configuration br-arch Boot root archiving -bash-3.2$ pfexec distro_const build -r slim-im-mod -p slim-post-mod slim_cd.xml.lzma /usr/share/distro_const/DC-manifest.defval.xml validates /tmp/slim_cd.lzma_temp_28421.xml validates You must specify an earlier step to resume at. Valid steps to resume from are: im-pop Populate the image with packages im-mod Image area modifications slim-im-mod Slim CD Image area Modifications br-init Boot root initialization slim-br-config Slim CD boot root configuration br-config Boot root configuration br-arch Boot root archiving -bash-3.2$ pfexec distro_const build -r im-mod -p slim-post-mod slim_cd.xml.lzma /usr/share/distro_const/DC-manifest.defval.xml validates /tmp/slim_cd.lzma_temp_28430.xml validates You must specify an earlier step to resume at. Valid steps to resume from are: im-pop Populate the image with packages im-mod Image area modifications slim-im-mod Slim CD Image area Modifications br-init Boot root initialization slim-br-config Slim CD boot root configuration br-config Boot root configuration br-arch Boot root archiving -bash-3.2$ pfexec distro_const build -r im-pop -p slim-post-mod slim_cd.xml.lzma /usr/share/distro_const/DC-manifest.defval.xml validates /tmp/slim_cd.lzma_temp_28438.xml validates You must specify an earlier step to resume at. Valid steps to resume from are: im-pop Populate the image with packages im-mod Image area modifications slim-im-mod Slim CD Image area Modifications br-init Boot root initialization slim-br-config Slim CD boot root configuration br-config Boot root configuration br-arch Boot root archiving -bash-3.2$ I have reproduced this and have a current workspace available for evaluation.
The workaround for this is to specify the -p first and then the -r. Like this: pfexec distro_const build -p slim-post-mod -r br-arch slim_cd.xml.lzma The cause is the following code in distro_const.py Around line 227, in the DC_parse_command_line method if not cp.get_resume_step() == -1: err = DC_verify_resume_step(cp, stepno) if err != 0 : return -1 The problem is that stepno was set in the elif opt == "-p": code. The fix is to change the call to DC_verify_resume_step to err = DC_verify_resume_step(cp, cp.get_resume_step())
*** Bug 4588 has been marked as a duplicate of this bug. ***
changeset: 2f858d7ed2cc5e22c8f1f15df65b95fc7e9324b8