Jump to content


  • Content Count

  • Joined

  • Last visited

About kby

  • Rank
    InsanelyMac Protégé

Profile Information

  • Gender
  • Location
  1. I originally posted on this topic in a reply in the Netbook section here, but it is really more general than that so I thought I would post follow-ups here. I will not reproduce all of the information that is there, so I would suggest looking at that post for the basics. This concerns booting a given machine completely over the network: what Apple normally calls diskless netboot (there is also netboot where the operating system is loaded from th network, but a local disk is used for some storage related to making the network image appear writable). I will try to distinguish between the two where it is significant. An example of such a machine is illustrated in this screen shot (which is a better one than in the original post; the original post was not "diskless netboot" as described above as at that time I had not figured out to make it work at all): Note that the boot volume shows as a network disk image (at least that is Apple's icon for such) and that the disk in this machine actually only shows Windows partitions (it is a Dell D630 running Windows 10 normally, but the partitions are mounted via NTFS-3G). I described the bare essential details in the earlier post so will not repeat them here unless needed to provide context to answer questions. Since that post I have learned some things and made some progress. The most important was enabling diskless netboot, albeit in a very limited and restricted sense.The limitation is at the moment I can only handle one diskless machine of this type booted at a time from the server. I do know what it would take to make it work more generally, but have not yet found code sufficiently close to what I need to hack it up fairly easily. In the meantime I've implemented it by making some changes to the /etc/rc.netboot script in the disk image (this will be required in either case), although it is modified in sucha way that if the information is available through normal channels, it will work in that way preferentially, but, if not, it will fall back to this single-client only mode. Note that I have not implemented a way to actually police this so it is most likely "gentlemen's timesharing" as we used to say, although it may actually fail for the second person as he tries to gain write access to the shadow file that is already in use. I should mention my motivation for this project. I do some small amount of consulting for a shop that is mostly a mac shop but is gaining some Windoze clients, mostly machines from fairly naive users that are very poor at maintenance. Sometimes I need to access files but either can't boot windows on the machine, or need to do things with respect to moving files around that windows doesn't want to allow even an administrator to do, so I like to be able to access the disk with some system other than windows. Since it's a customer's machine, I can't really install OS X, which I tend to prefer as I am more familiar with it on a day-to-day basis and am less likely to mess something up. Otherwise, what I want to do could mostly be accomplished with Ubuntu Live (which I also have netboot set up for on my server, which is a quad G5 (powerpc) mac running 10.5.8 server. Note that the fact that I am using a real mac for the server is largely a convenience for me; it is not required that the server be running OS X or anything in particular as long as the correct services needed are able to be provided by the system. Now it would also be possible to (maybe) boot off an external disk, but that is often more problematic than one would like (keeping track of which disks can boot which machines, finding the disks, etc. I woudl much prefer to have nicely named server repositories to handle the varying hardware. This varied hardware, sadly is what made me realize that my ideal will be pretty impossible to attain. However, I do have a system whcih can be used in at least some cases (with a minor tweak during boot time, I can boot the Dell or a Lenovo G550 to varying degress of success). Note that I don't necessarily expect all the fine details to work, either, although that is not necessarily a problem with only netboots, again, due to the varied hardware. So, what doesn't work for me now (at least in Snow Leopard, which is what I've been using for various reasons). Main thing right now is I can't upgrade netboot to 10.6.8. I have been able to upgrade the Lenovo on disk to 10.6.8, so it does run on that machine, but somehow the BCM7522 driver (the Adlan driver) doesn't seem to handle the network traffic as well and drops off-line (never to reterun) during the netboot, which is fatal, of 10.6.8. I've also try the BCDM5906 driver on the machine that has that chip, but it has the same issues. Of course, the netboot only works at best as well as a disk-based system would. In this case that means the screen doesn't work on the dell (but VNC to the machine does), and the native resolution of the G550 doesn't work. I'm not sure whyt 10.6.8 is so much worse on this than 10.6.3 which at least in this particular aspect, seems to work fine.
  2. kby

    Info about Netboot

    I have managed to pxeboot snow leopard, for the most part. I would say it's 80-90% of a real netboot right now; enough to be usable for my purposes, but I will hopefuly do some work to make it work more like real netboot.: (oops, apologies for the inversion of the picture. That's the way it got into the phone, but I thought it was rotated in the file I uploaded as it looks that way in preview. Apparently not…will see if I can fix or if some admin can fix it, but until then…) (please enjoy but do not take seriously the weird hardware specs—the netboot image is of a vanilla snow leopard installation so they are not accurate (duh!). What does work: 1. You can boot into an installation DVD image from the netboot server. I haven't tried to do a full installation, but I would expect it to mostly work, with the caveats listed below. 2. No disk involved in the early boot process. This particular screen is not, however, a completely "diskless" boot. In order to do that I have to make some modifications to the root image to get around the fact that I am not using bspd to set up the netboot. This is an issue which is not strictly related to hackintoshes—it will occur if you netboot genuine macs, but dpn't use Apple's bsdp protocol. The issue is that without bspd the initialzation scripts have no way of knowing where to union/overlay mount the shadow file on tope of the read-only netboot image, so they end up using local disk for that. NetInstall works differently and does not need a shadow file. What doesn't work and what are the problems: 1. True diskless, as detailed above. 2. System isn't the most stable; shutdown/reboot usually hangs at the end most times right now, most likely due to the vanilla-ness of the image (but booting and image of the Hackintosh modified image doesn't work yet either; it hangs at boot time and/or gets confused at which network interface it shoudl use and/or how to use it. 3. Shutdown/reboot usually hangs at the very end. I noticed that most working hackintoshes have some time of fix applied to deal with this but since I am booting the vanilla kernel, I haven't figured out how to transfer that yet. I am using a real Apple server (ppc, actually; 10.5.8) to serve the image, but that is not requirement. It is the same netboot server I use for real mac netboots, but that's just a convenience for me since I do both. My main interest in this project is to have a way to take a random customer machine and have acceess to OS X on its disk without removing it from the machine. I have not realized that under the appropriate conditions it could "work", sadly, the holy grail of throwing a random machine at the server to netboot is probably not pratical, mostly due to the varied hardware (especially network cards). Finding the right combination of drivers is tricky and not always possible. The boot sequence is PXE ROM loads lpxelinux (from the syslinux 6.03 distribution). This has a number of options, but one is to chainload pxegrub2. One should be able to set up the DHCP server to simple poiunt to pxegrub; I have other things that use pxelinux, so this is a way to not have to redo all of that right now. grub2 has the appropriate commands to load mach_kernel (aka mach.macosx) the mach.macosx.mkext (kernelcache). One tricky point here is what goes into the kernel cache file. I can provide more specifics, but essentially if there are too many things, there con occasionally be confusions. For example two machines I've used have a built-in NIC with a PXE ROM but they also have Broadcom wireless cars for which with the right coercing via an extension, can work with the Apple driver. Problem is, the machine always wants to boot off of en0 which is the only way that can actually work with the hardwre I've used—the wireless cards are usually stymied on terms of getting credentials to attach to the network, but, also, they don't have PXE roms, so can't be used eariler. Unfortunately, if they work with the Apple driver, they end up taking the en0 device name and netboot can't figure out how to mount /read the disk image (over NFS or HTTP) through en0. Trying to set rd=en1 or something like that through the kernel parameters doesn't appear to work (but it must be set to something like enet, en0, or en1; eliminating tries to do a local disk boot). FWIW this (or some close variant) is the grub2 entry I am using to boot the kernel: menuentry "Hackintosh 10.6 netboot" { set root=(pxe) insmod video insmod vbe gfxmod="1366x768x32" xnu_kernel (pxe)/NetBoot/NetBootSP0/Boot/Hackintosh_10.6/i386/mach.macosx rd=enet rp=nfs: xnu_mkext (pxe)/NetBoot/NetBootSP0/Boot/Hackintosh_10.6/i386/mach.macosx.mkext } (it's actually a dual-architecture kernel and mach.macosx.mkext so it does boot in 64-bit mode on this machine). No the gfxmode doesn't properlywork on this machine, but it seems to essentially be a noop so I have left it in for documentation purposes as for this particular test machine, that's the desired native resolution. The kernel and mkext locations are slightly modified from standard Apple server, but that is because I am using some symbolic links to candy-coat the paths sufficiently so I don't have to figure out how/if special quoting is needed to get some characters (e.g. <space>) through. The "normal" path for the disk image is "/Library/NetBoot/NetBootSP0/NetBoot of Snow Leopard.nbi/NetBoot.dmg" for reference to those familiar with how the Apple NetBoot server actually sets things up. I have done some modifications to the paths that the Apple server uses by default to get around some aspects of the way syslinux & grub modules seem to want to find things, and also to save disk space (so I can use links to share files rather than duplicate copies, which would additionally be harder to maintain and also keep the Apple ServerAdmin utilities copacetic. -kby