Skip to main content
Unix & Linux

Return to Answer

added 172 characters in body
Source Link
frostschutz
frostschutz
  • 52.1k
  • 7
  • 129
  • 179

There is no fixed default value for sector size in cryptsetup. It uses either 512 or 4096, auto-detected at cryptsetup luksFormat time, recorded in the LUKS header, as shown by luksDump.

Once LUKS is set to use 4096 byte sectors, you have to provide a device multiple of 4096 bytes large (regardless of physical/logical sector size), or it will be rejected altogether. This is quite unfortunate but dm-crypt simply refuses to operate on a backing device of the wrong size, this should also be the reason why --device-size does not help.

This can be a problem when resizing partitions incorrectly, but in your case it seems you didn't use a partition table at all. So there is nothing to resize and creating a partition table would instead corrupt your LUKS header (happens sooner or later, if you don't use partitions).

Another common issue is with USB enclosures or other specialty controllers. Sometimes they cut off a couple of sectors to store their own metadata, or emulate different sector sizes or the like.

So the drive is not passed through properly, resulting in minor discrepancies, sometimes with major effects. In that case, going back to whatever enclosure or controller you were previously using might resolve the issue.

As a workaround, you can try to emulate the aligned device size with a loop device (readonly for testing).

For this simple workaround, any data in the last partial 4K sector will be missing (size is rounded down to align, not up). If the missing data is important, you could only use a linear device mapper to attach a few extra bytes.

Of course, if you have the storage space to spare, you could do it all with an image file instead.

# luksdev=/dev/sdx
# size=$(blockdev --getsize64 "${luksdev}")
# alignsize=$(((size/4096)*4096))
# losetup --find --show --read-only --sector-size 4096 --sizelimit "${alignsize}" "${luksdev}"
/dev/loop9
# cryptsetup open --readonly /dev/loop9 crypttest

If that works, you should backup everything, then set it up again properly with partitions. If you really don't want partitions and need a more permanent solution, you might be able to convert to 512 byte sectors using cryptsetup reencrypt. You'd no longer need the loop device once the conversion is finished. However, converting data in-place always carries some risks. Data loss is possible.

There is no fixed default value for sector size in cryptsetup. It uses either 512 or 4096, auto-detected at cryptsetup luksFormat time, recorded in the LUKS header, as shown by luksDump.

Once LUKS is set to use 4096 byte sectors, you have to provide a device multiple of 4096 bytes large (regardless of physical/logical sector size), or it will be rejected altogether.

This can be a problem when resizing partitions incorrectly, but in your case it seems you didn't use a partition table at all. So there is nothing to resize and creating a partition table would instead corrupt your LUKS header (happens sooner or later, if you don't use partitions).

Another common issue is with USB enclosures or other specialty controllers. Sometimes they cut off a couple of sectors to store their own metadata, or emulate different sector sizes or the like.

So the drive is not passed through properly, resulting in minor discrepancies, sometimes with major effects. In that case, going back to whatever enclosure or controller you were previously using might resolve the issue.

As a workaround, you can try to emulate the aligned device size with a loop device (readonly for testing).

For this simple workaround, any data in the last partial 4K sector will be missing (size is rounded down to align, not up). If the missing data is important, you could only use a linear device mapper to attach a few extra bytes.

Of course, if you have the storage space to spare, you could do it all with an image file instead.

# luksdev=/dev/sdx
# size=$(blockdev --getsize64 "${luksdev}")
# alignsize=$(((size/4096)*4096))
# losetup --find --show --read-only --sector-size 4096 --sizelimit "${alignsize}" "${luksdev}"
/dev/loop9
# cryptsetup open --readonly /dev/loop9 crypttest

If that works, you should backup everything, then set it up again properly with partitions. If you really don't want partitions and need a more permanent solution, you might be able to convert to 512 byte sectors using cryptsetup reencrypt. You'd no longer need the loop device once the conversion is finished. However, converting data in-place always carries some risks. Data loss is possible.

