Re: can't boot livedvd64_SL54_2009-11-20.iso
Hi Stephen, Stephen Isard wrote: > On Wed, 17 Mar 2010 16:11:47 -0500, Stephen Isard <7p03xy...@sneakemail.c > OM> > wrote: > >> On Wed, 17 Mar 2010 20:23:12 +0100, Urs Beyerle > >> wrote: >> >>> Try to boot with boot parameter "norhgb/"/ >>> >>> linux norhgb >>> >>> norhgb turns graphical bootup off. >>> >>> If this help I should add norhgb to the failsafe option in the next >>> LiveCD release. >> Thanks, Urs. Booting with norhgb didn't change anything, but then I tri > e >> d >> "nox" and that got me a console session. After I logged in as sluser, I > >> was able to start an X session with "startx" and everything seemed norma > l >> except that the time was off by 4 hours (ntpd wasn't running). > > Hi Urs, > > Is it possible that the reason "norhgb" has no effect is the line in > /etc/rc.sysinit that begins "if strstr "$cmdline" rhgb && ". rhg > b won't get > invoked if the command line doesn't mention rhbg at all, but since > "rhgb" is a substring of "norhgb" ... > > My problem seems to be that an xorg.conf that works for my hardware doesn > 't > get configured until your runlast script, and whatever default configurat > ion > there is at the beginning causes a crash if rhgb is allowed to run. I think you are right. In fact, because "rhgb" is already in $cmdline per default, and "linux norhgb" only adds norhgb to $cmdline, "rhgb" still matches $cmdline. Therefore "norhgb" as no effect. As you already mentioned, only "linux nox" and a manual "startx" is working. :-( To avoid this problem in future releases of the SL LiveCDs, I see three possibilities: 1. remove "rhgb" from the default boot options - no graphical bootup per default. 2. make "norhgb" working - /etc/rc.sysinit has to be modified. 3. (at least) remove "rhgb" from failsafe bootup options. or just leave it like it is. Anybody has an opinion on that? Cheers, Urs
Re: SL archives and indexed postings not accessible
I tried to do what Mark Stodola indicated he did and didn't get very far. I went to: http://listserv.fnal.gov/ I clicked on `View list archives', which took me to: http://listserv.fnal.gov/archives/ which gives me a blank page. I looked at the page source and the the page is incomplete, there is no ending `' or `'. I have no idea what else is missing, but it is enough for my browser to just give up on the whole page and just give me a blank screen. I tried a MUCH older browser, Mosaic, I received the same Web page, but it displayed everything that it downloaded despite it being incomplete. In the old browser, I clicked on the SCIENTIFIC-LINUX-USERS link and I get a page displayed. I go back to my usual browser and put that link into it and get a blank page again. This page has the ending `', but no ending `'. Again in the old browser, I tried clicking on `March 2010' and then `February 2010'. Instead of showing me a page, both times it wants to download a file. I went ahead with the download and the page has a bunch of lines with control-M's at the beginning of the file and after every line in the file. It is an HTML file, but again with out an ending `' or `'. Apparently, these links run an executable on a Windbloze system as the link ends with: `/scripts/wa.exe?A1=ind1002&L=scientific-linux-users' -- Brent L. Bates (UNIX Sys. Admin.) M.S. 912 Phone:(757) 865-1400, x204 NASA Langley Research CenterFAX:(757) 865-8177 Hampton, Virginia 23681-0001 Email: b.l.ba...@larc.nasa.govhttp://www.vigyan.com/~blbates/
Re: can't boot livedvd64_SL54_2009-11-20.iso
On Mon, 22 Mar 2010 12:31:12 +0100, Urs Beyerle wrote: >Therefore "norhgb" as no effect. As you already mentioned, only "linux n ox" and a manual "startx" is working. :-( > >To avoid this problem in future releases of the SL LiveCDs, I see three possibilities: > >1. remove "rhgb" from the default boot options - no graphical bootup per default. >2. make "norhgb" working - /etc/rc.sysinit has to be modified. >3. (at least) remove "rhgb" from failsafe bootup options. > >or just leave it like it is. > >Anybody has an opinion on that? Is it out of the question to configure X before rhgb starts? For my case at least, the problem isn't that SL can't figure out how to run X on my hardware, just that it doesn't do so early enough. What would be the consequences of turning off rhgb? Would it stop gdm f rom running and force all users to type 'startx' after logging in if they wan t an X session? Or does rhgb just hide the details of the boot process? I f the second, then I personally would be happy with your option 1. Btw, what is the 'nox' option supposed to do? It evidently doesn't stop X from being configured. Does it really just mean 'no graphical login'? I t doesn't get consulted in /etc/rc.sysinit. Where does it have its effect?
Re: TESTING - rrdtool for SL4 and SL5
On Mon, 8 Feb 2010 Troy Dawson wrote > Looks like we didn't get enough testing done, and maybe rrdtool doesn't > really need to be in the plain SL release. I have no problem pulling it out > of the release and having people just install it from dag or EPEL, > whichever they prefer. Since it hasn't gotten into any final release, this > isn't that much of a problem, I just need to take it out of the > repositories. Does anyone *really* need it in the release? Is there any > real reasons why people can't get it from dag and/or EPEL after they are > installed? Someone answered: > If these packages *need* the particular version of rrdtool > I suggest that it might not be ready for an SL release. > If they only have tight dependencies because the package build > put precise version into the package, then those packages > ought to be remade. > > So no, I don't feel that SL needs to have rrdtool. Is there ever going to be a solution? Now installing ganglia, the gmetad node never can nightly yum update except by hand, due to rrdtool version clashes in public SL mirrors.
Re: can't boot livedvd64_SL54_2009-11-20.iso
Stephen Isard wrote: >> 1. remove "rhgb" from the default boot options - no graphical bootup per >> default. >> 2. make "norhgb" working - /etc/rc.sysinit has to be modified. >> 3. (at least) remove "rhgb" from failsafe bootup options. >> >> or just leave it like it is. >> >> Anybody has an opinion on that? > > Is it out of the question to configure X before rhgb starts? For my case at > least, the problem isn't that SL can't figure out how to run X on my > hardware, just that it doesn't do so early enough. > As far as I know rhgb (= redhat graphical boot) starts a temporary X server, which has its own configuration. So I guess that in your case just rhgb fails to configure its own X server. See /usr/share/doc/rhgb-0.16.4/HOW_IT_WORKS > What would be the consequences of turning off rhgb? Would it stop gdm from > running and force all users to type 'startx' after logging in if they want > an X session? Or does rhgb just hide the details of the boot process? If > the second, then I personally would be happy with your option 1. It's the second. So, I have already two votes for 1. > > Btw, what is the 'nox' option supposed to do? It evidently doesn't stop X > from being configured. Does it really just mean 'no graphical login'? It > doesn't get consulted in /etc/rc.sysinit. Where does it have its effect? "nox" only sets the default runlevel to 3. The X server is still configured. Having runlevel=3, rhgb does not start up (see /usr/share/doc/rhgb-0.16.4/HOW_IT_WORKS)
Re: can't boot livedvd64_SL54_2009-11-20.iso
On 22 March 2010 14:39, Urs Beyerle wrote: > Stephen Isard wrote: >>> 1. remove "rhgb" from the default boot options - no graphical bootup per >>> default. >>> 2. make "norhgb" working - /etc/rc.sysinit has to be modified. >>> 3. (at least) remove "rhgb" from failsafe bootup options. >>> >>> or just leave it like it is. >>> >>> Anybody has an opinion on that? +1 to option 1. :-) Alan.
Re: can't boot livedvd64_SL54_2009-11-20.iso
Alan Bartlett wrote: On 22 March 2010 14:39, Urs Beyerle wrote: Stephen Isard wrote: 1. remove "rhgb" from the default boot options - no graphical bootup per default. 2. make "norhgb" working - /etc/rc.sysinit has to be modified. 3. (at least) remove "rhgb" from failsafe bootup options. or just leave it like it is. Anybody has an opinion on that? +1 to option 1. :-) Alan. Although I don't use Urs' livecd (I do build my own using his scripts), I'd have to lean toward 1 or 3. I know for a fact that rhgb can cause problems if using the ati fglrx module as well. To me, 'failsafe' should mean no fancy options or actions during boot. -Mark -- Mr. Mark V. Stodola Digital Systems Engineer National Electrostatics Corp. P.O. Box 620310 Middleton, WI 53562-0310 USA Phone: (608) 831-7600 Fax: (608) 831-9591
Re: xfs mount failure with latest SL5.3 kernel and SELinux in permissive mode
Hi Everyone, This is my fault. As Jon noted, I accidentally pushed out the kernel-module-xfs rpm's for the new kernel. I'm sorry this happened. I'm about halfway through writting the new scripts that check for this sort of thing, but the kernels came before it was done. I have taken the x86_64 kernel-module-xfs-2.6.18-164.15.1.el5 kernel modules out of the security updates area's. I have also changed the script enough so that the x86_64 xfs kernel module rpm's don't even get built, so this shouldn't happen again. Again, my apologies for pushing this out. Troy Dawson Doug Benjamin wrote: Hi Jon, Thank you very much for the tips. There is a collision between the xfs.ko installed from the package - kernel-module-xfs-2.6.18-164.15.1.el5.x86_64 and installed from the kernel itself - kernel-2.6.18-164.15.1.el5.x86_64 [r...@ascwrk0 ~]# modinfo xfs filename: /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko license:GPL description:SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled author: Silicon Graphics, Inc. srcversion: EB72D8E7117BE062A7B96A4 depends: vermagic: 2.6.18-164.15.1.el5 SMP mod_unload gcc-4.1 module_sig: 883e3504ba0dc94626fb156c52e660112225809762cffd6ffbe28ceb9572fdb3f3b51a48bc8a509e311d9de94c5269ad84dcf97db8606cbc4db62477 I am not who is responsible for assembling the kernel-module-xfs package but I believe that there is a bug in it. thanks again for your help. Cheers, Doug Benjamin On Mar 21, 2010, at 10:26 AM, Jon Peatfield wrote: On Sun, 21 Mar 2010, Doug Benjamin wrote: Hello, Has anyone experienced this failure. xfs file system will not mount after a kernel upgrade. when SELinux is in permissive mode Here are the details: [r...@ascwrk0 ~]# uname -a Linux ascwrk0.hep.anl.gov 2.6.18-164.15.1.el5 #1 SMP Tue Mar 16 18:44:51 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [r...@ascwrk0 ~]# modinfo xfs filename: /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko license:GPL description:SGI XFS with ACLs, large block/inode numbers, no debug enabled author: Silicon Graphics, Inc. srcversion: CD41E32544B126D01477F5F depends: vermagic: 2.6.18-164.15.1.el5 SMP mod_unload gcc-4.1 The error is Operation not permitted when trying to mount the existing xfs partition. If I role back the kernel to [r...@ascwrk0 ~]# uname -a Linux ascwrk0.hep.anl.gov 2.6.18-164.11.1.el5 #1 SMP Wed Jan 20 00:57:09 EST 2010 x86_64 x86_64 x86_64 GNU/Linux and using this kernel module - [r...@ascwrk0 ~]# modinfo xfs filename: /lib/modules/2.6.18-164.11.1.el5/kernel/fs/xfs/xfs.ko license:GPL description:SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled author: Silicon Graphics, Inc. srcversion: EB72D8E7117BE062A7B96A4 depends: vermagic: 2.6.18-164.11.1.el5 SMP mod_unload gcc-4.1 module_sig: 883f3504b569fcd6ae2bfe7d51a34c11236e709d14c133b4bc8a959c91ef6630331b106c64cca97a09e2fed52ea7666ee49627c0342ef2e2e037723869 mount is successful. When SELinux is set to disabled then the xfs filesystem mounts with the latest kernel. Any suggestions how to fix the problem so that I can set SELinux back to permissive mode Where is the new xfs.ko comming from? I ask because I note that the latest sl kernels also include an xfs module package even on x86_64 while the recent previous versions have not since upstream include it xfs (on x86_64 at least). In the tree which includes the x86_64 versions of the updates I see: $ rpm -qlvp kernel-2.6.18-164.15.1.el5.x86_64.rpm | grep -i xfs.ko -rwxr--r--1 rootroot54872 Mar 16 23:53 /lib/modules/2.6.18-164.15.1.el5/kernel/fs/freevxfs/freevxfs.ko -rwxr--r--1 rootroot 694824 Mar 16 23:53 /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko $ rpm -qlvp kernel-module-xfs-2.6.18-164.15.1.el5-0.4-2.sl5.x86_64.rpm | grep -i xfs.ko -rwxr--r--1 rootroot 13023126 Mar 17 19:59 /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko so it seems likely to cause problems for someone if both get pulled in. Because we use xfs on top of md (raid5) we need to apply a patch to all recent TUV/sl kernels - I don't bother to build the external xfs modules - and it seems to work ok for me (in permissive mode), and I get: $ dmesg | grep -i xfs SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled SGI XFS Quota Management subsystem XFS mounting filesystem md0 Ending clean XFS mount for filesystem: md0 SELinux: initialized (dev md0, type xfs), uses mountpoint labeling and from modinfo $ modinfo xfs filename: /lib/modules/2.6.18-164.15.1.el5.D1/kernel/fs/xfs/xfs.ko license:GPL description:SGI XFS with ACLs, security attributes, large b
Re: Scientific Linux
On Sat, 20 Mar 2010 19:48:55 -0500 Nathan Jeffrey Allen wrote: > hello all i just installed scientific linux via live cd and i want to > now what to do next? particulary how > to get the internet up and running i have a linksys usb wireless > antenna adapter. is this compatible > with scientific linux. if it is then how do i activate it? also could > you tell me how to activate my cd > dvd tray as well? thanks Nathan Jeffrey Allen. nathan_all...@juno.com > P.S. I am new to this Be aware that SL may not be the easiest Linux distro to set up. (A much newer kernel would be useful) To identify the wireless device you have, please open a terminal and run lsusb #If that doesn't work, try "/usr/sbin/lsusb" http://linuxwireless.org/en/users/Devices/USB is handy for this. To view the loaded drivers, run /sbin/lsmod|more The right driver would be zd1211rw, p54usb, rt2800usb, or rt73usb. Hope this helps, Ibidem
Re: TESTING - rrdtool for SL4 and SL5
Winnie Lacesso wrote: On Mon, 8 Feb 2010 Troy Dawson wrote Looks like we didn't get enough testing done, and maybe rrdtool doesn't really need to be in the plain SL release. I have no problem pulling it out of the release and having people just install it from dag or EPEL, whichever they prefer. Since it hasn't gotten into any final release, this isn't that much of a problem, I just need to take it out of the repositories. Does anyone *really* need it in the release? Is there any real reasons why people can't get it from dag and/or EPEL after they are installed? Someone answered: If these packages *need* the particular version of rrdtool I suggest that it might not be ready for an SL release. If they only have tight dependencies because the package build put precise version into the package, then those packages ought to be remade. So no, I don't feel that SL needs to have rrdtool. Is there ever going to be a solution? Now installing ganglia, the gmetad node never can nightly yum update except by hand, due to rrdtool version clashes in public SL mirrors. Sorry about that. They are now *really* taken out. You might need to do a yum clean all Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
install gcc
SL Community: Hello I am relatively new to the linux community however I just congifured SL 5.4 x86 on my laptop. I am now trying to install the gcc4 compiler and was wondering how I go about doing that. I understand it is distributed with the SL5 release however I am having difficultly locating/installing the compiler. Does anyone know where/how I can do this, or possibly read more information about it. Thank you.
Re: install gcc
On 10-03-22 11:30 AM, Dana Stratton Ford wrote: > SL Community: > > Hello I am relatively new to the linux community however I just > congifured SL 5.4 x86 on my laptop. I am now trying to install the > gcc4 compiler and was wondering how I go about doing that. I > understand it is distributed with the SL5 release however I am having > difficultly locating/installing the compiler. Does anyone know > where/how I can do this, or possibly read more information about it. > Thank you. A good way to discover applications you're looking for is with yum. For instance, a quick --- yum search gcc --- returns a (semi) large list of packages that may or may not be completely associated with what you're looking for, but on one of my SL 5.4 systems, I get possibly a good candidate: --- gcc.x86_64 : Various compilers (C, C++, Objective-C, Java, ...) --- (of course, yours will be i386, not .x86_64) You can also look for specific commands with the "yum provides" command, ala: --- yum provides /usr/bin/gcc --- Which gives me a number of RPM packages that provide what I'm looking for (if you don't know the exact location of the command you can check out the man pages of yum and look for information on provides). (/usr/*/gcc works I think) Post more questions if you've got em :) Hope this helps! -Chris Tooley
Re: nox - [was can't boot livedvd64_SL54_2009-11-20.iso]
On Mon, 22 Mar 2010 15:39:47 +0100, Urs Beyerle wrote: >"nox" only sets the default runlevel to 3. The X server is still configu red. >Having runlevel=3, rhgb does not start up (see /usr/share/doc/rhgb-0.16.4/HOW_IT_WORKS) Just for my general education, do you know what program interprets the 'n ox' parameter and sets the runlevel? As I understand it, init usually gets t he runlevel from /etc/inittab, so nox must somehow be overriding that. I've run strings on the init and grub binaries and grepped the output for nox, but not come up with anything. HOW_IT_WORKS doesn't mention nox either.
Re: install gcc
Dana Stratton Ford wrote: SL Community: Hello I am relatively new to the linux community however I just congifured SL 5.4 x86 on my laptop. I am now trying to install the gcc4 compiler and was wondering how I go about doing that. I understand it is distributed with the SL5 release however I am having difficultly locating/installing the compiler. Does anyone know where/how I can do this, or possibly read more information about it. Thank you. Hello, There are two ways of looking for and installing packages for Scientific Linux. You can do it by hand or use a graphical program. *By Hand - using yum To list all the packages that start with gcc yum list gcc\* To install gcc (including everything it depends on) yum install gcc To list packages that have been arranged by groups yum grouplist To install the development groups (which includes gcc) yum groupinstall "Development Libraries" yum groupinstall "Development Tools" To find out all the things yum can do man yum *Using a graphical program The official graphical program is pirut Start Menu -> System -> Add/Remove Software I'm not a person who usually uses the graphical package installer, but to me is seems fairly straightforward, although it looks like the default is to do things by groups. Hope this helps Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: nox - [was can't boot livedvd64_SL54_2009-11-20.iso]
On 03/22/2010 07:47 PM, Stephen Isard wrote: > On Mon, 22 Mar 2010 15:39:47 +0100, Urs Beyerle > wrote: > >> "nox" only sets the default runlevel to 3. The X server is still configu > red. >> Having runlevel=3, rhgb does not start up (see > /usr/share/doc/rhgb-0.16.4/HOW_IT_WORKS) > > Just for my general education, do you know what program interprets the 'n > ox' > parameter and sets the runlevel? As I understand it, init usually gets t > he > runlevel from /etc/inittab, so nox must somehow be overriding that. I've > > run strings on the init and grub binaries and grepped the output for nox, > > but not come up with anything. HOW_IT_WORKS doesn't mention nox either. The nox parameter is "my invention" ;-) It only works with the SL LiveCD. If you specify nox, /etc/inittab is modified at the very beginning of the LiveCD bootup process (before chroot to the SL filesystem, inside the linuxrc of the initial ram disk). Search for nox in the script linuxrc: https://svn.iac.ethz.ch/pub/livecd/trunk/linux-live.sl/initrd/linuxrc Cheers, Urs
Re: grub consistently missing from root partition boot sector?
On Wed, 17 Mar 2010 12:42:25 -0500, Filippo Cattaneo wrote: > Years of Debian esperience, new to SL, 3rd attempt > at installing 5.4. I specify that grub should be installed > in the root partition, in my case /dev/hda4. > I use GAG as pure boot selector, each OS has its own > bootloader >on-partition. > Due to history, /dev/hda4 is the second primary, right after hda1 > on the disk. > > I decline to rearrange partition order, and also decline > to add other OS's >to the SL grub boot menu as proffered by installer. > >On 1st boot I consistently find no bootloader on /dev/hda4. > > Other OS's boot fine. > > Booted rescue twice, chrooted to root partition, > I see the fileysytem where it should be > - i.e. the system seemingly doesn't get confused > by partitions not being in order. > >Attempted this: > grub-install /dev/hda4 > >I repeatedly get this message: > error reading stage 1 > >I failed to find references to this on the list. >Is this a known problem? >Did I miss something in the archives? > >TIA! > = === Solved for the time being... - Booted with System Rescue CD 1.3.3, not the latest, uses Linux-2.6.31.6 , and that kernel calls all HDs "sd". - Mounted /dev/sda4 just to check (should not matter!). - Installed bootloader from the shell (not from the grub prompt): grub-install --recheck /dev/sda4 For the 1st time grub installed AND at reboot the bootloader was able to find kernel and initrd. I suspect it was an issue with the older SL and Debian kernels not being able to read the partition table correctly at each step of the grub installation process. I.e. maybe yes for find from the grub prompt but definitely not for installing. This would imply the older Debian kernels would be accessing the same partition table in different ways, one where "find" from the grub prompt works, one where "setup" fails. Is this conceivable? All partitioning tools report the partition is fine, albeit with partitio ns not in normal order. Even the SL installer offered to reorder partitions but did not complain when I declined.
