# [solved] udevd-work[810]: ressize 4096 too short

## ueymir

Hey,

I updated my system after many months of inactivity, only to stumble across some udev troubles.

There was the issue with pata/sata/scsi that messed up the system, which should have been solved. When successfully booting into the new kernel, though, I get no less than 22 new messages from udevd-work:

```
udevd-work[810]: ressize 4096 too short
```

How can I find out more about that or even solve those (error)-messages? The system seems to be working fine. I may be blind but neither the forum nor google gave me a clue on where to look.

What I did prior to that was updating gcc from 4.3.4 to 4.4.4, emerge -e system and world, installing kernel 2.6.36-gentoo-r5 (previous was 2.6.27-gentoo-r10) and updating my initrd to deal with the change in harddrive naming. I am using grub to load my initrd to decrypt three encypted partitions to /dev/mapper/xyz, if that should matter.

Any help is welcome! ThanksLast edited by ueymir on Thu Jan 13, 2011 4:38 pm; edited 1 time in total

----------

## ueymir

Solved it while getting undervolting to work: there was a not-yet-updated module (phc_intel) that seemed to have caused this. I removed it and am still in the process of patching the kernel, but the messages dissapeared.

Sorry for the trouble.

----------

## doublehp

I have the same message; it's not related to SATA in my case, but with luks/raid.

I did not find yet the exact reason of it (still searching), but it happens after doing luksopen. I have 2 arrays of partitions; after luks, one provides raid0 for swap, the second provides a set of blocks that are partitionned. For the second array, after luckopen, i have to bind the /dev/mapper/foo<n> blocks to /dev/loop<n>, so that the loop manager discovers the partition table, and creates the set of /dev/loop<n>p<m> . I have a warning message by losetup saying that the blocks are very small, and may not be usable. But I don't know if losetup is talking about input blocks (that are generated by luksopen), or the output base blocks, or the discovered partitions.

When building this setup, I started by doing things manually; I always had the losetup warning. I have the udev message only since configuring this stuff in /etc at boot time. Same command after boot is quite; commands during boot are verbose.

This message could be critical for me; my arrays are very large, not only in volume, but also in number of sub partitions. When doing things at boot time, the discovery of some partitions fail; some /dev/loop<n>p<m> are either not created, or, their content is not usable (udev does not detect properly that they contain partitions, so, does not provide them to ... the stuff that should handle them). In the end, when i do things at boot time, the stuff globally fails.

To illustrate: after boot, blkid will always show all loop partitions correctly, but, lsblk will not show the content of some partitions. Example:

```
|-loop65p118                      7:16758  0    50G  0 loop  

| `-md85                          9:85     0   150G  0 raid6 

|   `-Big_2014-Big_2014 (dm-10) 252:10     0     7T  0 lvm   /mnt/Big_2014

|-loop65p119                      7:16759  0    50G  0 loop  

| `-md92                          9:92     0   150G  0 raid6 

|   `-Big_2014-Big_2014 (dm-10) 252:10     0     7T  0 lvm   /mnt/Big_2014

|-loop65p120                      7:16760  0    50G  0 loop  

|-loop65p121                      7:16761  0    50G  0 loop  

| `-md102                         9:102    0   150G  0 raid6 

|   `-Big_2014-Big_2014 (dm-10) 252:10     0     7T  0 lvm   /mnt/Big_2014

|-loop65p122                      7:16762  0    50G  0 loop  

| `-md100                         9:100    0   150G  0 raid6 

|   `-Big_2014-Big_2014 (dm-10) 252:10     0     7T  0 lvm   /mnt/Big_2014

|-loop65p123                      7:16763  0    50G  0 loop  

| `-md106                         9:106    0   150G  0 raid6 

|   `-Big_2014-Big_2014 (dm-10) 252:10     0     7T  0 lvm   /mnt/Big_2014
```

loop65p119 is found, and blkid (which seems to perfom immediate full scan) does says it contains a raid stuff, but lsblk (which seem to rely on /dev/ and /proc) says it does not contain anything. Then, one raid element is missing, one raid array fails ... and so on ...

----------

