… | |
… | |
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 | |
… | |
… | |
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. 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. |
… | |
… | |
499 | the same is true for the C<partitionid>. How these are interpreted depends |
500 | the same is true for the C<partitionid>. How these are interpreted depends |
500 | on the C<partitiontype>: |
501 | on the C<partitiontype>: |
501 | |
502 | |
502 | =over |
503 | =over |
503 | |
504 | |
504 | =item mbr |
505 | =item C<mbr> |
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> |
518 | starting at sector C<2048> (= 1048576 / 512). |
519 | starting at sector C<2048> (= 1048576 / 512). |
519 | |
520 | |
520 | partition=<null>,harddisk,mbr,47cbc08a,1048576 |
521 | partition=<null>,harddisk,mbr,47cbc08a,1048576 |
521 | |
522 | |
522 | =item gpt |
523 | =item C<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 C<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=><I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<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 C<locate=><I<parent>>,I<locatetype>,I<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 |
557 | with a given path. |
558 | with a given path. |
558 | |
559 | |
559 | The C<< <parent> >> device is the device to search on (angle brackets are |
560 | The C<< <parent> >> device is the device to search on (angle brackets are |
… | |
… | |
573 | Example: find any partition which has the path specified in the |
574 | Example: find any partition which has the path specified in the |
574 | C<systemroot> element (typically C<\Windows>). |
575 | C<systemroot> element (typically C<\Windows>). |
575 | |
576 | |
576 | locate=<null>,element,systemroot |
577 | locate=<null>,element,systemroot |
577 | |
578 | |
578 | =item block=devicetype,args... |
579 | =item C<block=>I<devicetype>,I<args...> |
579 | |
580 | |
580 | Last not least, the most complex type, C<block>, which... specifies block |
581 | Last not least, the most complex type, C<block>, which... specifies block |
581 | devices (which could be inside a F<vhdx> file for example). |
582 | devices (which could be inside a F<vhdx> file for example). |
582 | |
583 | |
583 | C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, |
584 | C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, |
… | |
… | |
585 | |
586 | |
586 | The remaining arguments change depending on the C<devicetype>: |
587 | The remaining arguments change depending on the C<devicetype>: |
587 | |
588 | |
588 | =over |
589 | =over |
589 | |
590 | |
590 | =item block=file,<parent>,path |
591 | =item C<block=file>,<I<parent>>,I<path> |
591 | |
592 | |
592 | Interprets the C<< <parent> >> device (typically a partition) as a |
593 | Interprets the C<< <parent> >> device (typically a partition) as a |
593 | filesystem and specifies a file path inside. |
594 | filesystem and specifies a file path inside. |
594 | |
595 | |
595 | =item block=vhd,<parent> |
596 | =item C<block=vhd>,<I<parent>> |
596 | |
597 | |
597 | Pretty much just changes the interpretation of C<< <parent> >>, which is |
598 | Pretty much just changes the interpretation of C<< <parent> >>, which is |
598 | usually a disk image (C<block=file,...)>) to be a F<vhd> or F<vhdx> file. |
599 | usually a disk image (C<block=file,...)>) to be a F<vhd> or F<vhdx> file. |
599 | |
600 | |
600 | =item block=ramdisk,<parent>,base,size,offset,path |
601 | =item C<block=ramdisk>,<I<parent>>,I<base>,I<size>,I<offset>,I<path> |
601 | |
602 | |
602 | Interprets the C<< <parent> >> device as RAM disk, using the (decimal) |
603 | Interprets the C<< <parent> >> device as RAM disk, using the (decimal) |
603 | base address, byte size and byte offset inside a file specified by |
604 | 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 |
605 | C<path>. The numbers are usually all C<0> because they can be extracted |
605 | from the RAM disk image or other parameters. |
606 | from the RAM disk image or other parameters. |
606 | |
607 | |
607 | This is most commonly used to boot C<wim> images. |
608 | This is most commonly used to boot C<wim> images. |
608 | |
609 | |
609 | =item block=floppy,drivenum |
610 | =item C<block=floppy>,I<drivenum> |
610 | |
611 | |
611 | Refers to a removable drive identified by a number. BCDEDIT cannot display |
612 | 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. |
613 | the resulting device, and it is not clear what effect it will have. |
613 | |
614 | |
614 | =item block=cdrom,drivenum |
615 | =item C<block=cdrom>,I<drivenum> |
615 | |
616 | |
616 | Pretty much the same as C<floppy> but for CD-ROMs. |
617 | Pretty much the same as C<floppy> but for CD-ROMs. |
617 | |
618 | |
618 | =item anything else |
619 | =item anything else |
619 | |
620 | |
… | |
… | |
623 | |
624 | |
624 | =back5 Examples |
625 | =back5 Examples |
625 | |
626 | |
626 | This concludes the syntax overview for device elements, but probably |
627 | 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 |
628 | 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 |
629 | many questions, but I can walk you through some actual examples using more |
629 | complex aspects. |
630 | complex aspects. |
630 | |
631 | |
631 | =item locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path |
632 | =item locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path |
632 | |
633 | |
633 | Just like with C declarations, you best treat device descriptors as |
634 | Just like with C declarations, you best treat device descriptors as |
… | |
… | |
786 | For good reference on BCD objects and elements, see Geoff Chappels pages |
787 | For good reference on BCD objects and elements, see Geoff Chappels pages |
787 | at L<http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm>. |
788 | at L<http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm>. |
788 | |
789 | |
789 | =head1 AUTHOR |
790 | =head1 AUTHOR |
790 | |
791 | |
791 | Written by Marc A. Lehmann <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 tt he 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 | |