Re: EL 7 in-place upgrade
On Wed, 25 Jun 2014, Akemi Yagi wrote: On Tue, Jun 24, 2014 at 10:29 PM, Yasha Karant ykar...@csusb.edu wrote: I was not referring to the Fedora mechanism. Some licensed-for-fee commercial unix environments (not linux) used on primary servers allow for major release upgrade in place. Does the Red Hat method that is mentioned by Red Hat allow for this, or is the Red Hat enterprise z-stream insane to use in a production situation? If it is not insane but actually is effective, are there no Linux or GPL encumbrances on z-stream that force Red Hat to release the source? Please see this documentation: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/chap-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Upgrade_Tools.html But it is supported only in some use cases. The details are summarized here: https://access.redhat.com/site/solutions/799813 (this one needs subscription to read) As I understood it from a Red Hat spokesperson this functionality was absolutely required for their RHEV product so that hypervisors could be updated from the RHEL6-based product to the RHEL7-based product. Quite likely this will be used for other more appliance-like (read: self-contained) setups/offerings in the future as well. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Clarity on current status of Scientific Linux build
On Mon, 23 Jun 2014, Paul Robert Marino wrote: well what I dont understand here is all of RHEL SRPMs are on a web server an can be downloaded if you have an entitlement. all you need is 1) the CA cert located here /usr/share/rhn/RHNS-CA-CERT on any Red Hat host. 2) the entitlement cert from subscription manager winch you can get off of access.redhat.com go to Subscriptions - Subscription Management - UNITs then click on the subscription you would like to use. you will see a Download button on the top left side of the screen. 3) on the page where you downloaded the certificate there is a sub tab called Content Set take the URL's listed there and prefix them with https://cdn.redhat.com if you connect with a browser you can see its just a standard yum repo which uses the certificates for authentication, so most yum mirroring tools will work just fine as long as it can supply the the PKI (entitlement) cert to their web server. Exactly, if it is easy to download SRPM packages from RHN (provided you have the necessary funding to pay for various entitlements). Then the oft-repeated statement that the reason for not making the SRPMs publicly available as before, is to prevent competitors (i.e. Oracle) from being able to rebuild RHEL. Well, if anyone is able to pay for entitlements, it surely is Oracle and the likes. So in essence this change only harms community projects who may not have the yearly funding for the various entitlements (incl. RHSCL, HA, ...) Or what am I missing here ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Google chrome stable 28.0 installation problem
On Wed, 3 Jul 2013, Yasha Karant wrote:
On 07/03/2013 06:37 AM, Dag Wieers wrote:
They cannot be using mock, otherwise it wouldn't pick up the newer,
alien libstdc++ from Ubuntu 12.04. Besides, if they did it would all
have magically worked (or not have built at all).
Version : 27.0.1453.110
Build Host: lin64build12.chrome.corp.google.com
vs
Version : 28.0.1500.70
Build Host: precise64build2.chrome.corp.google.com
RPM version: 4.9.1.1
So the RPM version pretty much gives away that they do not build on
RHEL. And rpm-4.9.1.1 is exactly what ships with Ubuntu Precise Pangolin
(aka Ubuntu 12.04).
Need more proof ? :-)
Please pardon this question, but how did you extract the above information?
Try:
rpm --querytags
You'll get a list of query tags you can use together with rpm --queryformat:
[dag@moria ~]$ rpm -q --queryformat 'Version: %{VERSION}\nBuild Host:
%{BUILDHOST}\nRPM Version: %{RPMVERSION}\n' google-chrome-stable
Version: 27.0.1453.110
Build Host: lin64build12.chrome.corp.google.com
RPM Version: 4.7.2
[dag@moria ~]$ rpm -qp --queryformat 'Version: %{VERSION}\nBuild Host:
%{BUILDHOST}\nRPM Version: %{RPMVERSION}\n'
google-chrome-stable-28.0.1500.70-209565.x86_64.rpm
Version: 28.0.1500.70
Build Host: precise64build2.chrome.corp.google.com
RPM Version: 4.9.1.1
Kind regards,
--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
Re: Google chrome stable 28.0 installation problem
On Wed, 3 Jul 2013, Steven Haigh wrote: On 3/07/2013 6:04 PM, Yasha Karant wrote: On 07/02/2013 04:47 PM, Steven Haigh wrote: On 3/07/2013 9:33 AM, Tam Nguyen wrote: On Tue, Jul 2, 2013 at 6:45 PM, Yasha Karant ykar...@csusb.edu mailto:ykar...@csusb.edu wrote: Add/remove software shows: google-chrome-stable-28.0.__1500.70-209565 (x86_64) but installation results in a transaction error: google-chrome-stable-28.0.__1500.70-209565.x86_64 requires libstdc++.so.6(GLIBCXX_3.4.15)__(64bit) and the dependency does not automatically resolve. Is there a workaround for this issue? Download Google rpm here: http://orion.lcg.ufrj.br/RPMS/myrpms/google/ then yum install the download rpm. Sorry - but I think its really bad practice to just refer people to random, unknown repositories for common software... In a nutshell, the version of libstdc++ seems to be rather old that Google are using. SL has: # yum whatprovides libstdc++.so.6 libstdc++-4.4.7-3.el6.i686 : GNU Standard C++ Library Repo: sl6x Matched from: Other : libstdc++.so.6 I'd recommend is using chromium if you don't rely on any Google-only features. There is a thread about this on the SL forums: http://scientificlinuxforum.org/index.php?showtopic=1134 I thoroughly am confused about these responses. Unless I am mistaken, the chrome RPM seems to be from a standard EL6 repository. Moreover, the previous release of chrome through this same method did not produce this error, and installed and ran without obvious issues. However, as updates typically both fix bugs and security holes, we routinely update to current production. It is only the most current release of real chrome (not chromium) that shows this problem -- is there a repository with the necessary RPMs for a proper workaround? Google calls RHEL6 'too old' and 'obsolete' now. See: http://linux.slashdot.org/story/13/02/11/1452259/rhel-6-no-longer-supported-by-google-chrome Nothing in EL6 caused this break - purely internal stuff from Google. Their build-system is Ubuntu based, and Ubuntu moved on. It's pretty cynical to learn that at Google the RHEL packages have been build in an Ubuntu environment, rather than properly packaged on the same distribution. A practice that almost everyone is doing today. It's amazing that this even worked, we'd be better off if it didn't... -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Google chrome stable 28.0 installation problem
On Wed, 3 Jul 2013, Tom H wrote: On Wed, Jul 3, 2013 at 6:51 AM, Dag Wieers d...@wieers.com wrote: It's pretty cynical to learn that at Google the RHEL packages have been build in an Ubuntu environment, rather than properly packaged on the same distribution. A practice that almost everyone is doing today. It's amazing that this even worked, we'd be better off if it didn't... They must be using mock, which is available in Ubuntu. They cannot be using mock, otherwise it wouldn't pick up the newer, alien libstdc++ from Ubuntu 12.04. Besides, if they did it would all have magically worked (or not have built at all). Version : 27.0.1453.110 Build Host: lin64build12.chrome.corp.google.com vs Version : 28.0.1500.70 Build Host: precise64build2.chrome.corp.google.com RPM version: 4.9.1.1 So the RPM version pretty much gives away that they do not build on RHEL. And rpm-4.9.1.1 is exactly what ships with Ubuntu Precise Pangolin (aka Ubuntu 12.04). Need more proof ? :-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: SL6 on SSDs?
On Mon, 10 Jun 2013, jdow wrote: Just a little note, Vladimir, please be aware that there appears to be a problem with SSDs when you read the same portion of the disk very many times per day. The section of flash seems to lose data and cannot be refreshed after a couple years. We have customers who use SSDs in theme park rides in the vehicles for an audio server. It was a short, ride length, audio track repeated every run for the ride vehicle - every few minutes for a 12 hour day 365 days per year. We now counsel customers to use features in the program to allow storing many copies of the audio track and rotate their use to avoid this wear problem. This is mentioned so infrequently in the literature that I am not sure it has been generally recognized or dealt with by the disk manufacturers. It surely astounded us when the reports started coming in. Wouldn't the VFS layer make sure the audio track was in cache, avoiding to read from SSD on every request ? Even if the cache pressure (for whatever reason) would flush it from cache, make sure it stays in memory by putting it in a tmpfs filesystem during boot and use that instead ? Seems to me more worthwhile than rotating over different entries in a filesystem on an SSD. Especially since there's no need to keep reading it from SSD... -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Netrwork dropping transmitted packages on fresh SL 6.4 install
On Sun, 5 May 2013, Paul Robert Marino wrote: Elrepo is your problem they often push untested updated drivers. Use the drivers that came with the kernel they may not have all the features but they should work. Do not install kmod-8169. At ELRepo we actually advise people to use the drivers that come with SL/RHEL/CentOS/ if those work fine. But we do provide alternative drivers (usually from the hardware vendor or a more recent kernel) for those people who lack support from their distribution and do need working hardware. So I'd expect anyone turning to ELRepo for drivers to have an issue with the official drivers in one way or the other. But it's true we don't (and cannot) test every driver against the myriad of hardware that it supports, and in those cases people request drivers we do have a staging repository for testing those drivers. On the other hand one would expect drivers from the vendor to be tested by the vendor. Whatever the case, we provide an alternative, we don't force our drivers onto anyone. So if ELRepo is your problem, it must have been self-inflicted :) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
