Jump to content











Photo

Bug Reports, Requests, HowTo's about Tiny PXE Server

pxe network boot

  • Please log in to reply
783 replies to this topic

#726 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14263 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 16 November 2017 - 07:58 PM

However, whilst I like learning a lot, i much prefer seeing practical effects and cool stuff happening!! Sometimes learning is best jumping in feet first, seeing cool stuff happen, then when you get stuck going back to the documentation. Then the relevence, importance and therefore intrest of that exercise renders it a worthwhile and intersting experience. Saying read all these pages of abstract information first, then apply that knowledge is not how I learn best.

Sure, I know :) and personally I often cite Ray Bradbury:

 

Life is trying things to see if they work.

but in this peculiar case you are having some difficulties not because of TinyPxE, nor because of wimboot, but rather related on the (as said unfortunately actually complex) more "basic" booting mechanisms.

 

It is more like you want (rightly :thumbsup: ) to understand how (say) a 3 axis cnc machine works in detail but have no familiarity with the conventions about X, Y and Z planes and no idea on how a stepper motor works, you don't need to know much details but if you know that X goes from left to right, that Y goes from you outwards and that Z goes from bottom to top, this will help you a lot in understanding G-code, as well, without knowing how actually a stepper motor works, knowing that it rotates the shaft a given angle at each pulse it receives and that a finite number of pulses will go 360 degrees will be needed (and for this to happen you need to know that by definition a full turn is actually 360 degrees).

 

