Re: netbooting imac, docs not ok..
segfault@chello.se wrote:
>>I did get dhcpd.conf (DHCP v3) configured (w/o patching, just
>>examining the patch
>>and using available docs and the site-option-space, similar to
>>somehting I needed for booting using Intel PXE)
> What patch? This is great, other people have had the same problem!
You were trying to boot a pmac?
Yes, this is for booting a pmac (i.e. Xserve rev. 2). The patch is
mentioned on:
http://www.soziologie.ch/users/steinlin/d-i/#netboot
http://staff.harrisonburg.k12.va.us/~rlineweaver/macnb/
It turns out that this patch is not needed for the dhcp3-server package
from testing. However, you do need to get the "Apple voodoo" in there in
some way. I suppose your way, i.e. using vendor-encapsulated-options,
will do the trick (I'll try that one on monday), but I achieved the same
effect with the following configuration bits:
option space mac;
option mac.version code 230 = string;
option mac.user-name code 232 = text;
option mac.password code 233 = text;
option mac.nb-img code 234 = string;
option mac.apps-img code 235 = string;
option mac.machine-name code 237 = text;
option mac.client-nb-img code 238 = string;
and
site-option-space "mac";
option mac.version 00:00:00:00;
option mac.user-name "netboot";
option mac.password "abcdefg";
option mac.nb-img d4:f0:10:7:2:24:2:6E:62:0:0:0:0:2:6:73:68:0:68:64:31;
option mac.apps-img d4:f0:10:7:2:24:2:6E:62:0:0:0:0:2:6:73:68:0:68:64:30;
option mac.machine-name "NB-BML-FictLib-1533-IP19.153";
option mac.client-nb-img
d4:f0:10:7:2:24:2:6E:62:0:0:0:0:2:6:43:6C:0:31:35:33;
if exists dhcp-parameter-request-list {
option dhcp-parameter-request-list = concat(option
dhcp-parameter-request-list, e6, e8, e9, ea, eb, ed, ee);
}
I tried it with just mac.version, but that did not work. I do assume
that we can get away with less options than above, but did not really
try to find a 'minimal' solution.
The information about the option parameters I retrieved from the patch.
The values I just copied from:
http://frank.gwc.org.uk/~ali/nb/
> Do you need the same options when PXE booting x86 as booting the Mac,
does the manual say anything about this? I've never PXE booted so I
don't know.
For PXE i needed a 'magic' value and the "if exist...concat" part (for
DHCPd v3). However, PXE is using different parameters. I just used the
same idea and transposed it onto the information I could find about the
requirements for netbooting Apple machines.
>Do you know the name of them, I'm refering to these:
>>option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01:82:
>> 04: #length
>> 69:6d:61:63:34
No clue there, but I will try to boot with just:
option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01:82:00;
(that is, a 0-length hostname).
>>Then it hit me that we do not have to wait for yaboot 2 to be
>>released,
> Thanks that patch will help alot, I will try it pronto. Hopefully it
will work out well, is this the same thing that Sven did?
Not sure if Sven actually did this, but Colin's response was along the
same line of thinking. He mentions that this was suggested to upstream,
but that upstream does not want to apply this patch. To me it looks like
upstream wants to concentrate on an improved version of yaboot
all-around and that this limitation (which is valid just for TFTP
booting) will be taken care of too.
I don't care much, since I just wanted to get on with trying d-i,
without having to burn CD's all the time, so I am happy with running my
own patched yaboot for first stage netbooting.
>>device=enet:<secondary ip address>
> What is this? <secondary ip address>? Is it the tftp server?
This is a secondary TFTP server. The yaboot executable is actually
retrieved from the primary (i386) server, which runs the (corporate)
DHCP server and provides TFPT for network installation purposes (FAI).
The kernel image is retrieved from a different server (oldworld
powermac) which I use for automatic nightly builds of d-i. This way I
automatically get the most recent kernel/initrd, w/o having the copy the
recent stuff to a different machine ;)
>>I also tried starting installation from a USB key, and although
>>it seems (after device investigations through OpenFirmware) that
>>it does start yaboot,
> Have you tried booting from firewire, I think I will try that later
on as well? I really thing the holy grail is to get the kernel
executable directly by OF i.e. including yaboot in some way, it make no
sense that I can't load the kernel from OF.
It is not OF that prevents you from loading the kernel, it is the
limited bufferspace yaboot v1 has available for the kernelimage when
downloading it from the TFPT server. Yaboot is perfectly capable of
loading bigger kernel images, as long as they are not served thru TFTP.
The suggested modification takes care of that restriction, or actually
puts the boundary a bit higher.
> /Ha en trevlig helg
I like måte,
Pepijn.
Reply to: