First problem is: [ 8.090730] shure kernel: EXT4-fs (dm-0): unable to read superblock [ 8.090784] shure mount[471]: mount: /sysroot: can't read superblock on /dev/mapper/fedora_shure-root. Therefore sysroot can't mount. The reason it can't read it is really bad luck: [ 10.481731] shure kernel: sd 0:0:0:0: [sda] tag#14 Add. Sense: Unrecovered read error - auto reallocate failed [ 10.481735] shure kernel: sd 0:0:0:0: [sda] tag#14 CDB: Read(10) 28 00 1d 6a 30 06 00 00 01 00 An unrecoverable read error due to a bad sector, and (drive firmware) ECC can't reconstruct it. [ 10.481737] shure kernel: print_req_error: 9 callbacks suppressed [ 10.481740] shure kernel: blk_update_request: I/O error, dev sda, sector 493498374 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 10.481757] shure kernel: ata1: EH complete And that is the bad sector LBA as reported by the drive itself to the kernel, which coincides with this superblock, apparently. It's vaguely possible an fsck of the root file system will fix this, more likely it fails due to the I/O error. ext4 has more than one super block so it should be able to reconstruct from the others, but perhaps only if you can get rid of the I/O error first. My highly speculative and cautious suggestion is you could write zeros to just this LBA, thereby getting rid of the I/O error (the drive firmware will overwrite the sector and it'll either succeed or fail, if it fails it will remap the LBA to a reserve sector). How do do this depends on whether the drive has 512 byte or 4096 byte physical sectors. If it's 4KiB physical, you have to write 4KiB worth of zeros. But the LBA is based on 512 byte addresses so you have to do an adjustment. If you write just a 512 byte sector, the drive firmware actually *reads* first in order to do read-modify-write of that 4096 byte physical sector, and you'll just get a read error again. Super hilarious that you can do a write and get a read error returned, but that's why. Once that LBA is zeros instead of an IO error, then e2fsck can almost certainly fix it. But I have to couch in in a warning because... I don't know with 100% certainty. Someone else on this list might have a better idea or you could review the strategy on the ext4 list. Now, if this were Btrfs it too would fail to mount if the primary super block is bad or returns an IO error. I'm likewise not certain if any of the repair tools will easily deal with this with just a repair request, due to the I/O error. That might just stop the repair and has to be dealt with first. In the Btrfs case the number of superblocks depends on the size of the file system, 2 if it's at least 256MB, and 3 if it's at least 256G. There is a super recover specific command that can fix this problem, but again probably only once the uncorrectable read error is fixed by overwriting the bad sector. And yes that should sound a bit scary because people make mistakes with dd all the time. I have for sure. The way I remember not to screw up is skip has an i, therefore it applies to if= so when you're doing your sector read test based on 4KiB block size, you use skip, but when you reverse it to write to that sector you have to use seek= otherwise you're gonna overwrite the wrong thing and ... oopsie! And there are more ways to screw it up that this... I've forgotten to set count= before and end up writing megabytes of zeros before I CTRL-C. That was pretty funny. Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
