NetBoot and PXE Boot co-existence

https://macmule.com/2015/05/04/enableddisabled-identifiers-nbimageinfo-plist/

I think its actually a bug that has been fixed in a later version of bsdpy, i just haven't updated my container. I'll have to get around to doing that.

I think in the version of bsdpy that is in that container it looks at disabled and blocks them from booting. In later versions i'm pretty sure this was fixed and now it ignores items in disabled, unless there is an enabled system id in enabled and that system id is missing from disabled. then it becomes a whitelist where only enabled system ids are allowed to boot. I

Yeah looks like its fixed in this version:
https://bitbucket.org/bruienne/bsdpy/src/83270fb82b1163c46a9ac2380e9868268b4c8a95/bsdpserver.py?at=api&fileviewer=file-view-default#bsdpserver.py-414:484

OK, thanks for all your help.

will report back with findings

ok after a docker restart i dont get the restricted message for my mac but the tftp url seems alot missing from it plus theres nothing there for the boot Image url, anywhere I can define these?

12/08/2015 01:26:25 AM - DEBUG: Determining image list for system ID MacBookPro8,2
12/08/2015 01:26:25 AM - DEBUG: Image "No description" has no restrictions, adding to list
12/08/2015 01:26:25 AM - DEBUG: -=========================================-
12/08/2015 01:26:25 AM - DEBUG: Return ACK[SELECT] to 3c:7:54:29:2c:e4 - 10.59.65.3 on port 68
12/08/2015 01:26:25 AM - DEBUG: --> TFTP URI: tftp://10.59.195.240
12/08/2015 01:26:25 AM - DEBUG: --> Boot Image URI:
root@isp-osb-netboot1:~#

Your netboot image is definitely in /nbi?
Permissions all o.k?

this is what it should look like:

--> TFTP URI: tftp://10.1.1.1/nbi/My_NetBootImage.nbi/i386/booter
--> Boot Image URI: http://10.1.1.1/My_NetBootImage.nbi/NetBoot.dmg

You should also see this in the top of the logs

12/03/2015 05:20:38 AM - DEBUG: [========= Updating boot images list =========]
12/03/2015 05:20:38 AM - DEBUG: Considering NBI source at /nbi/MY_NetBootImage.nbi
12/03/2015 05:20:39 AM - DEBUG: /nbi/My_NetBootImage.nbi
12/03/2015 05:20:39 AM - DEBUG: [=========      End updated list     =========]
12/03/2015 05:20:39 AM - DEBUG: [========= Using the following boot images =========]
12/03/2015 05:20:39 AM - DEBUG: /nbi/My_NetBootImage.nbi
12/03/2015 05:20:39 AM - DEBUG: [=========     End boot image listing      =========]
12/08/2015 11:47:56 AM - DEBUG: -=========================================-

yep get

12/08/2015 01:25:58 AM - DEBUG: [========= Updating boot images list =========] 12/08/2015 01:25:58 AM - DEBUG: Considering NBI source at /nbi/10.11.1AutoCasperNBI.nbi 12/08/2015 01:25:58 AM - DEBUG: /nbi/10.11.1AutoCasperNBI.nbi 12/08/2015 01:25:58 AM - DEBUG: [========= End updated list =========] 12/08/2015 01:25:58 AM - DEBUG: [========= Using the following boot images =========] 12/08/2015 01:25:58 AM - DEBUG: /nbi/10.11.1AutoCasperNBI.nbi 12/08/2015 01:25:58 AM - DEBUG: [========= End boot image listing =========]

but each time spits out 12/08/2015 02:06:33 AM - DEBUG: --> TFTP URI: tftp://10.59.195.240
12/08/2015 02:06:33 AM - DEBUG: --> Boot Image URI:
root@isp-osb-netboot1:/etc#
then fails, so close

shall i delete the container then rerun it?

can you do a ls -la on the /nbi folder and post the results

drwxr-xr-x  3 nobody nogroup 4096 Nov 26 02:48 .
drwxr-xr-x 23 root   root    4096 Dec  8 02:14 ..
drwxr-xr-x  3 nobody nogroup 4096 Nov 26 01:10 10.11.1AutoCasperNBI.nbi
-rwxr-xr-x  1 nobody nogroup 4096 Nov 26 01:48 ._.DS_Store
-rwxr-xr-x  1 nobody nogroup 6148 Nov 26 02:31 .DS_Store
root@isp-osb-netboot1:/nbi#

root@isp-osb-netboot1:/nbi/10.11.1AutoCasperNBI.nbi# ls -la
total 10448928
drwxr-xr-x 3 nobody nogroup        4096 Nov 26 01:10 .
drwxr-xr-x 3 nobody nogroup        4096 Nov 26 02:48 ..
drwxr-xr-x 3 nobody nogroup        4096 Nov 26 01:09 i386
-rwxr-xr-x 1 nobody nogroup         998 Dec  8 02:33 NBImageInfo.plist
-rwxr-xr-x 1 nobody nogroup 10689228800 Nov 26 01:10 NetBoot.dmg
root@isp-osb-netboot1:/nbi/10.11.1AutoCasperNBI.nbi#

yeah that looks like the problem

do a chown -R root:root /nbi

that nobody no group looks weird

What OS is it?

pretty much identical to my working server except that nbi was owned by root:root.

changed /nbi to root: root (like working server)

still nope

12/08/2015 02:43:18 AM - DEBUG: -=========================================-
12/08/2015 02:43:18 AM - DEBUG: Got BSDP INFORM[LIST] packet:
12/08/2015 02:43:18 AM - DEBUG: Using provided clientip 10.59.65.3
12/08/2015 02:43:18 AM - DEBUG: Determining image list for system ID MacBookPro8,2
12/08/2015 02:43:18 AM - DEBUG: Image "No description" has no restrictions, adding to list
12/08/2015 02:43:18 AM - DEBUG: -=========================================-
12/08/2015 02:43:18 AM - DEBUG: Return ACK[LIST] to 3c:7:54:29:2c:e4 - 10.59.65.3 on port 68
12/08/2015 02:43:19 AM - DEBUG: -=========================================-
12/08/2015 02:43:19 AM - DEBUG: Got BSDP INFORM[SELECT] packet:
12/08/2015 02:43:19 AM - DEBUG: Using provided clientip 10.59.65.3
12/08/2015 02:43:19 AM - DEBUG: Determining image list for system ID MacBookPro8,2
12/08/2015 02:43:19 AM - DEBUG: Image "No description" has no restrictions, adding to list
12/08/2015 02:43:19 AM - DEBUG: -=========================================-
12/08/2015 02:43:19 AM - DEBUG: Return ACK[SELECT] to 3c:7:54:29:2c:e4 - 10.59.65.3 on port 68
12/08/2015 02:43:19 AM - DEBUG: --> TFTP URI: tftp://10.59.195.240
12/08/2015 02:43:19 AM - DEBUG: --> Boot Image URI:

what OS is it? how are you running it?

for example:

MacBook pro running VMWare running CentOS 7 running Docker

ESX host running Vmware Ubuntu 14.04 trusty

weird

not sure whats going on there

you'll need to do a docker restart netboot_server after changing permissions

You'll also need to do a docker restart netboot_server after changing permissions

fixed!

the macbook I was trying to netboot had the command bless --netboot bsdp://10.59.195.240 ran on it. and that for some reason wasnt returning the options

that'll do it

Further to this, is there anyway to reset these boot options, as some macs its still not serving a URI some it is.