The real issue is that this kind of info is rarely "consolidated" in a single, easily accessible/understandable location but rather scattered here and there over half the internet, I know :(, so when for once something (I believe) clear and understandable to the layman is available (such as diddy's and Misty's various guides) one must take advantage of them. 

 

:duff:

Wonko


  • MikhailCompo likes this

#727 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 01 February 2018 - 11:31 PM

I have a feature request.

The ability to have a unique rootfolder per arch.

 

The reason behind it?  

I need to boot both 32 and 64 bit winpe with secureboot on and without having to do a selection in any menu (aka unattended installations)

 

The alternatives i have found so far does not work.

Ipxe/Memboot/grub/pxelinux won't work with secureboot enabled.

Using a BCD menu would work with secureboot but it will fail on being unattended.

 

being able to have multiple root folders would be able to solve both so "Pretty please with sugar, nuts, a cherry and chocolate sprinkles?" (shameless monkey island ref)



#728 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 02 February 2018 - 04:56 PM

I have a feature request.

The ability to have a unique rootfolder per arch.

 

The reason behind it?  

I need to boot both 32 and 64 bit winpe with secureboot on and without having to do a selection in any menu (aka unattended installations)

 

The alternatives i have found so far does not work.

Ipxe/Memboot/grub/pxelinux won't work with secureboot enabled.

Using a BCD menu would work with secureboot but it will fail on being unattended.

 

being able to have multiple root folders would be able to solve both so "Pretty please with sugar, nuts, a cherry and chocolate sprinkles?" (shameless monkey island ref)

 

have you tried the [arch] section in config.ini?

with this you can server the right boot loader based on the client architecture.



#729 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 03 February 2018 - 11:47 AM

Yes. I have tried that and it helps a little bit but it doesn't get me all the way. I should have mentioned that we need complete separation between different boot images. IE we can not have a common folder between two boot images.

 

As I have it right now a X64 uefi boot sequence will look like:

%root%\00007\EFI\boot\bootx64.efi (as defined in arch in config.ini)

%root%\00007\boot\BCD (as defined in option 252)

 

And a X86 uefi boot sequence would look like:

%root%\00006\EFI\boot\bootx64.efi (as defined in arch in config.ini)

%root%\00006\boot\BCD (as defined in option 252)

 

So far so good but now comes the problem:

the next request is for 

%root%\EFI\ .... which brakes the scenario

 

If there could be a feature allowing something like

 

If archroot=1 then 

root=%root%\@arch it would solve it all

 

With %root% as c:\pxesrv\files it would give a X64 UEFI system a root folder of c:\pxe\files\00007 and a 32 bit UEFI system would get c:\pxe\files\00006 hence allowing separate folders for each arch.

as a bonus it would remove the need for modifying the BCD since the relative paths now would be right out of the box.

as an extra bonus it would allow for a cleaner root directory with just three folders for booting 32 bit bios, 32 bit UEFI and 64 bit UEFI instead of having a bunch of files and folders in the root folder



#730 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 03 February 2018 - 12:18 PM

Have you tried @arch in the filename field ?
It is an alternative to the arch section.

You can also combine both methods.
See http://labalec.fr/erwan/?p=1430

#731 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 03 February 2018 - 12:32 PM

I shall add that changing the root on the fly is not possible.
Daemons use that information when they start.
So a common root is necessary.
Similar to how a windows dvd is built containing both bios and efi files.

We can only influence the filename and to some extent its path, when the request comes in.

#732 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 03 February 2018 - 01:47 PM

Have you tried @arch in the filename field ?
It is an alternative to the arch section.

You can also combine both methods.
See http://labalec.fr/erwan/?p=1430

Yes, that is option 252 and as I stated it does not help



#733 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 03 February 2018 - 02:02 PM

have you look at this post?

rather than adapting the "server" part, why not work on the "client" part?

 

again, the windows dvd is a good example.

one common root folder containing both bios and efi files.

 

i am not saying that your idea of having a root folder for each architecture is wrong but it is challenging.

 

so far you can :

-have a different boot loader based on the arch

-have a different bcd based on the arch

-eventually customize your bcd to load wim files at different locations on the "server" side

-use wimboot (as one example) on the "client" side to load files based at different locations on the "server" side

 

with all these above combinations, you may want to slightly review your objectives to find the best compromise/solution.



#734 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 03 February 2018 - 02:53 PM

have you look at this post?

rather than adapting the "server" part, why not work on the "client" part?

 

again, the windows dvd is a good example.

one common root folder containing both bios and efi files.

 

i am not saying that your idea of having a root folder for each architecture is wrong but it is challenging.

 

so far you can :

-have a different boot loader based on the arch

-have a different bcd based on the arch

-eventually customize your bcd to load wim files at different locations on the "server" side

-use wimboot (as one example) on the "client" side to load files based at different locations on the "server" side

 

with all these above combinations, you may want to slightly review your objectives to find the best compromise/solution.

 

A DVD is quite right as an example.  The boot directory of a WDS server is and there you can see the separation of files based on arches.
It is a challenging task I agree but so far I have been unable to find anything else that works since Secureboot is a hard requirement (simply it can't even be turned off on some of our devices)

 

Different loader per arch - Yes but they must be signed so that secure boot works. 

Different BCD per arch -yes but they have to be modified from standard making it more work.

Different Wim - Yes, but still it will use common \boot and \EFI and that may be a major problem depending on versions 
Wimboot - can you do wimboot without Ipxe? As far as I know there is no Ipxe that works with secure boot?



#735 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 03 February 2018 - 03:10 PM

Aactually, kind of related to this thread, I could consider some remapping feature.

Where based a section in the config.ini, I could "on the fly" change part of a path by another part.

Like base to 00006, 00007, etc 



#736 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 03 February 2018 - 05:04 PM

That sounds like a good idea.

 

I have been doing some network captures to map the boot sequense.

Currently with option 252 set to @arch\boot\BCD and in config.ini

 

[arch]

00000=\00000\wdsnpb.com

00007=\00007\EFI\boot\bootx64.efi

 

a boot of a X86 bios box loads the following files (Files in bold are the ones that breaks "out of the box")

 

\00000\wdsnpb.com

\00000\pxeboot.com

\00000\bootmgr.exe

\00000\boot\BCD

\boot\en-US\bootmgr.exe.MUI

\hiberfile.sys -Doesn't exist so can be ignored

\00000\sources\boot.wim

\boot\boot.sdi

\boot\fonts\segoe_slboot.ttf

\boot\fonts\segmono_boot.ttf

\boot\resources\bootres.dll

\boot\fonts\wgl4_boot.ttf

\boot\boot.sdi

 

Here it should be enough to remap \boot\ to \00000\boot\ or as I would prefer it \@arch\boot ;)

 

for 64bit UEFI (arch 00007) it looks like 

\00007\EFI\boot\bootx64.efi

\00007\EFI\boot\BCD

\EFI\Microsoft\boot\policies\sbpflighttoken.p7b

\EFI\Microsoft\boot\securebootpolicy.p7b

\EFI\Microsoft\boot\skuSiPolicy,p7b

\EFI\Microsoft\boot\SiPolicy.p7b

\EFI\Microsoft\boot\UpdateSkuSiPolicy.p7b

\EFI\Microsoft\boot\UpdateSiPolicy.p7b

\EFI\Microsoft\boot\WinSiPolicy.p7b

\EFI\Microsoft\boot\UpdateWinSiPolicy.p7b

\EFI\Microsoft\boot\ATPSiPolicy.p7b

\EFI\Microsoft\boot\UpdateATPSiPolicy.p7b

\EFI\Microsoft\boot\EntRevokeSiPolicy.p7b

\EFI\Microsoft\boot\UpdateEntRevokeSiPolicy.p7b

\00007\EFI\Boot\en-us\bootx64.efi.mui

\EFI\Microsoft\boot\boot.stl

\00007\sources\boot.wim

\boot\boot.sdi

 

Here both \EFI and \boot needs to be remapped. 

therefore I belive that a remap function will need the arch to be reliable but with that it could do

\EFI\ to \00007\EFI and \boot\ to \0007\boot

 

Even better would be to be able to remap the leading \ to \@arch\ since that would remove the need for option 252 and BCD editing as a bonus :)