There is no fixed default value for sector size in cryptsetup. It uses either 512 or 4096, auto-detected at cryptsetup luksFormat time, recorded in the LUKS header, as shown by luksDump.

Once LUKS is set to use 4096 byte sectors, you have to provide a device multiple of 4096 bytes large (regardless of physical/logical sector size), or it will be rejected altogether. This is quite unfortunate but dm-crypt simply refuses to operate on a backing device of the wrong size, this should also be the reason why --device-size does not help.

This can be a problem when resizing partitions incorrectly, but in your case it seems you didn't use a partition table at all. So there is nothing to resize and creating a partition table would instead corrupt your LUKS header (happens sooner or later, if you don't use partitions).

Another common issue is with USB enclosures or other specialty controllers. Sometimes they cut off a couple of sectors to store their own metadata, or emulate different sector sizes or the like.

So the drive is not passed through properly, resulting in minor discrepancies, sometimes with major effects. In that case, going back to whatever enclosure or controller you were previously using might resolve the issue.

As a workaround, you can try to emulate the aligned device size with a loop device (readonly for testing).

For this simple workaround, any data in the last partial 4K sector will be missing (size is rounded down to align, not up). If the missing data is important, you could only use a linear device mapper to attach a few extra bytes.

Of course, if you have the storage space to spare, you could do it all with an image file instead.

# luksdev=/dev/sdx
# size=$(blockdev --getsize64 "${luksdev}")
# alignsize=$(((size/4096)*4096))
# losetup --find --show --read-only --sector-size 4096 --sizelimit "${alignsize}" "${luksdev}"
/dev/loop9
# cryptsetup open --readonly /dev/loop9 crypttest

If that works, you should backup everything, then set it up again properly with partitions. If you really don't want partitions and need a more permanent solution, you might be able to convert to 512 byte sectors using cryptsetup reencrypt. You'd no longer need the loop device once the conversion is finished. However, converting data in-place always carries some risks. Data loss is possible.

Source Link
frostschutz
frostschutz
  • 52.1k
  • 7
  • 129
  • 179

There is no fixed default value for sector size in cryptsetup. It uses either 512 or 4096, auto-detected at cryptsetup luksFormat time, recorded in the LUKS header, as shown by luksDump.

Once LUKS is set to use 4096 byte sectors, you have to provide a device multiple of 4096 bytes large (regardless of physical/logical sector size), or it will be rejected altogether.

This can be a problem when resizing partitions incorrectly, but in your case it seems you didn't use a partition table at all. So there is nothing to resize and creating a partition table would instead corrupt your LUKS header (happens sooner or later, if you don't use partitions).

Another common issue is with USB enclosures or other specialty controllers. Sometimes they cut off a couple of sectors to store their own metadata, or emulate different sector sizes or the like.

So the drive is not passed through properly, resulting in minor discrepancies, sometimes with major effects. In that case, going back to whatever enclosure or controller you were previously using might resolve the issue.

As a workaround, you can try to emulate the aligned device size with a loop device (readonly for testing).

For this simple workaround, any data in the last partial 4K sector will be missing (size is rounded down to align, not up). If the missing data is important, you could only use a linear device mapper to attach a few extra bytes.

Of course, if you have the storage space to spare, you could do it all with an image file instead.

# luksdev=/dev/sdx
# size=$(blockdev --getsize64 "${luksdev}")
# alignsize=$(((size/4096)*4096))
# losetup --find --show --read-only --sector-size 4096 --sizelimit "${alignsize}" "${luksdev}"
/dev/loop9
# cryptsetup open --readonly /dev/loop9 crypttest

If that works, you should backup everything, then set it up again properly with partitions. If you really don't want partitions and need a more permanent solution, you might be able to convert to 512 byte sectors using cryptsetup reencrypt. You'd no longer need the loop device once the conversion is finished. However, converting data in-place always carries some risks. Data loss is possible.