Re: CFLAGS errors
Could you provide the exact error message and VME drivers source download link? I'll take a look at it. --- wbr, Denis. On Tue, Nov 8, 2011 at 12:54 PM, Dr. Sunil M. Dogra smdo...@gmail.comwrote: Yes, I tried this page yesterday and it did not worked for me Thank you With best Regards sunil
Re: Moving from EL N to EL N+1
On Monday, November 07, 2011 07:00:08 PM you wrote:
On Mon, Nov 7, 2011 at 2:02 PM, Connie Sieh cs...@fnal.gov wrote:
Yes that is our support stance. It is NOT supported by either TUV or SL .
I remember that thread and Connie's response. I'm sorry that I
suggested in this thread that it was OK; I was confusing RHEL/SL with
Fedora, where it is OK and one of the Anaconda pre-release QA tests.
Not supported != doesn't work. Which means, if you get it to work, that's
great, but if it fails to work, you get to keep the pieces, and you won't be
'entitled' to any sympathy or help.
There has been an 'upgradeany' command line option in CentOS at least for
several cycles, but it is also not supported. It might work, but it likely
will leave your system in a 'self-supported' state. Meaning, again, that when
it breaks you won't get any sympathy, and you'll likely get the 'unsympathy'
which seems to be typical for techie lists sorry, but facts are facts, and
whether it's right and fair or not, it just *is* the case.
Likewise, preupgrade tends to work fairly well for Fedora; but when it works it
typically doesn't work for an upgrade increment of more than two Fedora
versions. The Fedora version skew between EL5, based somewhat on FC6, and EL6,
based somewhat on a melange of F12, F13, and other things, is 6 full Fedora
versions. Even if preupgrade were available for FC6, it likely would not
upgrade to F12 even in one step. It's not likely to be ever be *supported* on
EL of any version, even if it does become available.
This is where the one of the major differences between the RPM packaging and
the DEB packaging shows itself. Debian (and Debian-derivatives) take advantage
of the possibility of interactive response in a DEB to deal with real upgrade
issues; RPMs are not supposed to do any interaction with the user in any of the
package's scriptlets. The DEB scripts have wide latitude in what they can do,
and have several powerful tools available for use in the script. It does make
complete unattended upgrading somewhat difficult, as it prompts the user for
lots and lots of things and seemingly random times; IOW, it's not a 'start it
and let it run overnight' thing without effort.
I've attempted preupgrade upgrades, and have not had one go 100% successfully
yet. Nor, for that matter, have I ever had a DVD or CD upgrade of any Fedora
version go 100% successfully, either.
So I typically 'upgrade' by keeping a separate /home and backing up everything
in /etc and /var that will be needed in the new version (I of course back up
/home as a matter of course), and getting a 'versionless' RPM listing ( rpm -qa
--queryformat=%{NAME}\n|sort ). If anything is in /usr/local or /opt those
get backed up, too, and separately evaluated. For workstations it's not too
hard; servers are another matter. I then do a fresh installation, making sure
to neither format nor mount the old /home.
I'll retrieve the package listing and the repository info (being in
/etc/yum.repos.d, it gets backed up with /etc) and check those to make sure the
repos and options are the same, and then I'll enable those repos, do an initial
yum update, and then use the yum-utils program repoquery to get a full listing
of all packages that are available, use diff in a creative manner, and do other
manual things to get a valid list of packages to install, and pass that list to
yum.
Once I'm satisfied all the packages my /home are going to need are installed
properly, I'll read the release notes both of the distribution and of the major
upstream packages I use (things like, GNOME and KDE, Ardour, JACK, and those
other things I use on a daily basis) and make sure there's not going to be
major reshuffling or data corruption or improper operation in those programs'
configuration directories in my /home.
I'll test with a normal user named the same as my main user ID before
remounting my /home, and make sure things look reasonable with copies of what
that program needs from my /home (mounted somewhere else, of course), and once
that looks good I'll reboot in single user mode, rename /home to /new-home,
recreate the /home mount point, and set /etc/fstab to mount /home again. I'll
also set up an selinux relabel for the entire filesystem (I do, unlike most,
run my workstation with SELinux ON and ENFORCING).
And those release notes things and checking should be done even if you do a
preupgrade-sort of thing, or a string of yum updates with repo files pointing
to various places.
It is more of a pain for a user to do the upgrade the way I do upgrades, but
the fact of the matter is that the current RPM system simply is not built to do
robust upgrades when many upstream packages have major differences between
versions, in terms of data files and configuration; the scriptlets just don't
have enough power at their disposal, really, and especially in the anaconda
chroot used during media-based
running from an external USB drive
I have an external USB drive. I have successfully installed 6.1 (2011-07-27) on the external USB drive. And I it doesn't appear to have touched my internal drive (good!) I previously had done this with 5.3 (?) and used a mkinitrd command and associated cookbook found on a web page (http://www.brunel.ac.uk/~eesridr/extlinux.html) I believe that command puts certain things into a ramdisk, maybe for speedup? I'm not sure what it does. When I try that command under 6.1 I get a warning that it won't override without --force. I didn't do it. Do I want to do it? Things seem to work ok, but I haven't done anything substantial with it yet.
A question of dependencies
I attempted to install: [Downloads]$ rpm -iv bakoma-tex-9.7.5-02.i386.rpm error: Failed dependencies: libXinerama.so.1 is needed by bakoma-tex-9.7.5-03.i386 libatk-1.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libcairo.so.2 is needed by bakoma-tex-9.7.5-03.i386 libexpat.so.1 is needed by bakoma-tex-9.7.5-03.i386 libfontconfig.so.1 is needed by bakoma-tex-9.7.5-03.i386 libfreetype.so.6 is needed by bakoma-tex-9.7.5-03.i386 libgdk-x11-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libgdk_pixbuf-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libgio-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libglib-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libgmodule-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libgobject-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libgthread-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libgtk-x11-2.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libjpeg.so.62 is needed by bakoma-tex-9.7.5-03.i386 libpango-1.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libpangocairo-1.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libpangoft2-1.0.so.0 is needed by bakoma-tex-9.7.5-03.i386 libstdc++.so.6 is needed by bakoma-tex-9.7.5-03.i386 libstdc++.so.6(CXXABI_1.3) is needed by bakoma-tex-9.7.5-03.i386 libstdc++.so.6(GLIBCXX_3.4) is needed by bakoma-tex-9.7.5-03.i386 libstdc++.so.6(GLIBCXX_3.4.11) is needed by bakoma-tex-9.7.5-03.i386 libstdc++.so.6(GLIBCXX_3.4.9) is needed by bakoma-tex-9.7.5-03.i386 libz.so.1 is needed by bakoma-tex-9.7.5-03.i386 I put x86-64 SL 6 on a fresh harddrive. However, I have a separate mounted harddrive that is not in the system search path (neither for executables/scripts nor for libraries) but that contains an IA-32 EL 5 image, including all (most?) of the above missing files in what is the equivalent of /usr/lib . If I cp -pr the files from the equivalent, that is, /oldusr/lib to /usr/lib, will the above RPM install, or must I either (1) get current SL 6 IA-32 RPMs that contain the above .so files to resolve the dependencies. (1.1) if so, how does one one find which RPM provides the above (I have an output from, e.g., http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/libXinerama.so.1 , but this seems to show SL 4 and no more current SL)? (2) try rpm -iv --force --nodeps and then cp -pr /oldusr/lib/foobar.so.M /usr/lib where foobar.so.M is one of the missing .so files, for the entire list of missing .so files, so that ldd will find the necessary .so files. If both (1) and (2) will work -- (2) always should work barring special configuration files, say in /etc, needed by a .so -- which is the better alternative? Yasha Karant
Re: A question of dependencies
On Tuesday, November 08, 2011 19:38:46 Yasha Karant wrote: I attempted to install: [Downloads]$ rpm -iv bakoma-tex-9.7.5-02.i386.rpm error: Failed dependencies: [snip] list of 32bit deps I put x86-64 SL 6 on a fresh harddrive. However, I have a separate mounted harddrive that is not in the system search path (neither for executables/scripts nor for libraries) but that contains an IA-32 EL 5 image, including all (most?) of the above missing files in what is the equivalent of /usr/lib . If I cp -pr the files from the equivalent, that is, /oldusr/lib to /usr/lib, will the above RPM install, or must I either (1) get current SL 6 IA-32 RPMs that contain the above .so files to resolve the dependencies. yes, that's what you have to do. (1.1) if so, how does one one find which RPM provides the above (I have an output from, e.g., http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/libXinerama.so.1 , but this seems to show SL 4 and no more current SL)? Why don't you use yum? What do you usually use to resolve dependencies if you aren't using yum? yum install path tofile/bakoma-tex-9.7.5-02.i386.rpm If any of the enabled repos contain packages that satisfy the dependencies, yum will find them and install them. (2) try rpm -iv --force --nodeps and then cp -pr /oldusr/lib/foobar.so.M /usr/lib where foobar.so.M is one of the missing .so files, for the entire list of missing .so files, so that ldd will find the necessary .so files. Sure way to screw up your system.
Re: A question of dependencies
On 8 November 2011 18:55, Andreas Petzold andreas.petz...@kit.edu wrote: snip Why don't you use yum? What do you usually use to resolve dependencies if you aren't using yum? yum install path tofile/bakoma-tex-9.7.5-02.i386.rpm snip I suspect you intended -- yum localinstall path tofile/bakoma-tex-9.7.5-02.i386.rpm Alan.
Re: A question of dependencies
On Tue, 8 Nov 2011 at 7:05pm, Alan Bartlett wrote On 8 November 2011 18:55, Andreas Petzold andreas.petz...@kit.edu wrote: snip Why don't you use yum? What do you usually use to resolve dependencies if you aren't using yum? yum install path tofile/bakoma-tex-9.7.5-02.i386.rpm snip I suspect you intended -- yum localinstall path tofile/bakoma-tex-9.7.5-02.i386.rpm Nope. From 'man yum'[1]: * localinstall rpmfile1 [rpmfile2] [...] (maintained for legacy reasons only - use install) [1] Actually, that's from 'man yum' on a Fedora system. The SL6 yum package doesn't include a man page. Does that bug anybody else? 'yum --help' on SL6 doesn't include any mention of localinstall. -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF
Re: A question of dependencies
On 11/08/2011 10:55 AM, Andreas Petzold wrote: On Tuesday, November 08, 2011 19:38:46 Yasha Karant wrote: I attempted to install: [Downloads]$ rpm -iv bakoma-tex-9.7.5-02.i386.rpm error: Failed dependencies: [snip] list of 32bit deps I put x86-64 SL 6 on a fresh harddrive. However, I have a separate mounted harddrive that is not in the system search path (neither for executables/scripts nor for libraries) but that contains an IA-32 EL 5 image, including all (most?) of the above missing files in what is the equivalent of /usr/lib . If I cp -pr the files from the equivalent, that is, /oldusr/lib to /usr/lib, will the above RPM install, or must I either (1) get current SL 6 IA-32 RPMs that contain the above .so files to resolve the dependencies. yes, that's what you have to do. (1.1) if so, how does one one find which RPM provides the above (I have an output from, e.g., http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/libXinerama.so.1 , but this seems to show SL 4 and no more current SL)? Why don't you use yum? What do you usually use to resolve dependencies if you aren't using yum? yum installpath tofile/bakoma-tex-9.7.5-02.i386.rpm If any of the enabled repos contain packages that satisfy the dependencies, yum will find them and install them. (2) try rpm -iv --force --nodeps and then cp -pr /oldusr/lib/foobar.so.M /usr/lib where foobar.so.M is one of the missing .so files, for the entire list of missing .so files, so that ldd will find the necessary .so files. Sure way to screw up your system. Note: in the response below I am including the full output from the suggested command; feel free to remove this output from any further parts of this thread. However, there may be some specific diagnostic in the output that will elucidate the problem, and thus the full output is presented. Also, mention is made of nethack-vultures below that is unrelated to the bakomatex package -- I do install a current animation version of rogue for historical interest but evidently yum has some issues therein. Here is the output using your method: [ykarant Downloads]$ su Password: [root@jDownloads]# yum install ./bakoma-tex-9.7.5-02.i386.rpm Configuration file /etc/yum/pluginconf.d/fastestmirror.conf not found Unable to find configuration file for plugin fastestmirror Loaded plugins: changelog, downloadonly, kabi, refresh-packagekit, security Loading support for Red Hat kernel ABI Setting up Install Process Examining ./bakoma-tex-9.7.5-02.i386.rpm: bakoma-tex-9.7.5-03.i386 Marking ./bakoma-tex-9.7.5-02.i386.rpm to be installed Resolving Dependencies -- Running transaction check --- Package bakoma-tex.i386 0:9.7.5-03 will be installed -- Processing Dependency: libXinerama.so.1 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libatk-1.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libcairo.so.2 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libexpat.so.1 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libfontconfig.so.1 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libfreetype.so.6 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libgdk-x11-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libgdk_pixbuf-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libgio-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libglib-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libgmodule-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libgobject-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libgthread-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libgtk-x11-2.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libjpeg.so.62 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libpango-1.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libpangocairo-1.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libpangoft2-1.0.so.0 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libstdc++.so.6 for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libstdc++.so.6(CXXABI_1.3) for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libstdc++.so.6(GLIBCXX_3.4) for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.11) for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.9) for package: bakoma-tex-9.7.5-03.i386 -- Processing Dependency: libz.so.1 for package: bakoma-tex-9.7.5-03.i386 -- Running transaction check --- Package atk.i686 0:1.28.0-2.el6 will be installed --- Package cairo.i686 0:1.8.8-3.1.el6 will be
SL6.1 - Unable to login
Hello All,
I am relatively new to Linux.
Today I installed a system with SL6.1 with runlevel 3
Updated it via YUM
kernel 2.6.32-131.17.1.el6.x86_64
I was able to login to the system after install (locally as well as via SSH)
after some time suddenly I am unable to login to the system
SSH gives the following error
[root@sites Abhijeet]# ssh 192.168.1.6
root@192.168.1.6's password:
Last login: Wed Nov 9 00:05:34 2011 from 192.168.1.4
Usage: -bash {start|stop|restart}
Connection to 192.168.1.6 closed.
on the machine on startup it asks for login as usual but after providing
login and password it flashes the last login info and again goes back to
the startup login screen.
I am able to access the machine via webmin.
--
Best Regards,
Abhijeet Nagawade.
+91-9422919428
http://www.Shrigonda.in
Allow a group permissions to unlock a screensaver
Is there a screen saver or gnome configuration program that would enable features like : http://www.e-motional.com/TScreenLock.htm on RHEL? -- James Pulver Information Technology Area Supervisor LEPP Computer Group Cornell University
RE: SL6.1 - Unable to login
Usage: -bash {start|stop|restart}
-
It definitely looks like the style of thing found in /etc/init.d scripts
It looks to me like the executable for bash is a link into init.d
One way around may be to edit /etc/passwd to make the shell /bin/ksh
instead of /bin/bash, then you can get in and look around.
Re: Moving from EL N to EL N+1
On Tuesday, November 08, 2011 02:02:14 PM you wrote: 2. using dd and an external USB drive enclosure that mounts an external drive as /dev/sdX for some X, clone the drive from my wife's machine to this drive. As I only have a USB 2 interface on the enclosure, and neither her nor my laptop has USB 3 ports, this dd will take approximately 24 hours. Use your eSATA port; the 8530p's specification page lists one. This will be much much faster than USB2; 320GB shouldn't take more than three or four hours using something like ddrescue booted off a LiveCD and using a Thermaltake BLACX eSATA dock. I've used eSATA (using an ExpressCard eSATA interface) for cloning my laptop's drive for a couple of years, now. Makes a great deal of difference. I'm not sure whether the SL 6.1 LiveCD includes ddrescue or not. I use ddrescue for a couple of reasons; first, it provides a progress indication without having to send the dd process a SIGUSR1 from another shell; second, it intelligently blocks and can be some faster than dd. Otherwise your procedure doesn't look unreasonable.
imake : where is the template file?
Hi everyone, I need to use imake to compile some old libraries. Executing imake I obtain this message : jerome@GRELPT0464 src]$ imake Imakefile.c:34: erreur: Imake.tmpl : Aucun fichier ou dossier de ce type imake: Exit code 1. Stop. I've installed the last release of imake via yum update. I'm under SL6. I've read that template files should be under such a path : /usr/X11R6/lib/X11/config ... but haven't found such a path or nearly the same. thanks
Re: CFLAGS errors
Hello Sunil, Sorry for the long delay. 1) In file a2818.c, replace linux/config.h with linux/autoconf.h. Add #include linux/sched.h in a line below. 2) in file v1718.c, replace all occurrences of info() function call with pr_info(). Mind about EXTRA_CLAGS in both cases. --- wbr, Denis.
