From: Bettina L. <bet...@bi...> - 2009-11-13 19:17:07
|
Hello LTSP'ers, I'm sysadmin at a university library, we're running several Linux Terminal Servers under Ubuntu/LTSP5 here, and everything's working great (in general) :) However, while trying to upgrade from Ubuntu jaunty to karmic I've run into a few problems, which I hope you can help me with, or at least give some pointers. The upgrade on the server itself went smoothly, the client boots from the (jaunty) chroot as before, ldm connects and starts the session without any problems. The same thin client however fails to boot from a newly built ubuntu karmic chroot. I'll provide some info on versions and hardware used: On the server: 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686 GNU/Linux ii ltsp-server 5.1.92-0ubuntu1~ppa1~karmi Basic LTSP server environment ii ltspfs 0.5.13-1 Fuse based remote filesystem for LTSP thin clients ii ldm-server 2:2.0.49-0ubuntu1~ppa1~kar LTSP display manager (server component) on the client: ii ltsp-client 5.1.92-0ubuntu1~ppa1~karmi LTSP client environment ii ltsp-client-core 5.1.92-0ubuntu1~ppa1~karmi LTSP client environment (core) ii ltspfsd 0.5.13-1 Fuse based remote filesystem daemon for LTSP thin clients ii ltspfsd-core 0.5.13-1 Fuse based remote filesystem daemon for LTSP thin clients ii ldm 2:2.0.49-0ubuntu1~ppa1~kar LTSP display manager ii ldm-ubuntu-theme 2:2.0.41 Ubuntu theme for the LTSP Display Manager the server used for testing is a VM, the thin client is a HP t5630w. While trying to get to the root of the problem I obv did extensive googling, that's why the packages from Stephane Graber's ppa are installed. The thin client boots via PXE from a central DHCP server, it seems to receive the correct boot options, loads the kernel from tftp and starts booting, until it fails with a kernel panic, right after udhcp announces it obtained a successful lease. The line I get is something like: /init: export line 15 <ip address of secondary dns server>: bad variable name So our central DHCP server seems to return some weird options which udhcp doesn't like - which obviously has never been a problem before, previous client builds used ipconfig, and that worked just fine here. So I added IPAPPEND 3 to pxelinux.cfg/default, as advised in several bug reports, and the thin client now boots up, though unfortunately it cannot set its own hostname... seems a minor, fixable glitch. The bigger problem is that the client only boots successfully when using nbd. We use nfs for stability reasons (nbd became extremely unstable once more than a few clients were connected - thin clients would freeze frequently, and could only be brought back to life by hard reset, unacceptable for a production environment. Back when we set up our first Ubuntu/LTSP5 server, 8.04 hardy, we reverted back to nfs, which solved the problem). When I switch the new chroot to nfs (still basically according to https://help.ubuntu.com/community/UbuntuLTSP/LTSPWithoutNFS ), the thin client does boot up but then apparently cannot mount the nfsroot, or so it seems - the last output message on the screen is from scripts/nfs-bottom saying /root/etc/hostname can't be written because it's a read-only filesystem, then there seems to be a call to mountall that ends in some sort of timeout. According to the messages on the screen from mtab, the root is already mounted on /, but it's still trying to mount / and /tmp and fails. When the client boots up with nbd, you do get similar "already mounted" messages, but there's no loop timeout, it goes on to start the ltsp-client setup, and in the end it brings up the login screen. I'm assuming the configuration of which directories need to be mounted writable is somehow messed up, and I would be very grateful if someone here could point me in the right direction, so I can get the nfsroot to work. Are there any additional changes necessary to the chroot's /etc/default/ltsp-client-setup? At the moment it has: # /etc/default/ltsp-client-setup # bind_mounts or unionfs (leave empty to autodetect) # NOTE: if you change this parameter, you must regenerate the initramfs # e.g., dpkg-reconfigure linux-image-<version> root_write_method="bind_mounts" # tmpfs directory mounted when using tmpfs/bind tmpfs_dir=/var/lib/ltsp-client-setup # size of tmpfs mount tmpfs_size=10m # tmpfs/bind directories that get mounted with only directory structure # preserved rw_dirs="/var/lib/xkb /var/log /var/spool /var/tmp /tmp /etc/console-setup /var/lib/pulse /var/lib/dbus /var/cache/hald" # tmpfs/bind directories that get mounted with directory structure and data # copied copy_dirs="/root /home /var/cache/ltsp-localapps /etc/rsyslog.d /etc/cups /media /etc/cron.d" # tmpfs/bind directories that are mounted and copied, but then unmounted after # ltsp-client-setup finishes temp_copy_dirs="" # tmpfs/bind files that mounted on top of other files bindfiles="/etc/network/interfaces /etc/hostname /etc/hosts /etc/syslog.conf /etc/fstab /etc/resolv.conf /etc/X11/xorg.conf /etc/passwd /etc/group /etc/localtime" Thanks a lot in advance for your input, your help would be very much appreciated --Bettina -- Universitätsbibliothek Augsburg Referat Datenverarbeitung 86135 Augsburg http://www.bibliothek.uni-augsburg.de |
From: Alkis G. <al...@gm...> - 2009-11-13 19:41:28
|
Στις 13-11-2009, ημέρα Παρ, και ώρα 19:52 +0100, ο/η Bettina Lapp έγραψε: > The line I get is something like: > /init: export line 15 <ip address of secondary dns server>: bad variable > name > > So our central DHCP server seems to return some weird options which > udhcp doesn't like - which obviously has never been a problem before, > previous client builds used ipconfig, and that worked just fine here. So > I added IPAPPEND 3 to pxelinux.cfg/default, as advised in several bug > reports, and the thin client now boots up, though unfortunately it > cannot set its own hostname... seems a minor, fixable glitch. > For a proper fix for this, see https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/474703 Get the new udhcpc file from there and replace the one shipped with Karmic. I don't know about your nfs problem, though. |
From: Bettina L. <bet...@bi...> - 2009-11-13 20:02:42
|
thank you very much :) this will fix the udhcp error for sure, our dhcp server does return several ntp server ips Alkis Georgopoulos schrieb: > For a proper fix for this, see > https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/474703 > Get the new udhcpc file from there and replace the one shipped with > Karmic. > > I don't know about your nfs problem, though. > |
From: Bettina L. <bet...@bi...> - 2009-11-19 15:34:50
|
update: fixed udhcp script, boot with nbd works, boot with NFS root does not. Client still stops with message: One or more of the mounts listed in /etc/fstab cannot yet be mounted: /: waiting for xxx.xxx.xxx.xxx:/opt/ltsp/i386 /tmp: waiting for (null) Press ESC to enter a recovery shell (xxx. etc is the correct server ip) Any ideas? We can't possibly be the only ones still using NFS? --Bettina -- Universitätsbibliothek Augsburg Referat Datenverarbeitung 86135 Augsburg http://www.bibliothek.uni-augsburg.de |
From: Alkis G. <al...@gm...> - 2009-11-19 16:08:16
|
If you remove udhcpc from the chroot, so that everything reverts to the old behavior (ipconfig etc), does it work? Στις 19-11-2009, ημέρα Πεμ, και ώρα 16:34 +0100, ο/η Bettina Lapp έγραψε: > update: fixed udhcp script, boot with nbd works, boot with NFS root does > not. Client still stops with message: > > One or more of the mounts listed in /etc/fstab cannot yet be mounted: > /: waiting for xxx.xxx.xxx.xxx:/opt/ltsp/i386 > /tmp: waiting for (null) > Press ESC to enter a recovery shell > > (xxx. etc is the correct server ip) > > Any ideas? We can't possibly be the only ones still using NFS? > > --Bettina > > |
From: Bettina L. <bet...@bi...> - 2009-11-19 18:18:14
|
hm, I've tried removing udhcp, or replacing it with the version from the jaunty chroot, the results don't change - booting with nbd works, booting with nfs root does not. I also rebuilt the karmic chroot from scratch, and then only replaced /opt/ltsp/i386/usr/share/initramfs-tools/scripts/init-premount/udhcp with the fixed version, same thing. Looks like it's not the dhcp script that's causing the problem, more like nfs is broken in a different spot - I just have no idea where Thanks a lot for your help, I really appreciate it. Alkis Georgopoulos schrieb: > If you remove udhcpc from the chroot, so that everything reverts to the > old behavior (ipconfig etc), does it work? > > > Στις 19-11-2009, ημέρα Πεμ, και ώρα 16:34 +0100, ο/η Bettina Lapp > έγραψε: >> update: fixed udhcp script, boot with nbd works, boot with NFS root does >> not. Client still stops with message: >> >> One or more of the mounts listed in /etc/fstab cannot yet be mounted: >> /: waiting for xxx.xxx.xxx.xxx:/opt/ltsp/i386 >> /tmp: waiting for (null) >> Press ESC to enter a recovery shell >> >> (xxx. etc is the correct server ip) >> >> Any ideas? We can't possibly be the only ones still using NFS? >> >> --Bettina -- Universitätsbibliothek Augsburg Referat Datenverarbeitung 86135 Augsburg http://www.bibliothek.uni-augsburg.de |
From: Alkis G. <al...@gm...> - 2009-11-19 18:38:33
|
After removing udhcpc, don't forget to also update the kernel, i.e. `update-initramfs -u` in the chroot, and `ltsp-update-kernels` outside of the chroot. `ltsp-update-image` is NOT needed. If you want, you may visit #ltsp at irc.freenode.net for live help on the problem... Στις 19-11-2009, ημέρα Πεμ, και ώρα 19:17 +0100, ο/η Bettina Lapp έγραψε: > hm, I've tried removing udhcp, or replacing it with the version from the > jaunty chroot, the results don't change - booting with nbd works, > booting with nfs root does not. > > I also rebuilt the karmic chroot from scratch, and then only replaced > /opt/ltsp/i386/usr/share/initramfs-tools/scripts/init-premount/udhcp > with the fixed version, same thing. > > Looks like it's not the dhcp script that's causing the problem, more > like nfs is broken in a different spot - I just have no idea where > > Thanks a lot for your help, I really appreciate it. |
From: Bettina L. <bet...@bi...> - 2009-11-19 20:21:04
|
Gadi, Alkis, thanks for your replies > I trust you also did: > sudo chroot /opt/ltsp/i386 > update-initramfs -u > /usr/share/ltsp/update-kernels > exit > sudo ltsp-update-kernels > every time you make a change that you want to be propagated to the initramfs served to the clients. Yes, I did, I'm aware that otherwise changes to the initramfs scripts wouldnt have any effect :) forgot about the irc channel, I'll try and visit tomorrow -Bettina On Thu, 19 Nov 2009 20:38:17 +0200, Alkis Georgopoulos <al...@gm...> wrote: > After removing udhcpc, don't forget to also update the kernel, i.e. > > `update-initramfs -u` in the chroot, and > `ltsp-update-kernels` outside of the chroot. > `ltsp-update-image` is NOT needed. > > If you want, you may visit #ltsp at irc.freenode.net for live help on > the problem... > |
From: Gideon R. <lt...@sy...> - 2009-11-19 18:35:47
|
I trust you also did: sudo chroot /opt/ltsp/i386 update-initramfs -u /usr/share/ltsp/update-kernels exit sudo ltsp-update-kernels every time you make a change that you want to be propagated to the initramfs served to the clients. -Gadi On Thu, 2009-11-19 at 19:17 +0100, Bettina Lapp wrote: > hm, I've tried removing udhcp, or replacing it with the version from the > jaunty chroot, the results don't change - booting with nbd works, > booting with nfs root does not. > > I also rebuilt the karmic chroot from scratch, and then only replaced > /opt/ltsp/i386/usr/share/initramfs-tools/scripts/init-premount/udhcp > with the fixed version, same thing. > > Looks like it's not the dhcp script that's causing the problem, more > like nfs is broken in a different spot - I just have no idea where > > Thanks a lot for your help, I really appreciate it. > > > Alkis Georgopoulos schrieb: > > If you remove udhcpc from the chroot, so that everything reverts to the > > old behavior (ipconfig etc), does it work? > > > > > > Στις 19-11-2009, ημέρα Πεμ, και ώρα 16:34 +0100, ο/η Bettina Lapp > > έγραψε: > >> update: fixed udhcp script, boot with nbd works, boot with NFS root does > >> not. Client still stops with message: > >> > >> One or more of the mounts listed in /etc/fstab cannot yet be mounted: > >> /: waiting for xxx.xxx.xxx.xxx:/opt/ltsp/i386 > >> /tmp: waiting for (null) > >> Press ESC to enter a recovery shell > >> > >> (xxx. etc is the correct server ip) > >> > >> Any ideas? We can't possibly be the only ones still using NFS? > >> > >> --Bettina > -- -------------------------------------------------------- Gideon Romm | Proud LTSP Developer lt...@sy... Pay It Forward! Intel Atom 1.6GHz, 512MB RAM + Symbiont Boot Stick = $275 10% of order goes to school or open source project of your choice! Buy yourself a lab or office and use your donation to set up a school, pay for a desperately needed feature added to a software package, or sponsor part of LTSP's annual developer's conference LTSP-by-the-sea! Check out: http://www.symbio-technologies.com/payitforward |