[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

udev memory problem when trying to plug a disk with corrupted partition table


I think most of my problem's description is in title, but here are some more informations.

I have a hard disk on which I tried a... quite unusual... procedure to install another OS. My try in this procedure [1] did not went well at all, but it's not the subject of this mail. Now, fact is that the hard-disk partition table is no longer correct, and when I plug it (it is an USB HD) into a Debian system, it makes udev eating all my memory, and more. The only way for me to have a chance to work with that drive plugged is to disable swap, because when the system swaps, all CPU is used to access hard-drive, and also to do: _ echo 80 > /proc/sys/vm/overcommit_ratio #honestly, I'm a newbie in kernel stuff, but I think I should use 95% here, that would be more effective, considering that I think I'll use such configuration on all my systems, since most of my tools does not need more than few hundred MiB. _ echo 2 > /proc/sys/vm/overcommit_memory #so, softwares which tries to take too much ram will know it or crash. Udev is crashing, I guess.

I think that udev crashes, instead of simply acknowledging that it can't handle the partitions of the device, because if I then try other operations involving it, they does not work. Also, I have noticed on more recent systems (testing and backported kernel) that I can't even access the device with fdisk after all udev processes died. On current stable kernel, I can (which gave me the hope to be able to use that disk anew, someday).

The symptoms I were able to see, through various means, like reading what is printed on TTY1 when I plug it, or using fdisk on the computer which did not made the hardware disappear when udev crashed, is that a very huge list of partitions is detected, I suspect an infinite loop.

So, does anyone know how to make udev stopping gracefully to detect the full list of partitions, and restrict itself to real hardware? Also, I should probably report that bug, but how could I find more informations to provide, since I strongly doubt that it can be reproduced, and so fixed, without the "correct" partition table?

Fun facts:
_ my BIOS... erm, no, not a BIOS, just a crappy UEFI, is not able to boot when that disk is plugged. I never felt good with that UEFI things, now I think I have some interesting reason. I'll try that on a old computer, just to see if real BIOSes are able to handle damaged logic, but *correct hardware*. _ windows XP is simply not able to see the disk, but it does not dies or eat all RAM. Well, that's a pretty damaged installation of XP anyway, so not really relevant. And this OS is obsolete anyway.

1: for the curious ones, here is what I tried:
create a virtualbox machine
add it a vmdk which were linked to /dev/sdb (yes, sdb, not sdb1, or sdb2: the whole extern disk)
booting the VM on a netBSD's iso
having a very bad feeling when seeing that the extended partition was recognized as unknown filesystem
feeling lucky and continuing
seeing that, finally, I was not lucky :)

Reply to: