cryptsetup: Cannot wipe header on device

5,151

Solution 1

One fellow solved this (or very similar) error by manually writing zeros to the first few megs of the target partition with a line similar to this:

 dd if=/dev/zero of=[target] bs=1M count=2

Or if it's just an overwriting FS problem, then wipefs might work instead of / with the above.

Also, another used the "--debug" option with cryptsetup to get more information, it's worth a try first.


The "Update II" info tests use /dev/sdb1 and then /dev/sdb, not sure it would make a difference though.

Another guy here says "I've had floppies, thumb drives and hard drives have 'sector 0' issues that were all fixed by going into a Linux Live CD and wiping the first hundred sectors or so with dd if=/dev/zero of=/dev/hdN bs=1024 count=1024 "

This bug report comment about another external USB hard drive and a "end_request: critical target error, dev sdb, sector 0" seems to say Ubuntu 12.04 worked while 14.04 didn't. Others say it's probably a bad or inadequate USB power supply or failing hardware (enclosure, wires, hard drive)

So mixed results & advice. I've not had the best luck with USB enclosures either, I'd be inclined to try a different enclosure or a direct to desktop/esata cable connection.

Solution 2

I'm aware that this question is very old, but I was looking for a solution for the same error message, "Cannot wipe header on device", and found a solution that is not listed here: if the cryptsetup luksFormat output also includes the following:

WARNING: Data offset is outside of currently available data device.

then the partition is too small.

You're most likely to run into this if you are creating a partition that is meant to just contain a key file to encrypt other partitions.

It appears that with cryptsetup 2.1.0, the LUKS header takes up just under 16MiB (see below for details), so the partition size must 16MiB + the size of the key you want to store in it (3MiB, say).

For illustration, with an 8MiB partition, I saw the following error:

$ sudo cryptsetup luksFormat ${/dev/keypartition} --debug
[...]
# Formatting LUKS2 with JSON metadata area 12288 bytes and keyslots area 16744448 bytes.
[...]
WARNING: Data offset is outside of currently available data device.
Device wipe error, offset 8388608.
Cannot wipe header on device /dev/sda2.

Note that 12288 bytes + 16744448 bytes = 15.98 MiB.

With the size of /dev/sda2 increased to 19MiB, I successfully set it up as a LUKS partition.

Note: cryptsetup luksFormat also worked with dev/sda2 at 16MiB, but a subsequent cryptsetup luksOpen failed with

Requested offset is beyond real size of device /dev/sda2.

Increasing /dev/sda2 further to 32MiB fixed this issue, but when I tried to use the partition as a key file, cryptsetup luksFormat --key-file=/dev/mapper/<mountpoint of /dev/sda2> <device to encrypt> failed with

Maximum keyfile size exceeded.

There are two solutions to this: (1) set the size of the partition containing to key to 16MiB + key file size ensuring that the key file size is less than the maximum; (2) use the --keyfile-size option so cryptsetup luksFormat only uses some part of the key file.

Share:
5,151

Related videos on Youtube

Luís de Sousa
Author by

Luís de Sousa

Member of the PyWPS Project Steering Committee; Charter Member of the OSGeo Foundation. Unix/Linux user since 1996. Experiencing Ubuntu since 2007, using it as main OS at home and office since 2009. Check my projects at Codeberg. More about what I do is in my personal web site. Follow me at Mastodon.

Updated on September 18, 2022

