| … | |
… | |
| 618 | many questions, but I can walk you through some actual examples using mroe |
618 | many questions, but I can walk you through some actual examples using mroe |
| 619 | complex aspects. |
619 | complex aspects. |
| 620 | |
620 | |
| 621 | =item locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path |
621 | =item locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path |
| 622 | |
622 | |
| 623 | #todo |
623 | Just like with C declarations, you best treat device descriptors as |
|
|
624 | instructions to find your device and work your way from the inside out: |
|
|
625 | |
|
|
626 | locate=<null>,path,\disk.vhdx |
|
|
627 | |
|
|
628 | First, the innermost device descriptor searches all partitions on the |
|
|
629 | system for a file called F<\disk.vhdx>: |
|
|
630 | |
|
|
631 | block=file,<see above>,\disk.vhdx |
|
|
632 | |
|
|
633 | Next, this takes the device locate has found and finds a file called |
|
|
634 | F<\disk.vhdx> on it. This is the same file locate was using, but that is |
|
|
635 | only because we find the device using the same path as finding the disk |
|
|
636 | image, so this is purely incidental, although quite common. |
|
|
637 | |
|
|
638 | Bext, this file will be opened as a virtual disk: |
|
|
639 | |
|
|
640 | block=vhd,<see above> |
|
|
641 | |
|
|
642 | And finally, inside this disk, another C<locate> will look for a partition |
|
|
643 | with a path as specified in the C<path> element, which most likely will be |
|
|
644 | F<\Windows\system32\winload.exe>: |
|
|
645 | |
|
|
646 | locate=<see above>,element,path |
|
|
647 | |
|
|
648 | As a result, this will boot the first Windows it finds on the first |
|
|
649 | F<disk.vhdx> disk image it can find anywhere. |
| 624 | |
650 | |
| 625 | =item locate=<block=vhd,<block=file,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,\win10.vhdx>>,element,path |
651 | =item locate=<block=vhd,<block=file,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,\win10.vhdx>>,element,path |
| 626 | |
652 | |
| 627 | #todo |
653 | Pretty much the same as the previous case, but witzh a bit of variance. First, look for a specific partition on |
|
|
654 | an MBR-partitioned disk: |
|
|
655 | |
|
|
656 | partition=<null>,harddisk,mbr,47cbc08a,242643632128 |
|
|
657 | |
|
|
658 | Then open the file F<\win10.vhdx> on that partition: |
|
|
659 | |
|
|
660 | block=file,<see above>,\win10.vhdx |
|
|
661 | |
|
|
662 | Then, again, the file is opened as a virtual disk image: |
|
|
663 | |
|
|
664 | block=vhd,<see above> |
|
|
665 | |
|
|
666 | And again the windows loader (or whatever is in C<path>) will be searched: |
|
|
667 | |
|
|
668 | locate=<see above>,element,path |
| 628 | |
669 | |
| 629 | =item {b097d2b2-bc00-11e9-8a9a-525400123456}block<1>=ramdisk,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,0,0,0,\boot.wim |
670 | =item {b097d2b2-bc00-11e9-8a9a-525400123456}block<1>=ramdisk,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,0,0,0,\boot.wim |
| 630 | |
671 | |
| 631 | #todo |
672 | This is quite different. First, it starts with a GUID. This GUID belongs |
|
|
673 | to a BCD object of type C<device>, which has additional parameters: |
|
|
674 | |
|
|
675 | "{b097d2b2-bc00-11e9-8a9a-525400123456}" : { |
|
|
676 | "type" : "device", |
|
|
677 | "description" : "sdi file for ramdisk", |
|
|
678 | "ramdisksdidevice" : "partition=<null>,harddisk,mbr,47cbc08a,1048576", |
|
|
679 | "ramdisksdipath" : "\boot.sdi" |
|
|
680 | }, |
|
|
681 | |
|
|
682 | I will not go into many details, but this specifies a (presumably empty) |
|
|
683 | template ramdisk image (F<\boot.sdi>) that is used to initiaolize the |
|
|
684 | ramdisk. The F<\boot.wim> file is then extracted into it. As you cna also |
|
|
685 | see, this F<.sdi> file resides on a different C<partition>. |
|
|
686 | |
|
|
687 | Continuitn, as always, form the inside out, first this device descriptor |
|
|
688 | finds a specific partition: |
|
|
689 | |
|
|
690 | partition=<null>,harddisk,mbr,47cbc08a,242643632128 |
|
|
691 | |
|
|
692 | And then specifies a C<ramdisk> image on this partition: |
|
|
693 | |
|
|
694 | block<1>=ramdisk,<see above>,0,0,0,\boot.wim |
|
|
695 | |
|
|
696 | I don't know what the purpose ofd the C<< <1> >> flag value is, but it |
|
|
697 | seems to be always there on this kind of entry. |
| 632 | |
698 | |
| 633 | |
699 | |
| 634 | =head1 SEE ALSO |
700 | =head1 SEE ALSO |
| 635 | |
701 | |
| 636 | For ideas on what you can do, and some introductory material, try |
702 | For ideas on what you can do, and some introductory material, try |
