Re: [SCIENTIFIC-LINUX-USERS] yum-cron problem on 7.x
On Wed, May 04, 2016 at 09:16:35AM -0400, Nico Kadel-Garcia wrote: > On Mon, May 2, 2016 at 12:29 PM, Konstantin Olchanski > >> >> > http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_automatic_system_updates_.28CentOS7.29 (on-list reply) A factually incorrect statement has been made by Nico and with apology to everybody on this list, I feel obligated to post a public rebuke. > > You've also improved the instructions to use standard repos rather > than private repository URL's, that's a good move. Thank you. > No, there were no changes to my instructions since I originally posted the link to this list. The full history of changes is easy to see on the wiki history page: http://www.triumf.info/wiki/DAQwiki/index.php?title=SLinstall=history A suggestion that I posted a link to defective instructions then quietly "improved" them I see as an attack on my professional integrity. I do stand behind my words and behind my product. (no, I do not expect to see a message from Nico about doctoring wiki history databases). P.S. > More checking shows that the "yum-kernel-module" ... > I've no idea why you think it's still needed. Perhaps you could > explain? Yes. Please do some more checking. It is an explicit dependancy to the yum-autoupdate rpm package. Why? Ask the authors, not me, I did not do any of it. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: [SCIENTIFIC-LINUX-USERS] yum-cron problem on 7.x
On Sun, May 01, 2016 at 12:49:01PM -0400, Nico Kadel-Garcia wrote: > >> > Use the much better yum-autoupdate from CERN instead: > >> > http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_automatic_system_updates_.28CentOS7.29 > > The directions and tools are also entirely incompatible with older > versions of Scientific Linux, such as SL 6 or the still supported SL 5. > (on-list reply) I think there is a misunderstanding. The intent of my instructions is to restore in SL7/CentOS7 the functionality that has been always present in SL5 and SL6, where yum-autoupdate was always present and is easy to enable via "chkconfig yum-autuopdate on": SL5: -rw-r--r-- 1 root root 27524 Dec 10 2014 6x/x86_64/os/Packages/yum-autoupdate-2-6.6.noarch.rpm SL6: -rw-r--r-- 1 root root 9111 Oct 8 2012 5x/x86_64/SL/yum-autoupdate-1.2-3.SL.noarch.rpm This package is absent in SL7 and CentOS7, so I have to pull it in from CERN linux CC-7. I agree it would have been cleaner to install the CC-7 yum repository, but that could have accidentally pulled some unwanted CERN packages. (to Nico) If you do not like the yum-autoupdate script, you do not have to use it, but there is no need to dump on the tool or/and on my instructions. > > ... Replacing a live, standard upstream kernel for such a small reason is > always a bad idea. ... > You are mistaken, my instructions do not replace the standard kernel. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: [SCIENTIFIC-LINUX-USERS] yum-cron problem on 7.x
On Sat, Apr 30, 2016 at 10:20:13PM -0400, Nico Kadel-Garcia wrote: > > > > Use the much better yum-autoupdate from CERN instead: > > http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_automatic_system_updates_.28CentOS7.29 > > Sorry, but that thing is a complex nightmare. > Excuse me? Complex nightmare? What? It is just a cron job script that runs "yum update" and emails you the result (with email subject saying the machine name and success/failure status). You can write replacement in 5 minutes. To use it or not is a choice. Nothing wrong with the tool itself. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: firefox 45.1 crashes
On Thu, Apr 28, 2016 at 01:25:00PM -0500, Graham Allan wrote: > After the excitement of seeing firefox 45.1 ESR released for SL, > we're getting a handful of reports of frequent crashing. Ask them if they were visiting any specific web sites at the moment of the crash. Last time we had problems with firefox (or was it google chrome?), the affected/complaining/crashing user was using it to read a reputable mainstream Israeli newspaper. Guess what we told him is the simplest solution to avoid crash? -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: [SCIENTIFIC-LINUX-USERS] yum-cron problem on 7.x
On Tue, Apr 26, 2016 at 12:06:42PM -0500, Pat Riehecky wrote: > On 04/26/2016 11:59 AM, Dan McDaniel wrote: > >Is there any way to get yum-cron to read environment variables? There > >doesn't seem to be anyway in /etc/yum/yum-cron.conf. They seem to expect > >you to edit that file on every single system. > > > >I want to change the email_from setting because getting 100 emails all > >from "root@localhost" is less than helpfull. On 6.x the emails came from > >root@$HOSTNAME, but I can't find any way to make this work on 7.x. > > > >Am I missing something simple? > > > > Alas no you are not missing anything: > https://bugzilla.redhat.com/show_bug.cgi?id=1121189 Use the much better yum-autoupdate from CERN instead: http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_automatic_system_updates_.28CentOS7.29 -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Identical disks, different # sectors
>product: WDC WD1003FBYX-0 >version: 1V02 >serial: WD-WCAW35919858 > >product: WDC WD1003FBYX-0 >version: 1V02 >serial: WD-WCAW33395036 These do appear to be identical disks - same product, same series (sn WD-WCAWxxx), same fireware. (Sometimes very different WDC disks have the same "product" name - but the serial number will have different series, i.e. WD-WCAWxxx vs WD-CAZAxxx). For more information, can you post the full output of "smartctl -a /dev/sdX" for both disks? Also if you have "too many disks" connected to the machine it is possible you printed the information from the wrong two disks. To check against that, post the full output of "smartctl -a /dev/sdX" for *every* disk. K.O. On Tue, Mar 29, 2016 at 07:10:41PM +, Thomas Leavitt wrote: > General Linux question, y'all seem very helpful generally, hope this is o.k. > > I noticed that a disk in an mdadm software RAID10 array had been > automatically removed. I pulled it, popped in a new disk that is the EXACT > same model as several disks already in the system and the array... ran fdisk > on it, created a partition, put a disk label on it, then tried to add it, and > got "not large enough to join array" as an error message. It seems like the > new disk is one sector smaller. Am I just out of luck with this disk, because > the firmware has decided to nuke one sector? Makes buying spares, and having > them on hand, pretty dicey if such is the case. Have two on order at the > moment. > > This is the second time I've been led a merry go round simply trying to > replace a disk in this array, it is seriously souring me on mdadm and > software RAID in general (not that I was a big fan of it anyway). > > Any suggestions? This is part of a dual clustered system, two RAID10 arrays > in a glusterfs, so one missing drive isn't a crisis, but obviously less than > ideal. > > Regards, > Thomas Leavitt > > [root@system1 ~]# fdisk -l /dev/sdb1 > > Disk /dev/sdb1: 1000.2 GB, 1000203837440 bytes > 255 heads, 63 sectors/track, 121601 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x > > [root@system1 ~]# fdisk -l /dev/sdk1 > > Disk /dev/sdk1: 1000.2 GB, 1000202241024 bytes > 255 heads, 63 sectors/track, 121600 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x > > > lshw > description: ATA Disk >product: WDC WD1003FBYX-0 >vendor: Western Digital >physical id: 0.b.0 >bus info: scsi@0:0.11.0 >logical name: /dev/sdb >version: 1V02 >serial: WD-WCAW35919858 >size: 931GiB (1TB) >capacity: 931GiB (1TB) > > description: ATA Disk >product: WDC WD1003FBYX-0 >vendor: Western Digital >physical id: 0.e.0 >bus info: scsi@0:0.14.0 >logical name: /dev/sdk >version: 1V02 >serial: WD-WCAW33395036 >size: 931GiB (1TB) >capacity: 931GiB (1TB) > > [root@sapphire ~]# mdadm --manage /dev/md3 --add /dev/sdk1 > mdadm: /dev/sdk1 not large enough to join array > > -- > Thomas Leavitt (tleav...@eag.com) > Interim Sr. Linux IT Consultant (880 IT Services) > 831-469-3382 (Google Voice forwards to 880 IT cell, accepts SMS) > 1-408-454-4569 (desk) > > > > This e-mail may contain privileged or confidential information. If you are > not the intended recipient: (1) you may not disclose, use, distribute, copy > or rely upon this message or attachment(s); and (2) please notify the sender > by reply e-mail, and then delete this message and its attachment(s). EAG, > Inc. and its affiliates disclaim all liability for any errors, omissions, > corruption or virus in this message or any attachments. > -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
chrony vs ntpd, Re: [SCIENTIFIC-LINUX-USERS] *RESOLVED* "Not using downloaded repomd.xml because it is older than what we have:"
> > I confess that I have no real evidence on performance differences > between NTPD and chronyd... > I do have some evidence. chrony works better: a) ntpd steps the time, some applications do not like that, chrony seems to always adjust time smoothly b) on some special purpose machines ntpd fails to lock and sync the time (at all - probably because of a hardwired limit on maximum permitted time drift), chrony works okey c) debug and diagnostics information from ntpd is impossible to understand, chronyc reports very well who we are locked on, what is the time difference, who's clock is running too fast/too slow, how well we are tracking, etc. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Troubles updating from 7.1 to 7.2...
On Mon, Feb 08, 2016 at 09:27:31AM -0600, S A wrote: > > I posted a while back about conflicts that came up under 7.1 when the kernel > for 7.2 was dropped into the 7.1 security repo. I had issues with VirtualBox > kernel modules and dependencies to packages not backported from 7.2 into 7.1. > Since that time I had avoided doing kernel updates and stayed on > 3.10.0-229.14.1. Now that 7.2 is GA, I've made a couple of attempts to > update and am running into several problems. > Yes, I too find it very inconvinient that the kernel in 7.2 is explicitely binary incompatible with the kernel in 7.1. For example, some ELREPO kernel modules will not load because "they are for 7.1". Do we must have ELREPO-7.1, ELREPO-7.2, etc? With luck this will settle soon enough, but I did not see any explanation for this binary incompatibility, should I think that this is the new way of things - each new release junks all the old driver kernel modules and I must harrass the hardware vendors to issue new drivers? > > Error: libX11 conflicts with libxcb-1.9-5.el7.x86_64 > Error: avahi-glib conflicts with avahi-0.6.31-15.el7.x86_64 > You could try using --skip-broken to work around the problem > ** Found 91 pre-existing rpmdb problem(s), 'yum check' output follows: > PackageKit-glib-1.0.7-5.sl7.x86_64 is a duplicate with > PackageKit-glib-0.8.9-11.sl7.x86_64 > accountsservice-0.6.35-9.el7.x86_64 is a duplicate with > accountsservice-0.6.35-7.el7.x86_64 > .. > > I've successfully removed the avahi package, as I don't need it. Removing > libxcb produces a dependency chain of an additional 412 packages to remove - > basically all of Gnome/X11, so I didn't attempt that. I've attempted > package-cleanup tool to list the dupes and run the cleanup, but this results > with the following: > > --> Finished Dependency Resolution > Error: Trying to remove "yum", which is protected > ** Found 90 pre-existing rpmdb problem(s), 'yum check' output follows: > PackageKit-glib-1.0.7-5.sl7.x86_64 is a duplicate with > PackageKit-glib-0.8.9-11.sl7.x86_64 > > Attempting to cleanup dupes again with --skip-broken does not change the > result. > > Anyone have any advice to cleanup this dupes problem? > I ran into similar problems - after an aborted "yum update" many dup packages. You have to clean them up pretty much by hand (hint: write a perl script). Compared to el6, the el7 yum+rpm had a much harder time recovering from this, for example el7 yum bombed with errors like this: - rpm shows both foo-15 and foo-20 installed - "yum update foo" says "updating foo" "foo-20" will be an update - "sorry, foo-20 is already installed, bomb!". Well, duh! The el7 too "package-cleanup --clean-dupes" just went into an infinite loop trying to remove all of everything. Another fine example of something that kind of worked in el6 works worse in el7. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL6 to SL7 transition guides?
On Sat, Jan 30, 2016 at 07:52:39PM -0800, Keith Lofstrom wrote: > > Is there a transition guide from 4,5,6 distros to 7 distros? > My cheat sheet is here - scroll down past the installer bits to the meat on setting up NIS, NFS, google-chrome, disabling junk services. Only el6 and el7 things shown, for el4 and el5, you will have to go back through the wiki history. https://www.triumf.info/wiki/DAQwiki/index.php/SLinstall -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: forced fsck
On Sat, Jan 16, 2016 at 02:38:23PM -0800, ToddAndMargo wrote: > sl 7.2 (Yipee!) > > How do I force an fsck on next reboot on all > three of the following partitions: > > / > /boot > /home > Boot from installer image into rescue mode and run fsck. Presumably you are doing this because there is trouble, and in case of trouble, regular boot with "forced fsck requested" will just tell you "run fsck by hand" and dump you into single user mode, which is not as nice as the rescue mode in the installer (no VTs, no job control, no network, etc). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: a year later - CERN move to Centos - what are we doing?
On Wed, Jan 13, 2016 at 07:59:43AM -0600, Alec T. Habig wrote: > Konstantin Olchanski writes: > > The installer for both have the same idiotic "you *must* create a fake > > user or no login prompt for you!", > > If you're not making a local user, then you've probably got a network > authentication scheme. > Indeed. We use NIS. Support for NIS was removed in the el7 installer. Rejoyce! > > In which case, you're probably deploying more than one machine. Take a > look at making a kickstart file to automate the install process. In > kickstart, you don't have to make a dummy user, you can just define your > network authentication setup. And much, much more: then use that same > script to install on as many machines as you want. > Indeed. Have been using kickstart installs for years. CD/DVD kickstarts, PXE-network-booted kickstarts, now mostly USB-flash-booted kickstarts. In our environement we cannot do a one-size-fits-all kickstart, so possibility to configure NIS during installation was quite handy. Now it becomes a post-install step - login as root, run authconfig. Actually now, due to this "must create, then delete fake user, which will also use a UID colliding with our historic UID allocation scheme", non-kickstart vanilla installer is pretty much useless. > > > and the same "you *must* use the disk partition tool designed by > > dummies for dummies". > > likewise solved by kickstart. > The kickstart disk partitioning tool is even dumber than they new GUI tool, only useful for "one-size-fits-all" cases where you also do not mind accidentally deleting the contents of all disks. (yes, open the machine, disconnect disks, install, reconnect disks, close the machine, thanks, but no thanks). At least the el7 installer does not overwrite the bootloader of the *installer* disk and seems to correctly install the boot loader for raid1 mirrored slash partitions. P.S. I keep banging about all this stuff because over the last 20 years all I see is each new installer only reluctantly fix a few of the old bugs, but consistently add new "features" which are not improvements. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: a year later - CERN move to Centos - what are we doing?
On Wed, Jan 13, 2016 at 10:51:26AM -0600, Jim Campbell wrote: > > As I understand it, one of the key values of SL is that it allows you to > stay on a point release and obtain only security fixes for your packages > (someone else mentioned this, too). This is important when running > scientific experiments where you can't allow changes in software to > impact your research results. Unless something has changed, neither > CentOS nor the North American Upstream Vendor provide this service. This > feature from Scientific Linux is a valuable one if you need it. > Something strange happened during the move from el6 to el7 - CERN Linux el6 was always automatically self-updating to latest point release, without causing any problems, so I came to like that and now configure SL6 machines to automatically update (using the SL6x repo). Now CERN Linux el7 comes in and I see the machines installed as 7.1 stay there, no automatic update to 7.2. Odd. Then here, I see same with CentOS7 - no automatic updates by default, no automatic updates to latest point release, 7.1 machines stay at 7.1. (I do not have any SL7 to compare) So I am puzzled by all this. Maybe I should ask google: "is centos7 supposed to self update to latest point release?" Then I takes quite a bit of work to get automatic updates to work at all on CentOS7 (CERN el7 seems to be okey): a) The yum.cron package is crazy - each time I need to use yum, I have to wait until it finishes some useless background tasks. Then "yum remove yum.cron" has no effect because all the cron jobs are part of the main yum package. Go figure. b) the CERN yum-autoupdate package, which we use for SL6 updates, depends on a yum plugin not available anywhere (except from a CERN repo) and then actually does not work out of the box because of strange interaction with systemd - only works after a reboot. bb) then it does not send any email about updates - the el6 yum-autoupdate did this, where did this function go?!? (Hmm... maybe I should try these auto update scripts from the SL7 repository?) So as they say, 1 step forward, 2 steps back. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: a year later - CERN move to Centos - what are we doing?
On Tue, Jan 12, 2016 at 09:48:23AM +, lejeczek wrote: > > I personally am just about to trial a migration from SL7 to Centos. > I'm thinking it's inevitable, am I wrong? > I tried both SL7 and CentOS7 (and I have CC7 machines running at CERN). The installer for both have the same idiotic "you *must* create a fake user or no login prompt for you!", and the same "you *must* use the disk partition tool designed by dummies for dummies". So no practical difference at installation. Both installers boot from USB flash, no need to engrave the ISO images into stone tablets (an improvement over SL6). After installation, I do not have to setup a local mirror for CentOS7 repositories - CentOS7 automatically finds and downloads all packages from the very super fast mirror at SFU.ca. This is compared to SL7 which very-very-very-very-very-very slowly slowly slowly downloads all packages from Fermilab. So one difference there. Going forward with CentOS7 to stay aligned with CERN. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
g77 story, Re: g2c library
On Wed, Dec 16, 2015 at 08:13:44PM +0100, Stephan Wiesand wrote:
>
> With the advent of gcc4 ("~ since the dawn of time"), g77 was replaced with
> gfortran and libg2c with libgfortran.
>
Must keep the story straight.
g77 is a proper Fortran compiler that implements Fortran-4, Fortran-77, IBM and
VAX extension, etc.
After the g77 author and maintainer retired, g77 was eventually deleted from
gcc. (as if nobody uses it anymore, go gcc, go!).
Meanwhile some young yahoos who have only seen a VAX on wikipedia wrote a
completely new compiler to the Fortran-90 specifications, now included in gcc
as "gfortran".
As all of you surely know, Fortran-90 has nothing to do with traditional
Fortran and this gfortran newthing
cannot compile most of the fortran code we still use daily. (nor does it
compile the Fortran-90 code
we have in one of our defunct experiments - that code was written using Absoft
and Intel f90 - unlike
gfortran, Absoft and Intel got it right - by including compatibility modes for
traditional fortran).
This is a sorry mess, same as if they deleted the gcc "c" compiler and told
everybody to use "g++" as replacement,
except that Fortran-90 comes without the clause about "incompatibilities
between C and C++ should be reduced as much as possible" - quoting Bjarne
Stroustrup at https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
(again, Bell Labs got it right, unnamed GCC yahoos got it wrong).
--
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SMR drives - has anybody tried?
On Thu, Dec 03, 2015 at 03:32:11PM +, lejeczek wrote: > > I wonder if there is a user/admin who tried SMR drive and could > share his/her thoughts on them? > Did not try and will not try. All published reports indicate that write performance is erratic (and quite reduced compared to conventional storage), making them unsuitable to our main application of recording experiment data in near-real time. These SMR disks are marketed by Seagate as "archive" media, but because they are very new there is no failure statistics, and the failure modes are not well understood (if a spot of disk platter goes bad, do I lose just a few sectors, like on normal disks, or do I lose everything, like on a self-bricked SSD?). So does the reduces cost compensate for the added risk of data loss? You can also read the reviews at newegg and elsewhere. K.O. P.S. FUD check: Fear - check, Uncertainty - check, Deception - hopefully not. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 7.1 not installing from DVD on unpartitioned disk
On Sun, Sep 20, 2015 at 03:54:18PM -0400, Nico Kadel-Garcia wrote: > > Hilarity ensued. I had to explain to several engineers, for both VM's > and for repurposing hardware, that you should really clear the first > blocks of a disk before handing it off to an installer, precisely to > clear this and other kinds of confusion. > First few blocks is not good enough. I had trouble with RHEL/SL installer finding some old md raid signatures or superblocks or something and refusing to use the disk (after asking and answering all the installer question, injury+insult). The installer must have a button for "yes, I want to use this disk, yes, I know it has/had some data, yes, I am know what I am doing, just use this disk already". But people who write installers have no brains. How else you explain multiple disks being presented as "you have 6 disks: wdc, wdc, wdc, wdc, wdc and wdc, you *must* chose the right one to install the bootloader". (some installers helpfully tell you the disk size, so you know which one of the identically listed "6tb wdc disk" to use). Aparently the thinking is that presenting users with disk serial numbers will confuse them (and forger about telling them the physical SATA ports or SATA topology). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: ypbind not registering with rpcbind on SL7
On Tue, Jan 06, 2015 at 11:20:30AM -0700, Stephen John Smoogen wrote: On 6 January 2015 at 05:08, Dirk Hoffmann hoffm...@cppm.in2p3.fr wrote: I installed SL7 yesterday from the standard DVD in Computing node flavour. yum update ran correctly, then I needed YP/NIS. I can confirm that NIS does work (can be made to work) in SL7, but out of the box, it will not work. I do not have all the steps written down yet, but at the least, you have to turn off the firewall. Wow.. I didn't know ypbind was still in use :)? There is no replacement to NIS for small clusters. Vendors send us in the direction of LDAP, which is supposed to be light weight. Well, if LDAP is light-weight, I hate to see what they consider as normal-weight. With NIS, management is vi /etc/auto.home; make -C /var/yp. Wake me up when LDAP gets anywhere near that easy to use. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: 64 bit VME SBC
On Mon, Dec 22, 2014 at 02:56:54PM -0800, Keith Lofstrom wrote: On Mon, Dec 22, 2014 at 01:15:43PM -0800, Konstantin Olchanski wrote: ... Upgrading to new hardware depends on the depth of your pockets of course, but we also see technical problems - some new 2GHz+ 64-bit SBCs overwhelm power supplies originally built to run 0.1GHz motorola 68020 SBCs. ... No low power 64 bit SBCs? This sounds like a market opportunity! Plenty of general purpose SBCs, not so many in VME form factor. Modern deep-submicron processes permit both very fast (Intel i7) and very low power (Atom) processors, the latter preferable when power and cooling is limited. Hmm... would be interesting to see an Atom CPU run VME DAQ at 40-60-100 Mbytes/sec over GigE... I am preparing a Zotac ZBOX small computer with SL7 for my wife's office; 64 bit dual core Atom, 5600 bogomips, two displays, terabyte HD, 8 GB RAM ... all drawing 9 to 14 watts. $220 for ZBOX and addons from newegg. It has a cheap low-speed fan, but I can't hear it running. Noctua.at makes the lowest noise fans. We are developing a CAMAC SBC using an ARM SoM http://www.criticallink.com/product/mitysom-335x/ and a Cyclone4 FPGA. Electronics development cost, FPGA programming cost, software programming cost is considerably higher than $220. We are considering a VME SBC using an ARM+FPGA SoM http://www.criticallink.com/product/mitysom-5csx/ but while really good on power and cooling, these ARM CPUs cannot drive GigE at full GigE speed (memory is too slow). I don't know if an FPGA can drive a VME backplane, but those have evolved towards lower power per gate-MHz, too. With all those extra gates, and live reconfiguration, a VME board could have BIST (built in self test) capabilities for on-line failure detection and debug. Most VME SBCs drive the VME bus using UniverseII and tsi148 PCI (*not* PCIe) to VME bridges, but it looks like some vendors are moving to FPGA solutions. I have seen at least one product announcement like this. If there is sufficient demand for a quiet low-power VME SBC replacement, I know consultants who can design one. Bringing this back on topic, if it can be further optimized by kernel modules, I can think of a distro that could support them... The demand is not very high, and a good part of the demand is for milspec hardware that has has extended temperature range, conductive cooling and tested for vibration tolerance. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Longest LTS - still SL/RHEL?
On Mon, Dec 22, 2014 at 09:20:28AM -0600, Robert Blair wrote: Some experiments (ATLAS as a for instance) have decided to simply upgrade their SBCs to 64 bit capable rather than suffer through the various problems associated with trying to hang on to the old hardware. We saw issues beyond just 32 bit vs. 64 bit. The older systems were many generations back in terms of capability which caused numerous hard to diagnose problems. In our case the pentium4 default broke some code since the SBCs we had were pentium3 only. Most things worked but a few applications simply crashed. The cost of upgrading was lower than the human cost of finding and fixing this sort of thing. Ahem, we see no special problems with running SL6.6 on Pentium3 (1GHz, SDR RAM) and 32-bit Athlon (DDR1 RAM) machines, even with low ram (0.5GB typical). Most problems we do see are rooted in the old laptop chipsets used by these SBCs that were never properly documented by Intel and properly supported by Linux. But of course we do not run any full-featured applications (firefox, etc). Upgrading to new hardware depends on the depth of your pockets of course, but we also see technical problems - some new 2GHz+ 64-bit SBCs overwhelm power supplies originally built to run 0.1GHz motorola 68020 SBCs. Also they are much more sensitive to good air flow for cooling. Also we see a very high failure rate of our chosen 64-bit VME SBC (vendor unnamed, suspect faulty PCBs or bad BGA soldering). K.O. On 12/18/2014 02:59 PM, Ian Murray wrote: On 18/12/14 20:16, Konstantin Olchanski wrote: On Mon, Dec 15, 2014 at 04:51:19PM -0800, Keith Lofstrom wrote: Again - the reason for 32 bit is not that I cherish old CPUs ... And that is why I ask here; if anybody runs old machines for compatibility reasons, it would be experimental scientists ... On target you are. Us experimental scientists have embedded computers (VME form factor) with 32-bit CPUs and 0.5GB/1GB RAM. We run 32-bit SL4, SL5 and SL6 on them today and I expect we will still be using these machines when SL6 becomes obsolete in 1-2-3 years. By then, I fully expect a 32-bit port of SL7/CentOS7 to become available, somehow. Some talk of it here, with people having a first pass at it:- http://www.karan.org/blog/2013/12/15/where-is-the-i686-in-rhel-7/ But for today, I have not even digested the 64-bit SL7 yet, 32-bit SL7 is not even on the wish list yet. Now, the ARM SL7 is a different matter. *that* I want yesterday. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUmDa7AAoJEPQM1KNWz8QalnEIAMaCjtomFbU/xDLyhCtIzKWb F48m7wjIS7QHJgmBarj40Oz7jCS6XIJz5VtXD2hh4WwwZsgnvLZvx5fy3bCKZ8xC /36MXaXCHeNBVr1KtgZDAedYpWVoJgn21t3yWlQnEjxiPqBFZogJRAU/ISrscXwJ vWCX7E1u8vwNUmBjUkYedNrWqcFUYDtFDIwkKXTqL4H4TZkBce4pDbpkYc607kIx h8G5EGBgDGc8MatkWrcCz2ISZI939USlzc0YLjDDfYIMN1zYaRwSS9zlpfmueG+/ eQifhTtJ2bHB6tG3LKxrPTx5t8pZJDSTmtcYtjzHCkEJuTDSpxulopj9jaaXyM8= =Es3t -END PGP SIGNATURE- begin:vcard org:Argonne National Lab.;HEP adr:9700 S. Cass Avenue;;Room F-213, Bldg. 360;Argonne;IL;60439;USA title:Physicist note;quoted-printable:Personal PGP key available at https://www.hep.anl.gov/reb/key.asc=0D=0A= DOE certificate available at https://www.hep.anl.gov/reb/certificate.asc url:http://www.hep.anl.gov version:2.1 end:vcard -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Longest LTS - still SL/RHEL?
On Mon, Dec 15, 2014 at 04:51:19PM -0800, Keith Lofstrom wrote: Again - the reason for 32 bit is not that I cherish old CPUs ... And that is why I ask here; if anybody runs old machines for compatibility reasons, it would be experimental scientists ... On target you are. Us experimental scientists have embedded computers (VME form factor) with 32-bit CPUs and 0.5GB/1GB RAM. We run 32-bit SL4, SL5 and SL6 on them today and I expect we will still be using these machines when SL6 becomes obsolete in 1-2-3 years. By then, I fully expect a 32-bit port of SL7/CentOS7 to become available, somehow. But for today, I have not even digested the 64-bit SL7 yet, 32-bit SL7 is not even on the wish list yet. Now, the ARM SL7 is a different matter. *that* I want yesterday. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL: not a good choice as a workstation
On Fri, Nov 07, 2014 at 03:35:51PM -0800, ToddAndMargo wrote: I think that SL 6.x was usable as a workstation, even though it has its legs somewhat broken. But SL 7 is now really only useful as a server. I do not see how this follows. You do not show any example where SL7 is worse than SL6, i.e. package not available in SL7, or SL7 package is older than SL6, etc. If you compare with Fedora, you should include the small print spelling out * Fedora has to be reinstalled every 6 months and ** each new Fedora comes with new features even if you do not want them. If you compare with Ubuntu, you should mention that learning Debian system management tools is required. yum, rpm not available, etc If you talk about firefox, my SL7 test machine has firefox-31.2.0-3.el7_0.x86_64 (vs firefox-31.2.0-3.el6_6.x86_64 on SL6, the same version). It looks to me like yum updates of your SL7 machine are broken and you are not seeing or getting any updated packages. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Scientific Linux 6.6 RC 2 i386/x86_64
On Thu, Nov 06, 2014 at 11:03:24AM -0600, Pat Riehecky wrote: Scientific Linux 6.6 RC 2 i386/x86_64 Nov 6, 2013 If no major bugs are reported by Nov 12 this Release Candidate will be released as Scientific Linux 6.6. I am confused. How much of SL6.6 was just pushed as security/fastbugs updates to SL6.5? All of it? K.O. Send comments/issues/test reports to scientific-linux-de...@fnal.gov during our pre-release period. DOWNLOAD INFO Network Install Images: http://ftp.scientificlinux.org/linux/scientific/6.6/i386/images/boot.iso http://ftp.scientificlinux.org/linux/scientific/6.6/x86_64/images/boot.iso DVD Install Images: http://ftp.scientificlinux.org/linux/scientific/6.6/i386/iso/ http://ftp.scientificlinux.org/linux/scientific/6.6/x86_64/iso/ Major Differences from SL6.5 OpenAFS OpenAFS has been updated to version 1.6.10 from openafs.org xorg-x11-server Features a new ABI, this was a security errata so it should be available to earlier releases. POSSIBLE UPGRADE PROBLEMS Users of proprietary drivers may experience issues with the X server loading due to changes between Xorg 1.13 and Xorg 1.15. Users of the 32bit iscsi utilities on x86_64 systems may experience multilib complaints. The 32bit iscsi utilities are not provided by upstream on x86_64 platforms. We have removed them from 6.6 to follow their behavior. -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL6 incompatible update of X11
On Wed, Nov 05, 2014 at 10:51:14PM -0500, Nico Kadel-Garcia wrote: On Wed, Nov 5, 2014 at 6:36 PM, Konstantin Olchanski olcha...@triumf.ca wrote: A few days ago an updated linux kernel and updated xorg packages were pushed into the SL6 updates. These updates are automatically installed by the default yum configuration of SL6.5. Unfortunately these updates are incompatible with pre-installed X11 video drivers for NVIDIA (GeForce 210) and AMD/ATI (AMD E-350/E-450 and socket AM1 on-board video) from ELREPO. Then you really need to talk to ELREPO, not Scientific Linux which is doing rebuilds from RHEL which are aimed at production servers. Support of non-frreware and non-opensource drivers for NVidia. Yes, the usual pass-the-buck game. SL point the finger at ELREPO, ELREPO point the finger at Red Hat. But my finger is firmly pointed at people who push rpms into my computers. There is also people who think (and even say) that it is good to maximize the pain for people who choose to use vendor-supported drivers instead of free drivers. None of *those* people are on this list, though. (but you know where they hang out). If what you need is the latest graphics drives, you need to hop to SL 7 or consider a non-server-based OS. For experiment data acquisition stations, we have the user sit in front of the same computer as we use to handle the data. We could provide a second Ubuntu computer just for the user to sit in front of. (and we have done this in several places). This will double the coomputer purchase budget, double the repair budget, double the number of outage (2 computers to break instead of 1), double the system administraction costs. So all computers with these video cards promptly broke. This seems unlikely. I can easily believe that sophisticated graphics drivers broke, but services such as SSH, httpd, and NFS are probably rock stable even with ELREPO enabled. The user has to see the data. Instead, the user sees the black screen, my phone rings. Me wake up in the middle of the night. Me unhappy. User unhappy. Continue? This incompatibility seems to be well known to the perpetrators (X.org API change, leading to crash of Xorg). That gets difficult. Nothing difficult. Today, there is NVIDIA, ATI/AMD and Intel. Grand total of 3 driver packages to keep track of. Does not sound so hard. Perhaps compatible hardware-vendor-supported graphics drivers should be distributed by SL, just to get ELREPO out of the picture. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL6 incompatible update of X11
On Thu, Nov 06, 2014 at 04:01:07PM +0100, Stephan Wiesand wrote: To add more fun, the -504 kernel ABI has changes in some agp... interfaces. Affects at least the nvidia-304 legacy driver. The 304xx packages ElRepo has now seem to be compatible with the -504 kernel, and thus are probably incompatible with earlier ones... Yes, saw that, too. That was the outage two weeks ago. Users call we get a black screen, we need this computer to monitor vacuum. So I look, and indeed X11 dies from NULL pointer. Google the error messages shows that there is a new 304xxx package. But cannot install - it requires the -504 kernel that was not released until a week later. The 310xxx driver installed fine, though. Luckily I only had just the one computer with such old drivers. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
SL6 incompatible update of X11
A few days ago an updated linux kernel and updated xorg packages were pushed into the SL6 updates. These updates are automatically installed by the default yum configuration of SL6.5. Unfortunately these updates are incompatible with pre-installed X11 video drivers for NVIDIA (GeForce 210) and AMD/ATI (AMD E-350/E-450 and socket AM1 on-board video) from ELREPO. These are the ELREPO kmod-fglrx and kmod-nvidia packages. So all computers with these video cards promptly broke. This incompatibility seems to be well known to the perpetrators (X.org API change, leading to crash of Xorg). I think such a disruptive update should have been announced a little bit more widely and maybe some technical solution could have been implemented to avoid breaking X11 outright (i.e. refuse to install new X.org packages if known-incompatible NVIDIA or AMD/ATI drivers are loaded). It looks like corrected drivers are available from ELREPO, but automatic updates from ELREPO are normally disabled because they break themselves (newly installed package fails to reload the old kernel module resulting in Xorg not starting because of mismatch between newly installed userland drivers and old kernel module). As end result, what could have been planned scheduled maintenance is now an emergency patch Wednesday with many computers requiring reboot and many end users disturbed. I have to fix about 6 computers with AMD/ATI drivers and only (what?) 20 computers with NVIDIA drivers. Please have a nice day. P.S. To add injury to insult, the super advanced Red Hat kernel module management system (dracut) does the super slow (bzip2 -9) rebuilt of initramfs not once, but twice - once on install of new driver and second time on removal of old driver. What should have taken 5 seconds takes a good 2-3 minutes (/usr/bin/time yum update kmod-nvidia). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: bash bugs - alternative shell
On Thu, Oct 02, 2014 at 04:33:17PM +, Howard, Chris wrote: I'm wondering if the quickest fix for all of the bash bug stuff coming out now is to replace bash with a different shell. For instance, I see that I have /bin/ksh, why not just link that to /bin/bash and ride out the storm? Is that an alternative? Is there any large subsystem that relies on a bash specific feature? For interactive use, most people switched from /bin/sh to /bin/tcsh back in the mid-1990-ies. (Bash, ksh, zsh came out much later). For scripting, all shells have bizarre syntax, if your script has if statements or loops, you are better off doing it in perl (or in perl's alternative of the day). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: bash bugs - alternative shell
On Thu, Oct 02, 2014 at 05:39:36PM -0400, Brett Viren wrote: Konstantin Olchanski olcha...@triumf.ca writes: For interactive use, most people switched from /bin/sh to /bin/tcsh back in the mid-1990-ies. (Bash, ksh, zsh came out much later). Just because I was curious, first releases as claimed on Wikipedia: Sh: 1977 Csh: 1978 Tcsh: 1981 (file-completion feature merge with csh) Ksh: 1983 Bash: 1989 Zsh: 1990 Fish: 2005 Well, if it's on wikipedia then it must be so. But go 1 step beyound wikipedia, and it appears as if there was no tcsh before tcsh 6.0 in 1991 and there was no bash before 1996 (bash-1.14) and 1997 (bash-2.x). Now go 2 steps beyound wikipedia and you discover that tcsh before 6.0 was distributed as patches against csh from 4.3BSD, i.e. see http://www.linuxmisc.com/12-unix-shell/737b0adda5a7f163.htm To remember, BSD sources were not publicly available until the famous USL Lawsuit and settlement and the release of 4.4BSD as free software in 1994. All this is more in line with my memory of tcsh coming into use in mid-1990-ies. I am sure bash had a much more boring history. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: transitional systemctl script for SL 5, 6
On Fri, Aug 22, 2014 at 04:31:42PM -0700, Denice wrote: http://grid.triumf.ca/share/ Hi, can you post the scripts themlseves as a tarball without all this rpm packaging stuff? -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: dual layer iso
On Tue, Sep 02, 2014 at 12:23:38PM -0700, ToddAndMargo wrote: I noticed http://ftp1.scientificlinux.org/linux/scientific/7rolling/x86_64/iso/SL-7-x86_64-Everything-Dual-Layer-DVD.iso And no more disk 1 and disk 2. Will there be no more two DVD ISO's? Finally, distribution of SL on punch cards is discontinued. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: How do you speed up rsync?
On Mon, Jul 14, 2014 at 04:33:03PM -0500, Kevin K wrote: I guess I don't understand the part about how files can be different sizes on different filesystems. They can obviously use up more or less disk space on different filesystems. For instance, a FAT disk with 32KB clusters will use up a minimum of 32KB even for a 10 byte file. While NTFS will probably put the 10 bytes in the directory entry or use up a maximum of 4KB for 4KB clusters. But I don't see why rsync would care about the unused data. It should just sync the 10 bytes accessible. I'm ignoring alternate streams here. This is the usual confusion between the st_size and st_blocks entries in struct stat returned by lstat() and co. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: How do you speed up rsync?
On Mon, Jul 14, 2014 at 04:51:03PM -0500, Kevin K wrote: On Jul 14, 2014, at 4:37 PM, Konstantin Olchanski olcha...@triumf.ca wrote: On Mon, Jul 14, 2014 at 04:33:03PM -0500, Kevin K wrote: I guess I don't understand the part about how files can be different sizes on different filesystems. They can obviously use up more or less disk space on different filesystems. For instance, a FAT disk with 32KB clusters will use up a minimum of 32KB even for a 10 byte file. While NTFS will probably put the 10 bytes in the directory entry or use up a maximum of 4KB for 4KB clusters. But I don't see why rsync would care about the unused data. It should just sync the 10 bytes accessible. I'm ignoring alternate streams here. This is the usual confusion between the st_size and st_blocks entries in struct stat returned by lstat() and co. Is what I was missing is complexities in files that, for example, may be sparse? I was thinking of the case that, when you do a ls -l, you normally get a byte size value. Depending on your options, you can also get block size, which du would also return. So, if I'm not going off the deep end, a quick determination of whether a file is different probably has to check both values. Since it may show 100 bytes, but if sparse most of the file may be nulls and therefore no on disk storage allocated to it. If that changes, on even the same filesystem, something may have changed and data may have to be synced. And with different cluster sizes, the normal case will be blocks used will be different. No, this will not work. You cannot rely on the st_blocks to compare file contents. For example, some filesystems implement tail packing, where contents of multiple files is packed into a single block. (I think ReiserFS was the first to do this and I have no idea what it returned as st_blocks for tail-packed files). Anyhow, for tail-packing, different versions of the same filesystems may use different heuristics on when files are packed or not and how and depending on what. Not deterministic and not reliable. Kind of like checking if this is the same person by counting the coins in their pockets. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: How do you speed up rsync?
On Fri, Jul 11, 2014 at 04:02:09PM -0400, Andrew Z wrote: ... synchronizing a flashing drive (target) with my hard drive (source) ... Problem: it is slow -- takes three hours. To help the speed issue, I upgraded from USB 2 to USB 3. Backup went from 3 hr-15 min to 3 hr-5 min. It is almost faster to wipe the stick and rewrite it. The main question is this: what is the actual write speed of your USB flash media? How about the re-write speed? (not the same, obviously - as it requires as erase step). I ask because I use USB flash media as boot and linux system disks on embedded machines (VME SBCs) and I have looked at different USB flash media. Most of them are very slow, actually it is very hard to find fast USB flash media. The common media you get for $10 at Staples is read 30M/s, write 10M/s (regardless of USB2 or USB3 interface). This is probably consistent with the speeds that you see. With some work, you can find media that writes at 20-30M/s, as measured by timing dd, but drops severely when you time rsync (must be inefficient at writing small files). So when you select a brand USB flash drive for your workload, as you run rsync, watch the output of vmstat 1 (the bo column is Mbytes/sec written to disk) and the output of iostat -x 1 - you will see %util pegged at 100% and svctm (in msec) running in 1-10-20 seconds for slow media, a little bit smaller for betyter media. For HDDs and SSDs, the svctm is in low milliseconds. svctm is the request service time - time from sending a request to the drive and getting the reply from the drive that the request is finished. Some USB drives advertize high write speeds (not up to but actual will write at promises), you can try those ($$$), but you will probably find that the speed of rsync does not reach the promised rates because of inefficiency of flashing small files. P.S. Another problem with USB flash drives - all brands except for 1 or 2 do not survive being used as linux system disks - they brick themselves within days or weeks. I notice that they tend to run quite hot, so I suspect they simply overheat and die. Actually, I did not find a single USB3 flash drive that survives use as linux system disk yet. By luck I have enough Patriot RageXT 8GB and 16GB USB2 flash media, these seem to last. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: How do you speed up rsync?
On Fri, Jul 11, 2014 at 06:52:07PM -0700, ToddAndMargo wrote: On 07/11/2014 06:12 PM, Konstantin Olchanski wrote: On Fri, Jul 11, 2014 at 04:02:09PM -0400, Andrew Z wrote: ... synchronizing a flashing drive (target) with my hard drive (source) ... Problem: it is slow -- takes three hours. To help the speed issue, I upgraded from USB 2 to USB 3. Backup went from 3 hr-15 min to 3 hr-5 min. It is almost faster to wipe the stick and rewrite it. The main question is this: what is the actual write speed of your USB flash media? How about the re-write speed? (not the same, obviously - as it requires as erase step). Kanguru SS3: Read 105 MB/sec; 78 MB/sec Right, this is almost SSD quality flash, but for some reason, performance for writing small files is much worse compared to SSDs. One would think that one could make a USB flash disk with same performance as SATA flash (SSD), but perhaps nobody makes the right flash controller chip and a dual chip solution is not workable (an SSD flash controller behind a USB-to-SATA interface). More likely, though, is that the USB form factor, power budget and cooling capacity does not permit implentation of full-performance flash disks. One would think that USB3 can provide enough juice, but maybe there are still problems with cooling and maybe they do not want to make a device that would not work in a USB2 slot... K.O. Don't have the re-write speed. I ask because I use USB flash media as boot and linux system disks on embedded machines (VME SBCs) and I have looked at different USB flash media. Most of them are very slow, actually it is very hard to find fast USB flash media. The cheap ones crawl. If you spend a little: El-Cheap-O: Read: 3 MB/sec Write: 2 MB/sec Kanguru SS3: Read: 105 MB/sec Write: 78 MB/sec Kanguru Flash Blu 30: Read: 145 MB/sec Write: 8GB: 25 MB/sec 16,32,64GB: 45 MB/sec Kingston Data Travler: Read: 70 MB/sec Write: 30 MB/sec Kingston Data Travler Hyper-X 3.0: Read: 225 MB/sec Write: 135 MB/sec For comparison: IntelSSD 530 Series SATA 3 flash drives: Sequential Read: 540 MB/s Sequential Write: 490 MB/s The common media you get for $10 at Staples is read 30M/s, write 10M/s (regardless of USB2 or USB3 interface). Worse than that! This is probably consistent with the speeds that you see. I went from 20 MB/sec to 78 MB/sec. Took 10 minutes off of three hours. With some work, you can find media that writes at 20-30M/s, as measured by timing dd, but drops severely when you time rsync (must be inefficient at writing small files). So when you select a brand USB flash drive for your workload, as you run rsync, watch the output of vmstat 1 (the bo column is Mbytes/sec written to disk) and the output of iostat -x 1 - you will see %util pegged at 100% and svctm (in msec) running in 1-10-20 seconds for slow media, a little bit smaller for betyter media. For HDDs and SSDs, the svctm is in low milliseconds. svctm is the request service time - time from sending a request to the drive and getting the reply from the drive that the request is finished. Some USB drives advertize high write speeds (not up to but actual will write at promises), you can try those ($$$), but you will probably find that the speed of rsync does not reach the promised rates because of inefficiency of flashing small files. sda is the source hard drive; sdc is the target flash drive $ iostat -x 1 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.00 28.000.00 7168.00 0.00 256.00 0.082.79 1.39 3.90 sdc 0.00 0.000.00 280.00 0.00 7406.00 26.45 1.344.74 3.25 90.90 Couldn't find svctm. Does the above tell you anything? P.S. Another problem with USB flash drives - all brands except for 1 or 2 do not survive being used as linux system disks - they brick themselves within days or weeks. I notice that they tend to run quite hot, so I suspect they simply overheat and die. Actually, I did not find a single USB3 flash drive that survives use as linux system disk yet. By luck I have enough Patriot RageXT 8GB and 16GB USB2 flash media, these seem to last. There is a lot of trash out there. I refuse to sell Buffalo, as have had almost 100% returns on them. -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~ -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Scientific Linux 7 -- no more IA-32 ?
Hi, Russ - thank you for pointing to the redsleeve package - I did not know about it - and when I was looking for such last Summer, it did not turn up - I ended up using Fedora 20 for my test system, but prefer EL based for final production. But with the redsleeve web currently down (Error establishing a database connection), do you know if they provide a preinstalled rootfs image? One that is easy to network-boot (via NFS-Root). My ARM hardware cannot run any installer (requires a custom linux kernel, low on RAM and not too speedy). Fedora 20 provides rootfs images and was easy to network boot (NFS-Root). And for development, network boot is so much faster and easier compared to writing and rewriting the very slow SD flash cards, plus having to move the flash card from crashed arm to PC and back. K.O. On Thu, Jul 10, 2014 at 11:40:48AM -0400, R P Herrold wrote: On Thu, 10 Jul 2014, Lamar Owen wrote: I'd like to see ARM as well, but IA-32 is lower-hanging fruit, since many of the packages are already built and the same hardware can build it as builds x86_64. As smooge said, the ARM port needs builders (and by that I assume he means the hardware on which to build, or a cross-compiler devchain that works for mock building). [I understand the RH history and desire for 'builds for record' to be on 'real' hardware. I can advocate until I am blue in the face as well as the rest of you that the compiler is just moving ((optionally ascii, altho' ebcdic also works in Z arch ... )) 8-bit text string tokens aroung and emitting new bit patterns, BUT, there is less room for excuses / blind paths for binary partition debugging when one is 'going native'] The round one 'starter yeast' for the clefos s390 / s390x RHEL 6 sources rebuild ['Azure Duck'] was build entirely under a stable of x86_64 under Hercules -- not pretty, nor fast, but not all that bad either. Later rounds moved through native re-compiles to remove and doubt as to self-hosting, or objection as not 'built on native' As I recall, there is a qemu arm VM that runs under libvirt out there. No reason not to start there I and others have a wide stable of 32 bit arm hardware, and saw a 64 bit devkit board announcement by ARM earlier this week; and there is the overdue AMD offering to the same effect which I am waiting to see in the market; after the Blacksburg fudcon, I also 'infected' jbj with an interest in such and he too has a build farm. Most compelling of course is Gordon Bobic's 'redsleve' rebuild of the RHEL 6 sources under arm 32 It really seems more having a trusted central binary [and sources] archive and a mechanism for a federation of mutually trusted builders to do retrieval, build, and return of binary fruit, is the issue Suporting as low as one person in such a federation is of course possible, but then the tragedy of the commons costs, vs benefits returned, rears its head I personally implicitly trust each enumerated person in the CC list as we have been working together since 'testers-list days' save Gordan --- perhaps we just need to tactically solve the management of ad hoc federations, and the minimal glue for diing the 'distributed' -- the latter really a solved problem already with buildbot C and C Thoughts? My 0.02 -- Russ herrold -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 7 alpha -- off-topic: test build of proprietary AMD graphics driver
On Thu, Jul 10, 2014 at 12:23:39PM -0700, Boryeu Mao wrote: I have tested, successfully, the installation of SL 7 alpha DVD to a harddisk image via qemu (under SL 6.5 x86_64 on an HP Pavilion g6 laptop). To test the build of AMD proprietary graphics driver however requires the detection of the gpu hardware, hence the installation onto a physical hard disk, which is something I prefer not to do until later. For this purpose, one approach is to build a bootable iso out of the virtual harddisk image from qemu - some info on this could be found in the ubuntu community but so far nothing (that I could find) for rhel systems - is this doable? Perhaps there may be other approaches for testing the build without the installation to the hard disk. If you have a running system (inside a VM, whatever), you can install it to a physical media (HDD, SSD, USB flash) using cd /; rsync -avx . /mnt/destination_disk. (some people frown upon cloning running systems, but I have been doing it for years without any problems). Before rsync, you need to fdisk and mkfs your destination media, after rsync, you need to grub it and adjust the UUID values in grub.conf and etc/fstab. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Scientific Linux 7 -- no more IA-32 ?
On Wed, Jul 09, 2014 at 04:16:46PM -0400, Lamar Owen wrote: On 07/08/2014 12:07 PM, Yasha Karant wrote: As a full IA-32 environment will no longer readily be available as an off-the-shelf EL distribution (that is, the kernel is 64 bit, etc.), a practical question: FWIW, since the CentOS group is planning an IA-32 release, ... I personally wish they spend the time on the ARM release instead... -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Scientific Linux 7 ALPHA rc.local doesn't work
On Tue, Jul 08, 2014 at 05:07:31PM +0300, Semi wrote: Scientific Linux 7 ALPHA rc.local doesn't work. Any solution? I tried the following: chmod 755 /etc/rc.d/rc.local ln -s /lib/systemd/system/rc-local.service /etc/systemd/system/multi-user.target.wants/rc-local.service systemctl enable rc-local.service I happen to know that rc.local works in Fedora 20 by following the advertised systemd instructions. I assume SL7 would be the same, baring bugs and severe misconfigurations. I would suggest you debug the rc.local service following the systemd troubleshooting instructions from systemd documentation - I find the systemd documentation quite coherent, easy to understand and well written. Also systemd seems to work as documented, so far. Unfortunately my Fedora 20 ARM machine is in pieces in the electronics shop so I cannot post the exact systemd configuration I have there. (Waiting for ARM RHEL/CentOS/??? 7) -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Scientific Linux 7 ALPHA
On Mon, Jul 07, 2014 at 03:29:45PM -0500, Connie Sieh wrote: On Mon, 7 Jul 2014, Arturo Fatturi wrote: Hi. The iso in http://ftp.scientificlinux.org/linux/scientific/7rolling/x86_64/iso/ This is 6.2 Gb, is this right? Yes. To burn to a DVD you will need a Dual Layer DVD . What is this talk about burning DVDs? The year is 2014 and we do not even have any DVD players on most computers. USB installer or bust! -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Scientific Linux 7 ALPHA
On Mon, Jul 07, 2014 at 04:52:22PM -0500, Connie Sieh wrote: The iso in http://ftp.scientificlinux.org/linux/scientific/7rolling/x86_64/iso/ Yes. To burn to a DVD you will need a Dual Layer DVD . USB installer or bust! Go for it. Just checked, the CentOS 7 ISO image explictely supports dd to USB flash. This is as opposed to the SL6.5 ISO images where dd to USB flash are not bootable. (SLC 6.5 (CERN) iso image dd to USB flash is also bootable). I am only partially aware of severe magic required to make bootable USB flash devices (spent 2 days last week making an SL 6.5 USB flash bootable - grub1 - error 18, extlinux - boot error and cannot load ldlinux.c32, depending on which extlinux, grub2 finally booted, but no SL6.5 grub2 RPMs, had to cross-build it myself), but if SLC, CentOS and Ubuntu can do it, no excuse for not having it in SL. P.S. But I have no idea how this integrates with using a site-specific kickstart file, the best I can tell, the ISO image is read-only and it is impossible to put my kickstart file inside it, so I still have to do what I do with my USB installer if I want to run kickstart installs from USB. P.P.S. But maybe this does not matter as I do many installs by cloning. (saves time on all the post-install customizations). P.P.P.S. But cloning does not run the RH installer (anaconda) which proved an eccelent hardware test - machines that crash, hang and fail during installation tend to be faulty and also fail in normal use, machines that can boot and run the installer from start to finish tend to be stable in normal use. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: In Place install of SL 6.5 over Centos 6.5 ?
On Wed, Jun 25, 2014 at 11:15:13AM -0500, James Fait wrote: I recently received a new server system that has Centos 6.5 installed on it. I would like to change that to a Scientific Linux 6.5 system without having to do a full reinstall, as this has no external media access except for the network. If your computer has a USB port (and can boot from USB), you can use my USB installer to do a vanilla or kickstart install SL6.5: http://trshare.triumf.ca/~olchansk/linux/SL65-64-USBBOOT/AAA-README-USBBOOT.txt (download tarball is two levels up). If you have infrastructure for network booting (dhcp+tftp+pxelinux), it is trivial to network-boot the SL6 installer and install over the network. (I find the speed of USB install and network install to be about the same). I personally recommend a reinstall to: a) avoid creating a mongrel system maybe hard to maintain long term, b) removes all doubt about who knows what was running on the computer before you got it and generally gives you a clean slate to work with. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
bad qt fastbugs
Just got bitten by a bug in the fastbugs qt update reported back in February. Basic problem is crash of KDE plasma desktop. http://bugs.centos.org/view.php?id=7012 http://listserv.fnal.gov/scripts/wa.exe?A2=ind1402L=scientific-linux-develT=0P=1742 https://bugzilla.redhat.com/show_bug.cgi?id=1070371 (secret bug report) Solution is to: yum downgrade qt qt-devel qt-mysql qt-sqlite qt-x11 This of course will be undone by the nightly yum update script. So, I hereby request the bad Qt packages be removed from the SL fastbugs repository. Please, please, please? -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: libotf not installed by SL6.5 installer?
On Fri, Mar 21, 2014 at 09:16:25PM -0700, Konstantin Olchanski wrote: I see an odd problem with installing SL 6.5. (I use my USB installer, see my other message about it). The installation works okey, boots into linux okey, login to root okey, but emacs does not work because libotf is not installed. This is very strange because libotf is listed as a dependancy for the emacs package. yum install libotf fixes emacs. Does anybody else see this? Thank you for confirming my problem. My solution is to explicitely require installation of libotf in the kickstart file. My SL6.5 USB installer tarball is being updated now - http://trshare.triumf.ca/~olchansk/linux/ Now if only I could figure out how to prevent the SL6 installer from writing the GRUB boot loader into the source USB-installer disk instead of the destination system disk... -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
libotf not installed by SL6.5 installer?
I see an odd problem with installing SL 6.5. (I use my USB installer, see my other message about it). The installation works okey, boots into linux okey, login to root okey, but emacs does not work because libotf is not installed. This is very strange because libotf is listed as a dependancy for the emacs package. yum install libotf fixes emacs. Does anybody else see this? -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Bootable USB installer for SL6.5
Hello, there - I updated my USB installer images to SL6.5 (64-bit only, sorry). Download the stuff from here: http://trshare.triumf.ca/~olchansk/linux/ Instructions are here: http://trshare.triumf.ca/~olchansk/linux/SL65-64-USBBOOT/AAA-README-USBBOOT.txt Major changes: - updated to SL6.5 (duh!) - includes an example kickstart file, customize it as you wish - includes all recent versions of memtest86 and memtest86+ (if you figure out how to boot memtest86-5.0.0, please drop me a note) The problem of installer writing the final GRUB to the installer source USB stick instead of to the target disk is still present, you have to catch it and change the drive order on the boot loader install page. (There is one caveat with running the installer from writable media - the SL6.3 installer sometimes writes the GRUB boot loader on the USB installer disk instead of the installation target disks - producing an unbootable system and ruining the USB installer disk at the same time. I have not seen the SL6.1 installer do this. Maybe one should use write-protect capable USB flash media). Previous announcement with discussion is below: K.O. On Thu, Apr 11, 2013 at 11:33:46AM -0700, Konstantin Olchanski wrote: For reasons unknown, RHEL and SL insist on publishing installer images that work only from the DVD physical media. But none of the computers I buy today have DVD drives and I am not sure if Staples carry DVD blanks anymore. I guess I must be happy that SL install images do not come on floppies, punch cards or paper tape. Generally, this does not inconvinience me too much - I do most installs over the network (PXE boot). But sometimes I have machines generally not connected to the Internet (on a private network or out in the woods), so I have constructed bootable USB images for SL6.1 and 6.3. (6.4 on the way). (This installer tree is a copy of the .../x86_64/os tree minus the Packages directory, plus the isolinux/extlinux stuff and the DVD .iso files. The SL installer refuses to install from the Packages directory) (There is one caveat with running the installer from writable media - the SL6.3 installer sometimes writes the GRUB boot loader on the USB installer disk instead of the installation target disks - producing an unbootable system and ruining the USB installer disk at the same time. I have not seen the SL6.1 installer do this. Maybe one should use write-protect capable USB flash media). Download the stuff from here: http://trshare.triumf.ca/~olchansk/linux/ Instructions are here: http://trshare.triumf.ca/~olchansk/linux/SL63-64-USBBOOT/AAA-README-USBBOOT.txt Instructions for making USB-Bootable installation disk for 64bit SL6.3 -- 0. These instructions are intended for making a 64-bit SL6.3 installer on a USB Flash disk. 8GB flash media is recommended. 1. The ISO DVD images are NOT included. Download your own copies, before following these instructions. 2. Prepare the USB disk: a) su - b) fdisk -H224 -S56 /dev/sdX, make one partition of type 83-Linux, mark it bootable. Result should look like this: root# fdisk -l /dev/sdX Disk /dev/sdc: 7996 MB, 7996440576 bytes 224 heads, 56 sectors/track, 1245 cylinders Units = cylinders of 12544 * 512 = 6422528 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdc1 * 11245 7808612 83 Linux b) mke2fs -j /dev/sdX1; tune2fs -c0 -i0 /dev/sdX1 c) mkdir /mnt/tmp d) mount /dev/sdX1 /mnt/tmp 3. Copy the data: a) cd to_the_directory_with_this_readme_file; rsync -av . /mnt/tmp b) cd to_the_directory_with_the_SL63_iso_images; rsync -av SL-63-*-DVD1.iso SL-63-*-DVD2.iso /mnt/tmp c) cd /mnt/tmp; chown -R root.root . 4. Make disk bootable a) cd /mnt/tmp/isolinux b) cat ./mbr.bin /dev/sdX ### (*NOT* /dev/sdX1) c) ./extlinux -i . 5. cd /; umount /mnt/tmp 6. try to boot from the newly made USB disk. //KO 21FEB2013 -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Glitch in autoupdate from 6.4 to 6.5
Hi, there! As you may know, current SL6.4 default installation configures yum for 6.x. In this mode, when 6.5 comes out, the system will automatically self-update. While new to SL, SLC (CERN) have done it this way since the 5.x days with good effect. For example, the few computers I run at CERN just recently self-updated to 5.10 and 6.5 without any issues. So, with some trepidation, I was waiting for SL6.5 to show up and see if my computers will self-update successfully or crash and burn in flames. So 6.5 is here, and I am so disappointed because exactly nothing happened. And a few glitches I need to report: a) the self update to 6.5 is not happening because yum broke - the error is: Error: failure: repodata/b2f5801fbcee3722b2bd03d00d2a725c211a795bcdb6918c45558d9fb5499f7d-filelists.sqlite.bz2 from triumfcs-mirror-sl-devtoolset: [Errno 256] No more mirrors to try. I guess some kind of mismatch in the devtoolset repository. To get past this this error, I do yum clean all. (nightly scripts used to do a yum clean, but that was taken out recently?) b) next glitch is with the configuration of our local mirror of SL repositories. yum update runs correctly, but then starts downloading packages from the main SL site instead of using the local mirror. It turns out that the local mirror is defined like this: [triumfcs-mirror-sl] name=Scientific Linux $releasever - $basearch baseurl=file:///triumfcs/mirror/SL/$releasever/$basearch/os So until sl-release is updated, it points to the previous release ($releasever). A fix is to yum update sl-release, then yum update starts using the local mirror and the reset of the update runs successfully. Since 6.4 and 6.5 are frozen I doubt anything can be done to fix these glitches, but maybe for 6.6 something can be done? Certainly glitch (b) is kind of nasty as everything appears to work correctly, except for overloading the central SL distribution servers and for running up unnecessary network traffic charges. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Finally figured out what is causing bug 836696
On Tue, Dec 10, 2013 at 03:27:30PM -0500, Bluejay Adametz wrote: Never really cared for LVM. Always used the direct partition approach. Well, perhaps I can try to convince you some more. I never used LVM either, but ... I used LVM once, until on a bright day the machine stopped working because the LVM volume decided that it is disabled (Aparently each LVM volume has a disable bit and some secret magic command to flip it). mdadm software raid does not have any such disable bits so out with LVM, back to mdadm software raid. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Finally figured out what is causing bug 836696
On Tue, Dec 10, 2013 at 02:43:14PM -0500, Jeff Siddall wrote: On 12/09/2013 11:20 PM, ToddAndMargo wrote: then you absolutely want to be running them against a snapshot rather than a live FS and LVM makes this easy. Never really cared for LVM. Always used the direct partition approach. Well, perhaps I can try to convince you some more. Take another example of upgrading to a bigger disk. You mean upgrade all the disks in the raid array. Surely you do not run any important machines with single disks? -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Finally figured out what is causing bug 836696
On Mon, Dec 09, 2013 at 11:35:03AM -0800, ToddAndMargo wrote: Bug 836696 has been driving me nuts for years. This is where you drop to fsck on boot for the backup drive, but you can't do anything with the drive when you get to maintenance mode. And, I finally figured out what is causing this. My OS and my backup drive's devices are randomly reversing themselves at boot. For details, see comment #37: https://bugzilla.redhat.com/show_bug.cgi?id=836696#c37 Hope no one else has to figure this one out the hard way, as I did. Doh! This linux feature bites rookie and wizard all the same. Linux assigns the sdN names in the order that devices are discovered and this order is not deterministic - SCSI, SATA and USB may all be scanned at the same time mixing up all the names each time. Mr. Torvalds cares about this not one bit, he has only a single drive inside his mac air and no usb ports to accidentally confuse things by leaving a usb drive connected during reboot. Therefore, on linux, you cannot put /dev/sda1 co into /etc/fstab. You have to mount filesystems by UUID or by label. This was true and worked quite well for ages now. (Even with IDE disks, the /dev/hda, /dev/hdb, etc assignement was not super fixed - it depended on the order that IDE host adapters were initialized and this order has been known to change between different linux releases). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Finally figured out what is causing bug 836696
On Mon, Dec 09, 2013 at 03:11:22PM -0500, John Lauro wrote: If you want deterministic assignments, and things do not always start in the same order, you just need to setup rules. http://www.reactivated.net/writing_udev_rules.html and then you can use /dev/sda1, etc... in fstab. You posted a link to instructions from 2008. (today is 2013, tomorrow 2014). I have to maintain udev rules for chmod a+wr /dev/ttyUSB*. In SL4, the above command in /etc/rc.local was sufficient (5 minutes of work) In Sl5, I had to write udev rules and I read the udev documentation and I found it useless, internet examples useless, finaly by groping around I cobbled some rules that worked (2 days of work). In SL6, those rules stopped working (2 days of work to figure out new rules) In SL7, I full expect udev to be replaced with vdev, wdev, xdev, with equally useless documentation. So thanks, but no thanks. For disks, the solution is to use UUID and labels. (For /dev/ttyUSB* the solution is to write application code that gropes around inside /proc/ and /sys/ to figure out which /dev/ttyUSB node is which hardware devices - we use them in multiples). (For network devices the solution is persistent network names which makes your machine unusable if you replace the network card, the mobo, or move the disks to a spare machine - it binds eth0 to a specific MAC and records this binding in a secret place. If MAC changes, eth0 becomes eth2 and ifcfg-eth0 no longer works. Clearly, this was well throught through). K.O. - Original Message - From: Konstantin Olchanski olcha...@triumf.ca To: ToddAndMargo toddandma...@zoho.com Cc: Scientific Linux Users SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Sent: Monday, December 9, 2013 2:58:27 PM Subject: Re: Finally figured out what is causing bug 836696 On Mon, Dec 09, 2013 at 11:35:03AM -0800, ToddAndMargo wrote: Bug 836696 has been driving me nuts for years. This is where you drop to fsck on boot for the backup drive, but you can't do anything with the drive when you get to maintenance mode. And, I finally figured out what is causing this. My OS and my backup drive's devices are randomly reversing themselves at boot. For details, see comment #37: https://bugzilla.redhat.com/show_bug.cgi?id=836696#c37 Hope no one else has to figure this one out the hard way, as I did. Doh! This linux feature bites rookie and wizard all the same. Linux assigns the sdN names in the order that devices are discovered and this order is not deterministic - SCSI, SATA and USB may all be scanned at the same time mixing up all the names each time. Mr. Torvalds cares about this not one bit, he has only a single drive inside his mac air and no usb ports to accidentally confuse things by leaving a usb drive connected during reboot. Therefore, on linux, you cannot put /dev/sda1 co into /etc/fstab. You have to mount filesystems by UUID or by label. This was true and worked quite well for ages now. (Even with IDE disks, the /dev/hda, /dev/hdb, etc assignement was not super fixed - it depended on the order that IDE host adapters were initialized and this order has been known to change between different linux releases). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Example of a successful non-EL Linux install on current UEFI secure boot motherboard
On Wed, Sep 25, 2013 at 01:16:10PM -0700, Yasha Karant wrote: ... my Gigabyte GA-970A-UD3 motherborad Ok, so now we know the identity of the motherboard. Product page: http://www.gigabyte.com/products/product-page.aspx?pid=3907#manual Manual: http://download.gigabyte.us/FileList/Manual/mb_manual_ga-970a-ud3_e.pdf From reading the manual: - this mobo uses an external TPM module (consider removing it if present) - it talks about installing Windows XP and Windows 7 (no secure boot in Windows XP) - no mention of secure boot - no mention of UEFI (talks about EFI for booting from GPT partitions) - latest BIOS is dated from December 2012. From all this I conclude that this motherboard does not do secure boot (unless the removable TP module is present?) and all the unspecified problems installing an non-SL operating system come from some other source. (I have not seen any secure boot only motheboards yet. If you have seen such, please let me know). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Robust local mirroring of SL
On Tue, Sep 03, 2013 at 11:47:25AM +0100, John Rowe wrote: Until now there seems to have been no _robust_ way of using a local repository for yum updates. Say what? $ more /etc/yum.repos.d/triumfcs-mirror-SL6.repo ... [triumfcs-mirror-sl] name=Scientific Linux $releasever - $basearch baseurl=file:///triumfcs/mirror/SL/$releasever/$basearch/os enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl6 file:///etc/pki/rpm-gpg/RPM-GPG-KEY-cern cost=100 ... Note the cost=100 entry makes yum use this local repo instead of the remote stock SL repo. 1. Am I the only one finding using a local repository to be irksome, or is everybody else just smarter than I am? Yes. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: [SCIENTIFIC-LINUX-USERS] Upgrade SLC5 to SLC6 ?
On Tue, Jul 23, 2013 at 05:56:17PM -0700, Jeffrey Anderson wrote: On Tue, Jul 23, 2013 at 5:45 PM, Nico Kadel-Garcia nka...@gmail.com wrote: the problem here is the switch from one OS, a CERN release, to an actual Scientific Linux release. That. can be an adventure. I've done it for CentOS=Scientific Linux, and for RHEL=CentOS and CentOS=RHEL. It's nasty, and I don't recommend it unless you're getting paid hourly. Actually that is not quite the problem I was trying to upgrade from the CERN SL5 to the CERN SL6, and that apparently is not supported. But neither is a vanilla SL5 to vanilla SL6. One way to think about this: the difference between minor update (5.8-5.9) and major update (5.9-6.x) is one that requires a full reinstall. Why? There are too many incompatible changes and writing an foolproof automated upgrade tool is significantly more difficult compared to a full reinstall. In other words, if yum update could handle it, they would have named it 5.10, not 6.x. And of course if you do not require a bulletproof automated tool and if you do not mind ending up with a funny mongrel system, you can do the update/upgrade manually, even live, even successfully - there are enough reports of people who have done exactly that. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: artheros-8161 card not usuable under standard linux
On Wed, Jul 03, 2013 at 05:18:05AM +0100, Charles Elsaesser wrote: artheros-8161 device not recognized by linux : missing driver Historically, SL/CentOS was not the place for freshest drivers and support of latest hardware. (That was before ELREPO, etc) Historically, Knoppix and Ubuntu had all the latest drivers, etc. So before you give up on Linux, please try Knoppix and Ubuntu. (And a fresh new Knoppix was just released!) attempt of compiling alx driver as explained at http://www.linuxfoundation.org/collaborate/workgroups/networking/alx failed and following outputs are joined. Has it a sense to recompile linux kernel 3.3 on a native older system? SL4 and SL5 had no big problems running on vanilla linux kernels. Combination of SL6 and vanilla linux kernel 3.3 would probably work okey, as long as you know which kernel options to enable... -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: [SCIENTIFIC-LINUX-USERS] compiling 32 app on 64 machine
what a pain... Please complain to the people who prevent you from running everything in 64-bit mode. There is no excuse for them not providing both the 32-bit and 64-bit versions of all their libraries and executables. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Bootable USB installer for SL6.3
On Fri, Apr 12, 2013 at 12:39:47AM -0500, g wrote: as for your writing grub to the usb memory stick, how is grub installer being called? There is an eternal confusion. The BIOS order disk is 0x80, 0x81, etc. (0x0, 0x1 are the A: and B: floppies if I remember right). This is all that GRUB can know about, *and* they get it right - by referring to (hd0), (hd1), etc. The BIOS order is best treated as magical, but usually the disks on built-in sata interaces go before the disks on add-on cards. For built-in interfaces, the order may or may not be the same as the labels on the mobo. (if the mobo is labeled correctly and the bios is in agreement with the labeling). Then you boot linux and it assigns the names /dev/sda, sdb, etc in the detection order which is roughly the same as the relevant kernel modules are loaded. The AHCI driver module is usually loaded first and it probably detects the interfaces in the lspci order. The order of the ports on each interface is again magical. For example, the ASUS A8N-E mobo with 4 disks on the 4 built-in SATA ports will have this order: sda=(hd2), sdb=(hd3), sdc=(hd0), sdd=(hd1). Then you start the SL installer anaconda and it tries to make sense of this. The result is best described as we tried for the better, but got the same as ever. The bottom line is that it the installer cannot guess the ordering of the disks and it cannot guess the intent of the user. Instead of guessing it should ask. Instead of asking it brings even more confusion: For the single disk case, it always guesses right. For dual mirrored disks (mdadm raid), it says install bootloader on /dev/sda, then installs the boot loader on both disks (as it should), but sometimes it gets the disks cross-referenced - load GRUB from hd0, load vmlinuz and initramfs from hd1. For three disks (USB installer + dual mirrored disks), it usually installs the boot loader on the USB disk. Of 3 common use cases, they get 1 right, 1 almost right and 1 completely wrong. Then they have a button to select the disk for the boot loader. The offered menu looks like this: USB disk, 3TB disk, 3TB disk - impossible to tell which 3TB disk is which. (They could should the sda/sdb identification, the disk serial number, etc). To improve on this situation, I think the installer should have one more button - install the bootloader on the same disk where it just installed the OS. P.S. I do not know if the EFI boot standard makes things any better... -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Bootable USB installer for SL6.3
For reasons unknown, RHEL and SL insist on publishing installer images that work only from the DVD physical media. But none of the computers I buy today have DVD drives and I am not sure if Staples carry DVD blanks anymore. I guess I must be happy that SL install images do not come on floppies, punch cards or paper tape. Generally, this does not inconvinience me too much - I do most installs over the network (PXE boot). But sometimes I have machines generally not connected to the Internet (on a private network or out in the woods), so I have constructed bootable USB images for SL6.1 and 6.3. (6.4 on the way). (This installer tree is a copy of the .../x86_64/os tree minus the Packages directory, plus the isolinux/extlinux stuff and the DVD .iso files. The SL installer refuses to install from the Packages directory) (There is one caveat with running the installer from writable media - the SL6.3 installer sometimes writes the GRUB boot loader on the USB installer disk instead of the installation target disks - producing an unbootable system and ruining the USB installer disk at the same time. I have not seen the SL6.1 installer do this. Maybe one should use write-protect capable USB flash media). Download the stuff from here: http://trshare.triumf.ca/~olchansk/linux/ Instructions are here: http://trshare.triumf.ca/~olchansk/linux/SL63-64-USBBOOT/AAA-README-USBBOOT.txt Instructions for making USB-Bootable installation disk for 64bit SL6.3 -- 0. These instructions are intended for making a 64-bit SL6.3 installer on a USB Flash disk. 8GB flash media is recommended. 1. The ISO DVD images are NOT included. Download your own copies, before following these instructions. 2. Prepare the USB disk: a) su - b) fdisk -H224 -S56 /dev/sdX, make one partition of type 83-Linux, mark it bootable. Result should look like this: root# fdisk -l /dev/sdX Disk /dev/sdc: 7996 MB, 7996440576 bytes 224 heads, 56 sectors/track, 1245 cylinders Units = cylinders of 12544 * 512 = 6422528 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdc1 * 11245 7808612 83 Linux b) mke2fs -j /dev/sdX1; tune2fs -c0 -i0 /dev/sdX1 c) mkdir /mnt/tmp d) mount /dev/sdX1 /mnt/tmp 3. Copy the data: a) cd to_the_directory_with_this_readme_file; rsync -av . /mnt/tmp b) cd to_the_directory_with_the_SL63_iso_images; rsync -av SL-63-*-DVD1.iso SL-63-*-DVD2.iso /mnt/tmp c) cd /mnt/tmp; chown -R root.root . 4. Make disk bootable a) cd /mnt/tmp/isolinux b) cat ./mbr.bin /dev/sdX ### (*NOT* /dev/sdX1) c) ./extlinux -i . 5. cd /; umount /mnt/tmp 6. try to boot from the newly made USB disk. //KO 21FEB2013 -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Any recommendations for a compatible USB WiFi?
On Tue, Mar 26, 2013 at 11:22:14AM -0700, Joseph Areeda wrote: Would someone recommend a good USB Wifi that has current drivers for SL6.3? Or point me to a list of drivers available in the release repositories? I have used the ASUS USB-N13 adapter with SL6. Do not remember if it used stock drivers or ELREPO drivers. NetworkManager tools worked just fine for configuration etc. http://ca.asus.com/en/Networks/Wireless_Adapters/USBN13/#specifications http://www.newegg.ca/Product/Product.aspx?Item=N82E16833320040 The major caveat is that sometimes some vendors replace the chip inside the device, but keep the same model and part number, so in a way you buy a cat in a sack. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: AMD edac_mce_amd kernel module question
On Tue, Feb 05, 2013 at 09:22:21PM -0800, Yasha Karant wrote: SL 6x X86-64 on an AMD CPU. During boot, the dac_mce_amd kernel module is indicated as not being loaded. However, lsmod as well as a direct viewing of /proc/modules shows that the module is loaded and live. Evidence below. Is this consistent? Is the module actually active? kernel: 2.6.32-279.el6.x86_64 #1 SMP from uname -a From /var/log/boot.log: AMD Processor family 16: Please load edac_mce_amd module. CPU is unsupported I confirm that in SL6, the EDAC modules load and work correctly in the default configuration. (I did not have to do anything special, they just worked after the normal installation). How do I know they work? On both dual AMD Opteron machines still alive (the 1st generation, single-core ones), the memory subsystem is iffy and I often see messages from EDAC/MCE about ECC correcting memory bits. In Yasha's case, I would be suspicious about the message about CPU is unsupported. Perhaps that's the real problem. But he is not telling us what CPU he has, so I cannot check the EDAC compatibility and supported CPU list for him. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Current production Firefox and Thunderbird on X86-64 SL 6x
On Thu, Jan 31, 2013 at 12:46:16AM -0800, Yasha Karant wrote: My university network security unit requires that the latest production releases of particular network applications be installed ... The situation with Firefox in SL is identical to the situation with IE in Windows and with Safari in MacOS. If your security officer is happy with you running the version of IE installed by Windows self updates, and the version of Safari installed by MacOS self updates, what is his objection to the version of Firefox installed by SL self updates? If your security officer does not know SL from Adam, or is worried that the SL version of Firefox is not up-to-date on security fixes compared to the Mozilla firefox, you can pointing him to the security section on the web site of the pay-ware version of SL. For example, here is the security advisory for the latest firefox update: https://rhn.redhat.com/errata/RHSA-2013-0144.html Here is the mailing list with all security advisories: https://www.redhat.com/archives/rhsa-announce/2013-January/date.html By looking at these advisories, your security officer can see for themselves if pay-ware SL and free SL are up to date on security fixes to the SL version of firefox in general and as compared to firefox from Mozilla. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Current production Firefox and Thunderbird on X86-64 SL 6x
On Thu, Jan 31, 2013 at 03:37:09PM -0600, Graham Allan wrote: On Thu, Jan 31, 2013 at 08:48:44AM -0800, Yasha Karant wrote: The other issue is compatibility. The university insists on certain specific web based applications, including proprietary Blackboard and a specialized Oracle PeopleSoft application called the Common Management System (CMS). Is there a means to verify that the current ESR release meets the requirements of these applications? You put the horse behind the cart. It is the university-supplied applications that are supposed to be compatible with the browsers used by university users. Not the other way round. And it is the applications people who are supposed to be testing their applications for compatibility with supported browsers. And the list of supported browsers should be negotiated between the two parties. That is how it should be in a sane world. In the world where you, as a user and a stakeholder, permit the applications people to dictate everything, one would be forever stuck with netscape 1.0, and forget about iphone and ipad, never mind linux. Yasha, why don't you move to some less crazy university? Vote with your feet. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: cloning with dd
On Wed, Jan 30, 2013 at 10:48:55AM -0500, Lamar Owen wrote: On 01/29/2013 10:48 AM, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. ... There are two issues with the procedure you posted: 1.) Cloning a r/w/ mounted filesystem with dd isn't a good idea, ... One more minor detail I forgot. Full install of SL is just a few GB, if you clone by rsync, takes a few minutes to copy. With dd, it will take hours to clone a 3TB/4TB disk. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: cloning with dd
On Tue, Jan 29, 2013 at 07:48:56AM -0800, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. I clone SL systems using both methods - dd (mdadm raid1, actually) and rsync. The down side of cloning with dd is that all UUIDs become cloned (root filesystem, etc) and that can cause some confusion. The down side of cloning with rsync is that things like persistent ethX naming become confused (but no more than if you replace the mobo) and you end up with eth8 and eth9 instead of eth0 and eth1, and other similar artefacts. When cloning using rsync, you have to make the target disk bootable, which requires resetting all the UUID strings in the bootloader and in /etc/fstab, a major hassle. Overall, it is faster to create new boot disks by cloning than by doing a fresh installation - because of all the required post-installation stuff that has to be done manually. My general SL post-installation instructions are here: https://www.triumf.info/wiki/DAQwiki/index.php/SLinstall Cloning using mdadm raid1: https://www.triumf.info/wiki/DAQwiki/index.php/Cloning_raid1_boot_disks Cloning using rsync manually: https://www.triumf.info/wiki/DAQwiki/index.php/VME-CPU#Clone_disk_manually Cloning using rsync using a script: https://www.triumf.info/wiki/DAQwiki/index.php/DEAP#64GB_SSD_boot_disks To defeat the persistent naming of ethX helpful helpers: https://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Configure_network -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: How to get IA-32 compatibility with X86-64
On Thu, Jan 24, 2013 at 12:46:40AM -0500, Bluejay Adametz wrote: How does one activate both to appear so that the library packages for both will be put into the system via the GUI? You should be able to explicitly install 32-bit versions of libraries with something like yum install libblah.i686 I'm not sure if there's a way to install both bits with one installation. Historically, the early 64-bit distributions (SL and others) did not include many important 32-bit packages which had to be grafted-in from the corresponding 32-bit distributions. Many such packages conflicted severely. But today, the 64-bit distributions of SL contain all the important 32-bit packages, so there is no need to kludge anything. I.e. there is no need to enable the 32-bit repos of SL on 64-bit machines. Most likely the 32-bit packages you want are already there in the 64-bit repository. Most 32-bit packages that are available are not installed by default. You have to install them manually using yum install xxx.i686 as explained by previous poster. For example, here is the list of 32-bit packages we install to support cross-compilation of ROOT and related software: http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Install_packages_needed_for_QUARTUS.2C_ROOT.2C_EPICS_and_MIDAS_DAQ Why would one want 32-bit packages on 64-bit machines: a) to cross-compile software that has to run on 32-bit hardware (VME processors, etc) b) to run 3rd party software only available in the 32-bit flavour (commercial software, 64-bit unclean software, etc) I would say that a modern 64-bit distribution has to include the full 32-bit development environement. E.g. all -devel packages have to come in both flavours. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
nvidia mess, Re: Is there a kernel update for SL 6.2 coming up soon?
On Thu, Jan 24, 2013 at 06:32:10PM +, Alan Bartlett wrote: It seems jdow has screwed up. I am not buying this. I shall bite the hand that feeds me and elaborate. Look at it from my side. As a small part of my job, I manage 20-30 machines with random ATI and NVIDIA video cards. I love ELREPO and I install the nvidia drivers the usual way: yum install elrepo-release; yum install nvidia-driver-blah; reboot, everything works great. Then on a nice sunny day, I read the post by jdow about elrepo having pushed out drivers with support for her video card removed, and she is clearly unhappy about it (who would be happy?). Well, bad things happen to good people, could happen even to me, right? But wait, it did happen to me just now. These new drivers have been pushed into every one of my computers! Some of them have a supported video card, some not, but in any case, now I have to deal with this, happy or not. So where is here my fault, where is here jdow's fault? We did not do anything and our computers are broken now and we have to spend time fixing them. Before assigning the blame, let me list the evident problems: 1) yum install elrepo-release enables automatic updates from the repository, so any updated packages will be installed automatically. (elrepo-release-6-5.el6, [elrepo] enabled=1). 2) nvidia removes support for some video cards from their driver 3) nvidia and elrepo make a mess of the information on which cards are supported by which drivers. Quickly, GeForce210 is supported by which driver? Hint: http://elrepo.org/tiki/kmod-nvidia does not have a link to a list of supported cards. 4) elrepo pushes out the new driver under the old name, messing up all the unlucky machines. 5) elrepo tells us but you should have followed our mailing lists and converted those machine to the legacy driver, we gave you N days to do so! (even if you are on vacation, or busy with another project, or have the affected machines in inaccessible locations). Without assigning blame, I can suggest some solutions: a) yum install elrepo-release should have automatic updates disabled, for nvidia drivers or for all packages (through yum-autoupdate magic, through enabled=0, whatever). b) elrepo should have used a different name for the new incompatible driver (kmod-nvidia-310). c) elrepo should add a big warning any future update of this driver may remove support for your video card, please follow our mailing lists closely in http://elrepo.org/tiki/kmod-nvidia. As it stands now, I cannot even tell from the available documentation which driver I should be using for the GeForce210 cards I have on most machines. What a mess. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: nvidia mess, Re: Is there a kernel update for SL 6.2 coming up soon?
On Fri, Jan 25, 2013 at 12:19:14PM -0800, Konstantin Olchanski wrote: 3) nvidia and elrepo make a mess of the information on which cards are supported by which drivers. To elaborate: http://elrepo.org/tiki/kmod-nvidia The grand total of information on supported video cards is this: Supported Chipsets This driver is the current release and supports the most recent NVIDIA graphics cards (GeForce 8 series GPUs onwards, as well as Quadro series). Users of cards based on older chipsets should use one of the following legacy drivers. This is not helpful information. GeForce210 cards I bought in December are recent or not? Are they 8 series and onward or not? They are not listed in the legacy lists, is it an omission or have I dodged a bullet today or not? -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: [SCIENTIFIC-LINUX-USERS] nvidia mess, Re: Is there a kernel update for SL 6.2 coming up soon?
On Fri, Jan 25, 2013 at 02:35:27PM -0600, Pat Riehecky wrote: Nvidia has a helpful compatibility page (google result #2 for nvidia linux drivers): http://www.nvidia.com/Download/index.aspx?lang=en-us Not so helpful as to provide the actual list of supported products. Since I have nothing better to do today, I eventually found the actual list at: http://www.nvidia.com/object/linux-display-amd64-310.32-driver.html By luck, it's the list for the same version of the driver as was helpfully pushed into my computers by elrepo: iris01:~$ rpm -q kmod-nvidia kmod-nvidia-310.32-1.el6.elrepo.x86_64 I vote to have it linked from http://elrepo.org/tiki/kmod-nvidia Please don't hold the ELRepo folks accountable for changes NVidia makes. They are graciously donating their time to make these packages. Yes, as I said, one bites the hand that feeds us. Not the hand of the nice people where this yummy dogfood ultimately comes from. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: No more flash updates?
On Mon, Jan 14, 2013 at 10:32:33AM -0800, Todd And Margo Chester wrote: http://get.adobe.com/flashplayer/?promoid=JZEFT My reading of tea leaves is that going forward, the only flash for linux will be the one packaged by google as part of the google-chrome web browser. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6.3 doesn't no network present until user logs in on GUI
On Wed, Dec 12, 2012 at 09:19:05PM -0500, Nico Kadel-Garcia wrote: Since it's packaged as the default from the upstream vendor distribution, and since the system-config-network tool from the upstream vendor provides no ability to access or manipulate this feature or numerous others, ... Complaint rejected. RTFM the Deployment Guide, section Networking. It tells you to use nm-connection-editor. It even explains all this business of system and user network connections. https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/part-Networking.html P.S. system-config-network is gone, but of late, it was simpler to vi /etc/sysconfig/network-scripts/ifcfg-ethX, and Look Ma! Vi those files directly still works, even with the NetworkManager! -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6.3 doesn't no network present until user logs in on GUI
On Thu, Dec 13, 2012 at 05:15:58PM -0500, Tom H wrote: I don't use the GUI ... Yes, right. New way of thinking, if you are not using a GUI you are some kind of luddite. No matter that I am in Canada and I need to manage a machine in Japan hidden behind 25 firewalls. Ping time is 200 ms, ssh is barely usable, forget about X11 tunneling and good luck getting a VNC connection through the 25 firewalls. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6.3 doesn't no network present until user logs in on GUI
On Wed, Dec 12, 2012 at 01:54:21PM +, Winnie Lacesso wrote: Konstantin Olchanski wrote: This disables the super-clever extra-useful network manager feature where it enables networking when a user logs in into the console and helpfully disables the networking when a user logs out from the console. Do I grok this aright - you set up an SL workstation to do network stuff in the background, i.e: dhcp renewal, ntp, wee-hours automatic security updates, possibly other things (overnight backups? rsync of data to central server?); but if no one's logged onto the console, those all just stop working bcs NM has shut off the network? TUV thinks this is a good idea?! astonish It seems badly thought, if someone's not logged on overnight, no security updates. Or does yum rerun its wee-hours cron if someone logs in at the console during daytime? I do not think this comes from TUV. It comes from the NetworkManager croud, which I think is the same as the GNOME croud, or at least they think the same way - my laptop^H^H^H^H^H^Htablet is the only use-case that matters. The normal SL setup (after the installer) is to have available to all users enabled on all system network interfaces and then none of this nonsense happens, the network functions normally (always enabled). But I have seen this problem - after the installer, available to all users is off and you see the silly behaviour. I discount it as an installer malfunction. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: changes in gcc 3.4 compatibility rpms between SLF5 and 6
On Tue, Dec 11, 2012 at 12:07:17PM -0600, Kenneth Herner wrote: I am attempting to build root 5.28 as part of testing some legacy software, and for maximum compatibility I would like to use gcc/g++/g77 3.4 when building. I've installed all of the appropriate compatibility rpms on two machines, one running SLF 5.7 and the other 6.3. When I build on the SLF 5.7 machine everything works fine. When I do the same thing on the SLF 6.3 machine it works until almost the end, where I get the following error: g77 -m32 -O2 -o bin/g2root main/src/g2root.o \ -Llib lib/libminicern.so \ /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/libg2c.so -lnsl -lm -ldl -pthread -rdynamic /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a: could not read symbols: File in wrong format So you are trying to cross-compile 32-bit ROOT on a 64-bit machine. I confirm that such cross-compilation works correctly for most recent versions of ROOT, but older versions had problems in the Makefile and in the configure scripts. The error you report seems like one of those problems - the Makefile thinks it is doing a 32-bit compilation (-m32 on the g77 command line), but supplies a 64-bit fortran runtime library (/usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a) To begin with, you need to find the 32-bit version of the same library, then you need to convince the Makefile to use it (hint: vi the Makefile). Also check that you are doing the cross compilation correctly: do setarch i386 before anything to fool the ROOT build scripts into thinking that they are running on a 32-bit machine. Good luck. K.O. collect2: ld returned 1 exit status make: *** [bin/g2root] Error 1 When I do rpm -qf /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a I get compat-gcc-34-g77-3.4.6-19.el6.x86_64 for SLF6, and compat-gcc-34-g77-3.4.6-4.1.x86_64 for SLF 5.7. Are there any changes in this package that would cause an error such as the one above? It looks like it's the same version of the compiler, but something important must have changed between version 4 and 19. Does anyone have an idea regarding a workaround? Many thanks, Ken -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: changes in gcc 3.4 compatibility rpms between SLF5 and 6
On Tue, Dec 11, 2012 at 01:37:37PM -0600, Connie Sieh wrote: On Tue, 11 Dec 2012, Kenneth Herner wrote: Hello, I am attempting to build root 5.28 as part of testing some legacy = software, and for maximum compatibility I would like to use gcc/g++/g77 = 3.4 when building. I've installed all of the appropriate compatibility = rpms on two machines, one running SLF 5.7 and the other 6.3. When I = build on the SLF 5.7 machine everything works fine. When I do the same = thing on the SLF 6.3 machine it works until almost the end, where I get = the following error: g77 -m32 -O2 -o bin/g2root main/src/g2root.o \ -Llib lib/libminicern.so \ /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a = /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/libg2c.so -lnsl -lm -ldl = -pthread -rdynamic /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a: could not read = symbols: File in wrong format collect2: ld returned 1 exit status A common reason for the above error is using a 32bit library/archive when a 64 bit one is expected and vice versa. A default install for SL5 installs many i386 packages in addition to the x86_64 packages for a x86_64 install. On SL6 only x86_64 packages are installed. I routinely cross-compile 32-bit ROOT on 64-bit machines, and indeed lack of 32-bit devel packages in the default installation is a minor difficulty. Here is the complete list of packages I have to install for building 32-bit ROOT (and some other packages) yum install --skip-broken giflib.i386 giflib.i686 giflib.x86_64 compat-libf2c-34.i386 compat-libf2c-34.i686 mysql-devel mysql-devel.i686 openssl-devel.i686 sysstat libusb-devel* unixODBC-devel unixODBC-devel.i686 postgresql-devel libxml2-devel libXpm-devel libgfortran libstdc++-devel.i386 libstdc++-devel.i686 git compat-readline43 graphviz* dcap zlib-*.i686 libXext-*.i686 libXtst-*.i686 tigervnc* telnet glibc* glibc-static.i686 freetype.i686 fontconfig.i686 libpng.i686 libXrender.i686 strace fftw* libpng freetype* xpdf xemacs* tkcvs xterm mutt *g77* joe libXmu* glibc-devel.i686 libX11-devel.i686 libXpm-devel.i686 libXft-devel.i686 mysql-devel.i686 dcap-devel dcap-devel.i686 gsl-devel gsl-devel.i686 pcre-devel pcre-devel.i686 fontconfig-devel.i686 freetype-devel.i686 libpng-devel.i686 libjpeg-devel.i686 libgfortran.i686 libxml2-devel.i686 h5py gd-devel gd-devel.i686 readline-devel.i686 ncurses-devel.i686 libXdmcp.i686 xorg-x11-fonts* rdesktop minicom xfig* (Note that this list is historical - packages are added to but never removed from this list) http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall The reason for cross-compilation is that we have: a) proprietary 32-bit only libraries b) 32-bit VME-form-factor computers that do not have sufficient memory for building ROOT similar. And of course cross-compilation of ARM binaries is on the way... K.O. -Connie Sieh make: *** [bin/g2root] Error 1 When I do rpm -qf /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a I = get compat-gcc-34-g77-3.4.6-19.el6.x86_64 for SLF6, and compat-gcc-34-g77-3.4.6-4.1.x86_64 for SLF 5.7. Are there any changes in this package that would cause an = error such as the one above? It looks like it's the same version of the = compiler, but something important must have changed between version 4 = and 19. Does anyone have an idea regarding a workaround? Many thanks, Ken= -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6.3 doesn't no network present until user logs in on GUI.
On Sun, Dec 09, 2012 at 09:53:34AM -0600, Jos? Pablo M?ndez Soto wrote: I noticed that my virtual machine with GUI, that I built from the SL-63-x86_64-2012-08-02-Install-DVD.iso, won't reply to pings or open SSH sessions until a user logs in. Open network manager - edit connections or run nm-connection-editor, open each connection and tick the available to all users check-box. This disables the super-clever extra-useful network manager feature where it enables networking when a user logs in into the console and helpfully disables the networking when a user logs out from the console. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6 etc. on ARM CPU units
On Sat, Dec 08, 2012 at 05:17:06PM -0800, Joseph Areeda wrote: I'm pretty sure there are Debian ports for ARM including RasberryPi. I am more interested in getting the SL userland running on the ARM machines. K.O. Here's an interesting project out of the UK http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64 node cluster using Lego for the supports. I'm also sure it was a lot of work like others have mentioned. Perhaps when the upstream providers get the kernel and the drivers going in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM also. Joe On 12/07/2012 11:27 AM, Konstantin Olchanski wrote: Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU compatibility issue. Even though most of the Linux system will run on either without modification, there are still some unique issues to each of them; from having worked and studied VirtualBox, there are differences in how each manufacturer chose to implement the ring structure that permits virtualization to work as nicely as it does on these platforms. For the most part, they are compatible, but the kernel developers have to be aware of certain implemention issues, including a bug in the Intel CPU platform that requires a VirtualBox workaround (for optimizing the code or something; I forget). And this is in addition to Linux supporting umpteen different processing platforms besides the x86 types. New hardware
Re: SL 6 etc. on ARM CPU units
On Mon, Dec 10, 2012 at 05:54:36PM -0600, Connie Sieh wrote: On Mon, 10 Dec 2012, Konstantin Olchanski wrote: On Sat, Dec 08, 2012 at 05:17:06PM -0800, Joseph Areeda wrote: I'm pretty sure there are Debian ports for ARM including RasberryPi. I am more interested in getting the SL userland running on the ARM machines. There is a RHEL 6 rebuild for arm called RedSleeve. http://www.redsleeve.org . Yes, thanks. One difficulty I expect is with no cross-install capability when I can use a 2nd computer (x86) to cross-install ARM RPMs into an ARM boot media. If you do frequent cross-compilation, you would agree with me that lack of cross-install is so silly. I think the expectation is that I have an ARM machine big enough to run the SL installer. At least the text-mode installation is still there and there is no requirement of a working ARM X11 server on whatever funny ARM machine I happen to have. K.O. -Connie Sieh K.O. Here's an interesting project out of the UK http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64 node cluster using Lego for the supports. I'm also sure it was a lot of work like others have mentioned. Perhaps when the upstream providers get the kernel and the drivers going in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM also. Joe On 12/07/2012 11:27 AM, Konstantin Olchanski wrote: Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU
Re: SL 6 etc. on ARM CPU units
Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU compatibility issue. Even though most of the Linux system will run on either without modification, there are still some unique issues to each of them; from having worked and studied VirtualBox, there are differences in how each manufacturer chose to implement the ring structure that permits virtualization to work as nicely as it does on these platforms. For the most part, they are compatible, but the kernel developers have to be aware of certain implemention issues, including a bug in the Intel CPU platform that requires a VirtualBox workaround (for optimizing the code or something; I forget). And this is in addition to Linux supporting umpteen different processing platforms besides the x86 types. New hardware appears constantly, and some Linux user somewhere wants to use it on their system. I feel that variety of hardware and variation in hardware implementation is a fact, and a main reason why Linux and Unix are so powerful and ubiquitous. Now I just hope no one will hold me to this and insist that I actually port Linux to all these different hardware configuration! I'm not signing up; I'm just pointing out what I think is reality. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: self contained usb install using kickstart howto
On Tue, Nov 27, 2012 at 07:52:02AM -0600, Bill wrote: On Thu, 15 Nov 2012 07:17:51 -0800, EXT-Askew, R W r.w.as...@boeing.com wrote: I wanted to follow up with answers to my own questions in case it may help someone else. Thanks for the response. I have couple of more questions. In your readme mentioned mbr.bin and extlinux. Is mbr.bin a copy of /usr/share/syslinux/mbr.bin ? /usr/share/syslinux/mbr.bin seems to work just fine My instructions do not assume that one has the SYSLINUX package installed on your machine - because the default SL SYSLINUX package is severely out of date. But I think any SYSLINUX mbr.bin is okey. Are extlinux and extlinux.conf copies of /sbin/extlinux and /etc/extlinux.conf ? No. Negative. extlinux.conf is necessarily customized for booting the SL installer package. extlinux binary: I tend to use the latest version of SYSLINUX/EXTLINUX/PXELINUX so that would be the binary present in the image boot directory. These new versions support many advanced functions such as menus, conditional boot loading, etc. One way to tell old EXTLINUX from new one is the command syntax changed from ./extlinux . to ./extlinux -i . (-i was added). The above worked fine as well Yes, the old SYSLINUX/EXTLINUX still works quiet well, but I am not too sure about support for booting from EXT4 filesystems. Also it works because my example extlinux.conf does not use any advanced features. Also, do you do the install with a kickstart file on the USB drive? From a DVD, my boot line looks like this Boot: Linux ks=cdrom:/ks.cfg What would I replace cdrom: with? No, I did not make a kickstart file for the USB bootable installer. I usually do PXEBOOT network installs and I do have a kickstart file there. The USB installer was done for doing vanilla SL installations. I am still trying to determine the smallest packege set required, but I am off and running. :-) I gave up on smallest package set long time ago. The full installation fits on 16 GB media and I do not have to install yet anothing one missing package every day. (I am still pissed at upstream for removing the install everything installer button). K.O. -Original Message- From: Konstantin Olchanski [mailto:olcha...@triumf.ca] Sent: Tuesday, November 13, 2012 11:09 AM To: EXT-Askew, R W Cc: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Re: self contained usb install using kickstart howto On Tue, Nov 13, 2012 at 09:48:01AM -0600, rwa wrote: I am working on a custom SL6.2 installation and am interested in using a USB thumb drive to trouble shoot the installation so that I do not need to burn so many DVDs. I have looked through a lot of HowTos but none of them seem to be geared toward a standalone self contained install from a USB drive using a kickstart file. Can anyone point me to such a HowTo? I have instructions for building an SL6.1 USB install disk here (trivial to update for SL6.2): http://trshare.triumf.ca/~olchansk/linux/SL61-64-USBBOOT/ -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: nfs-utils-1.2.3-28.el6 ?
On Fri, Nov 16, 2012 at 08:35:16AM +0100, Rupert Kolb wrote: there is a bug in nfs-utils: The mapping of user name and group doesn't work: I get nouser and nogroup, which is really annoying, see: https://bugzilla.redhat.com/show_bug.cgi?id=849945 Can this be fixed in SL 6.3 shortly? If I read the referenced bug correctly, they think it is a problem with a FreeBSD NFSv4 server. If your servers and clients are SL6, perhaps your problem is elsewhere. I, too, have seen NFSv4 report nouser and nogroup. This is connected to this idmapd thing and I remember some gyrations with it through SL6.0-6.1-6.2. For a standalone cluster (no NIS), it appears that you have to set the Domain value in idmapd.conf to the same value on all machines. Without that, I was seeing some machines decide to use Domain=triumf.ca, others Domain=localdomain, etc, and obviously uid-name mapping did not work. There were reasonably explanatory messages in the syslog. Then after changing the Domain= value in idmapd.conf I remember having to reboot every machine - restarting nfs, idmapd, etc was not enough - it was remembering the old settings somewhere. This is for SL6.1, SL6.2. For an NIS cluster, the default value (Domain= commented out in /etc/idmapd.conf) seems to work in SL6.2. (But I have no idea what domain name (realm name?) it is using, it does not seem to report it to the syslog). We also have sporadic DHCP problems with domains and hostnames changing between abc.triumf.ca and abc.Trumf.CA (note capital letters), another thing to watch for that may trip-up the NFSv4 idmapd. Good luck! -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: self contained usb install using kickstart howto
On Tue, Nov 13, 2012 at 09:48:01AM -0600, rwa wrote: I am working on a custom SL6.2 installation and am interested in using a USB thumb drive to trouble shoot the installation so that I do not need to burn so many DVDs. I have looked through a lot of HowTos but none of them seem to be geared toward a standalone self contained install from a USB drive using a kickstart file. Can anyone point me to such a HowTo? I have instructions for building an SL6.1 USB install disk here (trivial to update for SL6.2): http://trshare.triumf.ca/~olchansk/linux/SL61-64-USBBOOT/ -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: recent kernel and root raid1
On Tue, Nov 13, 2012 at 08:33:05PM +0100, David Sommerseth wrote: On 12/11/12 22:14, Konstantin Olchanski wrote: On Sat, Nov 10, 2012 at 08:14:41AM -0600, Robert Blair wrote: I have a system that failed to boot after the most recent kernel update. It took a while, but I eventually traced it to the initramfs not having raid1 included. I had to manually do a mkinitrd --preload raid1 ... ... dracut-004-283.el6.noarch All are invited to inspect the mdadm-related code in dracut. I've been uncertain if I should respond to this mail or not. But I struggle to let such rants pass when I think this is a really an unfair attack. I say inspect the product in question then decide if my attach is fair or not. ... But I do react to your claim which sounds like you think the upstream developers are clueless and don't care about what they do. That is not what I said. I did not say they are stupid, I did not say they are indifferent or malicious. I said that they are crazy. There is a difference. Some crazy stuff works great, this one does not. All the code in this Enterprise Linux distro comes from an open source upstream source. There are usually upstream communities to discuss things with. And there are communities where you can provide patches fixing things you find not being in a good shape. There is a minor problem with your suggestion that I send bug fixes to upstream: Upstream is at dracut-024 (Oct-2012), SL6 is at dracut-004 (January-2010). I can elaborate on how bug fixes to upstream do no good to SL users. Throwing out such trash which you did will definitely not improve anything. Upstream developers do really deserve better treatment from us - no matter what we think of their work. Please refer to: http://en.wikipedia.org/wiki/The_Emperor's_New_Clothes -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6 etc. on ARM CPU units
On Mon, Oct 22, 2012 at 01:42:51PM -0700, Yasha Karant wrote: ... I have a Samsung Galaxy Tab 2 7 (USA version) ... [with] Android, ... ARM CPU platform. ... I am considering attempting to switch it it to Linux. Gaaahh! Crazy Yasha is back! Evidently, there is both an Ubuntu and Arch distribution for some versions of the ARM platform -- any versions of EL for this platform? Anyone using Linux on this platform? There is a major misunderstanding regarding the ARM platform. An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. It is even worse. There is no generic Android OS that will run on every ARM machine: Look at CyanogenMod - a community effort to port generic Android to every available phone or tablet. They have to port the code specifically to each device: http://wiki.cyanogenmod.com/wiki/Devices_Overview If not, and there are any members of this list who also use this sort of platform under Android, off list correspondence and recommendations would be appreciated (e.g., how to get bash working, how to get non-GUI file and directory manipulation commands, etc.). There are android apps for some of these things, but all the good stuff is outside of the google play store. Much open source android apps (MyTracks, etc) live on the google project hosting site: http://code.google.com/hosting/search?q=label%3aAndroid Typical amateur end-user material that I have seen on some of the Android lists (e.g., the use as an entertainment device) is of less use to me. Several of my students have discussed rooting Android to get around the limitations imposed by the environment and getting closer to the underlying linux core (that is missing most of the support programs and APIs that make functional a regular linux distribution), but I need to more fully understand the consequences for this approach before proceeding (as well as getting detailed how-to instructions). You may discover that you have to root your device to do anything interesting at all. In the nutshell, an android device is like a Linux PC with an unknown root password. (actually the password is blank, but chmod u+s /bin/su and /bin/sudo are missing so you cannot get in). Rooting is like using a blow torch to open the hood of your own car that (for better or worse) was welded shut by the car maker. To extend the analogy, with Win8/WinRT MS require that the car hood be made out of titanium, regular blow torch does not work, you have to use an h-bomb (illegal is some countries). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Iptable rule required to block youtube
On Thu, Oct 04, 2012 at 12:57:00PM +0530, vivek chalotra wrote: And now i want to block youtube on my network. kindly suggest iptable rules to do that. block youtube on my network is not a very well defined wish. If you want to merely block the well known youtube IP and DNS addresses, you can use iptables, etc. Be prepared to update these lists frequently to keep up with things like youtu.be co. If you want to prevent users of the network from watching all youtube videos always, give up now. First of all, you will have to be able to handle legitimate exceptions: how do I watch training videos for Altera Quartus software that happen to be hosted on youtube?!?. Second, you will have to handle all the possible 3rd party redirectors, proxies, and other kludges specifically designed to circumvent youtube blockers such as you are try to build. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Autofs segfaults on 6.3 - and solution
On Thu, Oct 04, 2012 at 01:22:21PM -0400, Tom H wrote: On Thu, Oct 4, 2012 at 8:01 AM, Sean Murray mur...@tlabs.ac.za wrote: RAID0: LOL. If I suggested using RAID0, even on a simple dev box, I'd either be asked to clear my desk on the spot or my name would rise immediately to #1 on the headcount-reduction list... That is supposed to be RAID1, I think Konstantin has a buggy keyboard as well ;-) Oh! So Konstantin's confusing 0s and 1s. Maybe he's produced by Intel! ;) I wish. Unlink the Intel fdiv bug which yielded wrong results consistently, my brain does it randomly. I now remember the bug. There was a public bug to which Harald posted a possible fix a few weeks after it was reported and there was a private bug, where most of the real discussion and work must've taken place that resulted in a fix and an advisory after 4 or 5 months. Far too long, I agree... Yes, the bug was no boot if 1 disk of a mirrored set is missing. As follow up, here I report that I duely tested the fix, confirmed that I can boot with either of the 2 disks missing, pushed this into a production machine, which now happily does not boot at all with both disks present (one has to do the rdshell, mdadm -As, continue dance, then it boots). If you have seen the dracut md code, you would wonder why it boot ever at all, ever. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Autofs segfaults on 6.3 - and solution
On Wed, Oct 03, 2012 at 07:00:00AM -0400, Tom H wrote: On Mon, Oct 1, 2012 at 6:53 PM, Konstantin Olchanski olcha...@triumf.ca wrote: On Sat, Sep 29, 2012 at 04:28:22PM +0200, Gerhard Schneider wrote: After upgrading to 6.3 we were seeing autofs segfaulting on many machines. Something is rotten in the state of Denmark. First busted NIS (no broadcast NIS), then busted DRACUT (no boot from raid-0 disks), and now this? What, me worry? As was pointed out in [1], RH gives precedence to its paying customers who are most likely large corporations where neither NIS nor RAID0 are used... I somehow doubt that there are no paying customers who use NIS, Autofs and MD/Raid0. Anyhow, from what I see, paying for support would be a complete waste of money because both for paying customer and for freeloader, the products are still broken with no fix. To make it look even worse, the nature of NIS and Autofs breakage indicates either a large hole in their testing procedure (I assume they do test NIS and Autofs) or a major shift of focus away from traditional Unix (in which case NIS, Autofs co have de-facto become unmaintained). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Autofs segfaults on 6.3 - and solution
On Wed, Oct 03, 2012 at 04:38:23PM -0400, Chris Schanzle wrote: On 09/29/2012 10:28 AM, Gerhard Schneider wrote: A bug fix can be downloaded via https://bugzilla.redhat.com/show_bug.cgi?id=846852 I am not authorized to access that bug, even with a freebie account - can someone paraphrase? I'm curious under what conditions it is segfaulting. I confirm that the bug went secret, I could but now cannot access it, too. By luck I still have it open in a browser window. In the bug report, they see no crash under normal conditions, but crash if they firewall the NFS UDP ports. (They use NFS/TCP, so UDP ports should not be used, in theory). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Gauging interest in an IA64 rebuild.
On Thu, Sep 20, 2012 at 09:44:20AM -0400, Lamar Owen wrote: I'm posting this to gauge the potential interest in such a project by the larger SL community. ... Hi! I wish you the greatest luck in your little project. SGI forever! While I am sure there is great theoretical interest in non-x86 ports of SL (and siblings), I can see how there is no practical interest in the IA-64 port because IA-64 hardware is not generally available. (We do have IA-64 machines at TRIUMF, but they run VMS, of all things. They are part of the control system of our 500-MeV/c proton cyclotron, replacing ALPHA VMS machines, replacing VAX VMS machines). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SSD and RAID question
On Mon, Sep 17, 2012 at 08:46:34PM -0700, Todd And Margo Chester wrote: Yes, I did miss the sda on all four partitions. Does the [2/1] mean this is the first of two drives? Please RTFM. Somehow you expect this list to teach you how to read the output of /proc/mdstat. Please believe me, you will learn much more and understand things much better by reading the MD/mdadm documentation first. A good place to start is the R** H** system administrators guides. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: User proc uses all RAM+swap = kernel panic - shouldn't OS not allow?
On Thu, Sep 13, 2012 at 04:32:00PM +0200, Stephan Wiesand wrote: Hello Winnie, On Sep 13, 2012, at 16:01 , Winnie Lacesso wrote: Several times over past few years I've seen user processes go mad (programming error) use all RAM, then all swap (as ganglia so vividly shows), then the box ends up at a kernel panic. (Server OS is SL5.x 64-bit BTW) we rarely see panics in these cases. The box just becomes unusable. Which effectively makes no difference though. yes, same here. often, the system starts paging and becomes unresponsive (user pushes the reset button) well before OOM kills the offending process. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SSD and RAID question
On Sun, Sep 02, 2012 at 05:33:24PM -0700, Todd And Margo Chester wrote: Cherryville drives have a 1.2 million hour MTBF (mean time between failure) and a 5 year warranty. Note that MTBF of 1.2 Mhrs (137 years?!?) is the *vendor's estimate*. Actual failure rates observed in production are unknown, the devices have not been around long enough. However, if you read product feedback on newegg, you may note that many SSDs seem to suffer from the sudden death syndrome - a problem we happily no longer see on spinning disks. I guess the 5 year warranty is real enough, but it does not cover your costs in labour for replacing dead disks, costs of down time and costs of lost data. ... risk of dropping RAID in favor of just one of these drives? To help you make a informed decision, here is my data. I have about 9 SSDs in production use (most are in RAID1 pairs), oldest has been running since last October: - 1 has 3 bad blocks (no RAID1), - 1 has SATA comm problem (vanishes from the system - system survives because it's a RAID1 pair). - 0 dead so far I have about 20 USB and CF flash drives in production used as SL4/5/6 system disks, some in RAID1, some as singles, oldest has been in use for 3 ( or more?) years. There are zero failures, except 1 USB flash has a few bad blocks, except for infant mortality (every USB3 and all except 1 brand USB2 flash drives fail within a few weeks). All drives used as singles are backed up nightly (rsync). All spining disks are installed in RAID1 pairs. Would *I* use single drives (any technology - SSD, USB flash, spinning)? Only for a system that does not require 100% uptime (is not used by any users) and when I can do daily backups (it cannot be in a room without a GigE network). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Procmail problem
On Wed, Aug 22, 2012 at 12:33:09PM +0100, Anne Wilson wrote: ... procmail appears to be not doing its stuff What could be wrong? Why just had a spike of cartalk style questions my car does not start, what could be wrong? (my procmail, my wifi, whatever). What could be wrong? -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6 vs. other RHEL clones: security advisory comparison
On Mon, Aug 20, 2012 at 10:45:04PM +0100, Karanbir Singh wrote: On 08/20/2012 04:59 PM, Konstantin Olchanski wrote: b) delays in issuing bug fixes are good for you - no delay means they did not test the stuff before pushing it out. FUD F = fear U = uncertainty D = deception what did I say that qualifies? There is no S there for stupid or O for obvious. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6 vs. other RHEL clones: security advisory comparison
On Tue, Aug 21, 2012 at 12:36:15AM +0100, Mr IT Guru wrote: While the graphs are nice, and provide a visual representation of the time it takes to releasing a patch with regards to a security advisory - what real information do they tell us? I liked the graphs, the writeup and the overall presentaion and I am impressed by the research done by the O.P. There is even useful information in his report - for example RHSA-2012:744 (or so) clearly had something about it that caused trouble for all 3 distributions. The measurement of the worst delay - 20 days - is also useful. It compares favourably with other OS distributors, i.e. Apple, where delays for fixing similar bugs seem to be much longer. (so now I have to do the same report for Linux vs MacOS vs Windows - delay from CVE to vendor advisory to release of solution. Nah... I go to the beach instead). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6 vs. other RHEL clones: security advisory comparison
On Mon, Aug 20, 2012 at 07:02:47PM +0700, Janne Snabb wrote: http://bitrate.epipe.com/rhel-vs-centos-scientific-oracle-linux-6_187 A few comments: a) you forgot to include the SLC (CERN) distribution. This distribution is most important when dealing with hardware vendors - most vendors in our field sell stuff to CERN and when there are problems and they tell us but we tested it with Ubuntu-2000 I happily reply, that SLC/RHEL/SL/CentOS is what they should be testing with and supporting. b) delays in issuing bug fixes are good for you - no delay means they did not test the stuff before pushing it out. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL6.2 no boot from degraded RAID1... with fix... Re: dracut update not available ?
On Sun, Aug 05, 2012 at 03:54:21PM -0700, Konstantin Olchanski wrote: FYI, as a regression from SL6.0 and SL6.1, SL6.2 does not boot from degraded RAID1 devices. For the record, the present bug affects the md Linux software raid devices. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
SL6.2 no boot from degraded RAID1... with fix... Re: dracut update not available ?
FYI, as a regression from SL6.0 and SL6.1, SL6.2 does not boot from degraded
RAID1 devices.
If your / is on a RAID1 mirrored across 2 disks and 1 of the 2 disks dies,
your system will
not boot because dracut does not activate the required md devices.
This is a very serious problem because RAID1 (mirroring) of / and swap is a
popular
solution for protecting against single-disk failures. The present bug defeats
this protection
and makes the situation worse because failure of either of the 2 disks makes
your system
unbootable.
It is astonishing that this problem was not caught by anybody's QA, did not
receive
wide publicity *and* the solution was not pushed into the current release of SL.
Bug report against dracut was filed in January:
https://bugzilla.redhat.com/show_bug.cgi?id=772926
marked as duplicate of secret bug:
https://bugzilla.redhat.com/show_bug.cgi?id=761584
solution made available in July for (the best I can tell) the 6.3 release:
http://rhn.redhat.com/errata/RHBA-2012-0839.html (dracut-004-283.el6.src.rpm)
http://rhn.redhat.com/errata/RHBA-2012-1078.html (dracut-004-284.el6_3.src.rpm)
These RPMs are available in SL6 .../6rolling/x86_64/updates/fastbugs/
I confirm that dracut-004-284.el6_3 can boot SL6.2 from degraded / (one disk
missing).
Note that applying the fix on affected systems is not trivial:
1) rpm -vh --upgrade dracut-004-284.el6_3.noarch.rpm
dracut-kernel-004-284.el6_3.noarch.rpm
2) bad dracut is still present inside the /boot/initramfs files, your system is
still broken
3) dracut -v -f ### this rebuilds the initramfs for the ***presently running***
kernel, not necessarily the one used for the next reboot
4) find /boot -name 'initramfs*.img' -print -exec lsinitrd {} \; | grep
dracut-0 ### report dracut version inside all /boot/initramfs files
5) dracut -v -f /boot/initramfs-2.6.32-279.1.1.el6.x86_64.img
2.6.32-279.1.1.el6.x86_64 ### rebuild initramfs for the latest update kernel
Good luck!
K.O.
On Thu, Jul 19, 2012 at 03:07:19PM -0500, Connie Sieh wrote:
On Thu, 19 Jul 2012, Sean wrote:
Hi
With reference to : http://rhn.redhat.com/errata/RHBA-2012-0839.html
I have a bunch of new servers which we bought with dual internal disks
for raid1, these are effectively unusable until this update
is pushed through to SL ?
Is there a reason for it not making it from redhat into sl6 x86_64?
I have looked everywhere but can only find dracut 004-256.
and not 004-283.
004-283 was a fastbug for RHEL 6.3 . Since we have not released SL
6.3 yet it is only available in the 6rolling tree.
ftp://ftp.scientificlinux.org/linux/scientific/6rolling/x86_64/updates/fastbugs/
-Connie Sieh
Thanks
Sean
--
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL giving up on DHCP search
On Thu, Aug 02, 2012 at 06:51:11PM +, Adam Bishop wrote: Yesterday afternoon the core router on our network decided to have a short nap and stopped routing packets for an hour or so. Layer 2 connectivity was not affected. As the DHCP server is on a different VLAN to most of my SL servers, a few of them were unable to renew their DHCP leases. If you are using SL6 and the NetworkManager: https://bugzilla.redhat.com/show_bug.cgi?id=829499 -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL giving up on DHCP search
On Fri, Aug 03, 2012 at 04:15:24PM -0400, Nico Kadel-Garcia wrote: On Fri, Aug 3, 2012 at 2:15 PM, Konstantin Olchanski olcha...@triumf.ca wrote: On Thu, Aug 02, 2012 at 06:51:11PM +, Adam Bishop wrote: Yesterday afternoon the core router on our network decided to have a short nap and stopped routing packets for an hour or so. Layer 2 connectivity was not affected. As the DHCP server is on a different VLAN to most of my SL servers, a few of them were unable to renew their DHCP leases. If you are using SL6 and the NetworkManager: https://bugzilla.redhat.com/show_bug.cgi?id=829499 If you're using NetworkManager for *anything* on a server, don't. This was and still is good advice for SL5 based systems. On SL6, (after some initial doubts,) I find the NetworkManager to be quite good at handling statically configured interfaces (see note 1). For DHCP-configured addresses, it seems to work well enough, except for the referenced bug, which is NOT a regression from SL5 without NM (see note 2). YMMV, as always. Note 1: Why use NM to manage static IP addresses?!? It so happens that for computers with 2 network interfaces, and NM will assign the one static IP address to the interface that has a cable plugged into it. No need to remember which plug on the back of the computer is eth0 or eth1 and no need to cover the wrong plug with black tape. Plus the NM GUI nm-connection-editor is better than the old system-config-network GUI and I can still vi the config files directly. Note 2: SL6 with NM usually survives a network outage, but SL5 without NM does NOT survive long network outages because of a ypbind crash (https://bugzilla.redhat.com/show_bug.cgi?id=717069) -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL giving up on DHCP search
On Fri, Aug 03, 2012 at 04:40:38PM -0600, Nathan wrote: On Fri, Aug 3, 2012 at 3:43 PM, Konstantin Olchanski olcha...@triumf.ca wrote: On Fri, Aug 03, 2012 at 04:15:24PM -0400, Nico Kadel-Garcia wrote: If you're using NetworkManager for *anything* on a server, don't. This was and still is good advice for SL5 based systems. On SL6, (after some initial doubts,) I find the NetworkManager to be quite good at handling statically configured interfaces (see note 1). Well I don't. I find that NetworkManager prevents me from setting up ethernet bridges entirely on SL6 unless I simply turn it off. I agree. I think NM was designed for handling Wifi on laptops, but just happens to work mostly okey for plain wired interfaces. Bridges, bonding, vlans, aliases (multiple IP on the same physical eth) are right out. Such a huge amount of work for such big infractructure for so limited function. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: is the drop to fsck visual fixed in 6.3?
On Wed, Jul 18, 2012 at 12:47:22PM -0700, Todd And Margo Chester wrote: Any of you working with 6.3 beta know is the bug where you drop to fsck at boot and its gives no visual indication is fixed? (One of these days I am going to just flip the power off thinking it is crashed and ...) You are supposed to remove rhgb and quiet from the kernel command line in grub. Then your problem goes away. (Ubuntu co are one step in front of everybody on this - their boot screen is completely blank from GRUB to X11 login. If the same people built cars, there would be no speedometer, no fuel guage and no radio volume turn-knob). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: is the drop to fsck visual fixed in 6.3?
On Fri, Jul 20, 2012 at 01:17:47AM +0200, David Sommerseth wrote: ... even an automatic fsck shouldn't cause much extra delay next time you boot. With full respect, extra delay being a subjective term, etc, but do you have any idea how long it takes to fsck a 20TB filesystem 99% full with a mixture of small and big files? (Hint: it takes more than 30 seconds). But I guess it is the modern view of things: if it is quick on my laptop it would not cause much extra delay for anybody else. No need to put numbers on it or think about scaling (at least fsck is mostly O(n) in disk size). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
