Wimboot specifying wim index not working in version 2.7.4

[rushyn]

Has any one else run in to an issue after updating to last wimboot(2.7.4) where index= (number) no longer works, and instead it boots the first index of the wim file? Updated from wimboot 2.5.2 going back to 2.5.2 resumes normal behavior.

[mcb30]

Could you try using git bisection to find the precise commit that caused the problem?

You can find a guide for bisecting at https://ipxe.org/howto/bisect. It's written for iPXE, but the idea is the same for wimboot: you'll want to do something like:

• git clone https://github.com/ipxe/wimboot.git
• make -C src
• git bisect start
• git bisect good v2.5.2
• git bisect bad v2.7.4

and then repeatedly

• make -C src
• test the resulting wimboot binary
• git bisect good if it works, or git bisect bad if it fails

until git reports that it has identified the culprit commit.

[mcb30]

@rushyn Thank you for running the bisection. Could you please try the following:

• Boot using the unmodified commit 2240d7f with an index=... command-line parameter to specify a non-default index and an additional pause command-line parameter
• Boot using your modified commit 2240d7f with the four lines from commit ac4190a removed, with the same index=... pause command-line parameters

That should get you a screenshot showing the modifications performed to the WIM image. Could you please post both screenshots here?

[rushyn]

@mcb30 I had no issues taking a picture of the unmodified wimboot output, however once I removed the lines from src/wimpatch.c the out put was too long to fit on one screen, I have edited together two video frames to capture the full output.

This is the wimboot line "kernel ftp://192.168.1.254/wimboot pause index=50"

Here is the out put for unmodified wimboot.

This is the output for the same commit with the 4 lines removed.

[mcb30]

Thank you. Your screenshot has coincidentally revealed an unrelated bug: #41 🙂

For your issue: I do see the ...patching WIM header at [0x0,0xd0) in both screenshots, and this is the only part that should be relevant in terms of patching the boot index.

Could you please try the unmodified commit 2240d7f but built using make DEBUG=3 to enable additional debugging? The additional debug messages that I am interested in are the ones produced by:

wimboot/src/wimpatch.c

Lines 246 to 273 in 2240d7f

	static int wim_patch_header ( struct wim_patch *patch,
	struct wim_patch_region *region,
	void *data, size_t offset, size_t len ) {
	struct wim_header *header = &patch->header;
	/* Sanity checks */
	assert ( offset < sizeof ( *header ) );
	assert ( len <= ( sizeof ( *header ) - offset ) );
	/* Copy patched header */
	if ( patch->lookup.offset != patch->header.lookup.offset ) {
	DBG2 ( "...patched WIM %s lookup table %#llx->%#llx\n",
	region->name, patch->lookup.offset,
	patch->header.lookup.offset );
	}
	if ( patch->boot.offset != patch->header.boot.offset ) {
	DBG2 ( "...patched WIM %s boot metadata %#llx->%#llx\n",
	region->name, patch->boot.offset,
	patch->header.boot.offset );
	}
	if ( patch->boot_index != patch->header.boot_index ) {
	DBG2 ( "...patched WIM %s boot index %d->%d\n", region->name,
	patch->boot_index, patch->header.boot_index );
	}
	memcpy ( data, ( ( ( void * ) &patch->header ) + offset ), len );
	return 0;
	}

These messages will not appear until bootmgfw.efi starts reading from the patched WIM image, which happens only after the Press any key to continue booting... prompt (if enabled). They may be challenging to capture via video: if so, you should be able to safely add an extra call to pause() at the end of wim_patch_header():

--- a/src/wimpatch.c
+++ b/src/wimpatch.c
@@ -269,6 +269,9 @@ static int wim_patch_header ( struct wim_patch *patch,
        }
        memcpy ( data, ( ( ( void * ) &patch->header ) + offset ), len );
 
+       // temporary hack
+       pause();
+
        return 0;
 }
 

[rushyn]

Happy I could help find a bug another bug,

I did not have any luck getting a good video of the of the debug output, After adding the pause() to wimpatch.c the compiler errored out.

Removed the -Werror flag from make file, and it complied with this warranting.

Is this what you are after?

[mcb30]

Is this what you are after?

Yes, thank you. I believe that gives me enough information to figure out what is happening. I'm going to convert this to an issue since it is a genuine bug.

[mcb30]

Moving to issue #43 (and locking this discussion: please continue conversation in the issue)