[arch-dev-public] [signoff] kernel26 2.6.28.1-1
Hi guys, new kernel adresses the following things: - bump to latest version - fixed bugs: http://bugs.archlinux.org/task/12821 http://bugs.archlinux.org/task/12816 http://bugs.archlinux.org/task/12820 please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Sonntag 18 Januar 2009 21:25:35 schrieb Tobias Powalowski:
please signoff for both arches
signed-off for both. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Tobias Powalowski schrieb:
Hi guys, new kernel adresses the following things: - bump to latest version - fixed bugs: http://bugs.archlinux.org/task/12821 http://bugs.archlinux.org/task/12816 http://bugs.archlinux.org/task/12820
Since 2.6.28, hci_usb fails after resume for me. Can we use btusb instead of hci_usb? I hear it is feature-complete and stable now, and hci_usb will be removed in 2.6.29.
Did not worked here (x86_64 with ext4) I was getting a "Invalid or Unsupported executable format" on Grub. 2.6.28 worked fine. -- Hugo
On Mon, Jan 19, 2009 at 7:19 AM, Hugo Doria
Did not worked here (x86_64 with ext4)
I was getting a "Invalid or Unsupported executable format" on Grub. 2.6.28 worked fine.
Is /boot ext4 now, and did the kernel image get written with extents? lsattr /boot- If you see lower-case 'e', the file was written in extents format. My guess is the previous kernel was not written to disk this way. -Dan
(2.6.28.1) # md5sum /boot/vmlinuz26 6c96af7941680c91ecb25926a949d88a /boot/vmlinuz26 # lsattr /boot -------------e- /boot/System.map26 --------------- /boot/kernel26.img -------------e- /boot/vmlinuz26 --------------- /boot/grub --------------- /boot/kernel26-fallback.img (2.6.28) # lsattr /boot -------------e- /boot/System.map26 --------------- /boot/kernel26.img -------------e- /boot/vmlinuz26 --------------- /boot/grub --------------- /boot/kernel26-fallback.img I am on 2.6.28 right now. Oh! My /boot is not a separated partition on this machine. And, yes, my / is ext4.
(sorry for the double post) kernel26 2.6.28.1 is running fine here now. So here goes my signoff for x86_64. I think the problem was related with a bad download (or something like this). Thomas had a different md5sum for /boot/vmlinuz26 than mine. rm /var/cache/pacman/pkg/kernel26-2.6.28.1-1-x86_64.pkg.tar.gz pacman -Sy testing/kernel26 again solved the problem. The correct md5sum is the one i sent in the last email: # m5sum /boot/vmlinuz26 6c96af7941680c91ecb25926a949d88a /boot/vmlinuz26 -- Hugo
On Mon, Jan 19, 2009 at 2:58 PM, Hugo Doria
(sorry for the double post)
kernel26 2.6.28.1 is running fine here now. So here goes my signoff for x86_64.
I think the problem was related with a bad download (or something like this). Thomas had a different md5sum for /boot/vmlinuz26 than mine.
rm /var/cache/pacman/pkg/kernel26-2.6.28.1-1-x86_64.pkg.tar.gz pacman -Sy testing/kernel26 again solved the problem.
The correct md5sum is the one i sent in the last email:
# m5sum /boot/vmlinuz26 6c96af7941680c91ecb25926a949d88a /boot/vmlinuz26
Shouldn't pacman md5 check catch bad download? The md5 of kernel26-2.6.28.1-1-x86_64.pkg.tar.gz is normally stored in the database, and pacman normally checks this after a download.
Xavier schrieb:
Shouldn't pacman md5 check catch bad download? The md5 of kernel26-2.6.28.1-1-x86_64.pkg.tar.gz is normally stored in the database, and pacman normally checks this after a download.
This could only have happened due to some corruption during extraction! Sounds weird, but these things happen occasionally.
On Mon, Jan 19, 2009 at 8:34 AM, Thomas Bächler
Xavier schrieb:
Shouldn't pacman md5 check catch bad download? The md5 of kernel26-2.6.28.1-1-x86_64.pkg.tar.gz is normally stored in the database, and pacman normally checks this after a download.
This could only have happened due to some corruption during extraction! Sounds weird, but these things happen occasionally.
Yeah I would put it on extraction corruption if in fact the md5sum download check didn't alert you to any errors. It's a shame you didn't hold onto that old package file though... You don't have any bad sectors on your HDD, do you? -Dan
participants (7)
-
Dan McGee
-
Eduardo Romero
-
Hugo Doria
-
Pierre Schmitz
-
Thomas Bächler
-
Tobias Powalowski
-
Xavier