Comments

  • Luís de Sousa
    Luís de Sousa over 1 year

    I am trying to encrypt an external hard drive on Ubuntu 14.04 followig this guide. I started by formatting to ext4:

    $ sudo mkfs.ext4 /dev/sde1
    mke2fs 1.42.9 (4-Feb-2014)
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    9773056 inodes, 39072470 blocks
    1953623 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=4294967296
    1193 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872
    
    Allocating group tables: done                            
    Writing inode tables: done                            
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done     
    

    And then proceeded with the initialisation, but it returns this error:

    $ sudo cryptsetup -y -v luksFormat /dev/sde1
    
    WARNING!
    ========
    This will overwrite data on /dev/sde1 irrevocably.
    
    Are you sure? (Type uppercase yes): YES
    Enter passphrase: 
    Verify passphrase: 
    Cannot wipe header on device /dev/sde1.
    Command failed with code 5: Cannot wipe header on device /dev/sde1.
    

    So far I could not anything useful on the web regarding this error. Any ideas on what may be wrong?

    Update I: answering the questions posed by Xen2050. I ran bablocks in write mode prior to formatting and no errors were reported.

    I tried the ecryption again, paying more attention to systems messages. Here is the dmesg output right after connecting the drive:

    $ dmesg
    [ 3208.032228] usb 2-1.4: new high-speed USB device number 7 using ehci-pci
    [ 3208.140990] usb 2-1.4: New USB device found, idVendor=059f, idProduct=0651
    [ 3208.141001] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 3208.141024] usb 2-1.4: Product: LaCie Hard Drive USB
    [ 3208.141031] usb 2-1.4: Manufacturer: LaCie
    [ 3208.141037] usb 2-1.4: SerialNumber: 10000E000BD8A671
    [ 3208.177576] usb-storage 2-1.4:1.0: USB Mass Storage device detected
    [ 3208.178112] scsi4 : usb-storage 2-1.4:1.0
    [ 3208.178183] usbcore: registered new interface driver usb-storage
    [ 3209.176917] scsi 4:0:0:0: Direct-Access     SEAGATE  ST3160812A       3.AA PQ: 0 ANSI: 2
    [ 3209.177561] sd 4:0:0:0: Attached scsi generic sg2 type 0
    [ 3209.181342] sd 4:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB)
    [ 3209.182337] sd 4:0:0:0: [sdb] Write Protect is off
    [ 3209.182348] sd 4:0:0:0: [sdb] Mode Sense: 53 00 00 08
    [ 3209.183339] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [ 3209.201618]  sdb: sdb1
    [ 3209.229465] sd 4:0:0:0: [sdb] Attached SCSI disk
    

    Then verified it is not mounted:

    $ findmnt /dev/sdb
    $ findmnt /dev/sdb1
    $
    

    Another try at initialisation:

    $ sudo cryptsetup -y -v luksFormat /dev/sdb1
    
    WARNING!
    ========
    This will overwrite data on /dev/sdb1 irrevocably.
    
    Are you sure? (Type uppercase yes): YES
    Enter passphrase: 
    Verify passphrase: 
    Cannot wipe header on device /dev/sdb1.
    Command failed with code 5: Cannot wipe header on device /dev/sdb1.
    

    Two new lines show up in the log:

    $ tail /var/log/syslog
    Dec  8 09:18:20 MekanikDestruktiwKommandoh kernel: [ 3698.016311] end_request: critical target error, dev sdb, sector 0
    Dec  8 09:18:28 MekanikDestruktiwKommandoh wpa_supplicant[1188]: wlan0: CTRL-EVENT-SCAN-STARTED 
    

    Something seems going wrong with sector 0, but not at all clear what.

    Update II: Trying the new suggestions by Xen2050. First writing zeros to sector 0:

    $ sudo dd if=/dev/zero of=/dev/sdb1 bs=1M count=10
    10+0 records in
    10+0 records out
    10485760 bytes (10 MB) copied, 0.564427 s, 18.6 MB/s
    

    After this the cryptsetup initialisation still fails. wipefs returns a strange warning:

    $ sudo wipefs -a /dev/sdb
    wipefs: WARNING: /dev/sdb: appears to contain 'dos' partition table
    

    And apparently does nothing. Then ran cryptsetup with the debug flag; it printed out a bunch of new stuff, but does not give more information regarding the error:

    $ sudo cryptsetup --debug -y -v luksFormat /dev/sdb
    # cryptsetup 1.6.1 processing "cryptsetup --debug -y -v luksFormat /dev/sdb"
    # Running command luksFormat.
    # Locking memory.
    # Installing SIGINT/SIGTERM handler.
    # Unblocking interruption on signal.
    
    WARNING!
    ========
    This will overwrite data on /dev/sdb irrevocably.
    
    Are you sure? (Type uppercase yes): YES
    # Allocating crypt device /dev/sdb context.
    # Trying to open and read device /dev/sdb.
    # Initialising device-mapper backend library.
    # Timeout set to 0 miliseconds.
    # Iteration time set to 1000 miliseconds.
    # Interactive passphrase entry requested.
    Enter passphrase: 
    Verify passphrase: 
    # Formatting device /dev/sdb as type LUKS1.
    # Crypto backend (gcrypt 1.5.3) initialized.
    # Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes.
    # Generating LUKS header version 1 using hash sha1, aes, xts-plain64, MK 32 bytes
    # Crypto backend (gcrypt 1.5.3) initialized.
    # KDF pbkdf2, hash sha1: 356173 iterations per second.
    # Data offset 4096, UUID 5fa9c58f-b047-4c9e-a6e8-26a9a433a438, digest iterations 43375
    Cannot wipe header on device /dev/sdb.
    # Releasing crypt device /dev/sdb context.
    # Releasing device-mapper backend.
    # Unlocking memory.
    Command failed with code 5: Cannot wipe header on device /dev/sdb.
    
    • Xen2050
      Xen2050 over 8 years
      That's an onion in the ointment... any more descriptive messages in /var/log/syslog? /dev/sde1 isn't mounted while trying to luksFormat it? Maybe cryptsetup doesn't want to overwrite a mounted in-use partition... And it's still a "healthy" writeable drive? And the format to ext4 step should be after the luksFormat, but I think cryptsetup should be able to overwrite anything anyway, so that shouldn't stop it...
    • Xen2050
      Xen2050 over 8 years
      How strange, badblocks writes ok, mkfs.ext4 writes ok, but cryptsetup fails trying to write to sector 0... maybe a cryptsetup bug, I wonder if sdb1 contains a sector 0, or if it's trying to write to the very start of sdb (actually I'm not sure if drives start at sector 1 or 0, writing to a non-existing sector sounds like a critical error...) (No access to a regular browser now or I'd google that sector 0 error + cryptsetup)