Hello.
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 :)
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/2221850cae78d8b6eab1bbcf02ae3...@neutralite.org
