Re: Floppy and tftp - was Woody Freeze
On Mon, Apr 09, 2001 at 11:14:55PM +0200, PiotR wrote:
> I'm not using grub. I load directly the kernels via tftp. Why use a boot manager in a diskless client :-?
> Is it required for booting via PXE?
Well there might be problems with just the intel card. Can you give boot
options to the kernel?
Regards,
// Ola
> > Client: (well the image in /images/foo)
> > =======
> > kernel (see above)
> > devfs (speeds things up)
> I have this in mind, but over a 100Mbs Network is difficult to notice any delay in accesing devices
Well I had quite a lot of problems with that. Especially with gpm.
/dev/gpmdata will be accessed everytime you move the mouse so when you
start programs like netscape or xemacs the mouse will slow down quite a lot
and with a lot of users... :)
> > ramfs (to localize the host, /tmp /var/tmp /var/run etc.)
> I do that via nfs. What are the benefits of doing this in ramfs?
How do you give them an own directory for each host (without fiddling
with different mount locations) ?
> > 8. Some directories are remounted to enable nfs v3. It seems
> > like (my kernel at least) does not support nfs v3 for the
> > root.
> > /usr
> > /lib
> > /opt
> > /etc
> > /root
> > /bin
> > /sbin
> > /home -> to some other place maybe.
> The problem i see here is that when you have a lot of clients, you want them all to mount the same /bin /sbin ... etcetera. A solution is to make the client mount some little root with /etc and /sbin directories (and probably others) that are *client specific*.
> for example in a path like /var/lib/diskless/192.168.0.1/ wich can be done by passing /var/lib/diskless/%s with dhcp to the kernel. And then remount all correctly. With all the client sharing common direcotories and maybe having others in ramfs ( what if you don't have a lot of ram in the clients? ) or via nfs separately.
Ohh... I think we maybe have a different way to look at it.
All my clients share the same image. That is why I have to "localize" them
with ramfs. :)
> > 9. Swapd is started to allow swapping over nfs. But there are
> > some problems with this and it probably have to do with
> > that the filesystem is not local. I do not know... Anyone
> > have experience with this?
> >
> > Well now the host behaves (almost) as any other debian host.
> >
> > To update the image I log in to the server and
> > chroot to the image root.
> >
> > ssh foo
> > sudo bash
> > chroot /images/bar
> >
> > and then
> > apt-get update
> > apt-get upgrade
> >
> > or similar.
> I have been thinking about this. And I believe that installing standard debian packages in the clients that way flustrates all that i have explained.
Sorry english is not my native language, what does flustrates mean?
> >
> > Atually I would like to boot another kernel at the server for
> > updating the image but I have not found any good solution. The
> > user-space-linux project looks nice but it uses a file as
> > the filesystem...
> I don't understand very well what you mean. What has to do the kernel image in the server with the one the clients load?
To simplify the upgrade process for the image that all clients use. Well
at least make it less error prone (when upgrading in chroot) and
faster then to do it over nfs.
Regards,
// Ola
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: