Re: SL vs. RPMForge repo
On 15 April 2011 20:37, Brunner, Brian T. wrote: > All my field hardware is non-PAE (AMD Geode LX800 => -march=586); as are > many, if not most embedded and/or low-power targets. > I'm running RH7.3 (pre-Fedora) because I need to hack the kernel source > to support legacy hardware. I still have my RH9 installation disks but no longer run the OS. Being a person who is loath to make change just for the sake of it, my pathway to the present was RH9 ---> EL5 ---> EL6. > I would like (greatly) to see a non-PAE 32-bit 586-aware kernel > available, and to be able to yum install full-kernel-source The wish list gets longer! Can I just clarify that Dag and I were musing about a non-PAE 32-bit i686 kernel for SL6 . . . i586 may be possible. Alan.
Re: SL vs. RPMForge repo
On 15 April 2011 20:02, Lamar Owen wrote: > On the non-linux side, have a VAXstation 4000 still up, controlling a heavily > modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even > though it weighs 7,000+ pounds avoirdupois. Cowabunga! That brings back memories! Alan.
Re: TESTING - openafs update for SL4 and SL5
My apologies for taking so long on this. Everything is ready and tested for this update to go out. We plan on pushing this security update out to all SL4 and SL5 machines on Wednesday, April 20, 2011. Kernel modules for all released kernels have been built and are now available in the testing area's. Thank You Troy Dawson On 02/21/2011 04:14 PM, Troy J Dawson wrote: Hello, There is a new security update for openafs. This update addresses CVE-2011-0430 and CVE-2011-0431 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0430 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0431 This update will also bring all the SL4 and SL5 openafs versions up to the same version. We have put this update into the testing area, so that if people want to test the update before it is released they can. This update will go out on Tuesday March 1, 2011 Note: We haven't been able to get *every* kernel module built yet. We have only done them for the past 5 or 6 kernels. We will have all the kernel-modules built by the time this errata is released. To test or update SL4 --- yum --enablerepo=sl-testing update openafs\* kernel-module\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/40rolling/testing/i386/RPMS/openafs/ http://ftp.scientificlinux.org/linux/scientific/40rolling/testing/x86_64/RPMS/openafs/ openafs-1.4.14-80.sl4 SL5 --- yum --enablerepo=sl-testing update openafs\* kernel-module\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/openafs/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/openafs/ openafs-1.4.14-80.sl5 Thanks Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __ -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/SCF/FEF/SLSMS Group __
RE: SL vs. RPMForge repo
owner-scientific-linux-us...@listserv.fnal.gov wrote: > On 14 April 2011 23:48, Dag Wieers wrote: >> On Thu, 14 Apr 2011, Alan Bartlett wrote: >>> >>> I believe that processor does not support PAE, so you are out of >>> luck. >>> >>> Again, this is a Red Hat decision. The EL6 32-bit kernel is what >>> was a PAE kernel for EL5. Putting it another way, the EL5 32-bit >>> non-PAE kernel has been dropped for EL6 and so what would known as >>> a PAE kernel has had that descriptor removed. > >> There might be a case for a drop-in replacement kernel that supports >> non-PAE 32bit systems. So at least a PXE/USB installation works >> fine, without the need to respin the ISO (which may be too >> troublesome). >> >> Of course, that would also mean we'd have to update that non-PAE >> kernel as part of that repository. If people have a clear need for >> this (and there is at least one committed to support this) do speak >> up. It might be the beginning of something beautiful... > > You've obviously had similar thoughts just like mine . . . but have > developed them that bit further. > > It really depends upon the need for non-PAE 32-bit kernels for EL6. > > Alan. All my field hardware is non-PAE (AMD Geode LX800 => -march=586); as are many, if not most embedded and/or low-power targets. I'm running RH7.3 (pre-Fedora) because I need to hack the kernel source to support legacy hardware. I would like (greatly) to see a non-PAE 32-bit 586-aware kernel available, and to be able to yum install full-kernel-source Insert spiffy .sig here: Life is complex: it has both real and imaginary parts. //me *** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
Re: SL vs. RPMForge repo
On Fri, Apr 15, 2011 at 12:02 PM, Lamar Owen wrote: > On the non-linux side, have a VAXstation 4000 still up, controlling a heavily > modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even > though it weighs 7,000+ pounds avoirdupois. Wow, the VAX machine I had access to was retired 20 years ago ... Akemi
Re: SL vs. RPMForge repo
On Friday, April 15, 2011 11:47:07 AM you wrote: > Phil In looking into the background of non-pae c > pu's this seems an issue for mobile processors Pentium M based 400mhz FSB > and before. > One wouldn't think that there were this many devices out there still > kicking, but I guess I am wrong. Heh, I have Pentium II's, III's, and even a couple of Pentium Pro's still in production, in addition to a dozen or so Pentium M laptops (unsure of FSB, but these laptops are probably PAE-capable); also several Pentium III and 4 laptops. If it works, and does the job reliably. On the non-linux side, have a VAXstation 4000 still up, controlling a heavily modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even though it weighs 7,000+ pounds avoirdupois.
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
On 04/14/2011 04:41 PM, jdow wrote:
On 2011/04/13 13:08, Todd And Margo Chester wrote:
On 04/13/2011 12:38 PM, Phil Schaffner wrote:
Can't say it is perfect, but "riddled with bugs" seems a bit
exaggerated.
My overall experiences with VB have been very positive.
Phil
Not "exaggerated". Years of pain and experience.
Wait until you get your job threatened over it. Fortunately, as a
consultant, they are not my only customer. If loose them, I will
have to hustle and find someone else. Still sucks though, especially
when you have worked for them for over ten years and you
have become friends with many of them.
-T
A collection of some of my "recent" bug reports.
http://www.virtualbox.org/ticket/7628
http://www.virtualbox.org/ticket/7643
http://www.virtualbox.org/ticket/7607
http://www.virtualbox.org/ticket/7948
http://www.virtualbox.org/ticket/7957
http://www.virtualbox.org/ticket/7772
And the one I almost got and still may get fired over:
http://www.virtualbox.org/ticket/8478
Is there any reason you are stubbornly playing with 3.0.12 and
not upgrading to the latest build? It seems to correct all of
the problems I had with the earlier builds. The machines translate
in directly and "just work."
{^_^} Joanne Dow.
Hi Joanne,
"just work". Oh boy.
4.0.2 is slower than h--- on my XP guest at my office. I had rip 4.0.2
out and reinstall 3.2.12. There are also benchmarks out there showing
4 to be slower than 3.
Also, I do check the change logs for fixes to my bugs. 4.x
did not fix a single issue of mine. You are blessed that Oracle fixes
your. I wish they would fix mine.
I also ask on my bug reports and they do/did not answer me.
Don't remember if I have asked lately.
It is also my experience with VB bugs that when a new revision hits
and they thinks they have fixed something, that they ask me to
test it. They had not asked me on any of these bugs.
And to be completely honest, after calling all over Oracle trying
to find a support contract, I have lost confidence in Oracle.
The last on this issue is that they (Oracle) do not have a "pricing
schedule"
for VB support yet and do not know when they will. Oh yes, and they will
"reach out" to me. Eeee! I did finally ask a sales rep to
stop using that term, as it gave me the creeps, and he did respect
it, somewhat.
My VM's out there are production level machines. To answer your
question as to why I am holding out, I am holding out with 3.2.12
for the same reason are running Enterprise Linux and not Fedora
Core. I can not have any (more) screw ups.
Hope that explains it,
-T
p.s. on the other hand, I have a great deal of confidence in Red Hat
and if feasible, I am going to move all my VM's over to KVM. Poking
around on their developers mailing list shows a tremendous amount
of development. No foot dragging or dumb looks there.
Odd behavior of rhgb in SL6
I get an odd behavior during the boot of SL6. I'm running, dual boot w/WinXP, on a Dell Latitude D610 laptop that is parked in a Dell D-Dock PD01X docking station. My mouse and keyboard, both PS/2, are connected to the docking station. If I let SL6 go through a normal boot running rhgb, "Red Hat Graphical Boot," the mouse and keyboard are ignored and the system does not respond. If I hit during the graphical boot, revealing the underlying text boot, the mouse and keyboard are recognized and the system responds. The fix is easy, edit grub.conf and eliminate rhgb from the SL6 stanza. This is fine by me, as I like to have the detailed boot info. Did not have this problem with SL5x. Do not have this problem with WinXP. Docking station interconnect has been cleaned.
Re: SL vs. RPMForge repo
- Original Message - From: Jon Sent: 04/15/11 11:21 AM To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Re: SL vs. RPMForge repo It appears that not all Pentium M CPUs are created equal. I have SL6 installed in a dual boot config w/WinXP on my Dell Latitude D610 w/a Pentium M, 1.86GHz (x86 Family 6 Model 13 Stepping 8). A check with Auslogics' System Information analyzer indicates that it supports PAE. If the limitations of the current 32-bit kernel are spelled out and posted, at least folks would have a heads up for potential roadblocks. -- Jon On 14 Apr 2011 at 19:50, Phil Schaffner wrote: [snip] > My non-PAE-capable IBM T42p Pentium-M laptop is dead ATM from a fan > failure, but the possibility of a compatible SL6 release might prompt > me to resurrect it. Part of the reason I have not bothered to hack the > hardware is the upstream decision to drop support for non-PAE 32-bit > systems. > > As a matter of principle I heartily endorse the idea. There is a lot > of functional hardware out there that does not do PAE, but still has life > left in it. > > Phil In looking into the background of non-pae c pu's this seems an issue for mobile processors Pentium M based 400mhz FSB and before. One wouldn't think that there were this many devices out there still kicking, but I guess I am wrong. --- Dan :w! saves
Re: SL vs. RPMForge repo
I would like to see this - I very much doubt that all my non-PAE hardware will go away by the time I want to have switched to SL6. thanks! -- Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Fri, 15 Apr 2011, Dag Wieers wrote: There might be a case for a drop-in replacement kernel that supports non-PAE 32bit systems. So at least a PXE/USB installation works fine, without the need to respin the ISO (which may be too troublesome). Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful...
Re: SL vs. RPMForge repo
It appears that not all Pentium M CPUs are created equal. I have SL6 installed in a dual boot config w/WinXP on my Dell Latitude D610 w/a Pentium M, 1.86GHz (x86 Family 6 Model 13 Stepping 8). A check with Auslogics' System Information analyzer indicates that it supports PAE. If the limitations of the current 32-bit kernel are spelled out and posted, at least folks would have a heads up for potential roadblocks. -- Jon On 14 Apr 2011 at 19:50, Phil Schaffner wrote: [snip] > My non-PAE-capable IBM T42p Pentium-M laptop is dead ATM from a fan > failure, but the possibility of a compatible SL6 release might prompt > me to resurrect it. Part of the reason I have not bothered to hack the > hardware is the upstream decision to drop support for non-PAE 32-bit > systems. > > As a matter of principle I heartily endorse the idea. There is a lot > of functional hardware out there that does not do PAE, but still has life > left in it. > > Phil
Re: [OT] SL vs. RPMForge repo
Nico Kadel-Garcia wrote on 04/14/2011 10:19 PM: Is it worth it? The first reviews on that hardware are almost 7 years old. Can't argue with your logic, but when doing it on personal time I value the satisfaction of making something work, and avoiding the hassle and waste of recycling, to be worth a lot. Perhaps the inherited values of my Great Depression era parents. :-) Phil -- Philip R. Schaffner, RTD/ESB Phone: (757)864-1809 NASA/Langley Research Center, MS 473 FAX: (757)864-7891 8 North Dryden Street, B1299, Room 109 Hampton, VA 23681-2199
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
Hi, Todd KVM unders SL5/6 works quite nice for windows guests, including terminal session into them. Virt-manager console is noticeably slow, and has at least one annoying bug (when win7 guest prompts you to chose whether your network is home or work or internet, virt-manager freezes ad needs to be killed). But rdp session runs just fine. Bridge networking - not sure what do you mean. When you install kvm and ibvirt, a virtual bridge is created for you as a default network. It provides guests dhcp address in a private network withing the host and NATed access to internet. This all works with no additional config on your side. If you need your guests to be on the same network(s) as your host system, then you need to create an appropriate bridge yourself, outside of KVM and libvirt, but then libvirt will happily use it. Works like a charm with VLANs as well. So, if you project is kind of virtual desktop infrastructure, then I'd really suggest you look at kvm... cheers Artem. > I have heard that VB's interface is better. I have also heard that Red Hat > is cleaning up theirs. I will see. VB use to use the same "bridge" > networking. > I do believe I kept a copy of it around somewhere. It would be nice if > KVM handled bridge networking automatically the way VB does. > I will suffer a difficult interface for fewer bugs in operation. > > -T >
Re: SL vs. RPMForge repo
Le 15/04/2011 00:48, Dag Wieers a écrit : Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful... Yes, I do have a clear need for this. My company is specialized in providing Linux solutions for professionals (mostly small town halls, schools, public libraries). From time to time, I give one of the various consumer grade distros a spin, but I always seem to come back to some RHEL clone on desktops as well as on servers. More often than not, I have to perform installs on hardware that's quite old, if not completely outdated. The sort of dinosaur hardware that nothing - short of a meteor strike - can kill. CentOS 5 is still churning away on one of my client's PIII-500 with 128 MB RAM (recently beefed up to 256 MB). Of course, most of the time, folks ask for decent hardware. But I like to still be able to install a decent system on older hardware. Cheers from the sunny South of France, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32
