-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/10 18:16, James Hogarth wrote: > Hey all, > > Quick question for anyone that can give a quick answer... > > The kernel released for lucid last night (2.6.32-22.35) broke kvm > guests - prevented them from starting. > > The kernel that was in proposed (2.6.32-22.33) has no problems. > > Looking at launchpad it looks like 2.6.32-22.35 never hit proposed and > went straight to updates/security: > > https://launchpad.net/ubuntu/+source/linux/2.6.32-22.35/+publishinghistory > > Given that this broke KVM guests on an LTS release no less (and kvm is > pushed by Ubuntu as the virtualisation system to use) it presents a > reasonably serious problem. > > How did this get straight to release with no testing in proposed? > > What is the point of having proposed for bug testing if a released > package never goes through it - especially for something as critically > important to the core system as the kernel? > > Hopefully the issue can be fixed soon so those of us who use KVM on > Lucid are able to use the latest kernel with any bug fixes again.. > > As it is anyone with this issue cannot get a fix from Ubuntu as a > vendor for the following CVE's as they are part of the update that > broke kvm: > > CVE-2010-0419 > CVE-2010-1162 > CVE-2010-1488 > CVE-2010-1148 > CVE-2010-1146 > CVE-2009-4537 > > And if they don't have the savvy (or are unwilling to run a 'proposed' > kernel) to obtain the 2.6.32-22.33 kernel directly from the launchpad > build page they will also be missing updates for launchpad bugs 526354 > and 567016. > > Any thoughts on this issue? > > Regards, > > James >
As stated on https://wiki.ubuntu.com/KernelTeam/KernelUpdates: * Security updates will be uploaded directly into -security without other changes. This just requires a temporary GIT fork which will be immediately merged back into the main branch for that stable release. * Normal updates will be provided as pre-releases through the kernel-ppa users PPA. At certain points those get made into proposed releases which are uploaded to the proposed pocket. Then again they have to get verified to fix the problems and not to cause regressions. As far as I know, this applies to most security updates, skipping the - -proposed step Whether or not this policy is a good one, is a matter of discussion, since it obviously failed this one. Would more testing, which would mean a slower procedure for getting the security fixes through, be a viable compromise in some cases? What kind of testing is already in place by the security team? Could that be expanded? - - arand -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwIHE4ACgkQ67RiDgo9GiNR8QCghLwEDutw3x6i3YhxWJHlLrx4 xf0Anjle/R4uciiMfMGOfylk/AJZ2E8O =ImT2 -----END PGP SIGNATURE----- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
