ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/pbcdedit/pbcdedit
(Generate patch)

Comparing pbcdedit/pbcdedit (file contents):
Revision 1.10 by root, Wed Aug 14 23:03:07 2019 UTC vs.
Revision 1.11 by root, Wed Aug 14 23:15:36 2019 UTC

75sensitive data. 75sensitive data.
76 76
77=back 77=back
78 78
79The target audience for this program is professionals and tinkerers who 79The target audience for this program is professionals and tinkerers who
80are rewady to invest time into learning how it works. It is not an easy 80are ready to invest time into learning how it works. It is not an easy
81program to use and requires patience and a good understanding of BCD data 81program to use and requires patience and a good understanding of BCD data
82stores. 82stores.
83 83
84 84
85=head1 SUBCOMMANDS 85=head1 SUBCOMMANDS
86 86
87PCBEDIT expects a subcommand as first argument that tells it what to 87PBCDEDIT expects a subcommand as first argument that tells it what to
88do. The following subcommands exist: 88do. The following subcommands exist:
89 89
90=over 90=over
91 91
92=item help 92=item help
93 93
94Displays the whole manuale page (this document). 94Displays the whole manual page (this document).
95 95
96=item export F<path> 96=item export F<path>
97 97
98Reads a BCD data store and writes a JSON representation of it to standard 98Reads a BCD data store and writes a JSON representation of it to standard
99output. 99output.
100 100
101The format of the data is explained later in this document. 101The format of the data is explained later in this document.
102 102
103Example: read a BCD store, modify it wiht an extenral program, write it again. 103Example: read a BCD store, modify it with an external program, write it
104again.
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
126using this command - the external C<lsblk> command is required, as well as 127using this command - the external C<lsblk> command is required, as well as
127a mounted C</sys> file system. 128a mounted C</sys> file system.
128 129
129The output will be a list of all partitions in the system and C<partition> 130The output will be a list of all partitions in the system and C<partition>
130descriptors for GPT and both C<legacypartition> and C<partition> 131descriptors for GPT and both C<legacypartition> and C<partition>
131descritpors for MBR partitions. 132descriptors for MBR partitions.
132 133
133=item objects [--json] 134=item objects [--json]
134 135
135Outputs two tables: a table listing all type aliases with their hex bcd 136Outputs two tables: a table listing all type aliases with their hex BCD
136element ID, and all object name aliases with their GUID and default type 137element ID, and all object name aliases with their GUID and default type
137(if any). 138(if any).
138 139
139With C<--json> it prints similar information as a JSON object, for easier parsing. 140With C<--json> it prints similar information as a JSON object, for easier parsing.
140 141
162The written hive will always be in a slightly modified version 1.3 163The written hive will always be in a slightly modified version 1.3
163format. It's not the format windows would generate, but it should be 164format. It's not the format windows would generate, but it should be
164understood by any conformant hive reader. 165understood by any conformant hive reader.
165 166
166Note that the representation chosen by PBCDEDIT currently throws away 167Note that the representation chosen by PBCDEDIT currently throws away
167clasname data (often used for feeble attemtps at hiding stuff by 168classname data (often used for feeble attempts at hiding stuff by
168Microsoft) and security descriptors, so if you write anything other than 169Microsoft) and security descriptors, so if you write anything other than
169a BCD hive you will most likely destroy it. 170a 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
244The C<meta> key is not stored in the BCD data store but is used only 245The C<meta> key is not stored in the BCD data store but is used only
245by PBCDEDIT. It is always generated when exporting, and importing will 246by PBCDEDIT. It is always generated when exporting, and importing will
246be refused when it exists and the version stored inside doesn't store 247be refused when it exists and the version stored inside doesn't store
247the JSON schema version of PBCDEDIT. This ensures that differemt and 248the JSON schema version of PBCDEDIT. This ensures that different and
248incompatible versions of PBCDEDIT will not read and misinterΓΌret each 249incompatible versions of PBCDEDIT will not read and misinterpret each
249others data. 250others data.
250 251
251=head2 The object keys 252=head2 The object keys
252 253
253Every other key is a BCD object. There is usually a BCD object for the 254Every other key is a BCD object. There is usually a BCD object for the
254boot manager, one for every boot option and a few others that store common 255boot manager, one for every boot option and a few others that store common
255settings inherited by these. 256settings inherited by these.
256 257
257Each BCD object is represented by a GUID wrapped in curly braces. These 258Each BCD object is represented by a GUID wrapped in curly braces. These
258are usually random GUIDs used only to distinguish bCD objects from each 259are usually random GUIDs used only to distinguish BCD objects from each
259other. When adding a new boot option, you can simply generate a new GUID. 260other. When adding a new boot option, you can simply generate a new GUID.
260 261
261Some of these GUIDs are fixed well known GUIDs which PBCDEDIT will decode 262Some of these GUIDs are fixed well known GUIDs which PBCDEDIT will decode
262into human-readable strings such as C<{globalsettings}>, which is the same 263into human-readable strings such as C<{globalsettings}>, which is the same
263as C<{7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}>. 264as C<{7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}>.
297get a list of all BCD elements known to PBCDEDIT by running F<pbcdedit 298get a list of all BCD elements known to PBCDEDIT by running F<pbcdedit
298elements>. 299elements>.
299 300
300What was said about duplicate keys mapping to the same object is true for 301What was said about duplicate keys mapping to the same object is true for
301elements as well, so, again, you should always use the canonical name, 302elements as well, so, again, you should always use the canonical name,
302whcih is the human radable alias, if known. 303which is the human readable alias, if known.
303 304
304=head3 BCD element types 305=head3 BCD element types
305 306
306Each BCD element has a type such as I<string> or I<boolean>. This type 307Each BCD element has a type such as I<string> or I<boolean>. This type
307determines how the value is interpreted, and most of them are pretty easy 308determines 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
324Almost as simnple are booleans, which represent I<true>/I<false>, 325Almost as simple are booleans, which represent I<true>/I<false>,
325I<on>/I<off> and similar values. In the JSON form, true is represented 326I<on>/I<off> and similar values. In the JSON form, true is represented
326by the number C<1>, and false is represented by the number C<0>. Other 327by the number C<1>, and false is represented by the number C<0>. Other
327values will be accepted, but PBCDEDIT doesn't guarantee how these are 328values will be accepted, but PBCDEDIT doesn't guarantee how these are
328interpreted. 329interpreted.
329 330
335 336
336=item integer 337=item integer
337 338
338Again, very simple, this is a 64 bit integer. IT can be either specified 339Again, very simple, this is a 64 bit integer. IT can be either specified
339as a decimal number, as a hex number (by prefixing it with C<0x>) or as a 340as a decimal number, as a hex number (by prefixing it with C<0x>) or as a
340binatry number (prefix C<0b>). 341binary number (prefix C<0b>).
341 342
342For example, the boot C<timeout> is an integer, specifying the automatic 343For example, the boot C<timeout> is an integer, specifying the automatic
343boot delay in seconds: 344boot delay in seconds:
344 345
345 "timeout" : 30, 346 "timeout" : 30,
346 347
347=item integer list 348=item integer list
348 349
349This is a list of 64 bit integers separated by whitespace. It is not used 350This is a list of 64 bit integers separated by whitespace. It is not used
350much, so here is a somewhat artificial an untested exanmple of using 351much, so here is a somewhat artificial an untested example of using
351C<customactions> to specify a certain custom, eh, action to be executed 352C<customactions> to specify a certain custom, eh, action to be executed
352when pressing C<F10> at boot: 353when 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
358This represents a single GUID value wrqapped in curly braces. It is used a 359This represents a single GUID value wrapped in curly braces. It is used a
359lot to refer from one BCD object to other one. 360lot to refer from one BCD object to other one.
360 361
361For example, The C<{bootmgr}> object might refer to a resume boot option 362For example, The C<{bootmgr}> object might refer to a resume boot option
362using C<resumeobject>: 363using C<resumeobject>:
363 364
365 366
366Human readable aliases are used and allowed. 367Human readable aliases are used and allowed.
367 368
368=item guid list 369=item guid list
369 370
370Similar to te guid type, this represents a list of such GUIDs, separated 371Similar to the GUID type, this represents a list of such GUIDs, separated
371by whitespace from each other. 372by whitespace from each other.
372 373
373For example, many BCD objects can I<inherit> elements from other BCD 374For example, many BCD objects can I<inherit> elements from other BCD
374objects by specifying the GUIDs of those other objects ina GUID list 375objects by specifying the GUIDs of those other objects in a GUID list
375called surprisingly called C<inherit>: 376called surprisingly called C<inherit>:
376 377
377 "inherit" : "{dbgsettings} {emssettings} {badmemory}", 378 "inherit" : "{dbgsettings} {emssettings} {badmemory}",
378 379
379This example also shows how human readable aliases can be used. 380This 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
392Device elements specify, well, devices. They are used for such diverse 393Device elements specify, well, devices. They are used for such diverse
393purposes such as finding a TFTP network boot imagem serial ports or VMBUS 394purposes such as finding a TFTP network boot image, serial ports or VMBUS
394devices, but most commonly they are used to specify the disk (harddisk, 395devices, but most commonly they are used to specify the disk (harddisk,
395cdrom ramdisk, vhd...) to boot from. 396cdrom, ramdisk, vhd...) to boot from.
396 397
397The device element is kind of a mini-language in its own which is much 398The device element is kind of a mini-language in its own which is much
398more versatile then the limited windows interface to it - BCDEDIT - 399more versatile then the limited windows interface to it - BCDEDIT -
399reveals. 400reveals.
400 401
403element, so almost everything known about it had to be researched first 404element, so almost everything known about it had to be researched first
404in the process of writing this script, and consequently, support for BCD 405in the process of writing this script, and consequently, support for BCD
405device elements is partial only. 406device elements is partial only.
406 407
407On the other hand, the expressive power of PBCDEDIT in specifying devices 408On the other hand, the expressive power of PBCDEDIT in specifying devices
408is much bigger than BCDEDIT and therefore more cna be don with it. The 409is much bigger than BCDEDIT and therefore more can be done with it. The
409downside is that BCD device elements are much more complicated than what 410downside is that BCD device elements are much more complicated than what
410you might think from reading the BCDEDIT documentation. 411you might think from reading the BCDEDIT documentation.
411 412
412In other words, simple things are complicated, and complicated things are 413In other words, simple things are complicated, and complicated things are
413possible. 414possible.
414 415
415Anyway, the general syntax of device elements is an optional GUID, 416Anyway, the general syntax of device elements is an optional GUID,
416followed by a device type, optionally followed by hexdecimal flags in 417followed by a device type, optionally followed by hexadecimal flags in
417angle brackets, optionally followed by C<=> and a comma-separated list of 418angle brackets, optionally followed by C<=> and a comma-separated list of
418arguments, some of which can be (and often are) in turn devices again. 419arguments, 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
485This designates a specific partition on a block device. C<< <parent> 486This 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
487C<null>. Note that the anfgle brackets are part of the syntax. 488C<null>. Note that the angle brackets are part of the syntax.
488 489
489C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>, 490C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>,
490C<file> or C<vhd>, where the first three should be self-explaining, 491C<file> or C<vhd>, where the first three should be self-explaining,
491C<file> is usually used to locate a device by finding a magic file, and 492C<file> is usually used to locate a device by finding a magic file, and
492C<vhd> is used for virtual harddisks - F<.vhd> and F<-vhdx> files. 493C<vhd> is used for virtual harddisks - F<.vhd> and F<-vhdx> files.
505 506
506The C<diskid> is the 32 bit disk signature stored at offset 0x1b8 in the 507The C<diskid> is the 32 bit disk signature stored at offset 0x1b8 in the
507MBR, interpreted as a 32 bit unsigned little endian integer and written as 508MBR, interpreted as a 32 bit unsigned little endian integer and written as
508hex number. That is, the bytes C<01 02 03 04> would become C<04030201>. 509hex number. That is, the bytes C<01 02 03 04> would become C<04030201>.
509 510
510Diskpart (using the C<DETAIL> command) and the C<lsblk> comamnd typically 511Diskpart (using the C<DETAIL> command) and the C<lsblk> command typically
511found on GNU/Linux systems (using e.g. C<lsblk -o NAME,PARTUUID>) can 512found on GNU/Linux systems (using e.g. C<lsblk -o NAME,PARTUUID>) can
512display the disk id. 513display the C<diskid>.
513 514
514The C<partitionid> is the byte offset(!) of the partition counting from 515The C<partitionid> is the byte offset(!) of the partition counting from
515the beginning of the MBR. 516the beginning of the MBR.
516 517
517Example, use the partition on the harddisk with C<diskid> C<47cbc08a> 518Example, 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
524The C<diskid> is the disk UUID/disk identifier GUID from the partition 525The C<diskid> is the disk GUID/disk identifier GUID from the partition
525table (as displayed e.g. by C<gdisk>), and the C<partitionid> is the 526table (as displayed e.g. by C<gdisk>), and the C<partitionid> is the
526partition unique GUID (displayed using e.g. the C<gdisk> C<i> command). 527partition unique GUID (displayed using e.g. the C<gdisk> C<i> command).
527 528
528Example: use the partition C<76d39e5f-ad1b-407e-9c05-c81eb83b57dd> on GPT 529Example: use the partition C<76d39e5f-ad1b-407e-9c05-c81eb83b57dd> on GPT
529disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>. 530disk 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
535Instead of diskid and partitionid, this type only accepts a decimal disk 536Instead of C<diskid> and C<partitionid>, this type only accepts a decimal
536number and signifies the whole disk. BCDEDIT cannot display the resulting 537disk number and signifies the whole disk. BCDEDIT cannot display the
537device, and I am doubtful whether it has a useful effect. 538resulting 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
543This is exactly the same as the C<partition> type, except for a tiny 544This is exactly the same as the C<partition> type, except for a tiny
544detail: instead of using the partition start offset, this type uses the 545detail: instead of using the partition start offset, this type uses the
545partition number for MBR disks. Behaviour other partition types should be 546partition number for MBR disks. Behaviour other partition types should be
546the same. 547the same.
547 548
548The partition number starts at C<1> and skips unused partition, so if 549The partition number starts at C<1> and skips unused partition, so if
549there are two primary partitions and another partition inside the extended 550there are two primary partitions and another partition inside the extended
550partition, the primary partitions are number C<1> and C<2> and the 551partition, the primary partitions are number C<1> and C<2> and the
551partition inside the extended partition is number C<3>, rwegardless of any 552partition inside the extended partition is number C<3>, regardless of any
552gaps. 553gaps.
553 554
554=item locate=<parent>,locatetype,locatearg 555=item locate=<parent>,locatetype,locatearg
555 556
556This device description will make the bootloader search for a partition 557This device description will make the bootloader search for a partition
790 791
791Written by Marc A. Lehmann L<pbcdedit@schmorp.de>. 792Written by Marc A. Lehmann L<pbcdedit@schmorp.de>.
792 793
793=head1 REPORTING BUGS 794=head1 REPORTING BUGS
794 795
795Bugs can be reported dorectly the author at L<pcbedit@schmorp.de>. 796Bugs 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
799This should be a module. Of a series of modules, even. 800This should be a module. Of a series of modules, even.
800 801

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines