Comment 4 for bug 1055547

Got today again the same problem on another system, same workaround fixed it:

120928 04:48:05 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-file="/etc/my.cnf" --defaults-group="mysqld" --prepare --target-dir=/var/lib/mysql

xtrabackup_55 version 2.0.1 for Percona Server 5.5.16 Linux (x86_64) (revision id: 446)
xtrabackup: cd to /var/lib/mysql
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(7820822299761)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:128M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2097152
120928 4:48:05 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
120928 4:48:05 InnoDB: The InnoDB memory heap is disabled
120928 4:48:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120928 4:48:05 InnoDB: Compressed tables use zlib 1.2.3
120928 4:48:05 InnoDB: Using Linux native AIO
120928 4:48:05 InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
120928 4:48:05 InnoDB: Initializing buffer pool, size = 100.0M
120928 4:48:05 InnoDB: Completed initialization of buffer pool
120928 4:48:05 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 7820822299761
120928 4:48:05 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 7820822363128 (3 %)
120928 4:48:05 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 56157731, file name /var/lib/mysql/mysql-bin.000773
120928 4:48:06 InnoDB: Waiting for the background threads to start
120928 4:48:07 Percona XtraDB (http://www.percona.com) 1.1.8-20.1 started; log sequence number 7820822363128

[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 56157731, file name /var/lib/mysql/mysql-bin.000773

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120928 4:48:14 InnoDB: Starting shutdown...
120928 4:48:16 InnoDB: Shutdown completed; log sequence number 7820822363128
InnoDB: Error: tried to read 2048 bytes at offset 0 0.
InnoDB: Was only able to read 0.
120928 4:48:16 InnoDB: Operating system error number 22 in a file operation.
InnoDB: Error number 22 means 'Invalid argument'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
innobackupex: Error:
innobackupex: ibbackup failed at /usr//bin/innobackupex line 374.