Announcement

Collapse
No announcement yet.

Fsck error on sdb

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Fsck error on sdb

    hey, I'm hoping someone can assist me. I tried cloning my ssd drive to another one. The transfer seems to have gone ok but now when i boot i''m getting an initrams prompt. I read somewhere that fsck might be the solution to my little predicament I tried rebooting using the clonezilla usb drive but after doing that i could not locate fsck. I have kali linux downloaded, that gives me the lsblk and fsck commands. So i tried running fsck but i get this error.

    ─$ sudo fsck /dev/sdb
    fsck from util-linux 2.40.2
    fsck: fsck.iso9660 not found; ignore /dev/sdb​
    Is there any way around this?

    #2
    There's not enough details to offer advice.

    What are you booting to? The cloned drive? Did the cloning go OK without errors or warnings?

    The error message you gave returned "fsck.iso9660 not found". Seems to me you didn't do the cloning correctly. iso9660 is a read-only format for CDROMs not an SSD clone. I suspect you cloned using device-image rather than device-device.

    I would redo the cloning again and carefully choose the correct options.
    Last edited by oshunluvr; Dec 09, 2024, 04:16 PM.

    Please Read Me

    Comment


      #3
      Originally posted by TheYikes View Post
      I tried cloning my ssd drive to another one.
      Were both drives left connected after the cloning? If so, read on.

      Cloning copies all the UUIDs, which Linux and grub use to tell drives apart (at least, by default on debian-derived distros). If you boot from either, without addressing the no longer unique UUIDs, the OS and grub get confused, and grub being confused is a typical reason for getting the initramfs prompt.

      So, I think running fsck is not what you want, unless you have another reason to suspect corruption.

      I suggest booting with one of the drives disconnected, to avoid the confusion. If the purpose is to move to a new, possibly bigger or faster, drive, then removing the old would be good. Then, after a reboot, you can wipe the old drive to reuse it, or set new UUIDs on its partitions (KDE Partition Manager doesn't do that; gparted does, or one can use the tool for the filesystem, such as tune2fs for ext4, or mlabel for VFAT).

      IMO cloning drives is overrated, and comes from the Windows world where the OS resists being copied. I usually prefer to recreate partitions and copy the data using rsync with appropriate options, with care. It can be much faster, if the drive isn't nearly full. To boot from the copies I still have to fix the UUID references in grub and /etc/fstab. After the copy one can run sudo update-grub (with the OS prober enabled) to fix grub, and fixing the /etc/fstab is straightforward, especially if it is changed to using labels (after applying unique labels to the partitions with the partition manager).
      Regards, John Little

      Comment

      Working...
      X