Re: lpadmin/cups problem
On Wed, 31 Jan 2007, Lou Ruppert wrote: Per Foreby a écrit : I'm trying to setup printers during the installation, using $ROOTCMD lpadmin What I do now is to create /INSTALL.NEW at the end of the installation, and make that file trigger fai softupdate at the first boot, but it would of course be nice to avoid that extra stage. I found the same problem. What I've been doing is creating an init script to run on the first reboot of the machine, which then finishes the job when CUPS is running. The script then deletes itself when it's finished. Here's an example install script from FAI: #!/bin/sh # # We copy an init script to do the dirty work on reboot, so that we have CUPS # running properly, and so on. It's a dirty hack, but it works. fcopy /etc/rc2.d/S20installprinter And the script in question: #!/bin/sh /usr/sbin/lpadmin -E -plab -DHP Laser Printer -vparallel:/dev/lp0 -P/usr/share/ppd/hpijs/HP/HP-LaserJet_4V-hpijs.ppd /usr/bin/cupsenable lab /usr/sbin/lpadmin -d lab rm /etc/rc2.d/S20installprinter Same strategy works for other things which require a running system to pull off. Thanks, as you say, on less reboot. I try to use the same config for install and softupdate, but you solutions could easily be tweaked into running the script immediately on a softupdate: fcopy /etc/rc2.d/S20installprinter if [ $FAI_ACTION == softupdate ]; then /etc/rc2.d/S20installprinter fi To those who suggested fcopy/ftar: I try to avoid that approach for configuration files. The reason is maintainability. With fcopy most of the files need to be replaced when upgrading to a new debian version. However, using cfengine, debconf and configuration utilies like lpadmin, most of the local changes survive the upgrade. And I do of course have the same possibility to take advantage of the class hieracy in shell scripts (ifclass CLASS) and cfengine scripts (CLASS::). Cups is an excellent example: The upgrade from sarge to etch (cups 1.1.23 to 1.2.7) is a major cups upgrade, and the config files are probably not portable, but the lpadmin approach is. /Per
aptitude-r and softupdate
I'm having problems with softupdate removing packages that were installed as recommends with aptitude-r. Example configuration aptitude-r ntp This installs ntp-server and ntp-simple. (ntp-server is recommended by ntp, and depends on ntp-simple). So far so good. However, on the first softupdate ntp-server and ntp-simple (and some 50 other packages) are removed. From the software log: The following packages are unused and will be REMOVED: akode autogen ca-certificates dvd+rw-tools eject enscript esound-clients exuberant-ctags freepats fvwm-icons gdeb gimp-svg gnuhtml2latex jackd kdeprint libatk1.0-data libcompress-zlib-perl libfont-afm-perl libft-perl libgail-gnome-module libglib2.0-data libglib2.0-doc libhtml-format-perl libltdl3 libltdl3-dev libmail-sendmail-perl libmailtools-perl libmysqlclient14-dev libopts9 libopts9-dev libpango1.0-doc libpaper-utils libqt3-compat-headers librsvg2-bin libsamplerate0 libsasl2-modules libterm-size-perl libtimedate-perl libttf2 linuxdoc-tools lrzsz ntp-server ntp-simple orbit2 perl-suid perl-tk poster psfontmgr python2.3-iconvcodec sgmltools-lite texi2html wv x-ttcidfont-conf Shouldn't aptitude be supposed to keep recommended packages until the package recommending them is gone? In the ntp example, the first package is still there and should prevent the other packages from being removed: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii ntp4.2.0a+stable- Network Time Protocol: network utilities rc ntp-server 4.2.0a+stable- Network Time Protocol: common server tools rc ntp-simple 4.2.0a+stable- Network Time Protocol: daemon for simple sys Another thing: If I run aptitude manually on a newly installed computer (before the first softupdate), it reports no errors, and doesn't attempt to remove anything. The workaround (which I suppose must work) is to explicitly list all of these packages, but it shouldn't be necessary. So what am I doing wrong? Or is this maybe a bug in fai? The versions I'm using are: server (sarge): fai-server 2.10.1 client (sarge): fai-client 2.10.5 /Per
Re: forcedeth
On Sat, 8 Jul 2006, Holger Levsen wrote: Hi, On Friday 30 June 2006 08:22, Michael Tautschnig wrote: Trying to install some new AMD64 computers with NForce chipset, I noticed that the forcedeth driver is missing in the 2.6.16 installation kernel. Of course, I solved the problem by compiling my own kernel with CONFIG_FORCEDETH=y. Please file a bug with severity wishlist. It's included in fai-kernels since the previous version of fai-kernels, 1.10.2, which was uploaded to unstable on January 20th and migrated to testing on the 4th of february. regards, Holger I'm referring to the version in the fai repository: $ dpkg -s fai-kernels|grep -i version Version: 1.10.3 $ zgrep FORCEDETH /usr/share/doc/fai-kernels/config-2.6.16.gz # CONFIG_FORCEDETH is not set /Per
Re: forcedeth
On Sat, 8 Jul 2006, Holger Levsen wrote: On Saturday 08 July 2006 15:22, Per Foreby wrote: Trying to install some new AMD64 computers with NForce chipset, I I'm referring to the version in the fai repository: besides that I don't have control over what ends up there... $ dpkg -s fai-kernels|grep -i version Version: 1.10.3 $ zgrep FORCEDETH /usr/share/doc/fai-kernels/config-2.6.16.gz # CONFIG_FORCEDETH is not set I now guess that you're working with debian for i386 and not amd64, right? Correct, I don't trust the amd64 version in a production environment until December 4 (or whenever etch releases), and besides that, we still have some intel boxes, so it's easier to use the same port everywhere. Because in the amd64 config it is included, in the i386 config it's not. Will fix this in 1.11... I believe this will be appreciated, I'm probably not the only one running i386 on Athlon64 boxes. P.S.: this will be really solved when we use standard debian kernels, which is my aim to achieve at the upcoming fai developer workshop... Sounds interesting, but is it really possible when debian compiles almost everything av modules, and relies on initrd for booting? But if CONFIG_ROOT_NFS is statically linked, maybe you could use an initrd image from an nfs share? But using the stock sarge kernel wouldn't solve my problem, so one should of course be able to use any debian kernel package. (Our new computers use the NForce 430 chipset, and it't not supported until 2.6.15, so I install 2.6.16 kernel from backports.) Using standard kernels would also make it impossible to create a boot floppy, but it's probably only a matter of time before that would be impossible even with a custom kernel. Anyway, I wouldn't miss the boot floppy since booting from CD is much faster. And most network cards can PXE boot these days - I only use a boot CD on a few old boxes with old network cards which don't honour next-server (we don't have the dhcp server on the fai server). /Per
forcedeth
Trying to install some new AMD64 computers with NForce chipset, I noticed that the forcedeth driver is missing in the 2.6.16 installation kernel. Of course, I solved the problem by compiling my own kernel with CONFIG_FORCEDETH=y. Since most newer (939/AM2) AMD motherboards use nforce, I suggest that forcedeth is added to the standard kernel. This addition creates a kernel 1314196 bytes large, which is 46084 bytes more than the default 2.6.16 kernel. In other words: there is still plenty of space left when creating a fai floppy. /Per
How to move from woody to sarge
I'm currently using fai in an all woody environment (woody installation server and woody clients). The software versions are fai 2.5.4 and fai-kernels 1.7.1. I want to start som experiments with sarge clients, but I still want to be able to install woody clients. Is this possible, and in that case, what should I upgrade (server, fai-version) and in what order? -- Per Foreby http://www.efd.lth.se/perf/
Disable ctrl-alt-b?
This is not really an fai issue, but since it is closely associated with fai, I thought I'd ask here. In the fai guide, the technique of always booting from the network is described. It sounds very nice to be able to use fai-chboot to select normal boot or install, without even having to touch the client. But in my environment (students!), you always have to think about security in the sence of protecting the computers from our own users. Even if I enable all possible security in the BIOS setup, it is still possible to press ctrl-alt-b to change the MBA settings. I'm not sure if this is a security problem, but at least the students will be able to change the settings and leave the computer unbootable from the network. Does anyone know if it is possible to prevent the users from changing the MBA settings? If not, my backup solution is to only allow booting from C:, and password protect all lilo/grub alternativs but local boot. This requires physical access to the computers if I want to reinstall, but is still much better than the bios solution (halt, enter bios, change boot order, install from network, halt, enter bios, change boot order again, boot from disk). -- Per Foreby http://www.efd.lth.se/perf/
Re: Disable ctrl-alt-b?
On Fri, 13 Aug 2004, Steffen Grunewald wrote: On Fri, Aug 13, 2004 at 03:07:15PM +0200, Per Foreby wrote: Even if I enable all possible security in the BIOS setup, it is still possible to press ctrl-alt-b to change the MBA settings. I'm not sure if this is a security problem, but at least the students will be able to change the settings and leave the computer unbootable from the network. Does anyone know if it is possible to prevent the users from changing the MBA settings? Not really: there's some security by obscurity - you can hide the message... How can I do that? (My hardware is asus p4p800 with 3c940 (sk98) network, with bios integrated MBA.) If not, my backup solution is to only allow booting from C:, and password protect all lilo/grub alternativs but local boot. This requires physical access to the computers if I want to reinstall, but is still much better than the bios solution (halt, enter bios, change boot order, install from network, halt, enter bios, change boot order again, boot from disk). What's the exact problem? In general you'd be happy to boot locally, with or without a PXE response. If you want to do an install and don't succeed, then something is wrong with the PXE (MBA) settings... Next week, we will replace 24 suns in our computer labs with linux computers. Since this is our first try at linux in a student environment, i suspect there will be quite a few reinstallations before we get everything right. Thats why it would be nice if I could say fai_chboot -IBv, reboot the client and be assured that they always will start an installation. Of course, I could check the output from faimond and se if any computers didn't install correctly, so this is not a big problem. Our computer engineering students will try everything that is not disabled, so eventually some computer will have their settings altered. This is a small problem with 24 computers, but our plans are to replace all our suns (about 150), and in a more distant future maybe replace up to 600 windows computers, so the problem will grow. Still, I agree that this is kind of a luxury problem. I guess I'm a bit spoiled from running suns where OS and hardware are made for each other. But sparcstations with half the speed for twice the money are no longer an option for us. -- Per Foreby http://www.efd.lth.se/perf/
Re: Disable ctrl-alt-b?
On Fri, 13 Aug 2004, Per Foreby wrote: On Fri, 13 Aug 2004, Steffen Grunewald wrote: Does anyone know if it is possible to prevent the users from changing the MBA settings? Not really: there's some security by obscurity - you can hide the message... How can I do that? (My hardware is asus p4p800 with 3c940 (sk98) network, with bios integrated MBA.) Forget this question, I found the setting in the MBA setup. -- Per Foreby http://www.efd.lth.se/perf/
Re: woody problems
On Wed, 11 Aug 2004, Thomas Lange wrote: On Tue, 10 Aug 2004 22:57:34 +0200 (MEST), Per Foreby [EMAIL PROTECTED] said: ... Try fai-kernels 1.7.1 which uses a newer kernel (2.4.26) than in 1.6. This should fix problems with a sk98lin network card. Does this mean that I'll have to upgrade the installation server to sarge, No you can use fai 1.6 and the kernel from 1.7.1 or are the versions in download/woody only safe recommendations? In case of the latter, would it even be wise to try fai-2.6.1 on a woody server? YOu can install fai 2.6.1 on a woody server (use the newest debootstrap) but then you should install sarge on your install clients, while the server is running woody. Ok, thanks for the explanation. I just tried fai-kernels-1.7.1, and voila, no kernel panic. So now I only have to learn how to configure fai, but having used solaris jumpstart since 1992, that shouldn't be so hard. -- Per Foreby http://www.efd.lth.se/perf/
woody problems
I'm using fai-2.5.4 with fai-kernels-1.6, and I'm trying to install woody om clients with asus p4p800 motherboards with sk98lin (3c940) network. When I'm PXE booting, the system panics after looking up the nfs port: NET4: Unix domain sockets 1.0/SMP for Linux Net4.0. Looking up port of RPC 103/2 on 130.235.34.57 skput:over: c01d2e80:60 put:18 dev:eth0kernel BUG at skbuff.c:93! Invalid operand: ... Unfortunately all previuos output has scrolled off the screen, so I cannot check if the DHCP parameters look ok. Does anyone have a clue on what might be the problem? A real kernel bug, or a configuration error on my part? I might also add that this is my first try with fai. -- Per Foreby http://www.efd.lth.se/perf/
Re: woody problems
On Tue, 10 Aug 2004, Thomas Lange wrote: On Tue, 10 Aug 2004 19:24:46 +0200 (MEST), Per Foreby [EMAIL PROTECTED] said: I'm using fai-2.5.4 with fai-kernels-1.6, and I'm trying to install woody om clients with asus p4p800 motherboards with sk98lin (3c940) network. When I'm PXE booting, the system panics after looking up the nfs port: NET4: Unix domain sockets 1.0/SMP for Linux Net4.0. Looking up port of RPC 103/2 on 130.235.34.57 skput:over: c01d2e80:60 put:18 dev:eth0kernel BUG at skbuff.c:93! Invalid operand: ... Try fai-kernels 1.7.1 which uses a newer kernel (2.4.26) than in 1.6. This should fix problems with a sk98lin network card. Thanks, I'll try that. The install server itself has the same network chip, and runs 2.4.26 without any problems (manually installed). The reason i used fai-kernels-1.6 (2.4.24) was that it was listed at http://www.informatik.uni-koeln.de/fai/download/woody as the last version supported by woody. Does this mean that I'll have to upgrade the installation server to sarge, or are the versions in download/woody only safe recommendations? In case of the latter, would it even be wise to try fai-2.6.1 on a woody server? -- Per Foreby http://www.efd.lth.se/perf/
