… | |
… | |
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 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 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 import F<path> |
108 | |
109 | |
… | |
… | |
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 objects [--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 | |
… | |
… | |
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 | |
… | |
… | |
482 | |
483 | |
483 | =item partition=<parent>,devicetype,partitiontype,diskid,partitionid |
484 | =item partition=<parent>,devicetype,partitiontype,diskid,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. C<< <parent> |
486 | >> is an optional parent device on which to search on, and is often |
487 | >> is an optional parent device on which to search on, and is often |
487 | C<null>. Note that the anfgle brackets are part of the syntax. |
488 | C<null>. Note that the angle brackets are part of the syntax. |
488 | |
489 | |
489 | C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, |
490 | C<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 device by finding a magic file, and |
492 | C<vhd> is used for virtual harddisks - F<.vhd> and F<-vhdx> files. |
493 | C<vhd> is used for virtual harddisks - F<.vhd> and F<-vhdx> files. |
… | |
… | |
505 | |
506 | |
506 | The C<diskid> is the 32 bit disk signature stored at offset 0x1b8 in the |
507 | 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 |
508 | 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>. |
509 | hex number. That is, the bytes C<01 02 03 04> would become C<04030201>. |
509 | |
510 | |
510 | Diskpart (using the C<DETAIL> command) and the C<lsblk> comamnd typically |
511 | 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 |
512 | found on GNU/Linux systems (using e.g. C<lsblk -o NAME,PARTUUID>) can |
512 | display the disk id. |
513 | display the C<diskid>. |
513 | |
514 | |
514 | The C<partitionid> is the byte offset(!) of the partition counting from |
515 | The C<partitionid> is the byte offset(!) of the partition counting from |
515 | the beginning of the MBR. |
516 | the beginning of the MBR. |
516 | |
517 | |
517 | Example, use the partition on the harddisk with C<diskid> C<47cbc08a> |
518 | Example, use the partition on the harddisk with C<diskid> C<47cbc08a> |
… | |
… | |
519 | |
520 | |
520 | partition=<null>,harddisk,mbr,47cbc08a,1048576 |
521 | partition=<null>,harddisk,mbr,47cbc08a,1048576 |
521 | |
522 | |
522 | =item gpt |
523 | =item gpt |
523 | |
524 | |
524 | The C<diskid> is the disk UUID/disk identifier GUID from the partition |
525 | The C<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 |
526 | table (as displayed e.g. by C<gdisk>), and the C<partitionid> is the |
526 | partition unique GUID (displayed using e.g. the C<gdisk> C<i> command). |
527 | partition unique GUID (displayed using e.g. the C<gdisk> C<i> command). |
527 | |
528 | |
528 | Example: use the partition C<76d39e5f-ad1b-407e-9c05-c81eb83b57dd> on GPT |
529 | Example: use the partition C<76d39e5f-ad1b-407e-9c05-c81eb83b57dd> on GPT |
529 | disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>. |
530 | disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>. |
530 | |
531 | |
531 | partition=<null>,harddisk,gpt,9742e468-9206-48a0-b4e4-c4e9745a356a,76d39e5f-ad1b-407e-9c05-c81eb83b57dd |
532 | partition=<null>,harddisk,gpt,9742e468-9206-48a0-b4e4-c4e9745a356a,76d39e5f-ad1b-407e-9c05-c81eb83b57dd |
532 | |
533 | |
533 | =item raw |
534 | =item raw |
534 | |
535 | |
535 | Instead of diskid and partitionid, this type only accepts a decimal disk |
536 | Instead of C<diskid> and C<partitionid>, this type only accepts a decimal |
536 | number and signifies the whole disk. BCDEDIT cannot display the resulting |
537 | disk number and signifies the whole disk. BCDEDIT cannot display the |
537 | device, and I am doubtful whether it has a useful effect. |
538 | resulting device, and I am doubtful whether it has a useful effect. |
538 | |
539 | |
539 | =back |
540 | =back |
540 | |
541 | |
541 | =item legacypartition=<parent>,devicetype,partitiontype,diskid,partitionid |
542 | =item C<< legacypartition=< >>parentC<< >, >>devicetypeC<,>partitiontypeC<,>diskidC<,>partitionid |
542 | |
543 | |
543 | This is exactly the same as the C<partition> type, except for a tiny |
544 | 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 |
545 | detail: instead of using the partition start offset, this type uses the |
545 | partition number for MBR disks. Behaviour other partition types should be |
546 | partition number for MBR disks. Behaviour other partition types should be |
546 | the same. |
547 | the same. |
547 | |
548 | |
548 | The partition number starts at C<1> and skips unused partition, so if |
549 | 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 |
550 | 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 |
551 | 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 |
552 | partition inside the extended partition is number C<3>, regardless of any |
552 | gaps. |
553 | gaps. |
553 | |
554 | |
554 | =item locate=<parent>,locatetype,locatearg |
555 | =item locate=<parent>,locatetype,locatearg |
555 | |
556 | |
556 | This device description will make the bootloader search for a partition |
557 | This device description will make the bootloader search for a partition |
… | |
… | |
790 | |
791 | |
791 | Written by Marc A. Lehmann L<pbcdedit@schmorp.de>. |
792 | Written by Marc A. Lehmann L<pbcdedit@schmorp.de>. |
792 | |
793 | |
793 | =head1 REPORTING BUGS |
794 | =head1 REPORTING BUGS |
794 | |
795 | |
795 | Bugs can be reported dorectly the author at L<pcbedit@schmorp.de>. |
796 | Bugs can be reported directly the author at L<pcbedit@schmorp.de>. |
796 | |
797 | |
797 | =head1 BUGS AND SHORTCOMINGS |
798 | =head1 BUGS AND SHORTCOMINGS |
798 | |
799 | |
799 | This should be a module. Of a series of modules, even. |
800 | This should be a module. Of a series of modules, even. |
800 | |
801 | |