[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#140579: TFTP Testing



"Philip Dodd" <philip.dodd@free.fr> writes:

> > > I can make it boot by taking the bf2.4 root.bin and using mknbi-linux
> >
> > What is mknbi-linux?  Will that work with most/all i386 hardware that
> > is even capable of netbooting?
> 
> It is a debian package that creates Net Boot Images, hence the name.  I
> created an image using it to include the boot.bin

root.bin I think you mean?

> as a ram disk and to append root=/dev/ram as boot parameter to the
> tftpboot.img 

Is this something you had to do by hand by tftpboot.img?  I thought
kernel boot parameters were not actually contained in tftpboot.img
(how could they be?)

I'm still confused, probably because I've never done it.

It seems to me that perhaps we should be doing this preparation on the
tftpboot.img file as part of the build process, e.g., add the steps
you are doing to tftpboot.sh.

OTOH, there is more ways to net boot an i386 than etherboot, right?
There's etherboot and there's netboot.

> (also directly to a home-made kernel bzImage with the root.bin)
> Etherboot picks all this up directly and fetches the image and boots
> straight into the install.

Were you required to use a home-made kernel?  I recollect that
etherboot requires a specific driver-specific ROM loader thing, right?
Or wasn't it packet drivers?

Is it the case that we simply can't provide a "ready to use" netboot
image for i386 due to the fact that almost every different ethernet
card requires a different packet driver/ROM loader?

> > > i am trying to install onto an nfs / partition and this bit gives me
> > > lots of trouble.  it complains about locking when trying to chroot
> > > /target dpkg --force-depends --install etc.  i can get no further.  I
> > > assume this is a seperate issue, but think that it needs solving for
> > > tftp to be any use, since those using it may use it because the
> > > machine is diskless.
> >
> > Well, it's purely an NFS and kernel issue at this point.  Perhaps you
> > don't have lockd running on the server?  Have you consulted the docs,
> > Debian and otherwise?  NetBSD has some pretty good instructions on
> > this sort of stuff...
> 
> Yes, i guess so.  However, the machine in question runs as an NFS server for
> all the machines on my local net, including linux and solaris 2.8 machines,
> and _none_ of them complain about locking.  lockd is of course running on
> the server - i did some basic checks, but will of course thoroughly inspect
> my nfs setup before assuming this part is a bug.

Have you checked that the kernel-image you are using has the right
options enabled for NFS root?  Might be a bug in kernel-image-* pkg.

> >
> > > i am also unable to ascertain the correct method of installing the
> > > kernel and driver modules (the only success i have had is installing
> > > the bf2.4 ones from /dev/fd0).
> >
> > Why not from the network?
> 
> good question. :)  would it change anything though?

Nope, not effectively.

> Ok, this much is true. However, my personal sticking points aside, if there
> is an 'official' way of doing things, why then is the install guide so thin
> on the ground on these matters? 

Because it was added recently, and no one has documented it nor
provided us with patches.

> If a bug should be filed against the
> install guide to improve it, i would gladly, because it is as near as
> useless for booting tftp and nfs root machines (on intel at least). 

I think this bug we are using here can represent that... we don't need
a new one.


-- 
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>



-- 
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: