[arch-general] [signoff] kernel26 2.6.35.8-1
Upstream update. This package is NOT in testing (2.6.35 currently resides there), but at: http://dev.archlinux.org/~tpowa/kernel26/ please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 10/31/2010 12:55 AM, Tobias Powalowski wrote:
Upstream update. This package is NOT in testing (2.6.35 currently resides there), but at: http://dev.archlinux.org/~tpowa/kernel26/
please signoff for both arches.
greetings tpowa
Tobias, Updated an x86_64 box to 2.6.35.8-1 and the boot hangs at the very start with the following error: Booting 'Arch Linux on Archangel' root (hd1,5) Filesystem type is ext2fs, Partition type 0x83 Kernel /vmlinuz26 root=/dev/mapper/nvidia_baacca_jap5 ro vga=794 Error 24: Attempt to access block outside partition Press any key to continue... This is the same boot problem we have seen with 4 out of 6 of the past new kernel releases. This is the same issue reported in closed bug 20918. It looks like there has been a regression. All of the information in bug 20918 is current for this box. Let me know what else you need and if you want me to reopen the bug report. Thanks. P.S. kernel26-lts-2.6.32.25-2-x86_64 boots just fine as does suse 11. Downgrading to kernel26-2.6.35.7-1-x86_64 fixes the problem, so the issue is with 2.6.35.8-1. -- 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
Am 31.10.2010 22:00, schrieb David C. Rankin:
Updated an x86_64 box to 2.6.35.8-1 and the boot hangs at the very start with the following error:
Booting 'Arch Linux on Archangel'
root (hd1,5) Filesystem type is ext2fs, Partition type 0x83 Kernel /vmlinuz26 root=/dev/mapper/nvidia_baacca_jap5 ro vga=794
Error 24: Attempt to access block outside partition
Press any key to continue...
That's a grub error and has no relation to any kernel update.
On 10/31/2010 04:32 PM, Thomas Bächler wrote:
Am 31.10.2010 22:00, schrieb David C. Rankin:
Updated an x86_64 box to 2.6.35.8-1 and the boot hangs at the very start with the following error:
Booting 'Arch Linux on Archangel'
root (hd1,5) Filesystem type is ext2fs, Partition type 0x83 Kernel /vmlinuz26 root=/dev/mapper/nvidia_baacca_jap5 ro vga=794
Error 24: Attempt to access block outside partition
Press any key to continue... That's a grub error and has no relation to any kernel update.
I know that, but it has something to do with the kernel and/or dmraid because LTS boot just fine with the same menu.lst and kernel kernel26-2.6.35.7-1 boot just fine with the same menu.lst, but upgrading to 2.6.35.8-1 kills the box. While: pacman -U kernel26-2.6.35.7-1-x86_64.pkg.tar.xz kernel26-headers-2.6.35.7-1-x86_64.pkg.tar.xz fixes it. I know it looks like grub, but all kernels except 2.6.35.8-1 work?? -- 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
Am Montag 01 November 2010 schrieb David C. Rankin:
On 10/31/2010 04:32 PM, Thomas Bächler wrote:
Am 31.10.2010 22:00, schrieb David C. Rankin:
Updated an x86_64 box to 2.6.35.8-1 and the boot hangs at the very start with
the following error:
Booting 'Arch Linux on Archangel'
root (hd1,5)
Filesystem type is ext2fs, Partition type 0x83
Kernel /vmlinuz26 root=/dev/mapper/nvidia_baacca_jap5 ro vga=794
Error 24: Attempt to access block outside partition
Press any key to continue...
That's a grub error and has no relation to any kernel update.
I know that, but it has something to do with the kernel and/or dmraid because LTS boot just fine with the same menu.lst and kernel kernel26-2.6.35.7-1 boot just fine with the same menu.lst, but upgrading to 2.6.35.8-1 kills the box. While:
pacman -U kernel26-2.6.35.7-1-x86_64.pkg.tar.xz kernel26-headers-2.6.35.7-1-x86_64.pkg.tar.xz
fixes it.
I know it looks like grub, but all kernels except 2.6.35.8-1 work?? Well i'm not sure what error 24 is, but dmraid can be really complicated. I would recommend you write the dmraid authors from fedora, i'm sure it's a grub vs. dmraid issue which we cannot solve.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Mon, 1 Nov 2010 19:39:18 +0100
schrieb Tobias Powalowski
Am Montag 01 November 2010 schrieb David C. Rankin:
On 10/31/2010 04:32 PM, Thomas Bächler wrote:
Am 31.10.2010 22:00, schrieb David C. Rankin:
Updated an x86_64 box to 2.6.35.8-1 and the boot hangs at the very start with
the following error:
Booting 'Arch Linux on Archangel'
root (hd1,5)
Filesystem type is ext2fs, Partition type 0x83
Kernel /vmlinuz26 root=/dev/mapper/nvidia_baacca_jap5 ro vga=794
Error 24: Attempt to access block outside partition
Press any key to continue...
That's a grub error and has no relation to any kernel update.
I know that, but it has something to do with the kernel and/or dmraid because LTS boot just fine with the same menu.lst and kernel kernel26-2.6.35.7-1 boot just fine with the same menu.lst, but upgrading to 2.6.35.8-1 kills the box. While:
pacman -U kernel26-2.6.35.7-1-x86_64.pkg.tar.xz kernel26-headers-2.6.35.7-1-x86_64.pkg.tar.xz
fixes it.
I know it looks like grub, but all kernels except 2.6.35.8-1 work?? Well i'm not sure what error 24 is, but dmraid can be really complicated. I would recommend you write the dmraid authors from fedora, i'm sure it's a grub vs. dmraid issue which we cannot solve.
This is what the GRUB documentation says about this error: http://www.gnu.org/software/grub/manual/legacy/grub.html#Stage2-errors 24 : Attempt to access block outside partition This error is returned if a linear block address is outside of the disk partition. This generally happens because of a corrupt filesystem on the disk or a bug in the code handling it in GRUB (it's a great debugging tool). Heiko
On 11/01/2010 01:39 PM, Tobias Powalowski wrote:
Well i'm not sure what error 24 is, but dmraid can be really complicated. I would recommend you write the dmraid authors from fedora, i'm sure it's a grub vs. dmraid issue which we cannot solve.
greetings tpowa
Will do and I'll report back. If you look back over the bug report, you will see that this seems to pop up every other kernel or so. In the past, it has always been solved by "try the newer kernel in testing." which has worked most of the time. We'll see what the dmraid devs have to say. This seems to only effect my jmicron controller based box. The other boxes seem OK. So maybe it's a firware dmraid error that gets tripped depending the way the kernel loads the dmraid module?? Who knows... -- 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 11/01/2010 03:22 PM, David C. Rankin wrote:
We'll see what the dmraid devs have to say. This seems to only effect my jmicron controller based box. The other boxes seem OK. So maybe it's a firware dmraid error that gets tripped depending the way the kernel loads the dmraid module?? Who knows...
Just FYI, After upgrading to device-mapper-2.02.75-1 and reinstalling kernel26-2.6.35.8-1, the error has completely changed to: Error 5: Partition table invalid or corrupt Rebooting to LTS boots just fine :-( We will see what the dmraid guys say. -- 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
Am Mon, 01 Nov 2010 15:35:56 -0500
schrieb "David C. Rankin"
On 11/01/2010 03:22 PM, David C. Rankin wrote:
We'll see what the dmraid devs have to say. This seems to only effect my jmicron controller based box. The other boxes seem OK. So maybe it's a firware dmraid error that gets tripped depending the way the kernel loads the dmraid module?? Who knows...
Just FYI,
After upgrading to device-mapper-2.02.75-1 and reinstalling kernel26-2.6.35.8-1, the error has completely changed to:
Error 5: Partition table invalid or corrupt
Rebooting to LTS boots just fine :-( We will see what the dmraid guys say.
Have you made a complete system update with pacman -Syu and particularly updated lvm2 in case you are using this? Heiko
On 11/01/2010 04:01 PM, Heiko Baums wrote:
Have you made a complete system update with pacman -Syu and particularly updated lvm2 in case you are using this?
Heiko
Thanks Heiko, Yes, I've done the complete system update with pacman -Syu. (don't use lvm2, but yes it was updated as well) I've contacted the dm-devel list and I'm waiting on a response. I have another x84_64 box running dmraid and the updates installed fine and it boots. It looks like there is a dmraid issue with the nVidia MCP78S [GeForce 8200] SATA Controller that just gets tripped by some Russian-roulette oddity in the kernel builds -- dunno?? I'll report back if/when I get an answer from the redhat guys. -- 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
Am 01.11.2010 21:35, schrieb David C. Rankin:
On 11/01/2010 03:22 PM, David C. Rankin wrote:
We'll see what the dmraid devs have to say. This seems to only effect my jmicron controller based box. The other boxes seem OK. So maybe it's a firware dmraid error that gets tripped depending the way the kernel loads the dmraid module?? Who knows...
Just FYI,
After upgrading to device-mapper-2.02.75-1 and reinstalling kernel26-2.6.35.8-1, the error has completely changed to:
Error 5: Partition table invalid or corrupt
Rebooting to LTS boots just fine :-( We will see what the dmraid guys say.
These error are semi-random, they probably depend on where the kernel and initramfs files are physically located in the file system. It seems that about every second kernel works for you. Grub (and all other bootloaders for that matter) use BIOS calls to access files on the hard drive - they rely on the BIOS (and in your case, the jmicron dmraid BIOS) for file access. This access seems to fail for certain areas on your file system.
On 11/01/2010 04:56 PM, Thomas Bächler wrote:
These error are semi-random, they probably depend on where the kernel and initramfs files are physically located in the file system. It seems that about every second kernel works for you.
Grub (and all other bootloaders for that matter) use BIOS calls to access files on the hard drive - they rely on the BIOS (and in your case, the jmicron dmraid BIOS) for file access. This access seems to fail for certain areas on your file system.
Thomas, I think you are right. This MSI box runs like greased lightning when it boots, but I think the board/chipset/bios design is weak. I've got the June 2010 bios installed, but it has not been consistent with kernel changes. Hopefully the redhat guys will be able to find out why the controller is having init issues. Thanks for your help and I'll report what I find. -- 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
participants (4)
-
David C. Rankin
-
Heiko Baums
-
Thomas Bächler
-
Tobias Powalowski