Re: SL4 kernel
On 02/07/09 16:16, Troy Dawson wrote: Well ... this is a good place for the discussion. What *should* we do with those packages that redhat releases for the extended support series. Do you have access to them okay? I couldn't get to the rpms (or the src rpms) using my RHN account, but we have a fairly basic level of entitlements. I'll say this upfront that it's a bit of a pain. It's a piece of cake to look, download and build any src.rpm's that RedHat releases for them. But the hard part is that you then have to figure out which release those packages are for. That is the harder part. It is made even harder by the fact that these packages usually come out a day to a week after RedHat releases their usual security updates for the same package. So I have no idea that there is a extra backpatched security update for whatever it is until after I've already pushed out the normal security update. Hmm, I see the problem. Unless redhat have a specific announcement mechanism for the extended support chain, I can't see how to pick up on them easily. I imagine that there's quite an overhead in continuing to support N versions of SL4/5 - presumably Redhat also realise this (hence the large scale of deployment and subscription fees required to become a subscriber to the extended support service). That being said, lets say we do figure out a way for this. How would we get these packages out to you in a way that you could get them? How about dropping them into the SL4.7 update repository? That way, those who use 4x will skip past them (right?), but those sticking with 4.7 explicitly will still pick them up through yum. Troy Stephan Wiesand wrote: On Thu, 2009-07-02 at 11:33 +0100, Orlando Richards wrote: Ahh - it's released under Extended Update Support only - otherwise it's got to be 2.6.9-89.0.3 for the fix. Please ignore my original question then! Why? I think it's quite a good one. SL is actually providing this extended update support, so the z-stream kernel errata would be the most suitable choice, except for 4.8 beta, IMHO. It's my impression that with the much longer full support times, and the much longer time between point releases, feature backports upon minor releases have become significantly more aggressive, and updating to the 4.n+1 kernel on SL4.n is much more likely to cause problems than it used to be in the past. There were quite a few problems when updates for 5.3 were pushed out to 5.2 and older releases, and I wouldn't expect it to work any better with 4.8. One example: the openib in the 4.8 kernel won't match the userland packages on 4.7 and earlier. No clue yet whether or not this will cause any actual problems, but it doesn't feel right. Just my 2c, Stephan -Original Message- From: Orlando Richards [mailto:orlando.richa...@ed.ac.uk] Sent: 02 July 2009 11:25 To: Orlando Richards; Troy Dawson Cc: scientific-linux-users@listserv.fnal.gov Subject: RE: SL4 kernel Argh - it seems that redhat haven't even released it yet! At least, I can't find it in RHN - only up to 2.6.9-78.0.22 :( -- Dr Orlando Richards Information Services IT Infrastructure Division Unix Section Tel: 0131 650 4994 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner- scientific-linux-us...@listserv.fnal.gov] On Behalf Of Orlando Richards Sent: 02 July 2009 10:50 To: Troy Dawson Cc: scientific-linux-users@listserv.fnal.gov Subject: SL4 kernel Hi all, Do you know if there are any plans to release the 2.6.9-78.0.24 version of the RedHat 4.7 kernel? This has the fix for CVE-2009-1337, which has just been fixed with the release of 2.6.9-89.0.3 from Scientific Linux. However, we cannot yet use the -89 release kernel as our hardware vendors have not yet released supported drivers for RH4.8. Cheers, Orlando. -- -- Dr Orlando Richards Information Services IT Infrastructure Division Unix Section Tel: 0131 650 4994 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: Kickstarting SL 4.3 on Sun Fire x4140
Troy Dawson wrote: John Summerfield wrote: The obvious (to me) workaround is to install a new NIC, at least for the install. It might also be worth trying to boot a live CD (is CentOS4 available?) http://ftp.scientificlinux.org/linux/scientific/livecd/ There is both a SL 4.3 and the latest SL 4.7. Both worth a try. SL 4.3 to see if it really isn't supported in SL 4.3, and SL 4.7 to see if it's been fixed. I've just tried the 4.3 LiveCD and the network card works perfectly once booted up. In lspci it shows correctly as an 'Ethernet Controller'. For a test I've also tried kickstarting (using the same kickstart file) except with SL 4.7, and this kickstart works perfectly. So I guess it's a bug in anaconda in 4.3 that's fixed before 4.7. I'll try kickstarting off DVD media or putting in another NIC. Thanks Tim Edwards
Re: SL4 kernel
Orlando Richards wrote: On 02/07/09 16:16, Troy Dawson wrote: Well ... this is a good place for the discussion. What *should* we do with those packages that redhat releases for the extended support series. Do you have access to them okay? I couldn't get to the rpms (or the src rpms) using my RHN account, but we have a fairly basic level of entitlements. We only get our src rpm's (that we release) from their public ftp site ftp://ftp.redhat.com/pub/redhat/ or one of it's mirrors. I'll say this upfront that it's a bit of a pain. It's a piece of cake to look, download and build any src.rpm's that RedHat releases for them. But the hard part is that you then have to figure out which release those packages are for. That is the harder part. It is made even harder by the fact that these packages usually come out a day to a week after RedHat releases their usual security updates for the same package. So I have no idea that there is a extra backpatched security update for whatever it is until after I've already pushed out the normal security update. Hmm, I see the problem. Unless redhat have a specific announcement mechanism for the extended support chain, I can't see how to pick up on them easily. I imagine that there's quite an overhead in continuing to support N versions of SL4/5 - presumably Redhat also realise this (hence the large scale of deployment and subscription fees required to become a subscriber to the extended support service). That being said, lets say we do figure out a way for this. How would we get these packages out to you in a way that you could get them? How about dropping them into the SL4.7 update repository? That way, those who use 4x will skip past them (right?), but those sticking with 4.7 explicitly will still pick them up through yum. No, that's the problem. They will *not* get those updates even if they are in the yum repository. If we take the recent kernel for example, yum will see the kernel 2.6.9-89.0.3.EL and then the z kernel 2.6.9-78.0.24.EL and it will think that the 89.0.3 kernel is newer, and won't even show the users the z kernel. Although ... now that I think of it, if you explicitly say a version, yum will install it as long as it is newer than your kernel now ... but I'm not sure about that. We'll have to test that. If that is the case, and as long as people know that they want the package, and what it's version is, they can install it. That would make things very easy for my end. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
Re: Kickstarting SL 4.3 on Sun Fire x4140
Known bug in anaconda for nvidia ethernet dhcp. Solutions are boot with fixed IP or install other network card for kickstart (tedious if you have 40 x4100 servers). This is fixed in newer releases w/ newer anaconda. -- Date: Tue, 7 Jul 2009 09:17:10 -0500 From: Troy Dawson daw...@fnal.gov Subject: Re: Kickstarting SL 4.3 on Sun Fire x4140 John Summerfield wrote: Tim Edwards wrote: We're trying to kickstart SL4.3 on a Sunfire x4140 which appears to have inbuilt-NICs which use an Nvidia chipset. The problem is that although the NIC's ROM manages to boot off the network, once anaconda is started it fails to see any network devices. I can see in the messages that the forcedeth kernel module is loaded. I found a RHEL bug that suggests that the NICs are detected as bridge devices and not plain ethernet NICs: https://bugzilla.redhat.com/show_bug.cgi?id=156688 We need to use SL 4.3 (due to internal application certifications) so can anyone suggest a possible workaround for this? Has anyone installed SL/Centos/RHEL 4.x on this server before? Thanks Tim Edwards The obvious (to me) workaround is to install a new NIC, at least for the install. It might also be worth trying to boot a live CD (is CentOS4 available?) http://ftp.scientificlinux.org/linux/scientific/livecd/ There is both a SL 4.3 and the latest SL 4.7. Both worth a try. SL 4.3 to see if it really isn't supported in SL 4.3, and SL 4.7 to see if it's been fixed. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
