[arch-general] [signoff] kernel 2.6.36.1-3
Hi guys, please signoff 2.6.36 series for both arches, Latest and greatest moved to testing, including most patches from the stable queue of 2.6.36.2. In 2.6.36.1-3 the usb issues are fixed. Please signoff for both arches that we can move everything soon. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - Tomoyo support: https://bugs.archlinux.org/task/21533 - Apparmor support: https://bugs.archlinux.org/task/21533 - Build RTC support into kernel: https://bugs.archlinux.org/task/21137 - changed cpu support to 64 on x86_64 - added hugetables support: https://bugs.archlinux.org/task/20862 - disabled RDS modules due to security concerns: https://bugs.archlinux.org/task/21510 - pcieaspm enabled greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 2010/11/24 Tobias Powalowski <t.powa@gmx.de> wrote:
Hi guys, please signoff 2.6.36 series for both arches, Latest and greatest moved to testing, including most patches from the stable queue of 2.6.36.2. In 2.6.36.1-3 the usb issues are fixed.
Please signoff for both arches that we can move everything soon.
Signoff both (booted normally). -- Rémy.
On 11/24/2010 09:19 AM, Tobias Powalowski wrote:
Hi guys, please signoff 2.6.36 series for both arches, Latest and greatest moved to testing, including most patches from the stable queue of 2.6.36.2. In 2.6.36.1-3 the usb issues are fixed.
sign off x86_64 -- Ionuț
On 11/24/2010 01:19 AM, Tobias Powalowski wrote:
Hi guys, please signoff 2.6.36 series for both arches, Latest and greatest moved to testing, including most patches from the stable queue of 2.6.36.2. In 2.6.36.1-3 the usb issues are fixed.
Please signoff for both arches that we can move everything soon.
Upstream changes: http://kernelnewbies.org/LinuxChanges
Features included: - Tomoyo support: https://bugs.archlinux.org/task/21533
- Apparmor support: https://bugs.archlinux.org/task/21533
- Build RTC support into kernel: https://bugs.archlinux.org/task/21137
- changed cpu support to 64 on x86_64
- added hugetables support: https://bugs.archlinux.org/task/20862
- disabled RDS modules due to security concerns: https://bugs.archlinux.org/task/21510
- pcieaspm enabled
greetings tpowa
Tobias, You'da Man! kernel26 2.6.36.1-3 boot FINE on that whacky MSI based box. I don't know if you know what changed, but if so, I'm dying to find out. After running it by the Redhat dmraid (dm-devel) list, the kernel.org list, all I got back were the ideas I passed on here, but no real answers.... I updated my primary box (Tyan based with nv dmraid) that had shown the the weird drive initialization that caused the random read/write head excursions that happened if the box didn't boot just right -- and it booted perfectly, first try with kernel26 2.6.36.1-3. So I decided to give the MSI based box a try. It too -- booted just fine! So thanks and -- Happy Thanksgiving to the list! 18:35 archangel:~> pmq kernel26 kernel26 2.6.36.1-3 18:35 archangel:~> cat /proc/partitions major minor #blocks name 8 16 732574584 sdb 8 32 488386584 sdc 8 48 732574584 sdd 8 64 1465138584 sde 8 65 1 sde1 8 69 1465136128 sde5 8 80 1465138584 sdf 8 81 1 sdf1 8 85 1465136128 sdf5 8 0 488386584 sda 254 0 488386583 dm-0 254 1 732574583 dm-1 254 2 72229 dm-2 254 3 2104483 dm-3 254 4 20972826 dm-4 254 5 465234336 dm-5 254 6 19534977 dm-6 254 7 120456 dm-7 254 8 39062016 dm-8 254 9 1951866 dm-9 254 10 15358108 dm-10 254 11 30716248 dm-11 254 12 7510356 dm-12 254 13 618317721 dm-13 -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Thu, 2010-11-25 at 18:36 -0600, David C. Rankin wrote:
Tobias,
You'da Man! kernel26 2.6.36.1-3 boot FINE on that whacky MSI based box. I don't know if you know what changed, but if so, I'm dying to find out. After running it by the Redhat dmraid (dm-devel) list, the kernel.org list, all I got back were the ideas I passed on here, but no real answers....
I updated my primary box (Tyan based with nv dmraid) that had shown the the weird drive initialization that caused the random read/write head excursions that happened if the box didn't boot just right -- and it booted perfectly, first try with kernel26 2.6.36.1-3. So I decided to give the MSI based box a try. It too -- booted just fine!
For that boot problem, you really should try grub2 instead of grub. Last week we had a bug on the bugtracker that looked like your bug, but with a regular installation with / on ext4. Grub couldn't boot it with the same error message as you're facing now and then. After switching to grub2, things worked fine. I think grub is bugged somehow with its ext3/ext4 drivers, causing issues like yours. With your current grub installation, every kernel update could result in a surprise.
On Fri, Nov 26, 2010 at 4:29 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2010-11-25 at 18:36 -0600, David C. Rankin wrote:
Tobias,
You'da Man! kernel26 2.6.36.1-3 boot FINE on that whacky MSI based box. I don't know if you know what changed, but if so, I'm dying to find out. After running it by the Redhat dmraid (dm-devel) list, the kernel.org list, all I got back were the ideas I passed on here, but no real answers....
I updated my primary box (Tyan based with nv dmraid) that had shown the the weird drive initialization that caused the random read/write head excursions that happened if the box didn't boot just right -- and it booted perfectly, first try with kernel26 2.6.36.1-3. So I decided to give the MSI based box a try. It too -- booted just fine!
For that boot problem, you really should try grub2 instead of grub. Last week we had a bug on the bugtracker that looked like your bug, but with a regular installation with / on ext4. Grub couldn't boot it with the same error message as you're facing now and then. After switching to grub2, things worked fine. I think grub is bugged somehow with its ext3/ext4 drivers, causing issues like yours. With your current grub installation, every kernel update could result in a surprise.
could also try extlinux -- i have several systems using it with nothing but success, and it's slightly less daunting than grub2 (not to mention cool stuff like btrfs support... that's about to lead to _managed_ KERNEL rollbacks under Archlinux in < 48hrs... *cough* hint... :-) C Anthony
On Sat, Nov 27, 2010 at 12:30 AM, C Anthony Risinger <anthony@extof.me> wrote:
(not to mention cool stuff like btrfs support... that's about to lead to _managed_ KERNEL rollbacks under Archlinux in < 48hrs... *cough* hint... :-)
well once again i've been defeated... i thought i found a clever way to support kernel rollbacks by "peeking" into subvolumes for a kernel to boot... and due to a 1/1000 chance my tests *seemed* to confirm this. 6 hrs in... how was i to know that at the syslinux level snapshots are recursive loops back to the root? and i had identical structure at both levels, giving the appearance of a successful rollback? and COW had not caused the kernel images to disappear *yet*? ugh, when they say "no subvolume support" i guess they mean it :-) sorry to those who noticed this premature allusion, and to everyone else, sorry for the noise. C Anthony
participants (6)
-
C Anthony Risinger
-
David C. Rankin
-
Ionuț Bîru
-
Jan de Groot
-
Rémy Oudompheng
-
Tobias Powalowski