#737 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 03 February 2018 - 06:17 PM

I should be able to release a new version with a basic mapping feature later this evening (or this week end).

Then we can see how we can make it evolve if needed.

 

I foresee a new config.ini section called [map].

then we would have entries like boot=00007 or boot=@arch


  • ktp likes this

#738 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 03 February 2018 - 08:19 PM

New version uploaded with (very) basic string replacement in the tftp onreadfile event.

 

No regex, no generic or special char, no variable such as @arch, etc ... just a plain search and replace function.

 

The below will replace the first occurence 'boot' with '00000\boot'.

Example : \boot\boot.sdi would become \00000\boot\boot.sdi

[map]
boot=00000\boot

side note : when the tftp request comes in, it is pretty hard (if any possible) to know what is the arch of the pxe client (dhcpd and tftp are independant from each other).



#739 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 03 February 2018 - 08:33 PM

the zip file now includes a version.txt 

pxesrv.exe 
1.0.0.21
03/02/2018 21:10 
FF31411788DA055AC6995E2200BF22E5


#740 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 04 February 2018 - 10:13 AM

New version uploaded with (very) basic string replacement in the tftp onreadfile event.

 

No regex, no generic or special char, no variable such as @arch, etc ... just a plain search and replace function.

 

The below will replace the first occurence 'boot' with '00000\boot'.

Example : \boot\boot.sdi would become \00000\boot\boot.sdi

[map]
boot=00000\boot

side note : when the tftp request comes in, it is pretty hard (if any possible) to know what is the arch of the pxe client (dhcpd and tftp are independant from each other).

 

I'm sorry to report that it doesn't work 100%.

 

It will replace the first occurrence of boot but it will do so not only on the root folder boot but also subfolders and filenames.

That means that a request for \00000\pxeboot.com gets renamed to \00000\pxe\00000\boot.com hence breaking the boot

 

On a 64 bit UEFI boot the file \00007\EFI\Boot\Bootx64.efi will be remapped to \00007\EFI\00007\boot\00000\bootx64.efi

 

Therefore I think we need a way to make it just look at the first foldername to work in this scenario. It will probably still have a problem with /boot since that is used by both arches.

 

 

I have an Idea on the DHCP to TFTP issue. Its not 100% perfect but I think it could work. It will need code changes on both daemons though.

As I understand things the DHCP or proxyDHCP receives the arch as Option 60 or/and 93 when the client sends out a DHCP request.

IF the DHCP deamon would write down the mac and the arch to a simple database (aka textfile) there would be a store of this data.

 

