… | |
… | |
75 | sensitive data. |
75 | sensitive data. |
76 | |
76 | |
77 | =back |
77 | =back |
78 | |
78 | |
79 | The target audience for this program is professionals and tinkerers who |
79 | The target audience for this program is professionals and tinkerers who |
80 | are rewady to invest time into learning how it works. It is not an easy |
80 | are ready to invest time into learning how it works. It is not an easy |
81 | program to use and requires patience and a good understanding of BCD data |
81 | program to use and requires patience and a good understanding of BCD data |
82 | stores. |
82 | stores. |
83 | |
83 | |
84 | |
84 | |
85 | =head1 SUBCOMMANDS |
85 | =head1 SUBCOMMANDS |
86 | |
86 | |
87 | PCBEDIT expects a subcommand as first argument that tells it what to |
87 | PBCDEDIT expects a subcommand as first argument that tells it what to |
88 | do. The following subcommands exist: |
88 | do. The following subcommands exist: |
89 | |
89 | |
90 | =over |
90 | =over |
91 | |
91 | |
92 | =item help |
92 | =item C<help> |
93 | |
93 | |
94 | Displays the whole manuale page (this document). |
94 | Displays the whole manual page (this document). |
95 | |
95 | |
96 | =item export F<path> |
96 | =item C<export> F<path> |
97 | |
97 | |
98 | Reads a BCD data store and writes a JSON representation of it to standard |
98 | Reads a BCD data store and writes a JSON representation of it to standard |
99 | output. |
99 | output. |
100 | |
100 | |
101 | The format of the data is explained later in this document. |
101 | The format of the data is explained later in this document. |
102 | |
102 | |
103 | Example: read a BCD store, modify it wiht an extenral program, write it again. |
103 | Example: read a BCD store, modify it with an external program, write it |
|
|
104 | again. |
104 | |
105 | |
105 | pbcdedit export BCD | modify-json-somehow | pbcdedit import BCD |
106 | pbcdedit export BCD | modify-json-somehow | pbcdedit import BCD |
106 | |
107 | |
107 | =item import F<path> |
108 | =item C<import> F<path> |
108 | |
109 | |
109 | The reverse of C<export>: Reads a JSON representation of a BCD data store |
110 | The reverse of C<export>: Reads a JSON representation of a BCD data store |
110 | from standard input, and creates or replaces the given BCD data store. |
111 | from standard input, and creates or replaces the given BCD data store. |
111 | |
112 | |
112 | =item edit F<path> instructions... |
113 | =item C<edit> F<path> I<instructions...> |
113 | |
114 | |
114 | Load a BCD data store, apply some instructions to it, and save it again. |
115 | Load a BCD data store, apply some instructions to it, and save it again. |
115 | |
116 | |
116 | See the section L<EDITING BCD DATA STORES>, below, for more info. |
117 | See the section L<EDITING BCD DATA STORES>, below, for more info. |
117 | |
118 | |
118 | =item parse F<path> instructions... |
119 | =item C<parse> F<path> I<instructions...> |
119 | |
120 | |
120 | Same as C<edit>, above, except it doesn't save the data store again. Can |
121 | Same as C<edit>, above, except it doesn't save the data store again. Can |
121 | be useful to extract some data from it. |
122 | be useful to extract some data from it. |
122 | |
123 | |
123 | =item lsblk |
124 | =item C<lsblk> |
124 | |
125 | |
125 | On a GNU/Linux system, you can get a list of partition device descriptors |
126 | On a GNU/Linux system, you can get a list of partition device descriptors |
126 | using this command - the external C<lsblk> command is required, as well as |
127 | using this command - the external C<lsblk> command is required, as well as |
127 | a mounted C</sys> file system. |
128 | a mounted C</sys> file system. |
128 | |
129 | |
129 | The output will be a list of all partitions in the system and C<partition> |
130 | The output will be a list of all partitions in the system and C<partition> |
130 | descriptors for GPT and both C<legacypartition> and C<partition> |
131 | descriptors for GPT and both C<legacypartition> and C<partition> |
131 | descritpors for MBR partitions. |
132 | descriptors for MBR partitions. |
132 | |
133 | |
133 | =item objects [--json] |
134 | =item C<objects> [C<--json>] |
134 | |
135 | |
135 | Outputs two tables: a table listing all type aliases with their hex bcd |
136 | Outputs two tables: a table listing all type aliases with their hex BCD |
136 | element ID, and all object name aliases with their GUID and default type |
137 | element ID, and all object name aliases with their GUID and default type |
137 | (if any). |
138 | (if any). |
138 | |
139 | |
139 | With C<--json> it prints similar information as a JSON object, for easier parsing. |
140 | With C<--json> it prints similar information as a JSON object, for easier parsing. |
140 | |
141 | |
141 | =item elements [--json] |
142 | =item C<elements> [C<--json>] |
142 | |
143 | |
143 | Outputs a table of known element aliases with their hex ID and the format |
144 | Outputs a table of known element aliases with their hex ID and the format |
144 | type. |
145 | type. |
145 | |
146 | |
146 | With C<--json> it prints similar information as a JSON object, for easier parsing. |
147 | With C<--json> it prints similar information as a JSON object, for easier parsing. |
147 | |
148 | |
148 | =item export-regf F<path> |
149 | =item C<export-regf> F<path> |
149 | |
150 | |
150 | This has nothing to do with BCD data stores - it takes a registry hive |
151 | This has nothing to do with BCD data stores - it takes a registry hive |
151 | file as argument and outputs a JSON representation of it to standard |
152 | file as argument and outputs a JSON representation of it to standard |
152 | output. |
153 | output. |
153 | |
154 | |
154 | Hive versions 1.2 till 1.6 are supported. |
155 | Hive versions 1.2 till 1.6 are supported. |
155 | |
156 | |
156 | =item import-regf F<path> |
157 | =item C<import-regf> F<path> |
157 | |
158 | |
158 | The reverse of C<export-regf>: reads a JSON representation of a registry |
159 | The reverse of C<export-regf>: reads a JSON representation of a registry |
159 | hive from standard input and creates or replaces the registry hive file given as |
160 | hive from standard input and creates or replaces the registry hive file |
160 | argument. |
161 | given as argument. |
161 | |
162 | |
162 | The written hive will always be in a slightly modified version 1.3 |
163 | The written hive will always be in a slightly modified version 1.3 |
163 | format. It's not the format windows would generate, but it should be |
164 | format. It's not the format windows would generate, but it should be |
164 | understood by any conformant hive reader. |
165 | understood by any conformant hive reader. |
165 | |
166 | |
166 | Note that the representation chosen by PBCDEDIT currently throws away |
167 | Note that the representation chosen by PBCDEDIT currently throws away |
167 | clasname data (often used for feeble attemtps at hiding stuff by |
168 | classname data (often used for feeble attempts at hiding stuff by |
168 | Microsoft) and security descriptors, so if you write anything other than |
169 | Microsoft) and security descriptors, so if you write anything other than |
169 | a BCD hive you will most likely destroy it. |
170 | a BCD hive you will most likely destroy it. |
170 | |
171 | |
171 | =back |
172 | =back |
172 | |
173 | |
… | |
… | |
242 | =head2 The C<meta> key |
243 | =head2 The C<meta> key |
243 | |
244 | |
244 | The C<meta> key is not stored in the BCD data store but is used only |
245 | The C<meta> key is not stored in the BCD data store but is used only |
245 | by PBCDEDIT. It is always generated when exporting, and importing will |
246 | by PBCDEDIT. It is always generated when exporting, and importing will |
246 | be refused when it exists and the version stored inside doesn't store |
247 | be refused when it exists and the version stored inside doesn't store |
247 | the JSON schema version of PBCDEDIT. This ensures that differemt and |
248 | the JSON schema version of PBCDEDIT. This ensures that different and |
248 | incompatible versions of PBCDEDIT will not read and misinterΓΌret each |
249 | incompatible versions of PBCDEDIT will not read and misinterpret each |
249 | others data. |
250 | others data. |
250 | |
251 | |
251 | =head2 The object keys |
252 | =head2 The object keys |
252 | |
253 | |
253 | Every other key is a BCD object. There is usually a BCD object for the |
254 | Every other key is a BCD object. There is usually a BCD object for the |
254 | boot manager, one for every boot option and a few others that store common |
255 | boot manager, one for every boot option and a few others that store common |
255 | settings inherited by these. |
256 | settings inherited by these. |
256 | |
257 | |
257 | Each BCD object is represented by a GUID wrapped in curly braces. These |
258 | Each BCD object is represented by a GUID wrapped in curly braces. These |
258 | are usually random GUIDs used only to distinguish bCD objects from each |
259 | are usually random GUIDs used only to distinguish BCD objects from each |
259 | other. When adding a new boot option, you can simply generate a new GUID. |
260 | other. When adding a new boot option, you can simply generate a new GUID. |
260 | |
261 | |
261 | Some of these GUIDs are fixed well known GUIDs which PBCDEDIT will decode |
262 | Some of these GUIDs are fixed well known GUIDs which PBCDEDIT will decode |
262 | into human-readable strings such as C<{globalsettings}>, which is the same |
263 | into human-readable strings such as C<{globalsettings}>, which is the same |
263 | as C<{7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}>. |
264 | as C<{7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}>. |
… | |
… | |
297 | get a list of all BCD elements known to PBCDEDIT by running F<pbcdedit |
298 | get a list of all BCD elements known to PBCDEDIT by running F<pbcdedit |
298 | elements>. |
299 | elements>. |
299 | |
300 | |
300 | What was said about duplicate keys mapping to the same object is true for |
301 | What was said about duplicate keys mapping to the same object is true for |
301 | elements as well, so, again, you should always use the canonical name, |
302 | elements as well, so, again, you should always use the canonical name, |
302 | whcih is the human radable alias, if known. |
303 | which is the human readable alias, if known. |
303 | |
304 | |
304 | =head3 BCD element types |
305 | =head3 BCD element types |
305 | |
306 | |
306 | Each BCD element has a type such as I<string> or I<boolean>. This type |
307 | Each BCD element has a type such as I<string> or I<boolean>. This type |
307 | determines how the value is interpreted, and most of them are pretty easy |
308 | determines how the value is interpreted, and most of them are pretty easy |
… | |
… | |
319 | "description" : "Windows 10", |
320 | "description" : "Windows 10", |
320 | "systemroot" : "\\Windows", |
321 | "systemroot" : "\\Windows", |
321 | |
322 | |
322 | =item boolean |
323 | =item boolean |
323 | |
324 | |
324 | Almost as simnple are booleans, which represent I<true>/I<false>, |
325 | Almost as simple are booleans, which represent I<true>/I<false>, |
325 | I<on>/I<off> and similar values. In the JSON form, true is represented |
326 | I<on>/I<off> and similar values. In the JSON form, true is represented |
326 | by the number C<1>, and false is represented by the number C<0>. Other |
327 | by the number C<1>, and false is represented by the number C<0>. Other |
327 | values will be accepted, but PBCDEDIT doesn't guarantee how these are |
328 | values will be accepted, but PBCDEDIT doesn't guarantee how these are |
328 | interpreted. |
329 | interpreted. |
329 | |
330 | |
… | |
… | |
335 | |
336 | |
336 | =item integer |
337 | =item integer |
337 | |
338 | |
338 | Again, very simple, this is a 64 bit integer. IT can be either specified |
339 | Again, very simple, this is a 64 bit integer. IT can be either specified |
339 | as a decimal number, as a hex number (by prefixing it with C<0x>) or as a |
340 | as a decimal number, as a hex number (by prefixing it with C<0x>) or as a |
340 | binatry number (prefix C<0b>). |
341 | binary number (prefix C<0b>). |
341 | |
342 | |
342 | For example, the boot C<timeout> is an integer, specifying the automatic |
343 | For example, the boot C<timeout> is an integer, specifying the automatic |
343 | boot delay in seconds: |
344 | boot delay in seconds: |
344 | |
345 | |
345 | "timeout" : 30, |
346 | "timeout" : 30, |
346 | |
347 | |
347 | =item integer list |
348 | =item integer list |
348 | |
349 | |
349 | This is a list of 64 bit integers separated by whitespace. It is not used |
350 | This is a list of 64 bit integers separated by whitespace. It is not used |
350 | much, so here is a somewhat artificial an untested exanmple of using |
351 | much, so here is a somewhat artificial an untested example of using |
351 | C<customactions> to specify a certain custom, eh, action to be executed |
352 | C<customactions> to specify a certain custom, eh, action to be executed |
352 | when pressing C<F10> at boot: |
353 | when pressing C<F10> at boot: |
353 | |
354 | |
354 | "customactions" : "0x1000044000001 0x54000001", |
355 | "customactions" : "0x1000044000001 0x54000001", |
355 | |
356 | |
356 | =item guid |
357 | =item guid |
357 | |
358 | |
358 | This represents a single GUID value wrqapped in curly braces. It is used a |
359 | This represents a single GUID value wrapped in curly braces. It is used a |
359 | lot to refer from one BCD object to other one. |
360 | lot to refer from one BCD object to other one. |
360 | |
361 | |
361 | For example, The C<{bootmgr}> object might refer to a resume boot option |
362 | For example, The C<{bootmgr}> object might refer to a resume boot option |
362 | using C<resumeobject>: |
363 | using C<resumeobject>: |
363 | |
364 | |
… | |
… | |
365 | |
366 | |
366 | Human readable aliases are used and allowed. |
367 | Human readable aliases are used and allowed. |
367 | |
368 | |
368 | =item guid list |
369 | =item guid list |
369 | |
370 | |
370 | Similar to te guid type, this represents a list of such GUIDs, separated |
371 | Similar to the GUID type, this represents a list of such GUIDs, separated |
371 | by whitespace from each other. |
372 | by whitespace from each other. |
372 | |
373 | |
373 | For example, many BCD objects can I<inherit> elements from other BCD |
374 | For example, many BCD objects can I<inherit> elements from other BCD |
374 | objects by specifying the GUIDs of those other objects ina GUID list |
375 | objects by specifying the GUIDs of those other objects in a GUID list |
375 | called surprisingly called C<inherit>: |
376 | called surprisingly called C<inherit>: |
376 | |
377 | |
377 | "inherit" : "{dbgsettings} {emssettings} {badmemory}", |
378 | "inherit" : "{dbgsettings} {emssettings} {badmemory}", |
378 | |
379 | |
379 | This example also shows how human readable aliases can be used. |
380 | This example also shows how human readable aliases can be used. |
… | |
… | |
388 | =back |
389 | =back |
389 | |
390 | |
390 | =head4 The BCD "device" element type |
391 | =head4 The BCD "device" element type |
391 | |
392 | |
392 | Device elements specify, well, devices. They are used for such diverse |
393 | Device elements specify, well, devices. They are used for such diverse |
393 | purposes such as finding a TFTP network boot imagem serial ports or VMBUS |
394 | purposes such as finding a TFTP network boot image, serial ports or VMBUS |
394 | devices, but most commonly they are used to specify the disk (harddisk, |
395 | devices, but most commonly they are used to specify the disk (harddisk, |
395 | cdrom ramdisk, vhd...) to boot from. |
396 | cdrom, ramdisk, vhd...) to boot from. |
396 | |
397 | |
397 | The device element is kind of a mini-language in its own which is much |
398 | The device element is kind of a mini-language in its own which is much |
398 | more versatile then the limited windows interface to it - BCDEDIT - |
399 | more versatile then the limited windows interface to it - BCDEDIT - |
399 | reveals. |
400 | reveals. |
400 | |
401 | |
… | |
… | |
403 | element, so almost everything known about it had to be researched first |
404 | element, so almost everything known about it had to be researched first |
404 | in the process of writing this script, and consequently, support for BCD |
405 | in the process of writing this script, and consequently, support for BCD |
405 | device elements is partial only. |
406 | device elements is partial only. |
406 | |
407 | |
407 | On the other hand, the expressive power of PBCDEDIT in specifying devices |
408 | On the other hand, the expressive power of PBCDEDIT in specifying devices |
408 | is much bigger than BCDEDIT and therefore more cna be don with it. The |
409 | is much bigger than BCDEDIT and therefore more can be done with it. The |
409 | downside is that BCD device elements are much more complicated than what |
410 | downside is that BCD device elements are much more complicated than what |
410 | you might think from reading the BCDEDIT documentation. |
411 | you might think from reading the BCDEDIT documentation. |
411 | |
412 | |
412 | In other words, simple things are complicated, and complicated things are |
413 | In other words, simple things are complicated, and complicated things are |
413 | possible. |
414 | possible. |
414 | |
415 | |
415 | Anyway, the general syntax of device elements is an optional GUID, |
416 | Anyway, the general syntax of device elements is an optional GUID, |
416 | followed by a device type, optionally followed by hexdecimal flags in |
417 | followed by a device type, optionally followed by hexadecimal flags in |
417 | angle brackets, optionally followed by C<=> and a comma-separated list of |
418 | angle brackets, optionally followed by C<=> and a comma-separated list of |
418 | arguments, some of which can be (and often are) in turn devices again. |
419 | arguments, some of which can be (and often are) in turn devices again. |
419 | |
420 | |
420 | [{GUID}]type[<flags>][=arg,arg...] |
421 | [{GUID}]type[<flags>][=arg,arg...] |
421 | |
422 | |
… | |
… | |
447 | The types understood and used by PBCDEDIT are as follows (keep in mind |
448 | The types understood and used by PBCDEDIT are as follows (keep in mind |
448 | that not of all the following is necessarily supported in PBCDEDIT): |
449 | that not of all the following is necessarily supported in PBCDEDIT): |
449 | |
450 | |
450 | =over |
451 | =over |
451 | |
452 | |
452 | =item binary=hex... |
453 | =item C<binary=>I<hex...> |
453 | |
454 | |
454 | This type isn't actually a real BCD element type, but a fallback for those |
455 | This type isn't actually a real BCD element type, but a fallback for those |
455 | cases where PBCDEDIT can't perfectly decode a device element (except for |
456 | cases where PBCDEDIT can't perfectly decode a device element (except for |
456 | the leading GUID, which it can always decode). In such cases, it will |
457 | the leading GUID, which it can always decode). In such cases, it will |
457 | convert the device into this type with a hexdump of the element data. |
458 | convert the device into this type with a hexdump of the element data. |
458 | |
459 | |
459 | =item null |
460 | =item C<null> |
460 | |
461 | |
461 | This is another special type - sometimes, a device all zero-filled, which |
462 | This is another special type - sometimes, a device all zero-filled, which |
462 | is not valid. This can mark the absence of a device or something PBCDEDIT |
463 | is not valid. This can mark the absence of a device or something PBCDEDIT |
463 | does not understand, so it decodes it into this special "all zero" type |
464 | does not understand, so it decodes it into this special "all zero" type |
464 | called C<null>. |
465 | called C<null>. |
465 | |
466 | |
466 | It's most commonly found in devices that can use an optional parent |
467 | It's most commonly found in devices that can use an optional parent |
467 | device, when no parent device is used. |
468 | device, when no parent device is used. |
468 | |
469 | |
469 | =item boot |
470 | =item C<boot> |
470 | |
471 | |
471 | Another type without parameters, this refers to the device that was booted |
472 | Another type without parameters, this refers to the device that was booted |
472 | from (nowadays typically the EFI system partition). |
473 | from (nowadays typically the EFI system partition). |
473 | |
474 | |
474 | =item vmbus=interfacetype,interfaceinstance |
475 | =item C<vmbus=>I<interfacetype>,I<interfaceinstance> |
475 | |
476 | |
476 | This specifies a VMBUS device with the given interface type and interface |
477 | This specifies a VMBUS device with the given interface type and interface |
477 | instance, both of which are "naked" (no curly braces) GUIDs. |
478 | instance, both of which are "naked" (no curly braces) GUIDs. |
478 | |
479 | |
479 | Made-up example (couldn't find a single example on the web): |
480 | Made-up example (couldn't find a single example on the web): |
480 | |
481 | |
481 | vmbus=c376c1c3-d276-48d2-90a9-c04748072c60,12345678-a234-b234-c234-d2345678abcd |
482 | vmbus=c376c1c3-d276-48d2-90a9-c04748072c60,12345678-a234-b234-c234-d2345678abcd |
482 | |
483 | |
483 | =item partition=<parent>,devicetype,partitiontype,diskid,partitionid |
484 | =item C<partition=><I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid> |
484 | |
485 | |
485 | This designates a specific partition on a block device. C<< <parent> |
486 | This designates a specific partition on a block device. I<parent> is an |
486 | >> is an optional parent device on which to search on, and is often |
487 | optional parent device on which to search on, and is often C<null>. Note |
487 | C<null>. Note that the anfgle brackets are part of the syntax. |
488 | that the angle brackets around I<parent> are part of the syntax. |
488 | |
489 | |
489 | C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, |
490 | I<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, |
490 | C<file> or C<vhd>, where the first three should be self-explaining, |
491 | C<file> or C<vhd>, where the first three should be self-explaining, |
491 | C<file> is usually used to locate a device by finding a magic file, and |
492 | C<file> is usually used to locate a file to be used as a disk image, |
492 | C<vhd> is used for virtual harddisks - F<.vhd> and F<-vhdx> files. |
493 | and C<vhd> is used to treat files as virtual harddisks, i.e. F<vhd> and |
|
|
494 | F<vhdx> files. |
493 | |
495 | |
494 | The C<partitiontype> is either C<mbr>, C<gpt> or C<raw>, the latter being |
496 | The I<partitiontype> is either C<mbr>, C<gpt> or C<raw>, the latter being |
495 | used for devices without partitions, such as cdroms, where the "partition" |
497 | used for devices without partitions, such as cdroms, where the "partition" |
496 | is usually the whole device. |
498 | is usually the whole device. |
497 | |
499 | |
498 | The C<diskid> identifies the disk or device using a unique signature, and |
500 | The I<diskid> identifies the disk or device using a unique signature, and |
499 | the same is true for the C<partitionid>. How these are interpreted depends |
501 | the same is true for the I<partitionid>. How these are interpreted depends |
500 | on the C<partitiontype>: |
502 | on the I<partitiontype>: |
501 | |
503 | |
502 | =over |
504 | =over |
503 | |
505 | |
504 | =item mbr |
506 | =item C<mbr> |
505 | |
507 | |
506 | The C<diskid> is the 32 bit disk signature stored at offset 0x1b8 in the |
508 | The C<diskid> is the 32 bit disk signature stored at offset 0x1b8 in the |
507 | MBR, interpreted as a 32 bit unsigned little endian integer and written as |
509 | MBR, interpreted as a 32 bit unsigned little endian integer and written as |
508 | hex number. That is, the bytes C<01 02 03 04> would become C<04030201>. |
510 | hex number. That is, the bytes C<01 02 03 04> would become C<04030201>. |
509 | |
511 | |
510 | Diskpart (using the C<DETAIL> command) and the C<lsblk> comamnd typically |
512 | Diskpart (using the C<DETAIL> command) and the C<lsblk> command typically |
511 | found on GNU/Linux systems (using e.g. C<lsblk -o NAME,PARTUUID>) can |
513 | found on GNU/Linux systems (using e.g. C<lsblk -o NAME,PARTUUID>) can |
512 | display the disk id. |
514 | display the I<diskid>. |
513 | |
515 | |
514 | The C<partitionid> is the byte offset(!) of the partition counting from |
516 | The I<partitionid> is the byte offset(!) of the partition counting from |
515 | the beginning of the MBR. |
517 | the beginning of the MBR. |
516 | |
518 | |
517 | Example, use the partition on the harddisk with C<diskid> C<47cbc08a> |
519 | Example, use the partition on the harddisk with I<diskid> C<47cbc08a> |
518 | starting at sector C<2048> (= 1048576 / 512). |
520 | starting at sector C<2048> (= 1048576 / 512). |
519 | |
521 | |
520 | partition=<null>,harddisk,mbr,47cbc08a,1048576 |
522 | partition=<null>,harddisk,mbr,47cbc08a,1048576 |
521 | |
523 | |
522 | =item gpt |
524 | =item C<gpt> |
523 | |
525 | |
524 | The C<diskid> is the disk UUID/disk identifier GUID from the partition |
526 | The I<diskid> is the disk GUID/disk identifier GUID from the partition |
525 | table (as displayed e.g. by C<gdisk>), and the C<partitionid> is the |
527 | table (as displayed e.g. by F<gdisk>), and the I<partitionid> is the |
526 | partition unique GUID (displayed using e.g. the C<gdisk> C<i> command). |
528 | partition unique GUID (displayed using e.g. the F<gdisk> F<i> command). |
527 | |
529 | |
528 | Example: use the partition C<76d39e5f-ad1b-407e-9c05-c81eb83b57dd> on GPT |
530 | Example: use the partition C<76d39e5f-ad1b-407e-9c05-c81eb83b57dd> on GPT |
529 | disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>. |
531 | disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>. |
530 | |
532 | |
531 | partition=<null>,harddisk,gpt,9742e468-9206-48a0-b4e4-c4e9745a356a,76d39e5f-ad1b-407e-9c05-c81eb83b57dd |
533 | partition=<null>,harddisk,gpt,9742e468-9206-48a0-b4e4-c4e9745a356a,76d39e5f-ad1b-407e-9c05-c81eb83b57dd |
532 | |
534 | |
533 | =item raw |
535 | =item C<raw> |
534 | |
536 | |
535 | Instead of diskid and partitionid, this type only accepts a decimal disk |
537 | Instead of I<diskid> and I<partitionid>, this type only accepts a decimal |
536 | number and signifies the whole disk. BCDEDIT cannot display the resulting |
538 | disk number and signifies the whole disk. BCDEDIT cannot display the |
537 | device, and I am doubtful whether it has a useful effect. |
539 | resulting device, and I am doubtful whether it has a useful effect. |
538 | |
540 | |
539 | =back |
541 | =back |
540 | |
542 | |
541 | =item legacypartition=<parent>,devicetype,partitiontype,diskid,partitionid |
543 | =item C<legacypartition=><I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid> |
542 | |
544 | |
543 | This is exactly the same as the C<partition> type, except for a tiny |
545 | This is exactly the same as the C<partition> type, except for a tiny |
544 | detail: instead of using the partition start offset, this type uses the |
546 | detail: instead of using the partition start offset, this type uses the |
545 | partition number for MBR disks. Behaviour other partition types should be |
547 | partition number for MBR disks. Behaviour other partition types should be |
546 | the same. |
548 | the same. |
547 | |
549 | |
548 | The partition number starts at C<1> and skips unused partition, so if |
550 | The partition number starts at C<1> and skips unused partition, so if |
549 | there are two primary partitions and another partition inside the extended |
551 | there are two primary partitions and another partition inside the extended |
550 | partition, the primary partitions are number C<1> and C<2> and the |
552 | partition, the primary partitions are number C<1> and C<2> and the |
551 | partition inside the extended partition is number C<3>, rwegardless of any |
553 | partition inside the extended partition is number C<3>, regardless of any |
552 | gaps. |
554 | gaps. |
553 | |
555 | |
554 | =item locate=<parent>,locatetype,locatearg |
556 | =item C<locate=><I<parent>>,I<locatetype>,I<locatearg> |
555 | |
557 | |
556 | This device description will make the bootloader search for a partition |
558 | This device description will make the bootloader search for a partition |
557 | with a given path. |
559 | with a given path. |
558 | |
560 | |
559 | The C<< <parent> >> device is the device to search on (angle brackets are |
561 | The I<parent> device is the device to search on (angle brackets are |
560 | still part of the syntax!) If it is C<< <null> >>, then C<locate> will |
562 | still part of the syntax!) If it is C<null>, then C<locate> will |
561 | search all disks it can find. |
563 | search all disks it can find. |
562 | |
564 | |
563 | C<locatetype> is either C<element> or C<path>, and merely distinguishes |
565 | I<locatetype> is either C<element> or C<path>, and merely distinguishes |
564 | between two different ways to specify the path to search for: C<element> |
566 | between two different ways to specify the path to search for: C<element> |
565 | uses an element ID (either as hex or as name) as C<locatearg> and C<path> |
567 | uses an element ID (either as hex or as name) as I<locatearg> and C<path> |
566 | uses a relative path as C<locatearg>. |
568 | uses a relative path as I<locatearg>. |
567 | |
569 | |
568 | Example: find any partition which has the C<magicfile.xxx> path in the |
570 | Example: find any partition which has the F<magicfile.xxx> path in the |
569 | root. |
571 | root. |
570 | |
572 | |
571 | locate=<null>,path,\magicfile.xxx |
573 | locate=<null>,path,\magicfile.xxx |
572 | |
574 | |
573 | Example: find any partition which has the path specified in the |
575 | Example: find any partition which has the path specified in the |
574 | C<systemroot> element (typically C<\Windows>). |
576 | C<systemroot> element (typically F<\Windows>). |
575 | |
577 | |
576 | locate=<null>,element,systemroot |
578 | locate=<null>,element,systemroot |
577 | |
579 | |
578 | =item block=devicetype,args... |
580 | =item C<block=>I<devicetype>,I<args...> |
579 | |
581 | |
580 | Last not least, the most complex type, C<block>, which... specifies block |
582 | Last not least, the most complex type, C<block>, which... specifies block |
581 | devices (which could be inside a F<vhdx> file for example). |
583 | devices (which could be inside a F<vhdx> file for example). |
582 | |
584 | |
583 | C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, |
585 | I<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, |
584 | C<file> or C<vhd> - the same as for C<partiion=>. |
586 | C<file> or C<vhd> - the same as for C<partiion=>. |
585 | |
587 | |
586 | The remaining arguments change depending on the C<devicetype>: |
588 | The remaining arguments change depending on the I<devicetype>: |
587 | |
589 | |
588 | =over |
590 | =over |
589 | |
591 | |
590 | =item block=file,<parent>,path |
592 | =item C<block=file>,<I<parent>>,I<path> |
591 | |
593 | |
592 | Interprets the C<< <parent> >> device (typically a partition) as a |
594 | Interprets the I<parent> device (typically a partition) as a |
593 | filesystem and specifies a file path inside. |
595 | filesystem and specifies a file path inside. |
594 | |
596 | |
595 | =item block=vhd,<parent> |
597 | =item C<block=vhd>,<I<parent>> |
596 | |
598 | |
597 | Pretty much just changes the interpretation of C<< <parent> >>, which is |
599 | Pretty much just changes the interpretation of I<parent>, which is |
598 | usually a disk image (C<block=file,...)>) to be a F<vhd> or F<vhdx> file. |
600 | usually a disk image (C<block=file,...)>) to be a F<vhd> or F<vhdx> file. |
599 | |
601 | |
600 | =item block=ramdisk,<parent>,base,size,offset,path |
602 | =item C<block=ramdisk>,<I<parent>>,I<base>,I<size>,I<offset>,I<path> |
601 | |
603 | |
602 | Interprets the C<< <parent> >> device as RAM disk, using the (decimal) |
604 | Interprets the I<parent> device as RAM disk, using the (decimal) |
603 | base address, byte size and byte offset inside a file specified by |
605 | base address, byte size and byte offset inside a file specified by |
604 | C<path>. The numbers are usually all C<0> because they cna be extracted |
606 | I<path>. The numbers are usually all C<0> because they can be extracted |
605 | from the RAM disk image or other parameters. |
607 | from the RAM disk image or other parameters. |
606 | |
608 | |
607 | This is most commonly used to boot C<wim> images. |
609 | This is most commonly used to boot C<wim> images. |
608 | |
610 | |
609 | =item block=floppy,drivenum |
611 | =item C<block=floppy>,I<drivenum> |
610 | |
612 | |
611 | Refers to a removable drive identified by a number. BCDEDIT cannot display |
613 | Refers to a removable drive identified by a number. BCDEDIT cannot display |
612 | the resultinfg device, and it is not clear what effect it will have. |
614 | the resulting device, and it is not clear what effect it will have. |
613 | |
615 | |
614 | =item block=cdrom,drivenum |
616 | =item C<block=cdrom>,I<drivenum> |
615 | |
617 | |
616 | Pretty much the same as C<floppy> but for CD-ROMs. |
618 | Pretty much the same as C<floppy> but for CD-ROMs. |
617 | |
619 | |
618 | =item anything else |
620 | =item anything else |
619 | |
621 | |
… | |
… | |
623 | |
625 | |
624 | =back5 Examples |
626 | =back5 Examples |
625 | |
627 | |
626 | This concludes the syntax overview for device elements, but probably |
628 | This concludes the syntax overview for device elements, but probably |
627 | leaves many questions open. I can't help with most of them, as I also ave |
629 | leaves many questions open. I can't help with most of them, as I also ave |
628 | many questions, but I can walk you through some actual examples using mroe |
630 | many questions, but I can walk you through some actual examples using more |
629 | complex aspects. |
631 | complex aspects. |
630 | |
632 | |
631 | =item locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path |
633 | =item C<< locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path >> |
632 | |
634 | |
633 | Just like with C declarations, you best treat device descriptors as |
635 | Just like with C declarations, you best treat device descriptors as |
634 | instructions to find your device and work your way from the inside out: |
636 | instructions to find your device and work your way from the inside out: |
635 | |
637 | |
636 | locate=<null>,path,\disk.vhdx |
638 | locate=<null>,path,\disk.vhdx |
… | |
… | |
643 | Next, this takes the device locate has found and finds a file called |
645 | Next, this takes the device locate has found and finds a file called |
644 | F<\disk.vhdx> on it. This is the same file locate was using, but that is |
646 | F<\disk.vhdx> on it. This is the same file locate was using, but that is |
645 | only because we find the device using the same path as finding the disk |
647 | only because we find the device using the same path as finding the disk |
646 | image, so this is purely incidental, although quite common. |
648 | image, so this is purely incidental, although quite common. |
647 | |
649 | |
648 | Bext, this file will be opened as a virtual disk: |
650 | Next, this file will be opened as a virtual disk: |
649 | |
651 | |
650 | block=vhd,<see above> |
652 | block=vhd,<see above> |
651 | |
653 | |
652 | And finally, inside this disk, another C<locate> will look for a partition |
654 | And finally, inside this disk, another C<locate> will look for a partition |
653 | with a path as specified in the C<path> element, which most likely will be |
655 | with a path as specified in the C<path> element, which most likely will be |
… | |
… | |
656 | locate=<see above>,element,path |
658 | locate=<see above>,element,path |
657 | |
659 | |
658 | As a result, this will boot the first Windows it finds on the first |
660 | As a result, this will boot the first Windows it finds on the first |
659 | F<disk.vhdx> disk image it can find anywhere. |
661 | F<disk.vhdx> disk image it can find anywhere. |
660 | |
662 | |
661 | =item locate=<block=vhd,<block=file,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,\win10.vhdx>>,element,path |
663 | =item C<< locate=<block=vhd,<block=file,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,\win10.vhdx>>,element,path >> |
662 | |
664 | |
663 | Pretty much the same as the previous case, but witzh a bit of variance. First, look for a specific partition on |
665 | Pretty much the same as the previous case, but with a bit of |
664 | an MBR-partitioned disk: |
666 | variance. First, look for a specific partition on an MBR-partitioned disk: |
665 | |
667 | |
666 | partition=<null>,harddisk,mbr,47cbc08a,242643632128 |
668 | partition=<null>,harddisk,mbr,47cbc08a,242643632128 |
667 | |
669 | |
668 | Then open the file F<\win10.vhdx> on that partition: |
670 | Then open the file F<\win10.vhdx> on that partition: |
669 | |
671 | |
… | |
… | |
675 | |
677 | |
676 | And again the windows loader (or whatever is in C<path>) will be searched: |
678 | And again the windows loader (or whatever is in C<path>) will be searched: |
677 | |
679 | |
678 | locate=<see above>,element,path |
680 | locate=<see above>,element,path |
679 | |
681 | |
680 | =item {b097d2b2-bc00-11e9-8a9a-525400123456}block<1>=ramdisk,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,0,0,0,\boot.wim |
682 | =item C<< {b097d2b2-bc00-11e9-8a9a-525400123456}block<1>=ramdisk,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,0,0,0,\boot.wim >> |
681 | |
683 | |
682 | This is quite different. First, it starts with a GUID. This GUID belongs |
684 | This is quite different. First, it starts with a GUID. This GUID belongs |
683 | to a BCD object of type C<device>, which has additional parameters: |
685 | to a BCD object of type C<device>, which has additional parameters: |
684 | |
686 | |
685 | "{b097d2b2-bc00-11e9-8a9a-525400123456}" : { |
687 | "{b097d2b2-bc00-11e9-8a9a-525400123456}" : { |
… | |
… | |
688 | "ramdisksdidevice" : "partition=<null>,harddisk,mbr,47cbc08a,1048576", |
690 | "ramdisksdidevice" : "partition=<null>,harddisk,mbr,47cbc08a,1048576", |
689 | "ramdisksdipath" : "\boot.sdi" |
691 | "ramdisksdipath" : "\boot.sdi" |
690 | }, |
692 | }, |
691 | |
693 | |
692 | I will not go into many details, but this specifies a (presumably empty) |
694 | I will not go into many details, but this specifies a (presumably empty) |
693 | template ramdisk image (F<\boot.sdi>) that is used to initiaolize the |
695 | template ramdisk image (F<\boot.sdi>) that is used to initialize the |
694 | ramdisk. The F<\boot.wim> file is then extracted into it. As you cna also |
696 | ramdisk. The F<\boot.wim> file is then extracted into it. As you can also |
695 | see, this F<.sdi> file resides on a different C<partition>. |
697 | see, this F<.sdi> file resides on a different C<partition>. |
696 | |
698 | |
697 | Continuitn, as always, form the inside out, first this device descriptor |
699 | Continuing, as always, from the inside out, first this device descriptor |
698 | finds a specific partition: |
700 | finds a specific partition: |
699 | |
701 | |
700 | partition=<null>,harddisk,mbr,47cbc08a,242643632128 |
702 | partition=<null>,harddisk,mbr,47cbc08a,242643632128 |
701 | |
703 | |
702 | And then specifies a C<ramdisk> image on this partition: |
704 | And then specifies a C<ramdisk> image on this partition: |
… | |
… | |
710 | |
712 | |
711 | |
713 | |
712 | =head1 EDITING BCD DATA STORES |
714 | =head1 EDITING BCD DATA STORES |
713 | |
715 | |
714 | The C<edit> and C<parse> subcommands allow you to read a BCD data store |
716 | The C<edit> and C<parse> subcommands allow you to read a BCD data store |
715 | and modify it or extract data from it. This is done by exyecuting a series |
717 | and modify it or extract data from it. This is done by executing a series |
716 | of "editing instructions" which are explained here. |
718 | of "editing instructions" which are explained here. |
717 | |
719 | |
718 | =over |
720 | =over |
719 | |
721 | |
720 | =item get I<object> I<element> |
722 | =item C<get> I<object> I<element> |
721 | |
723 | |
722 | Reads the BCD element I<element> from the BCD object I<object> and writes |
724 | Reads the BCD element I<element> from the BCD object I<object> and writes |
723 | it to standard output, followed by a newline. The I<object> can be a GUID |
725 | it to standard output, followed by a newline. The I<object> can be a GUID |
724 | or a human-readable alias, or the special string C<{default}>, which will |
726 | or a human-readable alias, or the special string C<{default}>, which will |
725 | refer to the default BCD object. |
727 | refer to the default BCD object. |
726 | |
728 | |
727 | Example: find description of the default BCD object. |
729 | Example: find description of the default BCD object. |
728 | |
730 | |
729 | pbcdedit parse BCD get "{default}" description |
731 | pbcdedit parse BCD get "{default}" description |
730 | |
732 | |
731 | =item set I<object> I<element> I<value> |
733 | =item C<set> I<object> I<element> I<value> |
732 | |
734 | |
733 | Similar to C<get>, but sets the element to the given I<value> instead. |
735 | Similar to C<get>, but sets the element to the given I<value> instead. |
734 | |
736 | |
735 | Example: change bootmgr default too |
737 | Example: change the bootmgr default too |
736 | C<{b097d2ad-bc00-11e9-8a9a-525400123456}>: |
738 | C<{b097d2ad-bc00-11e9-8a9a-525400123456}>: |
737 | |
739 | |
738 | pbcdedit edit BCD set "{bootmgr}" resumeobject "{b097d2ad-bc00-11e9-8a9a-525400123456}" |
740 | pbcdedit edit BCD set "{bootmgr}" resumeobject "{b097d2ad-bc00-11e9-8a9a-525400123456}" |
739 | |
741 | |
740 | =item eval I<perlcode> |
742 | =item C<eval> I<perlcode> |
741 | |
743 | |
742 | This takes the next argument, interprets it as Perl code and |
744 | This takes the next argument, interprets it as Perl code and |
743 | evaluates it. This allows you to do more complicated modifications or |
745 | evaluates it. This allows you to do more complicated modifications or |
744 | extractions. |
746 | extractions. |
745 | |
747 | |
… | |
… | |
764 | The example given for C<get>, above, could be expressed like this with |
766 | The example given for C<get>, above, could be expressed like this with |
765 | C<eval>: |
767 | C<eval>: |
766 | |
768 | |
767 | pbcdedit edit BCD eval 'say $BCD->{$DEFAULT}{description}' |
769 | pbcdedit edit BCD eval 'say $BCD->{$DEFAULT}{description}' |
768 | |
770 | |
769 | The example given for C<set> could be expresed like this: |
771 | The example given for C<set> could be expressed like this: |
770 | |
772 | |
771 | pbcdedit edit BCD eval '$BCD->{$DEFAULT}{resumeobject} = "{b097d2ad-bc00-11e9-8a9a-525400123456}"' |
773 | pbcdedit edit BCD eval '$BCD->{$DEFAULT}{resumeobject} = "{b097d2ad-bc00-11e9-8a9a-525400123456}"' |
772 | |
774 | |
773 | =item do I<path> |
775 | =item C<do> I<path> |
774 | |
776 | |
775 | Similar to C<eval>, above, but instead of using the argument as perl code, |
777 | Similar to C<eval>, above, but instead of using the argument as perl code, |
776 | it loads the perl code from the given file and executes it. This makes it |
778 | it loads the perl code from the given file and executes it. This makes it |
777 | easier to write more complicated or larger programs. |
779 | easier to write more complicated or larger programs. |
778 | |
780 | |
779 | =back |
781 | =back |
780 | |
782 | |
|
|
783 | |
781 | =head1 SEE ALSO |
784 | =head1 SEE ALSO |
782 | |
785 | |
783 | For ideas on what you can do, and some introductory material, try |
786 | For ideas on what you can do, and some introductory material, try |
784 | L<http://www.mistyprojects.co.uk/documents/BCDEdit/index.html>. |
787 | L<http://www.mistyprojects.co.uk/documents/BCDEdit/index.html>. |
785 | |
788 | |
786 | For good reference on BCD objects and elements, see Geoff Chappels pages |
789 | For good reference on which BCD objects and |
|
|
790 | elements exist, see Geoff Chappell's pages at |
787 | at L<http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm>. |
791 | L<http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm>. |
788 | |
792 | |
789 | =head1 AUTHOR |
793 | =head1 AUTHOR |
790 | |
794 | |
791 | Written by Marc A. Lehmann <pbcdedit@schmorp.de>. |
795 | Written by Marc A. Lehmann L<pbcdedit@schmorp.de>. |
792 | |
796 | |
793 | =head1 REPORTING BUGS |
797 | =head1 REPORTING BUGS |
794 | |
798 | |
795 | Bugs can be reported dorectly tt he author at L<pcbedit@schmorp.de>. |
799 | Bugs can be reported directly the author at L<pcbedit@schmorp.de>. |
796 | |
800 | |
797 | =head1 BUGS AND SHORTCOMINGS |
801 | =head1 BUGS AND SHORTCOMINGS |
798 | |
802 | |
799 | This should be a module. Of a series of modules, even. |
803 | This should be a module. Of a series of modules, even. |
800 | |
804 | |
801 | Registry code should preserve classname and security descriptor data, and |
805 | Registry code should preserve classname and security descriptor data, and |
802 | whatever else is necessary to read and write any registry hive file. |
806 | whatever else is necessary to read and write any registry hive file. |
803 | |
807 | |
804 | I am also not happy with device descriptors being strings rather than a |
808 | I am also not happy with device descriptors being strings rather than a |
805 | data structure, but strings are probably better for command line usage. In |
809 | data structure, but strings are probably better for command line usage. In |
806 | any case,. device descriptors could be converted by simply "splitting" at |
810 | any case, device descriptors could be converted by simply "splitting" at |
807 | "=" and "," into an array reference, recursively. |
811 | "=" and "," into an array reference, recursively. |
808 | |
812 | |
809 | =head1 HOMEPAGE |
813 | =head1 HOMEPAGE |
810 | |
814 | |
811 | Original versions of this program can be found at |
815 | Original versions of this program can be found at |
… | |
… | |
2269 | |
2273 | |
2270 | if ($insn eq "get") { |
2274 | if ($insn eq "get") { |
2271 | my $object = shift @insns; |
2275 | my $object = shift @insns; |
2272 | my $elem = shift @insns; |
2276 | my $elem = shift @insns; |
2273 | |
2277 | |
2274 | $object = $default if $object eq "{default}"; |
2278 | $object = $object eq "{default}" ? $default : dec_wguid enc_wguid $object; |
2275 | |
2279 | |
2276 | print $bcd->{$object}{$elem}, "\n"; |
2280 | print $bcd->{$object}{$elem}, "\n"; |
2277 | |
2281 | |
2278 | } elsif ($insn eq "set") { |
2282 | } elsif ($insn eq "set") { |
2279 | my $object = shift @insns; |
2283 | my $object = shift @insns; |
2280 | my $elem = shift @insns; |
2284 | my $elem = shift @insns; |
2281 | my $value = shift @insns; |
2285 | my $value = shift @insns; |
2282 | |
2286 | |
2283 | $object = $default if $object eq "{default}"; |
2287 | $object = $object eq "{default}" ? $default : dec_wguid enc_wguid $object; |
2284 | |
2288 | |
2285 | $bcd->{$object}{$elem} = $value; |
2289 | $bcd->{$object}{$elem} = $value; |
2286 | |
2290 | |
2287 | } elsif ($insn eq "eval") { |
2291 | } elsif ($insn eq "eval") { |
2288 | bcd_edit_eval shift @insns; |
2292 | bcd_edit_eval shift @insns; |