I/O error booting when using Intrepid kernel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
I dist-upgraded to Intrepid from Hardy, but now I cannot boot using the Intrepid kernel (2.6.27-6-generic). Reiserfs reports an unreadable block and kicks me to a root shell. Dmesg reports errors of the following kind (full file attached):
[ 23.807828] Buffer I/O error on device sda5, logical block 67360508
[ 23.807892] attempt to access beyond end of device
[ 23.807895] sda: rw=0, want=156296315, limit=153774180
. . .
The block that reiserfs reports is bad is block 16840127, and indeed running the following command fails and produces more dmesg errors:
dd if=/dev/sda5 of=/root/block bs=4096 count=1 skip=16840127
But the above command (as well as booting in general) works fine using the Hardy kernels.
Here is fdisk -l output:
Disk /dev/sda: 78.7 GB, 78732380160 bytes
255 heads, 63 sectors/track, 9572 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xe686f016
Device Boot Start End Blocks Id System
/dev/sda1 1 1216 9767488+ 83 Linux
/dev/sda2 1281 9729 67866592+ f W95 Ext'd (LBA)
/dev/sda4 * 1217 1280 514080 b W95 FAT32
/dev/sda5 1344 9729 67360545 83 Linux
/dev/sda6 1281 1343 505984+ 82 Linux swap / Solaris
And here is my fstab file:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=3415ef48-
# /dev/sda4
UUID=4464-0805 /dos vfat defaults,
# /dev/sda5
UUID=aa668c2e-
# /dev/sda6
UUID=9b024922-
/dev/scd0 /media/cdrom0 iso9660,udf user,noauto 0 0
#none /debug debugfs defaults 0 0
And the dmesg log will be attached. I will also momentarily post the reiser fsck log.
Changed in linux (Ubuntu): | |
status: | New → Won't Fix |
Gah, this appears to be an hpa issue. This is a Dell laptop that used to have one of those "MediaDirect" partitions once upon a time.
With the hardy kernel, /sys/module/ libata/ parameters/ ignore_ hpa is 1. But with the intrepid kernel, /sys/module/ libata/ parameters/ ignore_ hpa is 0, so apparently handling of hpa has changed here. (This was originally a Breezy install, so ignoring hpa must go a long way back...)
I used a tool called MHDD (ran it in FreeDOS) to remove the hpa from the drive. For posterity, once you're in the program, select the disk giving you issues. Then type the nhpa command.
Although I've fixed this in my personal circumstance, my solution may be considered "cheating," so I will let someone more knowledgeable decide whether to close this bug or not.