From: nntp.mbourne@spamgourmet.com   
      
   Jonathan N. Little wrote:   
   > Situation: Server uses to mirrored drives to save backup data. One drive   
   > was throwing bad sectors. Dreaded 3TB Constellation drives so replaced   
   > with 4TB IronWolf. After transferring 2.2TB data from the one good drive   
   > to the two new drives installed drives in server. Server would only boot   
   > into emergency mode. In emergency mode a manual mount command would   
   > mount the two drives  and you can exit to regular login.   
   >   
   > Diagnosis: Replacing the new drives triggered fsck upon boot, but   
   > systemd.fsck@dev-disk-by...service failed for each new drive. UUIDs were   
   > correctly updated in fstab. Went and tried manually fsck drives and   
   > e2fsck failed with incompatible version.   
   >   
   > Conclusion: (Or the DOH-Moment) That server is still running 18.04 LTS   
   > and I formatted the new drives with a usb drive dock and I am running   
   > 23.04! The files are currently accessible and writable so I temporarily   
   > disabled fsck for those two drives. In a live 18.04 session formatted up   
   > a new drive with correct version. Luckily I have a 3rd spare drive to   
   > expedite this. Have another system coping files from old good drive to   
   > this new drive so it can latter be swapped to the server and repeat the   
   > processes for the other drive...Just have to get it done before Sunday   
   > when the backup occurs.   
   >   
   > Penalty: Humiliation and time. Just passing on the info and maybe save   
   > someone else of the same mistake.   
   >   
   > BTW: have not found what they did to change the format of ext4 from the   
   > different versions OS. Both drives were gpt and same format. One would   
   > think that would not matter...   
      
   It is surprising that something that significant would have changed in   
   the formatting.  Perhaps the older fsck is just being cautious, and   
   refusing to try fixing a partition formatted with a newer version of   
   ext4, which might use features the older fsck doesn't know about.  And   
   then the rest of the system refuses to mount it because fsck failed.   
      
   However, a couple of years ago I did have an issue with a couple of   
   disks that I'd been using with a USB-SATA adapter, which then couldn't   
   be read when attached directly to the PC's SATA bus.  It turns out that   
   some USB-SATA adapters misreport the logical block size used by the disk   
   (seems to be an issue with a commonly used chipset).  When I attached a   
   disk to the USB adapter and formatted it, the adapter reported 4096 byte   
   logical blocks.  So the GPT partition table was placed at block 1, 4096   
   bytes into the disk, and partition addresses given in 4096 byte blocks.   
   But when I attached the disk directly to the PC's SATA bus, it reported   
   512 byte logical blocks.  The partition table couldn't be found at block   
   1 (now 512 bytes into the disk) and, even if could have been found, the   
   partition addresses would all have been misinterpreted.   
      
   Some relevant information I came across while trying to figure this one out:   
      
      
      
      
   That doesn't seem like the same issue you had, since your problems were   
   with fsck, so in your case it sounds like the partitions were read   
   correctly and the filesystem was found.   
      
   --   
   Mark.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)