The TFTP deamon could then read that file and since TFTP requests do contain the mac of the requesting system it now has the data it needs to be able to do remapping based on the arch since it got it from the DHCP data.



#741 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 11:26 AM

Have you tried \boot\=\00000\boot\ and \efi\microsoft\=\00007\efi\microsoft\?

I am not enthusiast about drastically change my code for this request.

#742 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 11:33 AM

I also need to update my code so that it updates the string only once.

#743 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 11:41 AM

new version uploaded.

pxesrv.exe 
1.0.0.21
04/02/2018 12:53 
AAF41FC46BBCE9FA86A0262096B5D98C

When altering the filename on the fly, it will only alter the first found occurence AND it will not process other entries in the map section.

 

code below.

procedure TfrmDHCPServer.OnReadFile (Sender: TObject; var FileName: String; const PeerInfo: TPeerInfo;
    var GrantAccess: Boolean; var AStream: TStream; var FreeStreamOnComplete: Boolean) ;
var
i:byte;
sl:tstringlist;
begin
//here we can modify the requested filename on the fly
//before the request gets to the TFTPD
try
if (h_map<>nil) then //do we have entries in the map section
  begin
  sl:=h_map.Keys ;
  for i:=0 to sl.Count -1 do  //lets loop thru map entries
    begin
    if pos(sl [i],filename)>0 then //we have a match
      begin
      filename:=StringReplace(filename,sl [i],h_map.GetString(sl [i]),[rfIgnoreCase]); //NOT rfReplaceAll
      break; //job done, we stop it there
      end;
    end;
  end;
except
end;
end;


#744 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 11:43 AM

@matso : with that latest version, based on your post 741, highlight precisely which cases are not covered or which new issue is introduced.

I have a few ideas ...

 

The below in the config.ini should address request in post 741 (or close enough to take it to the next update  :) ).

The order of the entries below [map] does matter.

 

Try this one.

[map]
\efi\=\00007\efi\
\boot\=\00000\boot\

And this one.

[map]
\efi\microsoft\=\00007\efi\microsoft\
\boot\=\00000\boot\


#745 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 01:10 PM

new version uploded.

 

although I am convinced the search and replace function can be handy, i am unsure about @Matso scenario.

pxesrv.exe 
1.0.0.21
04/02/2018 14:08 
CC9234D6500082C7C509E64FB6BE0F2F

new "search and replace" function code.

procedure TfrmDHCPServer.OnReadFile (Sender: TObject; var FileName: String; const PeerInfo: TPeerInfo;
    var GrantAccess: Boolean; var AStream: TStream; var FreeStreamOnComplete: Boolean) ;
var
i:byte;
sl:tstringlist;
begin
//here we can modify the requested filename on the fly
//before the request gets to the TFTPD
try
if (h_map<>nil) then //do we have entries in the map section
  begin
  sl:=h_map.Keys ;
  for i:=0 to sl.Count -1 do  //lets loop thru map entries
    begin
    if pos(lowercase(sl [i]),lowercase(filename))>0 then //we have a match
      begin
      if pos(lowercase(h_map.GetString(sl [i])),lowercase(filename))=0 then //lets replace only if filename does not contain our new string
        begin
        filename:=StringReplace(filename,sl [i],h_map.GetString(sl [i]),[rfIgnoreCase]); //NOT rfReplaceAll
        end;//if pos(h_map.GetString(sl [i]),filename)=0 then
       break; //we stop it there as we had a match, whether we actually modified the filename or not
      end;//if pos(sl [i],filename)>0
    end;//for i:=0 to sl.Count -1 do
  end;//if (h_map<>nil) then
except
end;
end;


#746 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 04 February 2018 - 03:19 PM

with latest version and 

[map]

\efi\=\00007\efi\
\boot\=\0
0000\boot\

 

and

 

[arch]

00007=\00007\EFI\Boot\bootx64.efi

 

It fails on UEFI 64 bit with a rewrite to \00007\EFI\00000\boot\bootx64.efi. I tried to add \00007\EFI\Boot\bootx64.efi=\00007\EFI\Boot\bootx64.efi to the [MAP] section so that it should get a first hit and abort the mapping but it did not help. 

 

