| … | |
… | |
| 448 | 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 |
| 449 | that not of all the following is necessarily supported in PBCDEDIT): |
449 | that not of all the following is necessarily supported in PBCDEDIT): |
| 450 | |
450 | |
| 451 | =over |
451 | =over |
| 452 | |
452 | |
| 453 | =item binary=I<hex...> |
453 | =item C<binary=>I<hex...> |
| 454 | |
454 | |
| 455 | 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 |
| 456 | 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 |
| 457 | 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 |
| 458 | 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. |
| 459 | |
459 | |
| 460 | =item null |
460 | =item C<null> |
| 461 | |
461 | |
| 462 | 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 |
| 463 | 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 |
| 464 | 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 |
| 465 | called C<null>. |
465 | called C<null>. |
| 466 | |
466 | |
| 467 | 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 |
| 468 | device, when no parent device is used. |
468 | device, when no parent device is used. |
| 469 | |
469 | |
| 470 | =item boot |
470 | =item C<boot> |
| 471 | |
471 | |
| 472 | 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 |
| 473 | from (nowadays typically the EFI system partition). |
473 | from (nowadays typically the EFI system partition). |
| 474 | |
474 | |
| 475 | =item vmbus=I<interfacetype>,I<interfaceinstance> |
475 | =item C<vmbus=>I<interfacetype>,I<interfaceinstance> |
| 476 | |
476 | |
| 477 | 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 |
| 478 | instance, both of which are "naked" (no curly braces) GUIDs. |
478 | instance, both of which are "naked" (no curly braces) GUIDs. |
| 479 | |
479 | |
| 480 | 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): |
| 481 | |
481 | |
| 482 | vmbus=c376c1c3-d276-48d2-90a9-c04748072c60,12345678-a234-b234-c234-d2345678abcd |
482 | vmbus=c376c1c3-d276-48d2-90a9-c04748072c60,12345678-a234-b234-c234-d2345678abcd |
| 483 | |
483 | |
| 484 | =item partition=<I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid> |
484 | =item C<partition=><I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid> |
| 485 | |
485 | |
| 486 | This designates a specific partition on a block device. C<< <parent> |
486 | This designates a specific partition on a block device. C<< <parent> |
| 487 | >> 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 |
| 488 | C<null>. Note that the angle brackets are part of the syntax. |
488 | C<null>. Note that the angle brackets are part of the syntax. |
| 489 | |
489 | |
| … | |
… | |
| 529 | 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 |
| 530 | disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>. |
530 | disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>. |
| 531 | |
531 | |
| 532 | 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 |
| 533 | |
533 | |
| 534 | =item raw |
534 | =item C<raw> |
| 535 | |
535 | |
| 536 | Instead of C<diskid> and C<partitionid>, this type only accepts a decimal |
536 | Instead of C<diskid> and C<partitionid>, this type only accepts a decimal |
| 537 | disk number and signifies the whole disk. BCDEDIT cannot display the |
537 | disk number and signifies the whole disk. BCDEDIT cannot display the |
| 538 | resulting device, and I am doubtful whether it has a useful effect. |
538 | resulting device, and I am doubtful whether it has a useful effect. |
| 539 | |
539 | |
| 540 | =back |
540 | =back |
| 541 | |
541 | |
| 542 | =item legacypartition=<I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid> |
542 | =item C<legacypartition=><I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid> |
| 543 | |
543 | |
| 544 | 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 |
| 545 | 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 |
| 546 | partition number for MBR disks. Behaviour other partition types should be |
546 | partition number for MBR disks. Behaviour other partition types should be |
| 547 | the same. |
547 | the same. |
| … | |
… | |
| 550 | there are two primary partitions and another partition inside the extended |
550 | there are two primary partitions and another partition inside the extended |
| 551 | 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 |
| 552 | partition inside the extended partition is number C<3>, regardless of any |
552 | partition inside the extended partition is number C<3>, regardless of any |
| 553 | gaps. |
553 | gaps. |
| 554 | |
554 | |
| 555 | =item locate=<parent>,locatetype,locatearg |
555 | =item C<locate=><I<parent>>,I<locatetype>,I<locatearg> |
| 556 | |
556 | |
| 557 | This device description will make the bootloader search for a partition |
557 | This device description will make the bootloader search for a partition |
| 558 | with a given path. |
558 | with a given path. |
| 559 | |
559 | |
| 560 | 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 |
| … | |
… | |
| 574 | Example: find any partition which has the path specified in the |
574 | Example: find any partition which has the path specified in the |
| 575 | C<systemroot> element (typically C<\Windows>). |
575 | C<systemroot> element (typically C<\Windows>). |
| 576 | |
576 | |
| 577 | locate=<null>,element,systemroot |
577 | locate=<null>,element,systemroot |
| 578 | |
578 | |
| 579 | =item block=devicetype,args... |
579 | =item C<block=>I<devicetype>,I<args...> |
| 580 | |
580 | |
| 581 | 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 |
| 582 | devices (which could be inside a F<vhdx> file for example). |
582 | devices (which could be inside a F<vhdx> file for example). |
| 583 | |
583 | |
| 584 | 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>, |
| … | |
… | |
| 586 | |
586 | |
| 587 | The remaining arguments change depending on the C<devicetype>: |
587 | The remaining arguments change depending on the C<devicetype>: |
| 588 | |
588 | |
| 589 | =over |
589 | =over |
| 590 | |
590 | |
| 591 | =item block=file,<parent>,path |
591 | =item C<block=file>,<I<parent>>,I<path> |
| 592 | |
592 | |
| 593 | Interprets the C<< <parent> >> device (typically a partition) as a |
593 | Interprets the C<< <parent> >> device (typically a partition) as a |
| 594 | filesystem and specifies a file path inside. |
594 | filesystem and specifies a file path inside. |
| 595 | |
595 | |
| 596 | =item block=vhd,<parent> |
596 | =item C<block=vhd>,<I<parent>> |
| 597 | |
597 | |
| 598 | Pretty much just changes the interpretation of C<< <parent> >>, which is |
598 | Pretty much just changes the interpretation of C<< <parent> >>, which is |
| 599 | 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. |
| 600 | |
600 | |
| 601 | =item block=ramdisk,<parent>,base,size,offset,path |
601 | =item C<block=ramdisk>,<I<parent>>,I<base>,I<size>,I<offset>,I<path> |
| 602 | |
602 | |
| 603 | Interprets the C<< <parent> >> device as RAM disk, using the (decimal) |
603 | Interprets the C<< <parent> >> device as RAM disk, using the (decimal) |
| 604 | 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 |
| 605 | 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 |
| 606 | from the RAM disk image or other parameters. |
606 | from the RAM disk image or other parameters. |
| 607 | |
607 | |
| 608 | This is most commonly used to boot C<wim> images. |
608 | This is most commonly used to boot C<wim> images. |
| 609 | |
609 | |
| 610 | =item block=floppy,drivenum |
610 | =item C<block=floppy>,I<drivenum> |
| 611 | |
611 | |
| 612 | 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 |
| 613 | 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. |
| 614 | |
614 | |
| 615 | =item block=cdrom,drivenum |
615 | =item C<block=cdrom>,I<drivenum> |
| 616 | |
616 | |
| 617 | Pretty much the same as C<floppy> but for CD-ROMs. |
617 | Pretty much the same as C<floppy> but for CD-ROMs. |
| 618 | |
618 | |
| 619 | =item anything else |
619 | =item anything else |
| 620 | |
620 | |
| … | |
… | |
| 624 | |
624 | |
| 625 | =back5 Examples |
625 | =back5 Examples |
| 626 | |
626 | |
| 627 | This concludes the syntax overview for device elements, but probably |
627 | This concludes the syntax overview for device elements, but probably |
| 628 | 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 |
| 629 | 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 |
| 630 | complex aspects. |
630 | complex aspects. |
| 631 | |
631 | |
| 632 | =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 |
| 633 | |
633 | |
| 634 | Just like with C declarations, you best treat device descriptors as |
634 | Just like with C declarations, you best treat device descriptors as |
