On Sun, Sep 27, 2026 at 11:58:58AM -0400, Gary Dale wrote: > Thanks Andy, but from what I've read, it's simpler to use e2fsck to check > for bad blocks. It turns out that the issue had nothing to do with bad > blocks at all.
I don't know what more I could have tried to explain this, but there still seems to be confusion here. *ANY* filesystem-related tool is the wrong tool to use on a partition that doesn't have that filesystem on it. I would have thought that would be obvious. Your statement that "this had nothing to do with bad blocks" has also not been proven (or disproven) by any of this. I have asked about three times now for things to be done that would prove it either way, and I'm tired of doing that, so it's good that you have it working now. > When I tried e2fsck, which I wouldn't expect to see a valid > ext file system, Yeah! > it pointed to the real problem: > > # e2fsck /dev/sda1 -L /root/badblocks.text > e2fsck 1.47.2 (1-Jan-2025) > ext2fs_open2: Bad magic number in super-block > e2fsck: Superblock invalid, trying backup blocks... > e2fsck: Bad magic number in super-block while trying to open /dev/sda1 How you can say this is "the real problem" when you asked e2fsck to read an ext filesystem off of something that ISN'T an ext filesystem is beyond me. Of COURSE it reported not being able to do so! The only thing shown here is that sda1 isn't an ext filesystem! You do understand that md array members have metadata areas that prevent them being used directly as filesystem,s even if they are simple mirrors, right? The current default metadata format for md is v1.2 which starts the array data 1MiB in to the device, so if you tried to read it directly as an ext filesystem that would fail as the first MiB is not what the tool would expect - even if there WAS a valid ext filesystem on that partition when it was in an MD mirror. > So I ran mkfs -t ext4 /dev/sda1. When it finished, I was able to add the > partition back in. The array is currently rebuilding. So you wrote over many of the sectors of the HDD that correspond to sda1 and now things work. Which is not contradictory to my hypothesis that one or more of those sectors was bad and that writing to it/them would force the HDD to remap. We now can't prove it though. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting > The optimum programming team size is 1. Has Jurassic Park taught us nothing? — pfilandr