On 32 bit bios it fails with a loader error f. It still tries to read something from /boot but I haven't found out what yet. 
The reason i know It's something in /boot? If i leave that folder it works and if i rename it, the error occurs.

 

I will work on finding out exactly what it is it tries to access in /boot

 

Edit:

 

Lucky guess on first attempt. It's at least /boot/fonts that still gets accessed. I restored (boot and renamed /boot/fonts to /boot/fonts.old and the boot failed.


Edited by matso, 04 February 2018 - 03:24 PM.


#747 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 03:27 PM

ok, getting closer.

there might be some light at the end of this tunnel :)

 

try the below for now (and move your boot loader at the root of  \00007).

it should get you a bit further.

 

i have spot another in the meantime (working on it).

[arch]
00007=\00007\bootx64.efi


#748 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 04:05 PM

with latest version and 

[map]

\efi\=\00007\efi\
\boot\=\00000\boot\

 

and

 

[arch]

00007=\00007\EFI\Boot\bootx64.efi

 

It fails on UEFI 64 bit with a rewrite to \00007\EFI\00000\boot\bootx64.efi. I tried to add \00007\EFI\Boot\bootx64.efi=\00007\EFI\Boot\bootx64.efi to the [MAP] section so that it should get a first hit and abort the mapping but it did not help. 

 

On 32 bit bios it fails with a loader error f. It still tries to read something from /boot but I haven't found out what yet. 
The reason i know It's something in /boot? If i leave that folder it works and if i rename it, the error occurs.

 

I will work on finding out exactly what it is it tries to access in /boot

 

Edit:

 

Lucky guess on first attempt. It's at least /boot/fonts that still gets accessed. I restored (boot and renamed /boot/fonts to /boot/fonts.old and the boot failed.

 

I am focusing on 00000 arch for now.

 

I have the same behavior as you reported.

 

Remaping works but only if i leave \boot\boot.sdi in the root folder ?

 

my config.ini.

[arch]
00000=pxeboot.n12
[map]
pxeboot.n12=00000\pxeboot.n12
bootmgr=00000\bootmgr
\boot\=\00000\boot\
\sources\boot.wim=\00000\sources\boot.wim

my log.

17:00:22 ROOT=C:\Users\erwan\Documents\-= SOURCES =-\delphi\network\sniffer_w2k\pxesrv\_pxe\
17:00:22 DHCPd 192.168.1.99:67 started...
17:00:22 DHCPd 192.168.1.99:4011 started...
17:00:22 TFPTd 192.168.1.99:69 started...
17:00:33 DHCPd:DISCOVER received, MAC:00-0C-29-EC-F3-3D, XID:2AECF33D
17:00:34 DHCPd:OFFER sent, IP:0.0.0.0, XID:2AECF33D
17:00:35 DHCPd:REQUEST discarded, MAC:00-0C-29-EC-F3-3D, XID:2AECF33D
17:00:35 PDHCPd:REQUEST received, MAC:00-0C-29-EC-F3-3D, IP:192.168.1.129, XID:2AECF33D
17:00:36 Proxy boot filename empty?
17:00:36 PDHCPd:DHCP_ACK sent, IP:192.168.1.129:68, xid:2AECF33D
17:00:36 TFTPd:DoReadFile:00000\pxeboot.n12 B:0 T:25358
17:00:36 TFTPd:DoReadFile:00000\pxeboot.n12 B:1456 T:0
17:00:36 TFTPd:DoReadFile:00000\bootmgr.exe B:1456 T:0
17:00:36 TFTPd:DoReadFile:\00000\bcd B:0 T:262144
17:00:36 TFTPd:DoReadFile:\00000\bcd B:1456 T:262144
17:00:36 TFTPd:DoReadFile:\00000\sources\boot.wim B:0 T:217166131
17:00:36 TFTPd:DoReadFile:\00000\boot\boot.sdi B:0 T:3170304
17:00:36 TFTPd:DoReadFile:\00000\boot\fonts\segoe_slboot.ttf B:0 T:77404
17:00:36 TFTPd:DoReadFile:\00000\boot\fonts\segoe_slboot.ttf B:1456 T:77404
17:00:36 TFTPd:DoReadFile:\00000\boot\fonts\segmono_boot.ttf B:0 T:36020
17:00:36 TFTPd:DoReadFile:\00000\boot\fonts\segmono_boot.ttf B:1456 T:36020
17:00:36 TFTPd:DoReadFile:\00000\boot\fonts\wgl4_boot.ttf B:0 T:47452
17:00:36 TFTPd:DoReadFile:\00000\boot\fonts\wgl4_boot.ttf B:1456 T:47452
17:00:36 TFTPd:DoReadFile:\00000\boot\boot.sdi B:1456 T:3170304
17:00:37 TFTPd:DoReadFile:\00000\sources\boot.wim B:1456 T:217166131


