Home Forums OS X Server and Client Discussion Questions and Answers Issues with 2011 Macs and netboot.

This topic contains 22 replies, has 8 voices, and was last updated by  Bartron 6 years, 9 months ago.

Viewing 15 posts - 1 through 15 (of 23 total)
  • Author
    Posts
  • #381374

    Bartron
    Participant

    So, I’ve been having this issue with the post Lion 2011 macs (Mini and Air and with a firmware update, now the MacBook Pro)

    Damn things won’t netboot. πŸ™ and I’ve been pouring over all the netboot documentation I can find to try and sus out why these new Macs won’t netboot.

    Anyway, we are hosting netboot from a distributed network of ]linux DHCP servers (https://www.afp548.com/article.php?story=20061220102102611) and for the last 5 years or so this has worked perfectly fine (and still does for pre July 2001 machines). I did a packet trace on the new Macs and it appears that during the DHCP DISCOVER the macs no longer send the vendor class identifier. This causes the macs to be offered our standard linux PXE boot environment (that we use for the PC fleet) at which point the machine defaults to booting from the local disk.

    So far I’m at a loss as to what to do here. We are in the process of re-writing parts of the code so that we can specify “option root-path” on a per MAC address basis but I’m not confident it will solve the issue (not to mention we’ll need to enter in these options every time we add a new machine rather than rely on a class). I have a thread on apple discussions here https://discussions.apple.com/thread/3433338?tstart=60 but no replies so far.

    I have also tried setting up a netboot server using Lion server. The client machines will see it and I can select it from the startup disk pref pane but still won’t boot. From what I can tell it gets as far as DHCP SELECT (or something to that effect…don’t have it in front of me at the moment) and then boots from local disk.

    Any thoughts on the issue would be greatly appreciated. πŸ™‚

    #381388

    airlocksniffer
    Participant

    Same issue here. We are running Lion Server 10.7.2 on a mid-2010 Mac Mini. I can see the netboot images fine but the machine will quickly boot to the internal disk after the large flashing globe. This machine is a late 2011 iMac (iMac 12,1). Older C2D MacBook Pro will boot to the lion image created off of the iMac fine. Here is a portion of what I get when logging the verbose boot when trying to Netboot the iMac:

    MAC Framework successfully initialized
    using 10485 buffer headers and 4096 cluster IO buffer headers
    IOAPIC: Version 0x20 Vectors 64:87
    ACPI: System State [S0 S3 S4 S5] (S3)
    PFM64 0xf10000000, 0xf0000000
    [ PCI configuration begin ]
    console relocated to 0xf10010000
    PCI configuration changed (bridge=2 device=3 cardbus=0)
    [ PCI configuration end, bridges 5 devices 16 ]
    AppleIntelCPUPowerManagement: Turbo Ratios 0000
    AppleIntelCPUPowerManagement: (built 16:44:42 Jun 7 2011) initialization complete
    mbinit: done (64 MB memory set for mbuf pool)
    rooting via boot-uuid from /chosen: 6F2D14F2-6EAB-3DD9-9C59-20D4FFE0134C
    Waiting on IOProviderClassIOResourcesIOResourceMatchboot-uuid-media
    com.apple.AppleFSCompressionTypeZlib kmod start
    com.apple.AppleFSCompressionTypeZlib load succeeded
    AppleIntelCPUPowerManagementClient: ready
    Got boot device = IOService:/AppleACPIPlatformExpert/[email protected]/AppleACPIPCI/[email protected],2/AppleIntelPchSeriesAHCI/[email protected]/[email protected]/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/WDC WD2500AAKS-402AA0 Media/IOGUIDPartitionScheme/[email protected]
    BSD root: disk0s2, major 14, minor 2
    FireWire (OHCI) Lucent ID 5901 built-in now active, GUID c82a14fffef06e7e; max speed s800.
    Kernel is LP64
    USBMSC Identifier (non-unique): 000000009833 0x5ac 0x8403 0x9833
    systemShutdown false
    Waiting for DSMOS…
    Previous Shutdown Cause: 5
    DSMOS has arrived

    And the same log when successfully netbooting with a MacBook Pro:

    MAC Framework successfully initialized
    using 16384 buffer headers and 10240 cluster IO buffer headers
    IOAPIC: Version 0x20 Vectors 64:87
    ACPI: System State [S0 S3 S4 S5] (S3)
    PFM64 (36 cpu) 0xf10000000, 0xf0000000
    [ PCI configuration begin ]
    console relocated to 0xf10030000
    AppleIntelCPUPowerManagement: (built 21:08:10 Aug 9 2011) initialization complete
    PCI configuration changed (bridge=5 device=1 cardbus=0)
    [ PCI configuration end, bridges 7 devices 17 ]
    FireWire (OHCI) TI ID 8025 built-in now active, GUID 001ff3fffe7db2e0; max speed s800.
    mbinit: done [64 MB total pool size, (42/21) split]
    Pthread support ABORTS when sync kernel primitives misused
    com.apple.AppleFSCompressionTypeZlib kmod start
    com.apple.AppleFSCompressionTypeDataless kmod start
    com.apple.AppleFSCompressionTypeZlib load succeeded
    com.apple.AppleFSCompressionTypeDataless load succeeded
    AppleIntelCPUPowerManagementClient: ready
    BTCOEXIST off
    wl0: Broadcom BCM4328 802.11 Wireless Controller
    5.10.131.36
    [IOBluetoothHCIController::setConfigState] calling registerService
    From path: “IOProviderClassIONetworkInterfaceIOParentMatchIOPropertyMatchIOMACAddress001ff3cf2166“, Waiting on IOProviderClassIONetworkInterfaceIOParentMatchIOPropertyMatchIOMACAddressAB/zzyFm
    AppleYukon2: Marvell Yukon Gigabit Adapter 88E8055 Singleport Copper SA
    AppleYukon2: RxRingSize <= 1024, TxRingSize 256, RX_MAX_LE 1024, TX_MAX_LE 768, ST_MAX_LE 3328 yukon: Ethernet address xx:xx:xx:xx:xx:xx Got boot device = IOService:/AppleACPIPlatformExpert/PCI0/AppleACPIPCI/[email protected],5/IOPCI2PCIBridge/[email protected]/yukon2osx/yukon/IOEthernetInterface BSD root: en0 netboot: using network interface 'en0' netboot: retrieving IP information from DHCP response netboot: IP address xx.xxx.xxx.xxx netmask 255.255.255.0 router xx.xxx.xxx.xx netboot: adding default route xx.xxx.xx.xxx netboot: retrieving root path from BSDP response netboot: NFS Server xx.xxx.xxx.xx Mount /Library/NetBoot/NetBootSP0 Image /Lion Netboot.nbi/NetBoot.dmg Ethernet [AppleYukon2]: Link up on en0, 1-Gigabit, Full-duplex, No flow-control, Debug [796d,ac08,0de1,0200,c1e1,2800] root on xx.xxx.xx.xxx:/Library/NetBoot/NetBootSP0 netboot_setup: calling imageboot_mount_image IOHDIXController: NOTE: administrator is creating non-ejectable disk image KDIFileBackingStore::_handleStart: initial R/W vn_open returned 30 imageboot_mount_image: root device 0xe000006 Kernel is LP64 jnl: disk0s2: replay_journal: from: 15992320 to: 1140736 (joffset 0xe8e000) jnl: disk0s2: journal replay done. hfs: Removed 4 orphaned / unlinked files and 0 directories macx_swapon SUCCESS Previous Shutdown Cause: -128 Waiting for DSMOS... WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for MacBookPro4,1 with 8 p-states, using default stepper instead nstat_lookup_entry failed: 2 NVDANV50HAL loaded and registered. DSMOS has arrived We have some newer MBP's and Mac Mini's coming soon so I be able to see if this is machine specific or all late 2011 Macs. Hopefully not the latter.

    #381399

    hjuutilainen
    Participant

    Same issue here. The most recent macs just flash the globe and then go on to boot from local disk. Can’t think of any other quick solution than to create preconfigured DeployStudio USB sticks for our support staff…

    Did you create bugreports for this issue?

    #381400

    Bartron
    Participant

    Yup, I’m essentially going through the process of working out alternate solution.

    I don’t use deploy studio (I use a modified version of the recovery hd) but I’m in the process of sorting out a dozen or so USB sticks to distribute around to the various sites. As our image is hosted on a http server so I can use the default recovery hd to do a restore but this is hardly ideal (especially since I went to the effort of hacking the recovery hd, made it net bootable and installed some custom apps…works well on older hardware at least).

    I have reported the issue to apple via bug track but I’m sorely tempted to write an email and sent it to Tim Cook directly (and CC in half a dozen other SVP’s) as communicating with Apple via normal channels is about as productive to talking to a wall.

    #381424

    airlocksniffer
    Participant

    I just got off the phone with AppleCare and was told this is a known issue by senior engineers. We have this symptom with the mid-2011 Mac Mini, late 2011 MacBook Pro and late 2011 iMac, seems like any machine that ships with Lion. Hopefully a firmware update will fix this soon.

    #381448

    electrowave
    Participant

    I had this same issue, I was able to overcome it. I don’t remember how at the moment. I will look into it and post back if I come up with something.

    #381547

    bpcruz
    Participant

    Has anyone here heard any updates regarding this problem or found any solutions? I’m unable to NetBoot most recently purchased Macs (though I can load my NetBoot sets by holding down the Option key and selecting them via the Startup Manager).

    After much testing, I’ve isolated the issue to Macs that ship with Apple’s latest firmware updates. Among other things, these updates enable the Internet Recovery feature, which at least appears to be something akin to downloading a NetBoot set hosted by Apple (the environment, once downloaded, is essentially the same as the hard disk’s hidden Lion Recovery partition).

    Here are links to the updates that have caused problems for me:

    http://support.apple.com/kb/DL1470

    http://support.apple.com/kb/DL1450

    To verify that this firmware update caused the issue, I tried loading a DeployStudio NetBoot set stored on my laptop from an Early-2011 MacBook Pro using the previous firmware update (Boot ROM version MBP81.0047.B0E) by pressing the “N” key at startup. NetBoot was enabled on my laptop’s ethernet interface, to which the MacBook Pro was directly connected. The NetBoot set loaded just fine, and I was able to automatically log into the DeployStudio Runtime on the NetBoot set without issue.

    I then upgraded that same Early-2011 MacBook Pro to the latest firmware version (MBP81.0047.B24) and tried loading my laptop’s NetBoot set in the same manner (by pressing the “N” key). The globe flashed for a few seconds before failing and booting the system partition on MBP’s hard disk instead.

    Below is the a comparison of the bootstrap protocol data from the DCHP discover packet sent by the same machine before and after the update. First, the packet issued before the update:

    Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x00000555
    Seconds elapsed: 4
    [b] Bootp flags: 0x0000 (Unicast)
    0… …. …. …. = Broadcast flag: Unicast
    .000 0000 0000 0000 = Reserved flags: 0x0000[/b]
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Discover
    Option: (53) DHCP Message Type
    Length: 1
    Value: 01
    Option: (t=55,l=5) Parameter Request List
    Option: (55) Parameter Request List
    Length: 5
    Value: 0103432b3c
    1 = Subnet Mask
    3 = Router
    67 = Bootfile name
    43 = Vendor-Specific Information
    60 = Vendor class identifier
    Option: (t=57,l=2) Maximum DHCP Message Size = 1500
    Option: (57) Maximum DHCP Message Size
    Length: 2
    Value: 05dc
    Option: (t=61,l=7) Client identifier
    Option: (61) Client identifier
    Length: 7
    Value: 013c07541b1400
    Hardware type: Ethernet
    Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
    [b] Option: (t=60,l=28) Vendor class identifier = “AAPLBSDPC/i386/MacBookPro8,1”
    Option: (60) Vendor class identifier
    Length: 28
    Value: 4141504c42534450432f693338362f4d6163426f6f6b5072…[/b]
    Option: (t=43,l=4) Vendor-Specific Information
    Option: (43) Vendor-Specific Information
    Length: 4
    Value: 02020101
    End Option
    Padding

    Now, after the update:

    Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x18553443
    Seconds elapsed: 0
    [b] Bootp flags: 0x8000 (Broadcast)
    1… …. …. …. = Broadcast flag: Broadcast
    .000 0000 0000 0000 = Reserved flags: 0x0000[/b]
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Discover
    Option: (53) DHCP Message Type
    Length: 1
    Value: 01
    Option: (t=55,l=7) Parameter Request List
    Option: (55) Parameter Request List
    Length: 7
    Value: 0103060f432b3c
    1 = Subnet Mask
    3 = Router
    6 = Domain Name Server
    15 = Domain Name
    67 = Bootfile name
    43 = Vendor-Specific Information
    60 = Vendor class identifier
    Option: (t=61,l=33) Client identifier
    Option: (61) Client identifier
    Length: 33
    Value: 013c07541b14000000000000000000000000000000000000…
    Option: (t=57,l=2) Maximum DHCP Message Size = 1500
    Option: (57) Maximum DHCP Message Size
    Length: 2
    Value: 05dc
    End Option

    Besides the absence of the vendor class identifier noted above, another notable difference between this packet and the one I captured before the update is the bootp flag. The packet after the update has the broadcast flag set. The one before is unicast.

    The DHCP offer packet sent by my laptop also has the unicast bootp flag set in the exchange made before the firmware update:

    Ethernet II, Src: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8), Dst: Apple_1b:14:00 (3c:07:54:1b:14:00)
    Destination: Apple_1b:14:00 (3c:07:54:1b:14:00)
    Address: Apple_1b:14:00 (3c:07:54:1b:14:00)
    …. …0 …. …. …. …. = IG bit: Individual address (unicast)
    …. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
    Source: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
    Address: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
    …. …0 …. …. …. …. = IG bit: Individual address (unicast)
    …. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)

    ….

    Bootstrap Protocol
    Message type: Boot Reply (2)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x00000555
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    0… …. …. …. = Broadcast flag: Unicast
    .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 192.168.1.1 (192.168.1.1)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
    Client hardware address padding: 00000000000000000000
    Server host name: C701-ML-FSPT-20.local
    Boot file name: /private/tftpboot/NetBoot/NetBootSP0/10.7.2_Combo_Intel_NB111213.nbi/i386/booter
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Offer
    Option: (53) DHCP Message Type
    Length: 1
    Value: 02
    Option: (t=54,l=4) DHCP Server Identifier = 192.168.1.1
    Option: (54) DHCP Server Identifier
    Length: 4
    Value: c0a80101
    Option: (t=60,l=9) Vendor class identifier = “AAPLBSDPC”
    Option: (60) Vendor class identifier
    Length: 9
    Value: 4141504c4253445043
    Option: (t=17,l=90) Root Path = “nfs:192.168.1.1:/Library/NetBoot/NetBootSP0:10.7.2_Combo_Intel_NB111213.nbi/NetInstall.dmg”
    Option: (17) Root Path
    Length: 90
    Value: 6e66733a3139322e3136382e312e313a2f4c696272617279…
    Option: (t=43,l=18) Vendor-Specific Information
    Option: (43) Vendor-Specific Information
    Length: 18
    Value: 08048200006e820a4e6574426f6f74363330
    End Option

    Below are the same sections from the discover packet sent by laptop to the MBP after the update:

    Ethernet II, Src: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Address: Broadcast (ff:ff:ff:ff:ff:ff)
    …. …1 …. …. …. …. = IG bit: Group address (multicast/broadcast)
    …. ..1. …. …. …. …. = LG bit: Locally administered address (this is NOT the factory default)
    Source: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
    Address: Apple_b7:b7:f8 (64:b9:e8:b7:b7:f8)
    …. …0 …. …. …. …. = IG bit: Individual address (unicast)
    …. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)

    ….

    Bootstrap Protocol
    Message type: Boot Reply (2)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x18553443
    Seconds elapsed: 0
    Bootp flags: 0x8000 (Broadcast)
    1… …. …. …. = Broadcast flag: Broadcast
    .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 192.168.1.13 (192.168.1.13)
    Next server IP address: 192.168.1.1 (192.168.1.1)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: Apple_1b:14:00 (3c:07:54:1b:14:00)
    Client hardware address padding: 00000000000000000000
    Server host name: C701-ML-FSPT-20.local
    Boot file name not given
    Magic cookie: DHCP
    Option: (t=53,l=1) DHCP Message Type = DHCP Offer
    Option: (53) DHCP Message Type
    Length: 1
    Value: 02
    Option: (t=54,l=4) DHCP Server Identifier = 192.168.1.1
    Option: (54) DHCP Server Identifier
    Length: 4
    Value: c0a80101
    Option: (t=51,l=4) IP Address Lease Time = 59 minutes, 24 seconds
    Option: (51) IP Address Lease Time
    Length: 4
    Value: 00000dec
    Option: (t=1,l=4) Subnet Mask = 255.255.255.0
    Option: (1) Subnet Mask
    Length: 4
    Value: ffffff00
    Option: (t=3,l=4) Router = 192.168.1.1
    Option: (3) Router
    Length: 4
    Value: c0a80101
    Option: (t=67,l=19) Bootfile name = “pxelinux/pxelinux.0”
    Option: (67) Bootfile name
    Length: 19
    Value: 7078656c696e75782f7078656c696e75782e30
    End Option
    Padding

    The after the update, the boot file location is missing–further, the destination of this offer packet is a broadcast address, not the MBP address as before.

    My problem is, I have very little idea what any of this means. I’m not sure how to interpret this data, nor do I have any idea what I can do to have my clients properly load the NetBoot set when pressing the “N” key. And the issue doesn’t even stop there–after applying the firmware update, even though I can load NetBoot set through the Startup Manager, strange error messages and drops in connection occur once the DeployStudio NetBoot set loads.

    Thoughts?

    #381647

    Bartron
    Participant

    After trying and looking at several solutions from custom USB boot drives, mucking about with the DHCP server, arcane terminal commands etc I had the bright idea of just forgetting about the whole “master image” concept.

    So I did. B)

    And here’s what Ive come up with instead:

    I originally had a set of shell scripts that would set up a master image of OS X. Nothing flash, but they did the job of automating my workflow. I have now extended those and wrapped them up in a nice piece of applescript that launches them all. Now my roll-out process involves pulling the Mac out of the box, going through the new user wizard (what the user is called is irrelevant) browsing to a simple web site hosting a DMG with the applescript application within. After authenticating the scripts go ahead and one after the other configure everything that needs to be configured and install all the apps that need installing, downloading packages from our distributed file system without further interaction (the whole ‘back end’ runs on Windows Server 2008 R2). The last thing it does is call an application I wrote to automate joining to our domain. Once re-booted the system is a fully configured and AD authenticated OS X workstation. The whole process takes about 9 minutes 51 seconds (I timed it) not including unboxing and creating the first user account.

    To many, this may seem a lot like what Puppet can do and it’s actually something we’ll look at in the future. Overall though the scripts I wrote only took a couple of days of the framework. The rest is just modifying individual scripts as new settings/applications are needed.

    So that was after about 2 weeks tying everything together. The great thing is that apart from my printer config, everything works on OS X 10.8 without changing anything. This will be handy now that Apple are moving to a yearly release cycle.

    So in the end, Apple breaking our net boot environment has actually resulted in my organisation being in a much better position in regards to new versions of OS X as they come out. πŸ™‚

    #381650

    airlocksniffer
    Participant

    This seems okay for one or a few macs at a time but netboot is really necessary for rolling out lots of machines in a decent amount of time with as little hands on time as necessary.

    #381651

    Bartron
    Participant

    Depends on your setup I guess.

    I support roughly 500 macs (a growing number admittedly) that get upgraded on a rolling 3-4 year cycle so the number of macs that need to be imaged is only going to be a handful every week and even then, distributed across the country. Unless something drastic happens I’ll never be in the position where I have to multicast to 50 macs at once. if that were ever to happen on a regular basis I’d invest in the proper hardware to do it. For now though we have something like 6 or 7 distribution servers around the country and each one can easily do 5-10 macs simultaneously. More if you stagger them by a minute or two (the biggest download is office at 900ish Mb but at 30Mb per second it’s only 30 seconds to download. Most of the time spent is installing, not downloading)

    So, [b]for me[/b], getting net booting sorted on our mainly windows/Linux network is no longer an issue.

    #381656

    airlocksniffer
    Participant

    Just tested the newly released firmware updates for my late 2011 MacBook Pro and can report the issue is not solved. Still cannot netboot to either my own images or Apple Service Diagnostic images. Still quits prematurely and boots to the internal drive:

    Feb 23 15:37:58 minixserver bootpd[48442]: BSDP INFORM [en0] 1,xx:xx:xx:xx:xx:xx NetBoot035 arch=i386 sysid=MacBookPro8,2
    Feb 23 15:37:58 minixserver bootpd[48442]: NetBoot: [1,xx:xx:xx:xx:xx:xx] BSDP ACK[LIST] sent xx.xx.xxx.xx pktsize 311
    Feb 23 15:38:00 minixserver bootpd[48442]: BSDP INFORM [en0] 1,xx:xx:xx:xx:xx:xx NetBoot035 arch=i386 sysid=MacBookPro8,2
    Feb 23 15:38:00 minixserver bootpd[48442]: NetBoot: [1,xx:xx:xx:xx:xx:xx] BSDP ACK[LIST] sent xx.xx.xxx.xx pktsize 311

    I’ll keep digging but it’s not looking good….. πŸ™

    #381657

    Bartron
    Participant

    Ditto.

    on with my scripted install plan πŸ™‚

    #381779

    csumb
    Participant

    anyone have any luck with getting a response from Apple? or figuring out a way around this?

    #381780

    Bartron
    Participant

    Other than a request to “try with the new firmware”? No.

    I closed my bug ticket though so I don’t expect to hear anything further (still haven’t heard from them about an older bug I found using ARD to unlock your desktop without your password but that’s another story).

    Anyway, I implemented an in-house developed scripted install method around 3 weeks ago and so far everyone is impressed. Takes about 10 minutes and the end result is a fully managed, branded, configured, adjusted install with domain authentication and all corporate apps installed and for the most part it’s hands-off (there’s about a 1 minute QnA at the end to name the computer and join the right OU). Bash scripts do the heavy lifting with an AppleScriptObjC app to make it look pretty (progress bar and other feedback). Longest part is installing Office 2011 @ 7 minutes including downloading. Speaking of which, updating the SOE to include SP2 will be as simple as copying the combo installer to the download location and changing the Office install script to point to the updated version..done. Only one component to test and it’s available straight away.

    *Bonus Round*
    With a slight adjustment to the scripts I already support 10.8 DP2 and should be able to support it on day 1 when it’s released πŸ™‚

    #381781

    airlocksniffer
    Participant

    We actually got this to work. What we found is that the newer firmware cannot get an IP address while netbooting when the DHCP server is on another subnet and falls back to the internal drive. We fired up an old HP server for DHCP and put it, the lion server and client on the same subnet and it works fine. I need to test whether or not I can netboot when the client is on one subnet and the dhcp/lion server are on another.

Viewing 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic.

Comments are closed