Re: TESTING - kernel update for SL5
On 02/22/11 21:11, Jan Kundrát wrote: On 01/20/11 18:30, Troy Dawson wrote: kernel-2.6.18-238.1.1.el5 Hi Troy, FYI -- I've now tracked this problem down to the patch linux-2.6-virt-nmi-don-t-print-nmi-stuck-messages-on-guests [1] and reported this issue on RHEL's Bugzilla [2]. The comment of the patch begins with Ok here is a controversial patch :). Cheers, Jan [1] http://dev.gentoo.org/~jkt/tmp/linux-2.6-virt-nmi-don-t-print-nmi-stuck-messages-on-guests.patch [2] https://bugzilla.redhat.com/show_bug.cgi?id=707966 smime.p7s Description: S/MIME Cryptographic Signature
Re: TESTING - kernel update for SL5
On 02/22/11 21:11, Jan Kundrát wrote: I'll try upgrading the dom0 to recent kernel tomorrow and keep you posted. I've updated the kernel to 2.6.18-238.1.1.el5xen and left Xen at xen-3.0.3-94.el5_4.1. Didn't help, so I just updated to the latest 5x repository, updated all packages on the physical system and rebooted. That didn't help, either, and the symptoms are still the same, ie. with serial='pty' it gets stuck when detecting serial ports, and with that commented out, it freezes after ide1: BM-DMA I've tried all permutations of tap:aio and file: for backend and hda and ioemu:hda for the frontend in the following disk configuration: disk = [ 'file:/root/image-pseudo-callisto,hda,w' ] I should probably mention that I can import the underlying image to virt-manager running on a completely independent machine with Gentoo Linux just fine, and it starts without any problem in there. Suggestions are much appreciated. With kind regards, Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: TESTING - kernel update for SL5
On 02/22/2011 02:11 PM, Jan Kundrát wrote: On 01/20/11 18:30, Troy Dawson wrote: kernel-2.6.18-238.1.1.el5 Hi list, looks like I'm the only person having this problem. I've installed a SL5.5 machine today as a fully virtualized guest in a SL5.2 Xen host (kernel 2.6.18-194.32.1.el5xen). The installation went fine and the auto updates brought in the 2.6.18-238.1.1.el5 kernel, which is where my troubles started. This is the xen configuration I have: [root@ha3 ~]# cat /etc/xen/callisto kernel = /usr/lib/xen/boot/hvmloader builder='hvm' memory = 512 name = callisto vcpus=1 #vif = [ 'type=ioemu, bridge=xenbr0' ] vif = [ 'mac=00:16:3e:e7:19:ce, bridge=xenbr0' ] disk = [ 'phy:/dev/mapper/callisto,ioemu:hda,w' ] on_reboot = 'restart' on_crash= 'restart' device_model = '/usr/lib64/xen/bin/qemu-dm' boot='nc' sdl=0 vnc=1 vncviewer=0 stdvga=0 serial='pty' ne2000=0 usb=1 pae=1 For testing, I've replaced it with a very similar configuration, it just uses tap:aio: as the backing store for the disk image and the vif= line is commented out. The symptoms are, as far as I can tell, the same on both configurations. I've also tried two different dom0 hosts (even though with the same configuration), and there's no difference between them. Whenever I boot any kernel newer than 2.6.18-194.32.1.el5 (tried 2.6.18-238.1.1.el5 from SL5.5 and 2.6.18-236, 2.6.18-245 from http://people.redhat.com/jwilson/el5/), it hangs in one of these few places: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled [here] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450 [...] PCI: Setting latency timer of device :00:01.1 to 64 ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio [here] Probing IDE interface ide0.. [here] hda: QEMU HARDDISK, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 If it makes it past the last [here], it will always boot properly. I have absolutely no idea what's wrong here. I've tried commenting out the serial='pty' line, that will make it not get stuck during the serial initialization, but it still hangs before/after the Probing IDE interface ide0... The behavior is same with all kernels newer than 2.6.18-194.32.1.el5 that I tried. The only *working* kernel is the 2.6.18-238.1.1.el5xen, ie. a Xen-specific version. This means running Xen dom0 inside HVM domU inside dom0 :). According to the changelog message from 238, something changed in the serial drivers realm: - [usb] serial: new driver MosChip MCS7840 (Stefan Assmann) [574507] ...but given that it's USB, it might not be related to my issue, This one looks much more interesting, though: * Tue Oct 20 2009 Don Zickusdzic...@redhat.com [2.6.18-170.el5] - [xen] allow booting with broken serial hardware (Chris Lalancette ) [518338] Of course I can't access that report... SO I wonder if someone is running the same combination of kernels as I do, ie. 2.6.18-194.32.1.el5 on dom0 and 2.6.18-238.1.1.el5 in HVM domU. I'd be interested in hearing if that combination works for you. I'll try upgrading the dom0 to recent kernel tomorrow and keep you posted. With kind regards, Jan Hi Jan, Just because the client kernel is running 2.6.18-238.1.1.el5xen does not mean it is trying to be a xen host. It means that it is running paravirtualized. If your xen machine was setup to be a paravirtualized client, then it *has* to continue to run the xen kernel. You can't just switch from the one to the other (as far as I know). When you are running it on Gentoo, you probably set it up to not be paravirtualized, so it happily ran the regular kernel. If you are wondering, I did test the scenario you have. I currently have a xen host running 2.6.18-238.1.1.el5. Some of it's clients are/were running the older kernel, some 2.6.18-238.1.1.el5. All of them are working fine. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/SCF/FEF/SLSMS Group __
Re: TESTING - kernel update for SL5
On 02/23/11 15:51, Troy Dawson wrote: Just because the client kernel is running 2.6.18-238.1.1.el5xen does not mean it is trying to be a xen host. It means that it is running paravirtualized. If your xen machine was setup to be a paravirtualized client, then it *has* to continue to run the xen kernel. You can't just switch from the one to the other (as far as I know). Hi Troy, the domU has always been a fully virtualized one, as requested by the builder=hvm stanza given in the configuration file. The disk image contains everything, from the bootloader and partitions to the kernel, and the in-the-image-installed Grub is invoked and asks me what kernel to boot. When I was speaking about kernel changes, I meant that I have installed various versions of the kernel RPM inside the domU, one of them being kernel-2.6.18-194.32.1.el5, other kernel-2.6.18-238.1.1.el5 and yet another being kernel-xen-2.6.18-238.1.1.el5. Now, no matter what kernel and Xen versions I choose to run in the dom0, physical host, I haven't managed to boot the domU using kernel-2.6.18-238.1.1.el5. I'm always using full virtualization, this has remained fixed during all tests. If I pick any of kernel-2.6.18-194.32.1.el5 or kernel-xen-2.6.18-238.1.1.el5 at the Grub's prompt displayed inside the vncviewer which I use to access the domU's console, it boots fine. Note that the kernel-xen package actually boots using the following lines: title Scientific Linux SL (2.6.18-238.1.1.el5xen) root (hd0,0) kernel /boot/xen.gz-2.6.18-238.1.1.el5 module /boot/vmlinuz-2.6.18-238.1.1.el5xen ro root=LABEL=/ module /boot/initrd-2.6.18-238.1.1.el5xen.img so that kernel is actually running on top of Xen which itself runs in the fully virtualized machine, which runs inside Xen on a physical machine. When you are running it on Gentoo, you probably set it up to not be paravirtualized, so it happily ran the regular kernel. In fact, the virt-manager run it via kvm, so without any traces of Xen at all. That particular physical machine has never had Xen on it. If you are wondering, I did test the scenario you have. I currently have a xen host running 2.6.18-238.1.1.el5. Some of it's clients are/were running the older kernel, some 2.6.18-238.1.1.el5. All of them are working fine. I've just updated kernel on another domU instance to the -238, again a fully virtualized one, and the symptoms are the same, ie. it won't boot and gets stuck on the serial thing. I suspect that both domUs have been installed via the same (or at least very similar) kickstart file via PXE. I guess I can clean up the image and provide it for testing, if you think it could help debugging this issue. The same applies for the kickstart file. Thank you for your help so far, I'm really lost at what I'm doing wrong here. With kind regards, Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: TESTING - kernel update for SL5
Hi Jan, On Feb 23, 2011, at 16:23 , Jan Kundrát wrote: On 02/23/11 15:51, Troy Dawson wrote: Just because the client kernel is running 2.6.18-238.1.1.el5xen does not mean it is trying to be a xen host. It means that it is running paravirtualized. If your xen machine was setup to be a paravirtualized client, then it *has* to continue to run the xen kernel. You can't just switch from the one to the other (as far as I know). Hi Troy, the domU has always been a fully virtualized one, as requested by the builder=hvm stanza given in the configuration file. I guess that explains why noone else is seeing this problem. Why would I want to run an SL5 Xen VM under an SL5 Xen hypervisor as an HVM instead of a paravirt VM? I agree it should work, though, and I know that it did in the past. The disk image contains everything, from the bootloader and partitions to the kernel, and the in-the-image-installed Grub is invoked and asks me what kernel to boot. When I was speaking about kernel changes, I meant that I have installed various versions of the kernel RPM inside the domU, one of them being kernel-2.6.18-194.32.1.el5, other kernel-2.6.18-238.1.1.el5 and yet another being kernel-xen-2.6.18-238.1.1.el5. Now, no matter what kernel and Xen versions I choose to run in the dom0, physical host, I haven't managed to boot the domU using kernel-2.6.18-238.1.1.el5. I'm always using full virtualization, this has remained fixed during all tests. If I pick any of kernel-2.6.18-194.32.1.el5 or kernel-xen-2.6.18-238.1.1.el5 at the Grub's prompt displayed inside the vncviewer which I use to access the domU's console, it boots fine. Note that the kernel-xen package actually boots using the following lines: title Scientific Linux SL (2.6.18-238.1.1.el5xen) root (hd0,0) kernel /boot/xen.gz-2.6.18-238.1.1.el5 module /boot/vmlinuz-2.6.18-238.1.1.el5xen ro root=LABEL=/ module /boot/initrd-2.6.18-238.1.1.el5xen.img so that kernel is actually running on top of Xen which itself runs in the fully virtualized machine, which runs inside Xen on a physical machine. Interesting, I thought it was impossible to run Xen under Xen and that this kind of recursive virtualization is an exclusive feature of KVM. When you are running it on Gentoo, you probably set it up to not be paravirtualized, so it happily ran the regular kernel. In fact, the virt-manager run it via kvm, so without any traces of Xen at all. That particular physical machine has never had Xen on it. KVM is readily available on SL5, so this may be a way to solve your actual problem. Best regards, Stephan If you are wondering, I did test the scenario you have. I currently have a xen host running 2.6.18-238.1.1.el5. Some of it's clients are/were running the older kernel, some 2.6.18-238.1.1.el5. All of them are working fine. I've just updated kernel on another domU instance to the -238, again a fully virtualized one, and the symptoms are the same, ie. it won't boot and gets stuck on the serial thing. I suspect that both domUs have been installed via the same (or at least very similar) kickstart file via PXE. I guess I can clean up the image and provide it for testing, if you think it could help debugging this issue. The same applies for the kickstart file. Thank you for your help so far, I'm really lost at what I'm doing wrong here. With kind regards, Jan -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany
Re: TESTING - kernel update for SL5
On 02/23/11 16:23, Jan Kundrát wrote: I've just updated kernel on another domU instance to the -238 I forgot to mention that when I `yum update`d that second domU, yum complained about the following: Running Transaction Installing : kernel Installing : kernel-xen WARNING: No module xen_vbd found for kernel 2.6.18-238.1.1.el5xen, continuing anyway WARNING: No module xen_vbd found for kernel 2.6.18-238.1.1.el5xen, continuing anyway Cleanup: kernel-xen Cleanup: kernel And one more information, this is what I get in the kernel log of the domU when I boot it with 2.6.18-194.32.1.el5, the last working kernel: xen_mem: Initialising balloon driver. Registering block device major 3 register_blkdev: cannot get major 3 for ide xen_blk: can't get major 3 with name ide vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/57/768 netfront: Initialising virtual ethernet driver. netfront: device eth1 has copying receive path. FDC 0 is a S82078B lp: driver loaded but no devices found md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. device-mapper: multipath: version 1.0.5 loaded loop: loaded (max 8 devices) EXT3 FS on hda1, internal journal Adding 1052248k swap on /dev/hda2. Priority:-1 extents:1 across:1052248k IA-32 Microcode Update Driver: v1.14a tig...@veritas.com NET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 eth0: no IPv6 routers present netfront: device eth1 has copying receive path. Registering block device major 3 register_blkdev: cannot get major 3 for ide xen_blk: can't get major 3 with name ide vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/768 netfront: device eth1 has copying receive path. Registering block device major 3 register_blkdev: cannot get major 3 for ide xen_blk: can't get major 3 with name ide vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/12/768 But it boots fine and mounts its disk. The physical dom0 is a HP DL-360 G5. With kind regards, Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: TESTING - kernel update for SL5
On 01/20/11 18:30, Troy Dawson wrote: kernel-2.6.18-238.1.1.el5 Hi list, looks like I'm the only person having this problem. I've installed a SL5.5 machine today as a fully virtualized guest in a SL5.2 Xen host (kernel 2.6.18-194.32.1.el5xen). The installation went fine and the auto updates brought in the 2.6.18-238.1.1.el5 kernel, which is where my troubles started. This is the xen configuration I have: [root@ha3 ~]# cat /etc/xen/callisto kernel = /usr/lib/xen/boot/hvmloader builder='hvm' memory = 512 name = callisto vcpus=1 #vif = [ 'type=ioemu, bridge=xenbr0' ] vif = [ 'mac=00:16:3e:e7:19:ce, bridge=xenbr0' ] disk = [ 'phy:/dev/mapper/callisto,ioemu:hda,w' ] on_reboot = 'restart' on_crash= 'restart' device_model = '/usr/lib64/xen/bin/qemu-dm' boot='nc' sdl=0 vnc=1 vncviewer=0 stdvga=0 serial='pty' ne2000=0 usb=1 pae=1 For testing, I've replaced it with a very similar configuration, it just uses tap:aio: as the backing store for the disk image and the vif= line is commented out. The symptoms are, as far as I can tell, the same on both configurations. I've also tried two different dom0 hosts (even though with the same configuration), and there's no difference between them. Whenever I boot any kernel newer than 2.6.18-194.32.1.el5 (tried 2.6.18-238.1.1.el5 from SL5.5 and 2.6.18-236, 2.6.18-245 from http://people.redhat.com/jwilson/el5/), it hangs in one of these few places: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled [here] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450 [...] PCI: Setting latency timer of device :00:01.1 to 64 ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio [here] Probing IDE interface ide0.. [here] hda: QEMU HARDDISK, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 If it makes it past the last [here], it will always boot properly. I have absolutely no idea what's wrong here. I've tried commenting out the serial='pty' line, that will make it not get stuck during the serial initialization, but it still hangs before/after the Probing IDE interface ide0... The behavior is same with all kernels newer than 2.6.18-194.32.1.el5 that I tried. The only *working* kernel is the 2.6.18-238.1.1.el5xen, ie. a Xen-specific version. This means running Xen dom0 inside HVM domU inside dom0 :). According to the changelog message from 238, something changed in the serial drivers realm: - [usb] serial: new driver MosChip MCS7840 (Stefan Assmann) [574507] ...but given that it's USB, it might not be related to my issue, This one looks much more interesting, though: * Tue Oct 20 2009 Don Zickus dzic...@redhat.com [2.6.18-170.el5] - [xen] allow booting with broken serial hardware (Chris Lalancette ) [518338] Of course I can't access that report... SO I wonder if someone is running the same combination of kernels as I do, ie. 2.6.18-194.32.1.el5 on dom0 and 2.6.18-238.1.1.el5 in HVM domU. I'd be interested in hearing if that combination works for you. I'll try upgrading the dom0 to recent kernel tomorrow and keep you posted. With kind regards, Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: TESTING - kernel update for SL5
I see 2.6.18-238.1.1 in the location Andrew mentioned below on linux.fnal.gov, in the sl-security repo. However it is *not* in the fermi-security repo, ftp://linux.fnal.gov/linux/slf55/x86_64/sites/Fermi/updates/security. What happened? Why hasn't it been released to Sci. Linux Fermi? Steve Timm On Mon, 14 Feb 2011, Dr Andrew C Aitchison wrote: On Mon, 14 Feb 2011, Steven Timm wrote: I thought this kernel 2.6.18-238.1.1 was going to be released last week. It doesn't appear to have been released yet. What happened? I see it, eg at http://ftp.scientificlinux.org/linux/scientific/55/x86_64/updates/security/kernel-2.6.18-238.1.1.el5.x86_64.rpm http://ftp.scientificlinux.org/linux/scientific/55/i386/updates/security/kernel-2.6.18-238.1.1.el5.i686.rpm and http://ftp.scientificlinux.org/linux/scientific/5rolling/x86_64/updates/security/kernel-2.6.18-238.1.1.el5.x86_64.rpm -- -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project.
RE: TESTING - kernel update for SL5
I see 2.6.18-238.1.1 in the location Andrew mentioned below on linux.fnal.gov, in the sl-security repo. However it is *not* in the fermi-security repo, ftp://linux.fnal.gov/linux/slf55/x86_64/sites/Fermi/updates/security. What happened? Why hasn't it been released to Sci. Linux Fermi? Steve Timm Perhaps the tcmalloc issues which broke some applications? http://code.google.com/p/google-perftools/issues/detail?id=305 Also check the list archives for more discussion. Forgive me if -238 wasn't the kernel from 5.6.. On Mon, 14 Feb 2011, Dr Andrew C Aitchison wrote: On Mon, 14 Feb 2011, Steven Timm wrote: I thought this kernel 2.6.18-238.1.1 was going to be released last week. It doesn't appear to have been released yet. What happened? I see it, eg at http://ftp.scientificlinux.org/linux/scientific/55/x86_64/updat es/security/kernel-2.6.18-238.1.1.el5.x86_64.rpm http://ftp.scientificlinux.org/linux/scientific/55/i386/updates /security/kernel-2.6.18-238.1.1.el5.i686.rpm and http://ftp.scientificlinux.org/linux/scientific/5rolling/x86_64 /updates/security/kernel-2.6.18-238.1.1.el5.x86_64.rpm -- -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com
Re: TESTING - kernel update for SL5
I thought this kernel 2.6.18-238.1.1 was going to be released last week. It doesn't appear to have been released yet. What happened? Steve Timm On Mon, 31 Jan 2011, Steven Timm wrote: I've tested it on i386, x86_64 on my laptop, bare metal servers, and Xen instances, all are OK. Steve On Thu, 20 Jan 2011, Troy Dawson wrote: Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ kernel-2.6.18-238.1.1.el5 Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __ -- -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project.
Re: TESTING - kernel update for SL5
On Mon, 14 Feb 2011, Steven Timm wrote: I thought this kernel 2.6.18-238.1.1 was going to be released last week. It doesn't appear to have been released yet. What happened? I see it, eg at http://ftp.scientificlinux.org/linux/scientific/55/x86_64/updates/security/kernel-2.6.18-238.1.1.el5.x86_64.rpm http://ftp.scientificlinux.org/linux/scientific/55/i386/updates/security/kernel-2.6.18-238.1.1.el5.i686.rpm and http://ftp.scientificlinux.org/linux/scientific/5rolling/x86_64/updates/security/kernel-2.6.18-238.1.1.el5.x86_64.rpm -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
Re: TESTING - kernel update for SL5
We have had alot of good testing, and thus far there haven't been any show stoppers. Unless something comes up, we will release this errata to all of SL5 on Wednesday February 8, 2011 Thanks Troy On 01/20/2011 11:30 AM, Troy J Dawson wrote: Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ kernel-2.6.18-238.1.1.el5 Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __ -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: TESTING - kernel update for SL5
Hi Troy, On Feb 4, 2011, at 15:33, Troy Dawson wrote: We have had alot of good testing, and thus far there haven't been any show stoppers. Unless something comes up, we will release this errata to all of SL5 on Wednesday February 8, 2011 we were made aware of this issue: http://code.google.com/p/google-perftools/issues/detail?id=305 I wouldn't consider it a showstopper, but it seems this is used by at least one LHC experiment (which should have a workaround in place now ;-). - Stephan Thanks Troy On 01/20/2011 11:30 AM, Troy J Dawson wrote: Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ kernel-2.6.18-238.1.1.el5 Thanks Troy Dawson -- Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany
Re: TESTING - kernel update for SL5
-- Le (On) 2011-01-21 +0100 à (at) 22:10:34 FRANCHISSEUR Robert écrivit (wrote): -- -- Le (On) 2011-01-20 -0600 à (at) 11:30:44 Troy Dawson écrivit (wrote): -- snip SL5 --- yum --enablerepo=sl-testing update kernel\* snip I'll try on a laptop Dell E6500 tomorow and I'll tell you the result. So far so good :) Till today I din'nt noticed that on laptops Dell E6500 we have the following warning with the new : kernel-2.6.18-238.1.1.el5.x86_64 Warning: pci_mmcfg_init marking 256MB space uncacheable. The solution is to add the folowing arg in the kernel call in grub.conf : acpi_mcfg_max_pci_bus_num=on HTH. -- Best regards, Robert FRANCHISSEUR Apollo_gist :-)___ | Robert FRANCHISSEUR | | Laboratoire de Météorologie Dynamique - C.N.R.S. | | Equipe R.A.M.S.E.S. - UPMC - Tour 45-55 3ème 315C | | Boite 99 - 4, place JussieuF-75252 PARIS CEDEX 05 FRANCE | | Phone : +33 (0)1 44 27 73 87 fax : +33 (0)1 44 27 62 72 | | e-mail : robert at lmd . jussieu . fr http://www.lmd.jussieu.fr | ---
Re: TESTING - kernel update for SL5
I've tested it on i386, x86_64 on my laptop, bare metal servers, and Xen instances, all are OK. Steve On Thu, 20 Jan 2011, Troy Dawson wrote: Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ kernel-2.6.18-238.1.1.el5 Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __ -- -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Group Leader. Lead of FermiCloud project.
Re: TESTING - kernel update for SL5
Hello, in use on ~20 workernodes without problems. The -238.* kernels has a new way to handle dentry that lead to a kernel panic when performing a 'stat()' syscall in some very particular cases, but we suspect it may be related to a GPFS bad-crafted dentry in mmfsd daemon. Regards, -- Y. - CC-IN2P3 Troy Dawson a écrit : Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ kernel-2.6.18-238.1.1.el5 Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __
Re: TESTING - kernel update for SL5
Hi Troy, On Jan 20, 2011, at 18:30 , Troy Dawson wrote: Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. we deployed this kernel on a dozen SL5.5 systems, including a number of Xen DOM0s and DOMUs, on friday. No obvious problems have shown up (at least none we haven't experienced with earlier kernels as well;-) - Stephan Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ kernel-2.6.18-238.1.1.el5 Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __ -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany smime.p7s Description: S/MIME cryptographic signature
Re: TESTING - kernel update for SL5
-- Le (On) 2011-01-21 +0100 à (at) 03:52:01 Franchisseur Robert écrivit (wrote): -- -- Le (On) 2011-01-20 -0600 à (at) 11:30:44 Troy Dawson écrivit (wrote): -- Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* snip Helo, I upgraded on a Dell Optiplex 760 under SL5.5 x86_64 and everything seems OK. I'll try on a laptop Dell E6500 tomorow and I'll tell you the result. So far so good :) (except that pcspkr has been changed yet :( -- Best regards, Robert FRANCHISSEUR Apollo_gist :-)___ | Robert FRANCHISSEUR | | Laboratoire de Météorologie Dynamique - C.N.R.S. | | Equipe R.A.M.S.E.S. - UPMC - Tour 45-55 3ème 315C | | Boite 99 - 4, place JussieuF-75252 PARIS CEDEX 05 FRANCE | | Phone : +33 (0)1 44 27 73 87 fax : +33 (0)1 44 27 62 72 | | e-mail : robert at lmd . jussieu . fr http://www.lmd.jussieu.fr | ---
Re: TESTING - kernel update for SL5
On Thu, Jan 20, 2011 at 9:30 AM, Troy Dawson daw...@fnal.gov wrote: Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. I installed the following updates on a SL 5.5 x86_64 system: kernel-2.6.18-238.1.1.el5.x86_64.rpm kernel-devel-2.6.18-238.1.1.el5.x86_64.rpm kernel-headers-2.6.18-238.1.1.el5.x86_64.rpm kmod-kvm-83-224.el5.x86_64.rpm kvm-83-224.el5.x86_64.rpm kvm-qemu-img-83-224.el5.x86_64.rpm kvm-tools-83-224.el5.x86_64.rpm I noticed kvm.ko was built against the 2.6.18-238 kernel. A correct symlink was created for the 2.6.18-238.1.1 kernel. One odd observation is that kvm.ko of the earlier kernels (2.6.18-194.xx) now points to non-existing files (broken symlinks). This may not be a problem unique to SL but was probably inherited from TUV. In any event, kvm guests run fine without any problem under the kernel 2.6.18-238.1.1. Akemi
Re: TESTING - kernel update for SL5
-- Le (On) 2011-01-20 -0600 à (at) 11:30:44 Troy Dawson écrivit (wrote): -- Hello, We have had our first kernel security update following the release of SL 5.6. We have tested it on a SL5.0 machine. It installs, runs and openafs works on it. I would feel much better if others ran it to make sure it works for them. Can others test this kernel out on their machines to make sure it doesn't break something we didn't expect. I have also put the new kvm into the x86_64 testing area with the kernel. To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* snip Helo, I upgraded on a Dell Optiplex 760 under SL5.5 x86_64 and everything seems OK. I'll try on a laptop Dell E6500 tomorow and I'll tell you the result. -- Best regards, Robert FRANCHISSEUR Apollo_gist :-)___ | Robert FRANCHISSEUR | | Laboratoire de Météorologie Dynamique - C.N.R.S. | | Equipe R.A.M.S.E.S. - UPMC - Tour 45-55 3ème 315C | | Boite 99 - 4, place JussieuF-75252 PARIS CEDEX 05 FRANCE | | Phone : +33 (0)1 44 27 73 87 fax : +33 (0)1 44 27 62 72 | | e-mail : robert at lmd . jussieu . fr http://www.lmd.jussieu.fr | ---
Re: TESTING - kernel update for SL5
I forgot to put down. This kernel fixes CVE-2010-3081 Troy Troy J Dawson wrote: Hello, Due to the high demand for this kernel, we are putting it into our general testing area so that people can install it as soon as possible. Although this kernel hasn't gone through our full testing procedure, it has gone through preliminary testing, and we expect it to pass all of our testing. We plan on pushing this out on tomorrow - 22 September 2010 To test or update SL5 --- yum --enablerepo=sl-testing update kernel\* or you can download rpm's by hand at http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/i386/kernel/ http://ftp.scientificlinux.org/linux/scientific/5rolling/testing/x86_64/kernel/ Thanks Troy Dawson -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __ -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: TESTING - kernel update for SL5
Troy Dawson wrote: yum --enablerepo=sl-testing update kernel\* Just a small comment about the i386 version: Package kernel-module-openafs-2.6.18-194.11.4.el5-1.4.12-79.sl5.i686.rpm is not signed
Re: TESTING - kernel update for SL5
On 09/21/2010 12:20 PM, Glenn Morris wrote: Troy Dawson wrote: yum --enablerepo=sl-testing update kernel\* Just a small comment about the i386 version: Package kernel-module-openafs-2.6.18-194.11.4.el5-1.4.12-79.sl5.i686.rpm is not signed Thanks. Our testing area scripts don't check the signatures. They are signed now and re-pushed out into the testing area. You probably will have to do a yum --enablerepo=sl-testing clean all if you have already tried to download them, which it looks like you already have. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LSCS/CSI/USS Group __
Re: TESTING - kernel update for SL5
On Tue, 21 Sep 2010, Troy Dawson wrote: On 09/21/2010 12:20 PM, Glenn Morris wrote: Troy Dawson wrote: yum --enablerepo=sl-testing update kernel\* Just a small comment about the i386 version: Package kernel-module-openafs-2.6.18-194.11.4.el5-1.4.12-79.sl5.i686.rpm is not signed Thanks. Our testing area scripts don't check the signatures. They are signed now and re-pushed out into the testing area. You probably will have to do a yum --enablerepo=sl-testing clean all if you have already tried to download them, which it looks like you already have. Another note: For completness I'm testing the i386 kernel too, and noticed that the kernel-headers RPM never made it to 5rolling/testing/i386/ cheers, etc. -- deatrich @ triumf.ca, Science/Atlas PH: +1 604-222-7665 * This moment's fortune cookie: If Love Were Oil, I'd Be About A Quart Low -- Book title by Lewis Grizzard
Re: TESTING - kernel update for SL5
If there aren't any problems, this update will go out on Monday, April 6, 2009 To test or update SL5 --- I've got the kernel: kernel-2.6.18-128.1.6.el5.i686.rpm and the XFS module: kernel-module-xfs-2.6.18-128.1.6.el5-0.4-2.sl5.i686.rpm (actually, I just issued a 'yum update') and I've got a kernel panic after reboot, so I had to revert to the previous GRUB entry, which was using: kernel-2.6.18-128.1.1.el5.i686.rpm kernel-module-xfs-2.6.18-128.1.1.el5-0.4-2.sl5.i686.rpm Yes, I'm using XFS. Is it me, or is it a bug? Cheers, R-C
Re: TESTING - kernel update for SL5
Radu-Cristian Fotescu wrote: If there aren't any problems, this update will go out on Monday, April 6, 2009 To test or update SL5 --- I've got the kernel: kernel-2.6.18-128.1.6.el5.i686.rpm and the XFS module: kernel-module-xfs-2.6.18-128.1.6.el5-0.4-2.sl5.i686.rpm (actually, I just issued a 'yum update') and I've got a kernel panic after reboot, so I had to revert to the previous GRUB entry, which was using: kernel-2.6.18-128.1.1.el5.i686.rpm kernel-module-xfs-2.6.18-128.1.1.el5-0.4-2.sl5.i686.rpm Yes, I'm using XFS. Is it me, or is it a bug? Cheers, R-C What did the kernel panic say? I know it's sometimes hard to get them into an email because ... well, it's a kernel panic, but can you get part of it into an email, even if it isn't exact. Thanks Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
Re: TESTING - kernel update for SL5
Troy J Dawson wrote: Radu-Cristian Fotescu wrote: If there aren't any problems, this update will go out on Monday, April 6, 2009 To test or update SL5 --- I've got the kernel: kernel-2.6.18-128.1.6.el5.i686.rpm and the XFS module: kernel-module-xfs-2.6.18-128.1.6.el5-0.4-2.sl5.i686.rpm (actually, I just issued a 'yum update') and I've got a kernel panic after reboot, so I had to revert to the previous GRUB entry, which was using: kernel-2.6.18-128.1.1.el5.i686.rpm kernel-module-xfs-2.6.18-128.1.1.el5-0.4-2.sl5.i686.rpm Yes, I'm using XFS. Is it me, or is it a bug? Cheers, R-C What did the kernel panic say? I know it's sometimes hard to get them into an email because ... well, it's a kernel panic, but can you get part of it into an email, even if it isn't exact. Thanks Troy I have just booted into that kernel with the corresponding xfs kernel without a kernel panic. So, right now, yes, it's just you :) Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/LCSI/CSI LMSS Group __
Re: TESTING - kernel update for SL5
What did the kernel panic say? It looked exactly like it looks when there is no support for that filesystem type! I have just booted into that kernel with the corresponding xfs kernel without a kernel panic. So, right now, yes, it's just you :) I'm glad to hear that. I'll check for the cause. The installation was performed from the mini_livecd 5.3, so this might have introduced some issues. BTW, the only way to install with / being XFS is to use a LiveCD. And, at least on the mini_livecd 5.3, GRUB fails to install on XFS, so I had to boot again the mini_livecd 5.2 and tp use grub-install from there, and it worked. (AFAIK, Urs is aware of this issue.) I'll check later to update a system installed normally (a netinstall, actually), and I suppose it'll work. Thanks, R-C __ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca
