From peter.onion at btinternet.com Tue Sep 24 12:36:50 2013 From: peter.onion at btinternet.com (Peter Onion) Date: Tue, 24 Sep 2013 13:36:50 +0100 (BST) Subject: [K12OSN] Problems shutting down cllients Message-ID: <1380026210.85212.YahooMailNeo@web87803.mail.ir2.yahoo.com> I've build clients on a Centos 6.4 platform and after some "tweaks" they are working, but they won't shut down properly. This is cause by the "stop" sections in network,nfs and nstfs scritps in /etc/init.d all failing to identify that the root file system is mounted over the network. stopping eth0, nfs or trying to umnount everything? has predictable results in this case ! And the halt script has a go as well when it kills the unionfs user space process and then everything stops ! Also "out of the box" /etc/mtab ends up as an empty file which I don't think is correct. I've got the clients to shutdown or reboot properly by adding "exit 1" at the beginning? of the "stop" sections in the abve mentioned scripts. Is there a better/correct solution to this ? PeterO From radek at bursztynowski.waw.pl Wed Sep 25 21:45:10 2013 From: radek at bursztynowski.waw.pl (Radek Bursztynowski) Date: Wed, 25 Sep 2013 23:45:10 +0200 Subject: [K12OSN] Problems shutting down cllients In-Reply-To: <1380026210.85212.YahooMailNeo@web87803.mail.ir2.yahoo.com> References: <1380026210.85212.YahooMailNeo@web87803.mail.ir2.yahoo.com> Message-ID: <1380145510.11850.47.camel@alpaga.bursztynowski.waw.pl> Peter, I have the same troubles with CentOS 6.4 LTSP client and others. Fortunately I have an older client image based on Scientific Linux 6.1 which works fine. I tried to compare both of them. It is difficult for me, and I didn't solve troubles but let me share my notices. /etc/mtab file -------------- CentOS 6.4 client image has empty /etc/mtab file. It's true, but if the client is booted you can check this file on a client on local xterm - this file is not empty. Scientific Linux 6.1 client image has symbolic link between /proc/mounts and /etc/mtab. So, I suppose that LTSP 5.4 uses different mechanizm. closing the client ------------------ When I try to close CentOS 6.4 client image I can see that /tmp/sysroot and /tmp/unionfs/rofs directories are unmounted and closing system suspends on shutting down eth0. Trucking Scientific Linux 6.1 client image I made as chroot /sys -> /tmp/sysroot symbolic link. Now closing CentOS 6.4 client I don't see message about unmounted /tmp/sysroot directory. So, I suppose it helped. But still I can see message that /tmp/unionfs/rofs is unmounted and the client doesn't power off. --- Let me add two other points. The first one: If I try to add some package to CentOS 6.4 client image I use: # setarch i386 chroot /opt/ltsp/i386 # mount /proc But I can see "can't find /proc in /etc/fstab or /etc/mtab" message. I can install additional packages, but sometimes I can see message that /proc is empty. If I add to /etc/fstab "proc /proc proc defaults 0 0" line all work fine. What interesting, if /etc/fstab is empty and I check this file on booted client - fstab is not empty. So, I don't know - does it makes sens to add to /etc/fstab "proc /proc proc defaults 0 0" line, or not? I added. The second one: Still CentOS 6.4 client. When LDM is loaded and I try the first time to log in the greater reloads. Te second log in is effective. I expect that the first trial should be effective. There are the reasons that I use Scientific Linux 6.1 client image. Best regards, Radek ---- > I've build clients on a Centos 6.4 platform and after some "tweaks" they are working, but they won't shut down properly. > > This is cause by the "stop" sections in network,nfs and nstfs scritps in /etc/init.d all failing to identify that the root file system is mounted over the network. > stopping eth0, nfs or trying to umnount everything has predictable results in this case ! > > And the halt script has a go as well when it kills the unionfs user space process and then everything stops ! > > Also "out of the box" /etc/mtab ends up as an empty file which I don't think is correct. > > I've got the clients to shutdown or reboot properly by adding "exit 1" at the beginning of the "stop" sections in the abve mentioned scripts. > > Is there a better/correct solution to this ? > > PeterO > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see From radek at bursztynowski.waw.pl Mon Sep 30 12:51:53 2013 From: radek at bursztynowski.waw.pl (Radek Bursztynowski) Date: Mon, 30 Sep 2013 14:51:53 +0200 Subject: [K12OSN] epel-6-i386, epel-6-x86_64 images - strange behaviour Message-ID: <20762714.261380545513499.JavaMail.root@poczta.bursztynowski.waw.pl> Hello, I installed epel-6-i386 epel-6-x86_64 images and I can see strange behaviour both of them. Client boots, I can see LDM login screen, but after few seconds LDM switchs to the screens which we know from CentOS installation: the first - welcome, the next one - license agreement, the next one - users management and the last one - NTP. Theses screens appear every client starting. How to delete theses screens? Best regards, Radek -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.onion at btinternet.com Mon Sep 30 15:14:09 2013 From: peter.onion at btinternet.com (Peter Onion) Date: Mon, 30 Sep 2013 16:14:09 +0100 (BST) Subject: [K12OSN] epel-6-i386, epel-6-x86_64 images - strange behaviour In-Reply-To: <20762714.261380545513499.JavaMail.root@poczta.bursztynowski.waw.pl> References: <20762714.261380545513499.JavaMail.root@poczta.bursztynowski.waw.pl> Message-ID: <1380554049.1205.YahooMailNeo@web87806.mail.ir2.yahoo.com> Try "chkconfig firstboot off" in the chroot. PeterO >________________________________ > From: Radek Bursztynowski >To: k12osn at redhat.com >Sent: Monday, 30 September 2013, 13:51 >Subject: [K12OSN] epel-6-i386, epel-6-x86_64 images - strange behaviour > > > >Hello, > >I installed epel-6-i386 epel-6-x86_64 images and I can see strange behaviour both of them. Client boots, I can see LDM login screen, but after few seconds LDM switchs to the screens which we know from CentOS installation: the first - welcome, the next one - license agreement, the next one - users management and the last one - NTP. Theses screens appear every client starting. > >How to delete theses screens? > >Best regards, >Radek > >_______________________________________________ >K12OSN mailing list >K12OSN at redhat.com >https://www.redhat.com/mailman/listinfo/k12osn >For more info see > > From radek at bursztynowski.waw.pl Mon Sep 30 18:49:24 2013 From: radek at bursztynowski.waw.pl (Radek Bursztynowski) Date: Mon, 30 Sep 2013 20:49:24 +0200 Subject: [K12OSN] epel-6-i386, epel-6-x86_64 images - strange behaviour In-Reply-To: <1380554049.1205.YahooMailNeo@web87806.mail.ir2.yahoo.com> References: <20762714.261380545513499.JavaMail.root@poczta.bursztynowski.waw.pl> Message-ID: <1380566964.20185.155.camel@alpaga.bursztynowski.waw.pl> Peter, Thanks for help. It works. Best regards, Radek > > Try "chkconfig firstboot off" in the chroot. > > PeterO > > >________________________________ > > From: Radek Bursztynowski > >To: k12osn at redhat.com > >Sent: Monday, 30 September 2013, 13:51 > >Subject: [K12OSN] epel-6-i386, epel-6-x86_64 images - strange behaviour > > > > > > > >Hello, > > > >I installed epel-6-i386 epel-6-x86_64 images and I can see strange behaviour both of them. Client boots, I can see LDM login screen, but after few seconds LDM switchs to the screens which we know from CentOS installation: the first - welcome, the next one - license agreement, the next one - users management and the last one - NTP. Theses screens appear every client starting. > > > >How to delete theses screens? > > > >Best regards, > >Radek > > > >_______________________________________________ > >K12OSN mailing list > >K12OSN at redhat.com > >https://www.redhat.com/mailman/listinfo/k12osn > >For more info see > > > > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see