FYI, I've just filed this against the kernel: http://bugzilla.redhat.com/486997 Perhaps it should be reassigned to e2fsprogs... --------- Normally I track rawhide pretty closely, but for the last few weeks new kernels haven't booted on the system I use for that, so I stuck with the most recent one that worked, 2.6.29-0.74.rc3.git3.fc11.x86_64 However, now that there are 4 newer kernel images, none of which boots, it's getting a little precarious, and I investigated. Note: this is the first that failed to boot: 2.6.29-0.99.rc4.git1.fc11.x86_64 The most recent, 2.6.29-0.131.rc5.git2.fc11.x86_64 also fails the same way, with a segfault from init/nash. The traceback I saw had (from memory, sorry) glibc's strlen ... libblkid's blkid_verify blkid_get_dev nash... I found that I could boot into any of the recent kernels, only if I'd either disconnect /dev/hdb physically, or if I had erased its partition table. I did save a copy. The partitions on /dev/hdb were of type ext4 and ext3: Here's what parted said before I reformatted the xfs partition as ext4, just to be sure xfs wasn't implicated: Model: ATA SAMSUNG HD501LJ (scsi) Disk /dev/sdb: 976773168s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32s 390625279s 390625248s primary ext3 boot 2 390625280s 488282111s 97656832s primary ext3 3 488282112s 625000447s 136718336s extended 5 488282144s 585938943s 97656800s logical xfs 6 585938976s 625000447s 39061472s logical If you need more detail, I'll be happy to help, but it may take me a week or so. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
