device-mapper: table: 253:2: dm-0 too small for target

dmmorgan · 01-17-2021, 11:39 AM

Greetings,

I inherited responsibility for an old linux box with an Intel Rapid Storage Technology RAID 1. / was full up, one drive had failed, other problems. Long story short, replaced the failed drive, added a new drive, and installed Mint-20 on the new drive.

My intention is to recover RAID, and use as /home. Current RAID status in BIOS is Rebuild.

Problem:
Output from dmesg:

[ 0.672643] device-mapper: uevent: version 1.0.3
[ 0.672777] device-mapper: ioctl: 4.41.0-ioctl (2019-09-16) initialised: dm-devel@redhat.com
[ 26.493728] device-mapper: table: 253:2: dm-0 too small for target: start=1026048, len=7813003264, dev_size=3519064328
[ 26.493730] device-mapper: core: Cannot calculate initial queue limits
[ 26.493740] device-mapper: ioctl: unable to set up device queue for new table.
[ 73.977965] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[ 76.386882] device-mapper: table: 253:2: dm-0 too small for target: start=1026048, len=7813003264, dev_size=3519064328
[ 76.386884] device-mapper: core: Cannot calculate initial queue limits
[ 76.386887] device-mapper: ioctl: unable to set up device queue for new table.

First, I don't really understand what this means. Second, I'm at a complete loss on how to proceed. Help?

Thanks,
Dave

computersavvy · 01-17-2021, 08:48 PM

Quote:

Originally Posted by dmmorgan

Greetings,

I inherited responsibility for an old linux box with an Intel Rapid Storage Technology RAID 1. / was full up, one drive had failed, other problems. Long story short, replaced the failed drive, added a new drive, and installed Mint-20 on the new drive.

My intention is to recover RAID, and use as /home. Current RAID status in BIOS is Rebuild.

Problem:
Output from dmesg:

[ 0.672643] device-mapper: uevent: version 1.0.3
[ 0.672777] device-mapper: ioctl: 4.41.0-ioctl (2019-09-16) initialised: dm-devel@redhat.com
[ 26.493728] device-mapper: table: 253:2: dm-0 too small for target: start=1026048, len=7813003264, dev_size=3519064328
[ 26.493730] device-mapper: core: Cannot calculate initial queue limits
[ 26.493740] device-mapper: ioctl: unable to set up device queue for new table.
[ 73.977965] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[ 76.386882] device-mapper: table: 253:2: dm-0 too small for target: start=1026048, len=7813003264, dev_size=3519064328
[ 76.386884] device-mapper: core: Cannot calculate initial queue limits
[ 76.386887] device-mapper: ioctl: unable to set up device queue for new table.

First, I don't really understand what this means. Second, I'm at a complete loss on how to proceed. Help?

Thanks,
Dave

1. When you installed the new drive it HAD TO BE at least as large as the other drive in the raid1 array in order to work. It also should not be significantly larger. Matching drive sizes is best.
2. If this is a raid array built by mdadm what is the status of the array in /proc/mdstat?

If the rebuild is not complete you really should wait for that to complete before you start using it.

Could you post the output of

Code:

cat /proc/mdstat
cat /etc/mdadm/mdadm.conf
sudo fdisk -l

dmmorgan · 01-18-2021, 02:45 PM

Thanks for this reply.
Yes, the replacement hard drive is the same size as the one it replaces, and the other member of the array.

Output of cat /proc/mdstat:
Personalities :
unused devices: <none>

Output of cat /etc/mdadm/mdadm.conf:
cat: /etc/mdadm/mdadm.conf: No such file or directory

Output of sudo fdisk -l:

Code:

The backup GPT table is not on the end of the device. This problem will be corrected by write.
Disk /dev/sda: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD4003FZEX-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 367D876B-7508-4BF6-A4C7-450D2FA41965

Device       Start        End    Sectors  Size Type
/dev/sda1     2048    1026047    1024000  500M EFI System
/dev/sda2  1026048 7814029311 7813003264  3.7T Linux LVM

The backup GPT table is corrupt, but the primary appears OK, so that will be used.
The backup GPT table is not on the end of the device. This problem will be corrected by write.

Code:

Disk /dev/sdb: 3.65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD4003FZEX-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 367D876B-7508-4BF6-A4C7-450D2FA41965

Device       Start        End    Sectors  Size Type
/dev/sdb1     2048    1026047    1024000  500M EFI System
/dev/sdb2  1026048 7814029311 7813003264  3.7T Linux LVM

Disk /dev/sdc: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: ST8000NM0055-1RM
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 615CF338-98C6-4841-BD52-C3F3C8E8EC46

Device          Start         End     Sectors  Size Type
/dev/sdc1        2048     3905535     3903488  1.9G Linux filesystem
/dev/sdc2     3905536  4003905535  4000000000  1.9T Linux filesystem
/dev/sdc3  4003905536 15628052479 11624146944  5.4T Linux filesystem


Disk /dev/mapper/isw_ebjegieaeg_Volume0: 1.65 TiB, 1801760935936 bytes, 3519064328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device                               Boot Start        End    Sectors Size Id Type
/dev/mapper/isw_ebjegieaeg_Volume0p1          1 4294967295 4294967295   2T ee GPT

Partition 1 does not start on physical sector boundary.

/dev/sda and /dev/sdb are the RAID disks to be rebuilt; /dev/hdc houses the Mint 20 OS.

On replacing the failed /dev/sdb with a new device, the Intel Rapid Storage Technology BIOS correctly identified the replacement disk as the one to add to the RAID, and switched from "Degraded" to "Rebuild" with the message "rebuild will continue in the OS." This clearly has not taken place.

Thanks - Dave

Quote:

Originally Posted by computersavvy

1. When you installed the new drive it HAD TO BE at least as large as the other drive in the raid1 array in order to work. It also should not be significantly larger. Matching drive sizes is best.
2. If this is a raid array built by mdadm what is the status of the array in /proc/mdstat?

If the rebuild is not complete you really should wait for that to complete before you start using it.

Could you post the output of

Code:

cat /proc/mdstat
cat /etc/mdadm/mdadm.conf
sudo fdisk -l

computersavvy · 01-19-2021, 07:15 AM

So that is bios controlled raid. I cannot help with that, except to say that rebuilding a 4 TB raid can take days and the PC has to be powered on full time for that to complete.

You posted an error with the backup gpt table. I wonder if that is a factor in the error.

My gut feeling is that you should backup the data on the raid, wipe out and create the array new, then restore the data.