Hi,
I ran into this issue, too, and I think I know why, so here are some
hints for anyone also encountering messages like this in
/var/log/kern.log:
device-mapper: table: 254:18: loop0 too small for target: start=98304,
len=3604480, dev_size=3702783
… while kpartx bails out on the commandline as follows:
add map loop0p1 (254:17): 0 88472 linear 7:0 8192
device-mapper: resume ioctl on loop0p2 failed: Invalid argument
create/reload failed on loop0p2
On Sun, Aug 09, 2015 at 03:06:23PM +0530, Ritesh Raj Sarraf wrote:
> Since it is not certain from this bug report that the problem is with
> kpartx, especially given that it works find for both of us with other
> images, I'm closing this bug report.
>From my point of view the only issue in here is that the error
messages given by both, kpartx as well as device-mapper, are not
really telling the real cause of the issue.
> If you are able to reproduce this issue persistently, please re-open.
I can. Just copy a not yet resized Raspbian image from an SD card onto
your disk and use "dd bs=512
count=<end-of-second-partition-as-reported-by-fdisk>".
In my case this was:
# fdisk -l /dev/sdf
Disk /dev/sdf: 29.8 GiB, 32010928128 bytes, 62521344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x22734fac
Device Boot Start End Sectors Size Id Type
/dev/sdf1 8192 96663 88472 43.2M c W95 FAT32 (LBA)
/dev/sdf2 98304 3702783 3604480 1.7G 83 Linux
# dd if=/dev/sdf bs=512 count=3702783 of=raspi.img status=progress
1887552000 bytes (1.9 GB, 1.8 GiB) copied, 22.0006 s, 85.8 MB/s
3702783+0 records in
3702783+0 records out
1895824896 bytes (1.9 GB, 1.8 GiB) copied, 22.17 s, 85.5 MB/s
# fdisk -l raspi.img
Disk raspi.img: 1.8 GiB, 1895824896 bytes, 3702783 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x22734fac
Looks fine so far, doesn't it?
But then:
# kpartx -a -v -f raspi.img
add map loop0p1 (254:17): 0 88472 linear 7:0 8192
device-mapper: resume ioctl on loop0p2 failed: Invalid argument
create/reload failed on loop0p2
… and the well-known message cited above in /var/log/kern.log:
Dec 6 16:04:18 somehost kernel: [1378621.747689] device-mapper: table: 254:18:
loop0 too small for target: start=98304, len=3604480, dev_size=3702783
The confusing part is that it claims /dev/loop0 is too small as that's
the device on my disk and not the disk image.
Using "gdisk" instead of "fdisk" revealed the cause:
# gdisk -l raspi.img
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Warning! Secondary partition table overlaps the last partition by
34 blocks!
You will need to delete this partition or resize it in another utility.
Disk raspi.img: 3702783 sectors, 1.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): C87070BD-B64D-437B-BCE9-8805FDD1B473
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3702749
Partitions will be aligned on 2048-sector boundaries
Total free space is 9798 sectors (4.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 96663 43.2 MiB 0700 Microsoft basic data
2 98304 3702783 1.7 GiB 8300 Linux filesystem
Please note especially these two lines in the output:
* Warning! Secondary partition table overlaps the last partition by 34 blocks!
* First usable sector is 34, last usable sector is 3702749
Is it a coincidence that both warnings say something about "34 blocks"?
Probably not.
So what primarily helped was redoing the dd with a count which is 34
higher than before:
# dd if=/dev/sdf bs=512 count=3702817 of=raspi.img status=progress
1894236672 bytes (1.9 GB, 1.8 GiB) copied, 22.0001 s, 86.1 MB/s
3702817+0 records in
3702817+0 records out
1895842304 bytes (1.9 GB, 1.8 GiB) copied, 22.7419 s, 83.4 MB/s
# kpartx -a -v raspi.img
add map loop0p1 (254:17): 0 88472 linear 7:0 8192
device-mapper: resume ioctl on loop0p2 failed: Invalid argument
create/reload failed on loop0p2
Now WTF? And kern.log still has the same error message:
Dec 6 16:11:19 somehost kernel: [1379043.324604] device-mapper: table: 254:18:
loop0 too small for target: start=98304, len=3604480, dev_size=3702783
Even with same numbers. So kpartx didn't seem to have cleaned up again
after this failure. So I first had to remove the (incomplete/failed)
mappings again before being able to continue:
# kpartx -d -v raspi.img
del devmap : loop0p1
loop deleted : /dev/loop0
# kpartx -a -v raspi.img
add map loop0p1 (254:17): 0 88472 linear 7:0 8192
add map loop0p2 (254:18): 0 3604480 linear 7:0 98304
So the conclusion is: This is no bug in kpartx. Sole cause was the
broken disk image. (Hence not reopening, just adding additional
information and hints on potential causes.) Just the error messages
could have been a little bit more helpful.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