#749 erwan.l

erwan.l

    Gold Member

  • Developer
  • 2286 posts
  • Location:Nantes - France
  •  
    France

Posted 04 February 2018 - 04:40 PM

Latest version "fully" works with new "[map]" feature uploaded.

pxesrv.exe 
1.0.0.21
04/02/2018 17:36 
10722DD2BF0006AB56C1A1E55E6C7EEC

My below config.ini.

No boot or sources folder in my root folder - all files sit in root\00000.

opt252=@arch\bcd

[arch]
00000=00000\pxeboot.n12
[map]
\boot\boot.sdi=\00000\boot\boot.sdi
;or
;\boot\=\00000\boot\
\sources\boot.wim=\00000\sources\boot.wim

the below wors as well.

[arch]
00000=pxeboot.n12
[map]
pxeboot.n12=00000\pxeboot.n12
bootmgr=00000\bootmgr
\boot\boot.sdi=\00000\boot\boot.sdi
;or
;\boot\=\00000\boot\
\sources\boot.wim=\00000\sources\boot.wim


#750 matso

matso
  • Members
  • 9 posts
  •  
    Sweden

Posted 04 February 2018 - 06:23 PM

I can do even better :)

using opt252=@arch\boot\BCD (and yes those BCD:s are modified to read from \%arch%\sources\boot.wim)

 

With [arch]

00000=\00000\wdsnbp.com

00007=\00007\EFI\Boot\bootx64.efi

 

[MAP]

\EFI\Microsoft\boot\fonts\segoe_slboot.ttf=\00007\EFI\Microsoft\boot\fonts\segoe_slboot.ttf \EFI\Microsoft\boot\fonts\segmono_boot.ttf=\00007\EFI\Microsoft\boot\fonts\segmono_boot.ttf \EFI\Microsoft\boot\fonts\wgl4_boot.ttf=\00007\EFI\Microsoft\boot\fonts\wgl4_boot.ttf \EFI\Microsoft\boot\resources\bootres.dll=\00007\EFI\Microsoft\boot\resources\bootres.dll \boot\boot.sdi=\00000\boot\boot.sdi

\boot\resources\bootres.dll=\00000\boot\resources\bootres.dll

\boot\fonts\wgl4_boot.ttf=\00000\boot\fonts\wgl4_boot.ttf \boot\fonts\segmono_boot.ttf=\00000\boot\fonts\segmono_boot.ttf \boot\fonts\segoe_slboot.ttf=\00000\boot\fonts\segoe_slboot.ttf

\boot\en-US\bootmgr.EXE.MUI=\00000\boot\en-US\bootmgr.EXE.MUI

 

Now there is two attempts from arch 00000 to access files outside it's folder, Hiberfile.sys and an EFI file that doesn't even exist. They can safely be ignored.

 

From Arch 00007 there are some attempts to read non existing EFI files which also can be ignored.

 

The only "bad" access so far is that 00007 will read \00000\boot\boot.sdi. It should be rather harmless since it's just an empty filesystem in that file.

 

So yes this works as long as we only have one Bios and one UEFI arch, if we want separation between UEFI arches like 00006,7 and 9. Well then it requires a lot more work ;)

 

It also would be nice to be able to remap \sources\boot.wim but if we do that we will send all arches to the same wim ....


Edited by matso, 04 February 2018 - 06:28 PM.






Also tagged with one or more of these keywords: pxe, network boot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users