Bug#140579: TFTP Testing
> CC'ing the bug in question is the best way in all cases. This lets us
> follow the progress of the issue.
Ok i've taken note :)
>
> > The tftpboot.img alone indeed seems not to include a root.bin image.
>
> No it does not. That is by design, so I'm told. Apparently there is
> no standard way to include the root image with the TFTP kernel image.
> Thus the root filesystem must be loaded and mounted by other means
> (root=/dev/nfs kernel boot argument, apparently).
>
> > 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 as a ram disk and to
append root=/dev/ram as boot parameter to the tftpboot.img (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.
> >
> > 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.
>
> > 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?
>
> > The server (dhcp, nfs-kernel) is a linux debian woody. i could test
> > this with solaris servers if it helps to take server side problems out
> > of the picutre, but i don't think the problem is here.
> >
> > The install guide is very unclear on both tftp booting and nfs root
> > installs.
> >
> > I am willing to help if i can, and to test various configs if
> > necessary, the client on which i'm installing is a test machine so
> > it's no prob. I would also like to improve the install guide sections
> > once we've tracked down an appropriate method for tftp installs.
>
> Well, the fact is, you can't get it working, so I doubt you can help
> us much.
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? 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). the
simple question of getting etherboot, for example - there are others, to
boot tftpboot.img is not even mentioned, and that does seem to be one of the
main uses of tftp booting on intel, though perhaps I am mistaken.
Cheers,
Philip DODD
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: