Re: Scientific Linux 7 ALPHA
On 07/07/2014 07:45 PM, Konstantin Olchanski wrote: 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. For EL6 I use the livecd-iso-to-disk tool. For my CentOS 6.5 installer USB stick, I joined the two DVD images together (using the mkdvdiso.sh script that has been around for years) and then issued: livecd-iso-to-disk --format --reset-mbr CentOS-6.5-x86_64-bin-DVDDL.iso /dev/sdb where /dev/sdb is the full disk device for the USB stick. You can tweak the mkdvdiso.sh script to add your kickstart file(s) into the iso and feed it a single iso. The mkdvdiso.sh script can be found at http://wiki.centos.org/TipsAndTricks/CDtoDVDMedia (yes, yes, I know it says CD to DVD media, but I also know that it works with two single-layer DVD images or even a single DVD image). The one caveat is that your kickstart is going to have to deal with the fact that during install the USB stick tends to come up as /dev/sda and your first hard disk as /dev/sdb, and you need to have anaconda install the bootloader to /dev/sdb but as if it were the first BIOS drive (anaconda in interactive mode allows this these days; early EL6 did not allow this to be done easily). And yes I know the tool is called livecd-iso-to-disk but it can and does create installer media; I've been doing it for a while this way. You can find the tool in the livecd-tools package from EPEL.
Re: Scientific Linux 7 ALPHA
For the next itteration of SL7 we've got a fixed package loaded. We've reproduced the fix from upstream bug #1116921 (based on your report) Pat On 07/07/2014 10:24 PM, Bill Maidment wrote: Yes. It is reproducible. The major difference between the RHEL7rc install and the SL7alpha install is that RHEL7rc was bare-metal and SL7alpha was a KVM guest under SL6.5 host. -Original message- From:Bill Maidment b...@maidment.com.au Sent: Tuesday 8th July 2014 10:51 To: Pat Riehecky riehe...@fnal.gov; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; scientific-linux-de...@listserv.fnal.gov Subject: RE: Scientific Linux 7 ALPHA I think this may be an SL issue as python-ethtool installed OK with RHEL7rc. I'll try a fresh install of SL7alpha to see if it is reproducible. -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Tuesday 8th July 2014 1:36 To: Bill Maidment b...@maidment.com.au; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; scientific-linux-de...@listserv.fnal.gov Subject: Re: Scientific Linux 7 ALPHA That's not right... Looks like we need an upstream bug for that. Pat On 07/04/2014 10:35 PM, Bill Maidment wrote: The actual error was caused by python-ethtool not being installed, so firstboot crashed. -Original message- From:Bill Maidment b...@maidment.com.au Sent: Saturday 5th July 2014 11:13 To: Pat Riehecky riehe...@fnal.gov; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: RE: Scientific Linux 7 ALPHA Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package:firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid:0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: [SCIENTIFIC-LINUX-USERS] [SL-Users] Re: Scientific Linux 7 ALPHA
On 07/07/2014 09:11 PM, John Lauro wrote: One thing noticed missing on testing... docker package is missing from SL7. Just downloaded and installed Centos 7, and it has it (via yum). Checking into a little more, it's in the extras repo (default enabled with Centos). Could not find an extras repo on SL7 (no yum config to add it, or an entry to update in /etc/yum.repos.d, but was a rather quick scan, could of missed something). PS: I did have a strange issue where network seemed to go out on me at logout and come back when I first installed a few days ago, but has been stable after disabling networkmanager, and I noticed those packages were updated so it might be already fixed. Overall, everything else I tested so far seems to be good besides missing packages... Thanks for the feedback, right now we are trying to focus in on the core os before we worry about the Extras repo. I've got those built, but miscellaneous docker tricks may distract from our current testing focus. Hope all is well, Pat -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: [SCIENTIFIC-LINUX-USERS] Scientific Linux 7 ALPHA
On 07/07/2014 04:56 PM, Horvath Andras wrote: A question: Will the point releases of SL7 be supported long term separatly as it was on SL6 (unlike on CentOS) ? Our current plans involve similar support for SL7 as in SL6. Pat -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: Scientific Linux 7 ALPHA rc.local doesn't work
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
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 rc.local doesn't work
On 8 July 2014 08:07, Semi s...@bgu.ac.il 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 What happens if you run /etc/rc.d/rc.local start by hand? Also what does journalctl | grep rc.local say -- Stephen J Smoogen.
Re: Scientific Linux 7 ALPHA
On Mon, 7 Jul 2014, Konstantin Olchanski wrote: 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. I created a newer version of the SL6.5 ISO images that worked with dd. Please indicate exact image url that was used for this test. (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. -Connie Sieh
Re: Scientific Linux 7 ALPHA
Thought I'd already gotten that, I'll tend to it shortly. Thanks for the feedback! Pat On 07/04/2014 08:10 PM, Bill Maidment wrote: Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package:firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid:0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: [SCIENTIFIC-LINUX-USERS] Scientific Linux 7 ALPHA
On 07/04/2014 10:54 AM, Yasha Karant wrote: A practical question: will any alpha or beta SL 7 distro based install be able to change into 7x production or will a full reinstall be required? I would strongly recommend a full reinstall from any Alpha/Beta before going into production. -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: Scientific Linux 7 ALPHA
On 07/06/2014 07:05 AM, Semi wrote: Useful package *xfig* is absent. Looks like upstream has removed it. You could request it for EPEL. On 04/07/2014 00:17, Pat Riehecky wrote: Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: Scientific Linux 7 ALPHA
One of the advantages of SL is that it includes packages that are not part of the upstream but are useful in scientfic environments. Xfig, IMHO, is one of those packages; if SL can include it, it will save me some hassle. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Mon, 7 Jul 2014, Orion Poplawski wrote: On 07/06/2014 07:05 AM, Semi wrote: Useful package *xfig* is absent. Looks like upstream has removed it. You could request it for EPEL. On 04/07/2014 00:17, Pat Riehecky wrote: Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: Scientific Linux 7 ALPHA
That's not right... Looks like we need an upstream bug for that. Pat On 07/04/2014 10:35 PM, Bill Maidment wrote: The actual error was caused by python-ethtool not being installed, so firstboot crashed. -Original message- From:Bill Maidment b...@maidment.com.au Sent: Saturday 5th July 2014 11:13 To: Pat Riehecky riehe...@fnal.gov; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: RE: Scientific Linux 7 ALPHA Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package:firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid:0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: Scientific Linux 7 ALPHA
On Fri, 4 Jul 2014, Nico Kadel-Garcia wrote: On Thu, Jul 3, 2014 at 5:17 PM, Pat Riehecky riehe...@fnal.gov wrote: Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ OK, I'm *impressed*. Did our faithful packagers work from an RHEL susbscription's SRPM's, or resolve the confusing new layout of the https://git.centos.org repository? There was already a copy in my local rsync mirror, and I'm happy to install from there and keep the lod off your servers. Getting the alpha into people's hands this quickly is one of the reasons I've come to personally prefer Scientific Linux over CentOS. Many of the packages were built from the src.rpms provided by TUV for the public release candidate for RHEL 7 that was released in April. All of the packages that were released after the Release Candidate were built from TUV source from git.centos.org . -Connie Sieh
Re: Scientific Linux 7 ALPHA
On Fri, 4 Jul 2014, Yasha Karant wrote: As has been made clear, no conspiracy in terms of getting the matter ported -- simply a possibly different set of impediments to building from source. (Anyone checked if the Oracle EL7 port is done yet? What about the Princeton port?) The conspiracy will be visible if there are significant performance degradations of CentOS 7 source compared to real RHEL source build distros/ports, and if RHEL 7 intended codes (as from the commercial sector) do not work on the CentOS based distros. The real conspiracy, if any, would be for security compromises left open in the CentOS based ports compared with the RHEL real source based distro. This was done in short order, not long after CentOS released pre-production distros. CentOS, as a division of Red Hat, presumably had a simpler job than the SL team, unless of course there were sub-rosa details from Red Hat to CentOS that also then went to SL. Is SL still a separate distro, or is it in fact a CentOS SIG/variant (probably the latter given that RHEL source was not used, but rather CentOS)? SL is still a separate distro. From the announcement These packages were built at Fermilab from TUV's sources. . A practical question: will any alpha or beta SL 7 distro based install be able to change into 7x production or will a full reinstall be required? It is suggested that a new install be done as we do not know what issues would happen with the continued use of this pre production version. Yasha Karant On 07/04/2014 04:37 AM, Bill Maidment wrote: Pat That's amazing work by you guys. So much for all the conspiracy theories ;-) Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -Connie Sieh
Scientific Linux 7 ALPHA
Hi. The iso in http://ftp.scientificlinux.org/linux/scientific/7rolling/x86_64/iso/ This is 6.2 Gb, is this right? Arturo
Re: Scientific Linux 7 ALPHA
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 . Arturo -Connie Sieh
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
CentOS-7.0-1406-x86_64-DVD 06-Jul-2014 17:33 4148166656 4 148 166 656 bytes should fit on one single layer DVD, as a DVD+R Single Layer 4,700,372,992 bytes DVD-R Single Layer 4,707,319,808 bytes Presumably, the production version of SL 7 should be approximately the same size. I note that only X86-64 is available; have I missed something about supported ISAs, or will there also be an IA-32 port/distribution as well? Yasha Karant On 07/07/2014 01:29 PM, 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 . Arturo -Connie Sieh
Re: Scientific Linux 7 ALPHA
On Mon, 7 Jul 2014, Konstantin Olchanski wrote: 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! Go for it. -Connie Sieh
Re: Scientific Linux 7 ALPHA
On Mon, 7 Jul 2014, Yasha Karant wrote: CentOS-7.0-1406-x86_64-DVD 06-Jul-2014 17:33 4148166656 4 148 166 656 bytes should fit on one single layer DVD, as a DVD+R Single Layer 4,700,372,992 bytes DVD-R Single Layer 4,707,319,808 bytes Presumably, the production version of SL 7 should be approximately the same size. We did release a install DVD for SL 6 and 2 DVD's for the everything install . It was hard to figure out what should be on a single DVD as there are many differences of opinion on what belongs on it. I note that only X86-64 is available; have I missed something about supported ISAs, or will there also be an IA-32 port/distribution as well? TUV is only releasing X86-64 . -Connie Sieh Yasha Karant On 07/07/2014 01:29 PM, 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 . Arturo -Connie Sieh
Re: Scientific Linux 7 ALPHA
A question: Will the point releases of SL7 be supported long term separatly as it was on SL6 (unlike on CentOS) ?
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: Scientific Linux 7 ALPHA
I think this may be an SL issue as python-ethtool installed OK with RHEL7rc. I'll try a fresh install of SL7alpha to see if it is reproducible. -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Tuesday 8th July 2014 1:36 To: Bill Maidment b...@maidment.com.au; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; scientific-linux-de...@listserv.fnal.gov Subject: Re: Scientific Linux 7 ALPHA That's not right... Looks like we need an upstream bug for that. Pat On 07/04/2014 10:35 PM, Bill Maidment wrote: The actual error was caused by python-ethtool not being installed, so firstboot crashed. -Original message- From:Bill Maidment b...@maidment.com.au Sent: Saturday 5th July 2014 11:13 To: Pat Riehecky riehe...@fnal.gov; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: RE: Scientific Linux 7 ALPHA Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package: firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid: 0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: [SL-Users] Re: Scientific Linux 7 ALPHA
One thing noticed missing on testing... docker package is missing from SL7. Just downloaded and installed Centos 7, and it has it (via yum). Checking into a little more, it's in the extras repo (default enabled with Centos). Could not find an extras repo on SL7 (no yum config to add it, or an entry to update in /etc/yum.repos.d, but was a rather quick scan, could of missed something). PS: I did have a strange issue where network seemed to go out on me at logout and come back when I first installed a few days ago, but has been stable after disabling networkmanager, and I noticed those packages were updated so it might be already fixed. Overall, everything else I tested so far seems to be good besides missing packages...
RE: Scientific Linux 7 ALPHA
Yes. It is reproducible. The major difference between the RHEL7rc install and the SL7alpha install is that RHEL7rc was bare-metal and SL7alpha was a KVM guest under SL6.5 host. -Original message- From:Bill Maidment b...@maidment.com.au Sent: Tuesday 8th July 2014 10:51 To: Pat Riehecky riehe...@fnal.gov; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; scientific-linux-de...@listserv.fnal.gov Subject: RE: Scientific Linux 7 ALPHA I think this may be an SL issue as python-ethtool installed OK with RHEL7rc. I'll try a fresh install of SL7alpha to see if it is reproducible. -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Tuesday 8th July 2014 1:36 To: Bill Maidment b...@maidment.com.au; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV; scientific-linux-de...@listserv.fnal.gov Subject: Re: Scientific Linux 7 ALPHA That's not right... Looks like we need an upstream bug for that. Pat On 07/04/2014 10:35 PM, Bill Maidment wrote: The actual error was caused by python-ethtool not being installed, so firstboot crashed. -Original message- From:Bill Maidment b...@maidment.com.au Sent: Saturday 5th July 2014 11:13 To: Pat Riehecky riehe...@fnal.gov; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: RE: Scientific Linux 7 ALPHA Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package: firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid: 0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: Scientific Linux 7 ALPHA
Useful package *xfig* is absent. On 04/07/2014 00:17, Pat Riehecky wrote: Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74
Re: [SL-Users] Re: Scientific Linux 7 ALPHA - Updating
The cron scripts I mentioned for doing local rsyncs are up at https://github.com/nkadel/nkadel-rsync-scripts/ There's also my old 'reposync' script, suitable for slurping yum based access repositories into a local mirror. It's what I used to use to pull RHEL SRPM's or RPM's, *only with a valid subscription*, so I could compare them to the equivalent CentOS or SL packages. The 'rsync-sl-obsolete.sh' was especially useful for environments where people *insisted*, for CentOS or SL, on using only a single locked down distribution that was no longer on the primary mirrors.
Re: [SL-Users] Re: Scientific Linux 7 ALPHA - Updating
On 07/04/2014 09:12 PM, Nico Kadel-Garcia wrote: On Fri, Jul 4, 2014 at 10:11 AM, Akemi Yagi amy...@gmail.com wrote: All, Please refrain from posting anything other than testing results of the released SL packages in this thread. Let's keep this one free of trolls. Akemi The SL 7 Alpha is running well in PC Virtualbox (my virtualiztion toolsuite of choice). The add-on tools for more graseful focus switching and for mouse management are not yet installable, but I expect that to be fixed upstream by PC Virtualbox, now that RHEL 7 is in production. I can report it also runs well in and SL6 Virtualbox VM. I saw the firstboot problem report. My question is how often should we download and reinstall from scratch vs using yum update (or autoupdate or cron)? I assume the only reason to download the DVD image is to test changes to the install procedure and yum update will end up with the same installation. I just want to confirm that how best to help the process. Joe
Re: [SL-Users] Re: Scientific Linux 7 ALPHA - Updating
On Sat, Jul 5, 2014 at 10:43 AM, Joseph Areeda newsre...@areeda.com wrote: On 07/04/2014 09:12 PM, Nico Kadel-Garcia wrote: On Fri, Jul 4, 2014 at 10:11 AM, Akemi Yagi amy...@gmail.com wrote: All, Please refrain from posting anything other than testing results of the released SL packages in this thread. Let's keep this one free of trolls. Akemi The SL 7 Alpha is running well in PC Virtualbox (my virtualiztion toolsuite of choice). The add-on tools for more graseful focus switching and for mouse management are not yet installable, but I expect that to be fixed upstream by PC Virtualbox, now that RHEL 7 is in production. I can report it also runs well in and SL6 Virtualbox VM. I saw the firstboot problem report. My question is how often should we download and reinstall from scratch vs using yum update (or autoupdate or cron)? I assume the only reason to download the DVD image is to test changes to the install procedure and yum update will end up with the same installation. I just want to confirm that how best to help the process. If you're a weasel and want to save speed and bandwidth: Set up a local rsync mirror from any of the locally fast upstream repositories, and slap a web server in front of it. Use the 'netinstall' from th elocal mirror,, or even a PXE setup, not the full DVD, to point to the local mirror. Ideally, set up a kickstart file too on the local mirror, ideally tied to a the PXE setup. Then just use the PXE or netinstall ISO to do a kickstarted, network based re-install. That way, you don't even have to download the DVD images, which are quite builky. If you like, I'll post my download scripts
Re: [SL-Users] Re: Scientific Linux 7 ALPHA - Updating
On 07/05/2014 08:03 AM, Nico Kadel-Garcia wrote: On Sat, Jul 5, 2014 at 10:43 AM, Joseph Areeda newsre...@areeda.com wrote: On 07/04/2014 09:12 PM, Nico Kadel-Garcia wrote: On Fri, Jul 4, 2014 at 10:11 AM, Akemi Yagi amy...@gmail.com wrote: All, Please refrain from posting anything other than testing results of the released SL packages in this thread. Let's keep this one free of trolls. Akemi The SL 7 Alpha is running well in PC Virtualbox (my virtualiztion toolsuite of choice). The add-on tools for more graseful focus switching and for mouse management are not yet installable, but I expect that to be fixed upstream by PC Virtualbox, now that RHEL 7 is in production. I can report it also runs well in and SL6 Virtualbox VM. I saw the firstboot problem report. My question is how often should we download and reinstall from scratch vs using yum update (or autoupdate or cron)? I assume the only reason to download the DVD image is to test changes to the install procedure and yum update will end up with the same installation. I just want to confirm that how best to help the process. If you're a weasel and want to save speed and bandwidth: Set up a local rsync mirror from any of the locally fast upstream repositories, and slap a web server in front of it. Use the 'netinstall' from th elocal mirror,, or even a PXE setup, not the full DVD, to point to the local mirror. Ideally, set up a kickstart file too on the local mirror, ideally tied to a the PXE setup. Then just use the PXE or netinstall ISO to do a kickstarted, network based re-install. That way, you don't even have to download the DVD images, which are quite builky. If you like, I'll post my download scripts Thanks Nico, I would like to see your scripts. What I will be testing is what changes are needed to our packaged and unpackaged applications. Excuse the basic questions but I'm more of a developer than a sysadmin. If I understand your recommendations the system including user accounts will be rebuilt on each boot. So if I want to work through multiple reboots I could put my home directory on an NFS mount and end up with fresh software but the same environment. Correct? Thanks. I'm sure others in our collaboration will be doing more extensive tests. Best, Joe
Re: [SL-Users] Re: Scientific Linux 7 ALPHA - Updating
On Sat, Jul 5, 2014 at 11:23 AM, Joseph Areeda newsre...@areeda.com wrote: On 07/05/2014 08:03 AM, Nico Kadel-Garcia wrote: On Sat, Jul 5, 2014 at 10:43 AM, Joseph Areeda newsre...@areeda.com wrote: On 07/04/2014 09:12 PM, Nico Kadel-Garcia wrote: Set up a local rsync mirror from any of the locally fast upstream repositories, and slap a web server in front of it. Use the 'netinstall' from th elocal mirror,, or even a PXE setup, not the full DVD, to point to the local mirror. Ideally, set up a kickstart file too on the local mirror, ideally tied to a the PXE setup. Then just use the PXE or netinstall ISO to do a kickstarted, network based re-install. That way, you don't even have to download the DVD images, which are quite builky. If you like, I'll post my download scripts Thanks Nico, I would like to see your scripts. Let me put them up at github.com, and give me a day. What I will be testing is what changes are needed to our packaged and unpackaged applications. Excuse the basic questions but I'm more of a developer than a sysadmin. If I understand your recommendations the system including user accounts will be rebuilt on each boot. So if I want to work through multiple reboots I could put my home directory on an NFS mount and end up with fresh software but the same environment. Correct? That's one workable way, yes. If PXE and kickstart can be set up correctly, the kickstart can even set up your NFS mounted home directory and local authentication and sudo privileges, and the PXE can allow a rebuild me from scratch option at boot time. that will select and automatically use the relevant kickstart file. It can even be set to auto-rebuild every time, if you want. I've done this a lot for hardware testing, and for building clusters. One of the limitations is local bandwidth: if you're rebuilding a bunch of times from the upstream SL 7 Alpha website, well, that's rude. It's hundereds of megs, possibly even Gigs, of bandwidth. Set up a local mirror to pull from instead, and keep *that* updated. Thanks. I'm sure others in our collaboration will be doing more extensive tests. Best, Joe
Re: [SL-Users] Re: Scientific Linux 7 ALPHA - Updating
On 07/05/2014 11:02 AM, Nico Kadel-Garcia wrote: On Sat, Jul 5, 2014 at 11:23 AM, Joseph Areeda newsre...@areeda.com wrote: On 07/05/2014 08:03 AM, Nico Kadel-Garcia wrote: On Sat, Jul 5, 2014 at 10:43 AM, Joseph Areeda newsre...@areeda.com wrote: On 07/04/2014 09:12 PM, Nico Kadel-Garcia wrote: Set up a local rsync mirror from any of the locally fast upstream repositories, and slap a web server in front of it. Use the 'netinstall' from th elocal mirror,, or even a PXE setup, not the full DVD, to point to the local mirror. Ideally, set up a kickstart file too on the local mirror, ideally tied to a the PXE setup. Then just use the PXE or netinstall ISO to do a kickstarted, network based re-install. That way, you don't even have to download the DVD images, which are quite builky. If you like, I'll post my download scripts Thanks Nico, I would like to see your scripts. Let me put them up at github.com, and give me a day. What I will be testing is what changes are needed to our packaged and unpackaged applications. Excuse the basic questions but I'm more of a developer than a sysadmin. If I understand your recommendations the system including user accounts will be rebuilt on each boot. So if I want to work through multiple reboots I could put my home directory on an NFS mount and end up with fresh software but the same environment. Correct? That's one workable way, yes. If PXE and kickstart can be set up correctly, the kickstart can even set up your NFS mounted home directory and local authentication and sudo privileges, and the PXE can allow a rebuild me from scratch option at boot time. that will select and automatically use the relevant kickstart file. It can even be set to auto-rebuild every time, if you want. I've done this a lot for hardware testing, and for building clusters. One of the limitations is local bandwidth: if you're rebuilding a bunch of times from the upstream SL 7 Alpha website, well, that's rude. It's hundereds of megs, possibly even Gigs, of bandwidth. Set up a local mirror to pull from instead, and keep *that* updated. Thanks. I'm sure others in our collaboration will be doing more extensive tests. Best, Joe Thanks again, I appreciate the help. I've set up kickstart once, successfully and I'm ready to do battle with PXE. Just one of quick question for now, I'm sure more will follow later: The mirror I've started is rsync://mirror.mcs.anl.gov/scientific-linux/7rolling/x86_64/os I think that's all I need to maintain, correct? I'm in Los Angeles. Best, Joe
Re: Scientific Linux 7 ALPHA
On Thu, Jul 3, 2014 at 5:17 PM, Pat Riehecky riehe...@fnal.gov wrote: Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/ OK, I'm *impressed*. Did our faithful packagers work from an RHEL susbscription's SRPM's, or resolve the confusing new layout of the https://git.centos.org repository? There was already a copy in my local rsync mirror, and I'm happy to install from there and keep the lod off your servers. Getting the alpha into people's hands this quickly is one of the reasons I've come to personally prefer Scientific Linux over CentOS.
RE: Scientific Linux 7 ALPHA
Pat That's amazing work by you guys. So much for all the conspiracy theories ;-) Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: Scientific Linux 7 ALPHA
As has been made clear, no conspiracy in terms of getting the matter ported -- simply a possibly different set of impediments to building from source. (Anyone checked if the Oracle EL7 port is done yet? What about the Princeton port?) The conspiracy will be visible if there are significant performance degradations of CentOS 7 source compared to real RHEL source build distros/ports, and if RHEL 7 intended codes (as from the commercial sector) do not work on the CentOS based distros. The real conspiracy, if any, would be for security compromises left open in the CentOS based ports compared with the RHEL real source based distro. This was done in short order, not long after CentOS released pre-production distros. CentOS, as a division of Red Hat, presumably had a simpler job than the SL team, unless of course there were sub-rosa details from Red Hat to CentOS that also then went to SL. Is SL still a separate distro, or is it in fact a CentOS SIG/variant (probably the latter given that RHEL source was not used, but rather CentOS)? A practical question: will any alpha or beta SL 7 distro based install be able to change into 7x production or will a full reinstall be required? Yasha Karant On 07/04/2014 04:37 AM, Bill Maidment wrote: Pat That's amazing work by you guys. So much for all the conspiracy theories ;-) Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
RE: Scientific Linux 7 ALPHA
Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package:firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid:0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
RE: Scientific Linux 7 ALPHA
The actual error was caused by python-ethtool not being installed, so firstboot crashed. -Original message- From:Bill Maidment b...@maidment.com.au Sent: Saturday 5th July 2014 11:13 To: Pat Riehecky riehe...@fnal.gov; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: RE: Scientific Linux 7 ALPHA Pat I'm getting the following error report at logon: Last login: Fri Jul 4 23:36:13 EST 2014 on pts/0 ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1404480973 [root@sl7 ~]# abrt-cli list --since 1404480973 id 2dcb3b8c827f788139fffe4995e64f615530216e Directory: /var/tmp/abrt/Python-2014-07-05-02:28:51-4814 count: 8 executable: /usr/sbin/firstboot package:firstboot-19.9-1.el7 time: Sat 05 Jul 2014 02:28:51 EST uid:0 Run 'abrt-cli report /var/tmp/abrt/Python-2014-07-05-02:28:51-4814' for creating a case in Red Hat Customer Portal The Autoreporting feature is disabled. Please consider enabling it by issuing 'abrt-auto-reporting enabled' as a user with root privileges [root@sl7 ~]# Is this a TUV reference/script to be removed? Cheers Bill -Original message- From:Pat Riehecky riehe...@fnal.gov Sent: Friday 4th July 2014 7:23 To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Scientific Linux 7 ALPHA Users interested in Scientific Linux 7 ALPHA can review: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407L=scientific-linux-develT=0X=30246605F08F0DC7EDP=74 -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Re: [SL-Users] Re: Scientific Linux 7 ALPHA
On Fri, Jul 4, 2014 at 10:11 AM, Akemi Yagi amy...@gmail.com wrote: All, Please refrain from posting anything other than testing results of the released SL packages in this thread. Let's keep this one free of trolls. Akemi The SL 7 Alpha is running well in PC Virtualbox (my virtualiztion toolsuite of choice). The add-on tools for more graseful focus switching and for mouse management are not yet installable, but I expect that to be fixed upstream by PC Virtualbox, now that RHEL 7 is in production.
